On Fri, Jun 21, 2013 at 6:21 PM, Alexander Shiyan <shc_work@xxxxxxx> wrote: >> On Fri, Jun 21, 2013 at 7:17 AM, Alexander Shiyan <shc_work@xxxxxxx> wrote: >> >> On Thu, Jun 20, 2013 at 5:26 PM, Grant Likely <grant.likely@xxxxxxxxxx> wrote: >> >> > On Thu, 20 Jun 2013 16:49:54 -0700, Bryan Wu <cooloney@xxxxxxxxx> wrote: >> >> >> Hi Rob, >> >> >> >> >> >> Is this patch good for merging? >> >> >> >> >> >> In Alex's one patch to add device tree supporting for a leds driver, >> >> >> we got building errors due to miss definitions of some of_xxx api >> >> >> functions. >> >> >> >> >> >> It looks obviously to me that we need to fix this in device tree core >> >> >> instead put #ifdef CONFIG_OF everywhere. >> >> > >> >> > Actually, the reason those things aren't universally defined is to catch >> >> > exactly what it caught. The "leds-mc13783: Add devicetree support" patch >> >> > interleaves DT and non-DT parsing which isn't generally a good idea. The >> >> > DT parsing code should be shuffled off into a separate function and/or >> >> > contained with "if (IS_ENABLED(CONFIG_OF)) {}". >> >> > >> >> >> >> Agree, reasonable! I will remove this patch from my tree firstly. >> >> >> >> Alex, could you please update your patch with Grant's feedback? >> > >> > As far I understand you mean only the last part of patch. Where DT support >> > is introduced. Is not it? >> > >> >> Yes, exactly. I still keep those 2 non-DT related patches in my tree >> and just removed that DT supporting patch. >> >> Please update that patch and posted again to linux-leds and DT >> maintainers as well. > > I am really dont like any #ifdef in the source, but will do if this is only > one way to put this patch into the main tree. You don't need any #ifdefs. Put all the DT-related calls into a separate function specifically for decoding the DT information and wrap the contents with: if (IS_ENABLED(CONFIG_OF)) { } g. -- To unsubscribe from this list: send the line "unsubscribe linux-leds" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html