linux-kernel - Re: [PATCH v2 2/8] dt-bindings: arm: apple: Add apple,pmgr binding

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: <c0f2587c-ab69-8194-e618-ce7919c1aeb1@marcan.st>
Date:   Wed, 27 Oct 2021 12:38:31 +0900
From:   Hector Martin <marcan@...can.st>
To:     Rob Herring <robh@...nel.org>
Cc:     linux-arm-kernel@...ts.infradead.org,
        Marc Zyngier <maz@...nel.org>, Arnd Bergmann <arnd@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mark Kettenis <mark.kettenis@...all.nl>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Johan Hovold <johan@...nel.org>, devicetree@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-samsung-soc@...r.kernel.org, linux-serial@...r.kernel.org,
        Mark Kettenis <kettenis@...nbsd.org>
Subject: Re: [PATCH v2 2/8] dt-bindings: arm: apple: Add apple,pmgr binding

On 27/10/2021 03.25, Rob Herring wrote:
> On Mon, Oct 25, 2021 at 11:47:12PM +0900, Hector Martin wrote:
>> +  compatible:
>> +    items:
>> +      - enum:
>> +          - apple,t8103-pmgr
>> +          - apple,t8103-minipmgr
>> +      - const: apple,pmgr
>> +      - const: syscon
>> +      - const: simple-mfd
> 
> 
> 'simple-mfd' means 'there's nothing in this node that any of the child
> nodes depend on'. You should be somewhat certain as dropping it later
> creates compatibility issues.

Hmm, I see simple-mfd turns this into a bus which I guess allows child 
nodes to be probed without the parent node doing anything special (then 
we use syscon_node_to_regmap to get the syscon instantiated). Do you 
have a example use case for doing this without simple-mfd?

At this point I can't think of anything we'd need from the parent node, 
especially if we end up using this syscon strictly for pwrstate subnodes 
(which seems likely at this point). One thing that comes to mind is 
telling the PMP (a coprocessor in charge of power metrics/management) 
about some domains being turned on/off, which is apparently a thing, but 
that wouldn't even be in this node; that'd have to be a phandle property 
in the child nodes referencing a PMP/coprocessor node elsewhere (none of 
which is implemented right now, and which should be backwards compatible 
once it is).

If it turns out we do have a dep of some sort in the end, could we just 
have the child node driver return -EPROBE_DEFER until the parent is 
probed and has made whatever service available? That would allow us to 
keep simple-mfd, right?

If it works for you, I'll also just squash the two bindings into one 
commit for the next spin, since there is a direct dependency at this 
point and it should make things easier. Otherwise, I can just swap the 
order if you prefer it that way.

Ack on the other formatting changes; if the rest of the series looks 
good to the other folks I'll try to respin this into a v3 soon, to see 
if we can sneak it in by 5.16, since it'd be nice to have the power 
domain stuff in there :)

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub