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

Message-ID: <8bc59991-53c2-cff1-c63a-07da93a34bf4@redhat.com>
Date:   Thu, 20 Oct 2022 15:53:10 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Randy Dunlap <rdunlap@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Lee Jones <lee@...nel.org>, Mark Brown <broonie@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Backlight for v6.1

Hi,

On 10/20/22 15:48, Andy Shevchenko wrote:
> On Wed, Oct 19, 2022 at 08:31:33PM -0700, Randy Dunlap wrote:
>> On 10/9/22 05:58, Hans de Goede wrote:
>>> On 10/9/22 01:23, Linus Torvalds wrote:
>>>> On Sat, Oct 8, 2022 at 12:59 PM Hans de Goede <hdegoede@...hat.com> wrote:
> 
> ...
> 
>>>> Because if it depends on some symbols from I2C_DESIGNWARE_PLATFORM,
>>>> and that one can be a module, then the Intel PMIC driver also needs to
>>>> be built as a module to just get the build coverage, at least.
>>
>> I don't see intel_soc_pmic_crc.c using any direct calls into
>> i2c-designware-platform code. If it calls into it, it must be thru some
>> indirect pointers (?).
> 
> It's on hardware level, the PMIC is connected to the I²C host controller,
> which is Synopsys DesignWare and being services by the respective driver.
> 
> Any access to the PMIC's registers requires the I²C to be involved.
> What we talked above is even bigger loop, that takes AML code in
> the chain.

Right and the involvement of AML means that we need this all to
work early on during boot, which means that all the bits, including
the I2C controller needs to be builtin. So things will compile fine
without the "depends on I2C_DESIGNWARE_PLATFORM=y" but then things
start breaking at runtime.

After a bunch of bug-reports due to wrong kernel configs I decided to
add the "depends on I2C_DESIGNWARE_PLATFORM=y" and since then we have
received no more bug reports about it. So although technically there
is no dependency on symbols from the i2c-designware driver I would
still very much like to keep the dependency around.

As I already mentioned earlier in the thread adding a
' || COMPILE_TEST' to this is absolutely fine and if I get Cc-ed
on such a patch I'm more then happy to Ack it.

Regards,

Hans