linux-kernel - Re: [PATCH] CHROMIUM: i2c: Add device property for probing

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:   Mon, 20 Dec 2021 13:49:10 -0800
From:   Dmitry Torokhov <dtor@...omium.org>
To:     Paul Menzel <pmenzel@...gen.mpg.de>
Cc:     Wolfram Sang <wsa@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Furquan Shaikh <furquan@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Tim Wawrzynczak <twawrzynczak@...omium.org>,
        coreboot@...eboot.org, Matt DeVillier <matt.devillier@...il.com>,
        Felix Singer <felixsinger@...teo.net>,
        Duncan Laurie <dlaurie@...omium.org>,
        Benson Leung <bleung@...omium.org>,
        Furquan Shaikh <furquan@...omium.org>,
        Justin TerAvest <teravest@...omium.org>,
        Guenter Roeck <groeck@...omium.org>, linux-i2c@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org
Subject: Re: [PATCH] CHROMIUM: i2c: Add device property for probing

Hi Paul,

On Mon, Dec 20, 2021 at 1:07 PM Paul Menzel <pmenzel@...gen.mpg.de> wrote:
>
> From: Furquan Shaikh <furquan@...gle.com>
>
> Dear Linux folks,
>
>
> Google Chromebooks are often built with devices sourced from different
> vendors. These need to be probed. To deal with this, the firmware – in
> this case coreboot – tags such optional devices accordingly – I think
> this is commit fbf2c79b (drivers/i2c/generic: Add config for marking
> device as probed) – and Chromium OS’ Linux kernel has the patch at hand
> applied to act accordingly. Right after the merge, Dmitry created a
> revert, which was actively discussed for two days but wasn’t applied.
> That means, millions of devices shipped with such a firmware and Linux
> kernel. To support these devices with upstream Linux kernel, is there an
> alternative to applying the patch to the Linux kernel, and to support
> the shipped devices?

*sigh* I should have pushed harder, but I see it managed to
proliferate even into our newer kernels. Not having this patch should
not cause any problems, it can only hurt, because the i2c core has no
idea how to power up and reset the device properly. The only downside
of not having this patch is that we may have devices in sysfs that are
not connected to actual hardware. They do now cause any problems and
is how we have been shipping ARM-based devices where we also dual- and
triple-source components. However if we were to have a device that
switches between several addresses (let's say device in bootloader
mode uses 0x10 address and in normal mode 0x20) this "probing" may
result in device not being detected at all.

If we wanted to do this correctly, coreboot would have to implement
full power and reset control and also add drivers for I2C controllers
to be able to communicate with peripherals, and then adjust _STA
methods to report "not present" when the device is indeed absent. And
note that even in this case we would have issues with "morphing
devices", so coreboot would also need to know how to reset device out
of bootloader mode, and maybe flash firmware so device can work in
normal mode.

However coreboot does (or did?) not want to add code to handle i2c
controllers, and would like to push this knowledge to the kernel. And
the kernel does know how to handle peripherals properly, but that
knowledge lies in individual drivers, not i2c core.

We should remove "linux,probed" from coreboot and not propagate to
newer Chrome OS kernels, and keep it away from upstream.

Thanks,
Dmitry