On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > On Tue, 17 Dec 2019, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > On Tue, Dec 17, 2019 at 1:56 PM Steven Price <steven.price@xxxxxxx> wrote: > > I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/. > > It fixes issue for me. > > As discussed off-line, this will allow silently building and linking a > configuration that's actually broken. (No backlight support despite > expectations.) In my case I have deliberately compile backlight as a module to be used exclusively with backlight-gpio which has nothing to do with i915. I dunno if backlight is a MUST dependency for i915. >From my perspective the original commit, with all good that it provides, should not break previously working configurations. Though we might argue if my "working" kernel configuration had been broken in the first place... Just my 2 cents, though. > IMO deep down the problem is that we "select" BACKLIGHT_CLASS_DEVICE all > over the place, while we should "depends on" it. Everything else is just > duct tape that allows configurations where built-in code calls backlight > symbols in modules. It used to be more about an interaction with ACPI, > now we've added DRM_PANEL to the mix. > > I've proposed a fix five years ago [1]. That's what it takes to fix > these recurring failures for good. I'm not really all that interested in > the whack-a-mole with the hacks. Agree with this. The root cause must be fixed once and for all. I guess it should be a logical continuation of Sam's series. > [1] http://lore.kernel.org/r/1413580403-16225-1-git-send-email-jani.nikula@xxxxxxxxx -- With Best Regards, Andy Shevchenko
