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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqJbVcqy8n0EroV=nFZoJ_WAr+JbrDf-c1jso856NghC2A@mail.gmail.com>
Date:   Wed, 27 Oct 2021 09:43:54 -0500
From:   Rob Herring <robh@...nel.org>
To:     Hector Martin <marcan@...can.st>
Cc:     linux-arm-kernel <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,
        "open list:THERMAL" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        "open list:SERIAL DRIVERS" <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 Tue, Oct 26, 2021 at 10:38 PM Hector Martin <marcan@...can.st> wrote:
>
> 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?

Drivers calling of_platform_populate or devm_of_platform_populate.

That of course does mean you need a driver. We could probably make the
syscon driver call these if needed.

> 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?

That would have saved you, but deferred probe is now a fallback to
fw_devlink and it makes sure parent driver probes first. That works
unless there isn't a parent driver which is often the case for
simple-bus[1]. I think you are okay since 'syscon' means there is a
driver.

> 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.

Just swapping seems like less work, but either way.

Rob

[1] https://lore.kernel.org/all/CAL_JsqJcsqjJBe8aULYYMkFtx8OTj2wHANZ=83VMMyJ=AEgReg@mail.gmail.com/