linux-kernel - Re: [GIT PULL] Backlight for v6.1

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]

Message-ID: <CAHk-=wg=hh8xkPjiySnjAyR66AG64eyZ1Y9gHw+MCs8uuSZReA@mail.gmail.com>
Date:   Fri, 7 Oct 2022 11:45:27 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Lee Jones <lee@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Mark Brown <broonie@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Backlight for v6.1

On Fri, Oct 7, 2022 at 6:16 AM Lee Jones <lee@...nel.org> wrote:
>
> PR satisfying this dependency was submitted the following day:

.. you ignored the whole "another driver hit v6.0 without ever getting
the dependency".

So this whole thing with "dead driver because the config option it
depended on didn't even exist" wasn't some little temporary thing.
It's literally there in a released kernel, which has a whole driver in
it that cannot actually even be enabled.

And now that I *did* get the MFD update, I notice that the build
coverage of *that* is pitiful too.

In particular, there was a silent semantic conflict in the Crystal
Cove (intel PMIC) driver with the i2c changes. I noticed it because
there were other things going on, and I went and looked.

But most notably I *didn't* notice it due to any build coverage,
because the Kconfig for that thing seems designed to hide the driver.
It does have

        depends on (X86 && ACPI) || COMPILE_TEST

so that it *looks* like it should get compile test coverage even
outside of x86, but in reality,  even on x86 it's actually really hard
to test, because it also has

        depends on I2C_DESIGNWARE_PLATFORM=y

so if you do a regular "allmodconfig" build, that driver doesn't
actually get any build testing at all, because while that platform is
indeed enabled, it's only a module.

So I caught this particular issue, but I really think that code that
cannot be enabled at all even for build testing - or code that is
quite hard to enable either intentionally or by mistake - is a
problem. And right now MFD was involved in both of the issues I've
noticed this merge window.

That's not a great look.

                Linus