Re: [PATCH] lcd: Provide dummy functions if CONFIG_LCD_CLASS_DEVICE is not set

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

On 13/03/14 10:48, Alexander Shiyan wrote:
> Четверг, 13 марта 2014, 10:23 +02:00 от Tomi Valkeinen <tomi.valkeinen@ti.com>:
>> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]