[PATCH v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

[Daniel Thompson]

On 03/10/17 09:03, Daniel Vetter wrote:
> On Mon, Oct 02, 2017 at 12:00:54PM +0300, Jani Nikula wrote:
>> On Mon, 02 Oct 2017, Daniel Thompson <daniel.thompson at linaro.org> wrote:
>>> So I'm coming to this patchset cold but can you explain *why* something
>>> wants to call of_find_backlight_by_node() when there is no backlight
>>> support enabled. Why isn't the code that called is conditional on
>>> BACKLIGHT_CLASS_DEVICE?
>>>
>>> The undefined symbol issue is a pain but to be honest I'd rather solve
>>> the use of undefined symbols by avoiding declaring them; this making
>>> them into compile errors rather than link errors.
>>
>> Typically the kernel header files define static inline stubs of the
>> functions when the actual functions aren't configured/built. The code
>> using the functions looks the same regardless of the config option, and
>> handles the -ENODEV or NULL or whatever returns from the stubs
>> gracefully. With the inlines, the compiler can usually throw out much of
>> the code anyway.
>>
>> In this regard, the backlight interface is an exception, forcing the
>> callers to wrap the code around IS_ENABLED(BACKLIGHT_CLASS_DEVICE), not
>> the rule.
> 
> fwiw, I think it'd be great if we can move backlight over to the common
> pattern, like everyone else. It's pretty big pain as-is ...

For sure, after Jani's mail yesterday I looked at the GMA500 driver and 
concluded I didn't want code related to backlight having to look like that!

Currently the three main patterns of use are:

  1. Standalone drivers simple depend on BACKLIGHT_CLASS_DEVICE,
  2. Some compound drivers select BACKLIGHT_CLASS_DEVICE (the AMD DRM
     driver is an example of this),
  3. Other compound drivers perform heroics with the pre-processor.

The main reason I'm not just agreeing straight away is that, to adopt 
the static inline pattern for the whole API, we have to believe that #3 
above is desirable. Given the size and scope of the compound drivers in 
#3 above, I don't entirely understand why they want to avoid the select.


Daniel.


PS Whatever the outcome here, I do agree 100% that is wrong to prototype
    undefined symbols. That must be changed!