On 13/03/14 10:48, Alexander Shiyan wrote: > Четверг, 13 марта 2014, 10:23 +02:00 от Tomi Valkeinen <tomi.valkeinen@xxxxxx>: >> On 13/03/14 09:31, Alexander Shiyan wrote: >>> Provide dummy functions for LCD register()/unregister() if >>> CONFIG_LCD_CLASS_DEVICE is not set. >> >> Hmm, why do you want to do that? If a driver needs the LCD class, it >> should depend on or select it. > > I inspect my recent changes for the imxfb driver. > I use the LCD class for power management and contrast, nevertheless, > if it lack in the kernel this leads to an error. So is the CONFIG_LCD_CLASS_DEVICE optional for imxfb? It works fine with or without the LCD class support? Is there some reason to run it without LCD class support? > Yes, we can choose the LCD_CLASS_DEVICE symbol for the imxfb driver, > but at the same time we must choose BACKLIGHT_LCD_SUPPORT. > I do not think it's a good way. Why not? > In any case, I would like to revise the patch to use NULL as a result > if there is no support LCD_CLASS_DEVICE in the kernel. Why do you want to run imxfb without LCD_CLASS_DEVICE? Isn't it simpler to just depend on it? > Additionally, I have a plan to convert "menuconfig" entry for > BACKLIGHT_LCD_SUPPORT to the "menu". Hmm. That does make sense, as I don't see BACKLIGHT_LCD_SUPPORT affecting anything, except enabling the BL & LCD Kconfig menu. However, many of the items in BL & LCD menu have, for some reason, "default y" or "default m". So if you make BACKLIGHT_LCD_SUPPORT a menu, it means all those subitems are always enabled. So there definitely will be a side effect to that change. I guess there's legacy reasons why many of the items are enabled by default. It would make sense to me to have BACKLIGHT_LCD_SUPPORT as a menu, as you suggest, and having all the subitems disabled by default. But again, that would change the current behavior, which may or may not cause issues. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
