linux-kernel - Re: [PATCH/RFC v4 2/4] regulator: fixed: add regulator

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, 29 Jun 2020 13:57:56 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>
Cc:     "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
        Sudeep Holla <sudeep.holla@....com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "geert+renesas@...der.be" <geert+renesas@...der.be>,
        "magnus.damm@...il.com" <magnus.damm@...il.com>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH/RFC v4 2/4] regulator: fixed: add regulator_ops members
 for suspend/resume

On Mon, Jun 29, 2020 at 02:42:26AM +0000, Yoshihiro Shimoda wrote:
> > From: Mark Brown, Sent: Friday, June 26, 2020 11:39 PM

Copying in Sudeep for the feedback on firmware interfaces.

> > According to the changelog this is all about reflecting changes in the
> > system state done by firmware but there's no interaction with firmware
> > here which means this will be at best fragile.  If we need to reflect
> > changes in firmware configuration I'd expect there to be some
> > interaction with firmware about how it is configured, or at least that
> > the configuration would come from the same source.

> I should have described background of previous patch series though,
> according to previous discussion [1] the firmware side (like PSCI) is
> also fragile unfortunately... So, I thought using regulator-off-in-suspend
> in a regulator was better.

> On other hand, Ulf is talking about either adding a property (perhaps like
> regulator-off-in-suspend) into a regulator or just adding a new property
> into MMC [2]. What do you think about Ulf' comment? I'm thinking
> adding a new property "full-pwr-cycle-in-suspend" is the best solution.
> This is because using a regulator property and reflecting a state of regulator without
> firmware is fragile, as you said.

TBH I worry about a property drifting out of sync with the firmware on
systems where the firmware can be updated.  Personally my default
assumption would always be that we're going to loose power for anything
except the RAM and whatever is needed for wake sources during suspend so
I find the discussion a bit surprising but in any case that seems like a
better option than trying to shoehorn things in the way the series here
did.  Like I said in my earlier replies if this is done through the
regulator API I'd expect it to be via the suspend interface.

> [1]
> https://lore.kernel.org/linux-renesas-soc/CAMuHMdXjU7N4oG89YsozGijMpjgKGN6ezw2qm6FeGX=JyRhsvg@mail.gmail.com/
> 
> [2]
> https://lore.kernel.org/linux-renesas-soc/CAPDyKFpiBU1D+a7zb+Ggm0_HZ+YR4=LXJZ5MPytXtT=uBEdjPA@mail.gmail.com/
> 
> Best regards,
> Yoshihiro Shimoda
> 

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)