linux-kernel - Re: [PATCH] dt-bindings: firmware: arm,scmi: Restrict protocol child node properties

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: <20230126144647.6q3qlu5sqz27cmyc@bogus>
Date:   Thu, 26 Jan 2023 14:46:47 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Cristian Marussi <cristian.marussi@....com>
Cc:     Rob Herring <robh@...nel.org>, Sudeep Holla <sudeep.holla@....com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: firmware: arm,scmi: Restrict protocol child
 node properties

On Thu, Jan 26, 2023 at 09:43:44AM +0000, Cristian Marussi wrote:
> On Wed, Jan 25, 2023 at 02:11:13PM +0000, Sudeep Holla wrote:
> > On Wed, Jan 25, 2023 at 01:43:48PM +0000, Cristian Marussi wrote:
> > > so now that the catch-all protocol@ patternProperty is gone in favour
> > > of the 'protocol-node' definition and $refs, does that mean that any
> > > current and future SCMI officially published protocol <N> has to be
> > > added to the above explicit protocol list, even though it does not
> > > have any special additional required property beside reg ?
> > > (like protocol@18 above...)
> > >
> > 
> > If there are no consumers, should we just not add and deal with it
> > entirely within the kernel. I know we rely today on presence of node
> > before we initialise, but hey we have exception for system power protocol
> > for other reasons, why not add this one too.
> > 
> > In short we shouldn't have to add a node if there are no consumers. It
> > was one of the topic of discussion initially when SCMI binding was added
> > and they exist only for the consumers otherwise we don't need it as
> > everything is discoverable from the interface.
> 
> It is fine for me the no-consumers/no-node argument (which anyway would
> require a few changes in the core init logic anyway to work this way...),
> BUT is it not that ANY protocol (even future-ones) does have, potentially,
> consumers indeed, since each protocol-node can potentially have a dedicated
> channel and related DT channel-descriptor ? (when multiple channels are
> allowed by the transport)
> 
> I mean, as an example, you dont strictly need protos 0x18/0x12 nodes for
> anything (if we patch the core init as said) UNLESS you want to dedicate
> a channel to those protocols; so I'm just checking here if these kind of
> scenarios will still be allowed with this binding change, or if I am
> missing something.

Ah, good point on the transport information. Yes we will need a node if
a protocol has a dedicated transport. No one has used so far other than
Juno perf, but we never know. We can always extended the bindings if
needed.

Sorry for missing the dedicated transport part.

-- 
Regards,
Sudeep