linux-kernel - Re: [PATCH v3 3/3] platform/chrome: cros_ec_spi: Boot fingerprint processor during probe

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: <CAE-0n501URga+ya37zmWjpZLxMO16CfoLeL2-Ui4qZa1PGK3CQ@mail.gmail.com>
Date:   Mon, 21 Mar 2022 19:40:16 +0100
From:   Stephen Boyd <swboyd@...omium.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Benson Leung <bleung@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        chrome-platform@...ts.linux.dev,
        Guenter Roeck <groeck@...omium.org>,
        Craig Hesling <hesling@...omium.org>,
        Tom Hughes <tomhughes@...omium.org>,
        Alexandru M Stan <amstan@...omium.org>,
        Tzung-Bi Shih <tzungbi@...nel.org>,
        Matthias Kaehlcke <mka@...omium.org>
Subject: Re: [PATCH v3 3/3] platform/chrome: cros_ec_spi: Boot fingerprint
 processor during probe

Quoting Stephen Boyd (2022-03-18 16:36:32)
> Quoting Doug Anderson (2022-03-18 15:06:59)
> > On Fri, Mar 18, 2022 at 3:01 PM Stephen Boyd <swboyd@...omium.org> wrote:
> > >
> > > I'd rather not expose regulator control to userspace through some other
> > > sysfs attribute. Instead I'd prefer the flashing logic that twiddles
> > > gpios and power live all in the kernel and have userspace interact with
> > > a character device to program the firmware.
> >
> > Yeah, that would be even better, you're right.
> >
> > Hmmm, so maybe the answer is to just delay adding the regulator until
> > we're actually ready to specify it correctly and have the flashing
> > happen in the kernel?
> >
>
> I can enable it during probe just so that if the BIOS isn't doing it
> we'll have something that works assuming the DT is actually controlling
> the regulator. Or do nothing. It doesn't matter right now.

Thinking about it more there's no point in controlling the supply here
until we support flashing logic in the kernel. Without flashing support
in the kernel and without the BIOS turning on the power we can simply
make the regulator always-on and boot-on with real gpio control and then
it will be turned on during boot, emulating what the BIOS is doing. The
power cycling after flashing the firmware doesn't seem to be necessary
from my testing. And even then, the flashing script could unbind that
regulator driver if it really needed to control the power.