Messages in this thread | | | From | Stephen Boyd <> | Date | Mon, 21 Mar 2022 19:40:16 +0100 | 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@chromium.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.
| |