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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 17 Dec 2019 17:49:28 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Jani Nikula <jani.nikula@...ux.intel.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, 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.

>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

-- 
With Best Regards,
Andy Shevchenko