On Tue, 17 Dec 2019, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > 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. It's not a required dependency, all combinations of i915 and backlight are fine, *except* i915=y, backlight=m. This can be achieved with: depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n BR, Jani. > > 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 -- Jani Nikula, Intel Open Source Graphics Center
