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, 21 Dec 2021 08:47:19 -0800
From:   Guenter Roeck <groeck@...gle.com>
To:     Dmitry Torokhov <dtor@...omium.org>
Cc:     Paul Menzel <pmenzel@...gen.mpg.de>, 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,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE" 
        <devicetree@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-acpi@...r.kernel.org
Subject: Re: [PATCH] CHROMIUM: i2c: Add device property for probing

On Mon, Dec 20, 2021 at 1:49 PM Dmitry Torokhov <dtor@...omium.org> wrote:
>
> 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.
>

Revert from chromeos-5.15 is at
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3350347.
Everyone please feel free to comment there.

Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ