linux-kernel - Re: [PATCH v3 0/4] regulator_sync

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 Jul 2020 20:29:13 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Marek Szyprowski <m.szyprowski@...sung.com>,
        John Stultz <john.stultz@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH v3 0/4] regulator_sync_state() support

On Wed, Jul 15, 2020 at 9:20 PM Saravana Kannan <saravanak@...gle.com> wrote:
>
> Consider the following example:
> - regulator-X is provided by device-X.
> - regulator-X is a supplier to device-A, device-B and device-C.
> - device-A is off/inactive from boot.
> - device-B and device-C are left on/active by the bootloader
> - regulator-X is left on boot by the bootloader at 2000 mV to supply
>   device-B and device-C.
>
> Example boot sequence 1:
> 1. device-X is probed successfully.
> 2. device-A is probed by driver-A
>    a. driver-A gets regulator-X
>    b. driver-A votes on regulator-X
>    c. driver-A initializes device-A
>    d. driver-A votes off regulator-X
>    e. regulator-X is turned off.
> 3. System crashes or device-B and device-C become unreliable because
>    regulator-X was turned off without following the proper quiescing
>    steps for device-B and device-C.
>
> Example boot sequence 2:
> 1. device-X is probed successfully.
> 2. device-B is probed by driver-B
>    a. driver-B gets regulator-X
>    b. driver-B votes on regulator-X
>    c. driver-B lowers device-B performance point.
>    d. driver-B lowers voltage vote to 1000 mV.
>    e. regulator-X voltage is lowered to 1000 mV.
> 3. System crashes or device-C becomes unreliable because regulator-X
>    voltage was lowered to 1000 mV when device-C still needed it at 2000 mV

Marek,

I'd appreciate it if you could test this series to see if it fixes
your coupled regulator issue that you reported earlier. I'm expecting
it to fix it without needing any special case handling in your
regulator drivers. But it'll be good to get confirmation from you.

Thanks,
Saravana