linux-kernel - Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 17 Dec 2019 18:06:18 +0200
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Steven Price <steven.price@....com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        intel-gfx <intel-gfx@...ts.freedesktop.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Sam Ravnborg <sam@...nborg.org>,
        Lee Jones <lee.jones@...aro.org>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        Jingoo Han <jingoohan1@...il.com>
Subject: Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)

On Tue, 17 Dec 2019, Andy Shevchenko <andy.shevchenko@...il.com> wrote:
> On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula <jani.nikula@...ux.intel.com> wrote:
>> On Tue, 17 Dec 2019, Andy Shevchenko <andy.shevchenko@...il.com> wrote:
>> > On Tue, Dec 17, 2019 at 1:56 PM Steven Price <steven.price@....com> 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@intel.com

-- 
Jani Nikula, Intel Open Source Graphics Center