linux-kernel - Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

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]

Message-ID: <20210617162428.GG5067@sirena.org.uk>
Date:   Thu, 17 Jun 2021 17:24:28 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Rob Herring <robh@...nel.org>
Cc:     cy_huang <u0084500@...il.com>, lgirdwood@...il.com,
        matthias.bgg@...il.com, gene_chen@...htek.com,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, devicetree@...r.kernel.org,
        cy_huang@...htek.com, gene.chen.richtek@...il.com
Subject: Re: [PATCH 1/2] regulator: mt6360: Add optional
 mediatek.power-off-sequence in bindings document

On Fri, Jun 11, 2021 at 02:16:43PM -0600, Rob Herring wrote:
> On Wed, Jun 02, 2021 at 02:54:34PM +0800, cy_huang wrote:

> > Originally, we think it must write in platform dependent code like as bootloader.
> > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > For the other cases, just follow HW immediate off by default.

> Wouldn't this be handled by PSCI implementation?

Ideally I think...

> > +  mediatek,power-off-sequence:
> > +    description: |
> > +      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
> > +      Cause these regulators are all default-on power. Each value from 0 to 63,
> > +      and step is 1. Each step means 2 millisecond delay.
> > +      Therefore, the power off sequence delay time range is from 0ms to 126ms.
> > +    $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +    minItems: 4
> > +    maxItems: 4

> So this is the delay between BUCK1 and BUCK2, then BUCK2 to LDO7, etcc? 
> If we wanted to express this in DT, we'd made this generic which would 
> need to be more flexible. A poweroff delay in each regulator (similar to 
> the existing power on delay) would be sufficient for what you need I 
> think.

It's not exactly a delay that's being described there - it's a series of
timeslots, each regulator getting assigned to a timeslot.  You could
possibly do a general binding by specifying a delay from the start of
the power off sequence and then (for this device) having the driver work
out a mapping of those times to timeslots.  That feels genericish, you
might also have things like mode changes but it'd cover a lot of the
cases.

On the other hand this is the sort of thing that is often just not
configurable and where people often make weird and inflexible hardware
so things that do implement it are likely to end up wanting to add a
bunch of constraints which might be a lot of hassle.

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