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]

Date:   Mon, 6 Feb 2023 10:47:04 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Rob Herring <robh@...nel.org>
Cc:     Cristian Marussi <cristian.marussi@....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

Hi Rob,

On Fri, Jan 27, 2023 at 12:52:33PM -0600, Rob Herring wrote:
>
> TBC, 'protocol@.*' would not allow anything but the properties defined
> in the /$defs/protocol-node. So [1] would throw errors without a
> schema addition.

Right I clearly missed that, somehow I assumed it would allow.

> We should either do that along with dropping 'protocol@18' or we keep
> protocol 0x18 node and add all other providerless protocols. I don't
> think we need the latter to just check unit-address vs. reg.

I only argument today it to allow protocol specific transport. So we could
delay addition of it until someone needs that way. So far we haven't seen
anyone using it other than performance(even that is not needed with the
introduction of fast channels that are auto discoverable in relatively
newer versions of the spec).

--
Regards,
Sudeep