linux-kernel - Re: [PATCH 8/8] dt-bindings: mfd: ocelot: mention MDIO management and add example

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: <87r02rsrri.fsf@prevas.dk>
Date: Thu, 20 Mar 2025 15:25:53 +0100
From: Rasmus Villemoes <ravi@...vas.dk>
To: "Rob Herring (Arm)" <robh@...nel.org>
Cc: Colin Foster <colin.foster@...advantage.com>,
  devicetree@...r.kernel.org,  Felix Blix Everberg <felix.blix@...vas.dk>,
  Lee Jones <lee@...nel.org>,  linux-kernel@...r.kernel.org
Subject: Re: [PATCH 8/8] dt-bindings: mfd: ocelot: mention MDIO management
 and add example

On Wed, Mar 19 2025, "Rob Herring (Arm)" <robh@...nel.org> wrote:

> On Wed, 19 Mar 2025 13:30:58 +0100, Rasmus Villemoes wrote:
>> The ocelot switches can also be strapped so that they can be
>> controlled via an MDIO bus (on either address 0 or 31). Mention that
>> and add an example.
>> 
>> Signed-off-by: Rasmus Villemoes <ravi@...vas.dk>
>> ---
>>  .../devicetree/bindings/mfd/mscc,ocelot.yaml  | 121 +++++++++++++++++-
>>  1 file changed, 119 insertions(+), 2 deletions(-)
>> 
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/mfd/mscc,ocelot.example.dtb: soc@0: ethernet-switch@...10000:ethernet-ports:port@a: 'phy-mode' is a required property
> 	from schema $id:
> http://devicetree.org/schemas/mfd/mscc,ocelot.yaml#

So I thought phy-mode and phy-connection-type were interchangeable, but
apparently not wrt. dt bindings. I also see that I wasn't even
consistent (I used phy-mode for the user ports), so that one is easy to
fix.

> Documentation/devicetree/bindings/mfd/mscc,ocelot.example.dtb:
> soc@0: ethernet-switch@...10000:ethernet-ports:port@a: Unevaluated
> properties are not allowed ('phys' was unexpected)
> 	from schema $id:
> http://devicetree.org/schemas/mfd/mscc,ocelot.yaml#

Well, I do need to specify that phys property for the cpu-facing port,
so I'm gonna need some help to extend the schema to allow that. The
definition of what is allowed here isn't in the mscc,vsc7514-switch.yaml
file itself but is "inherited" through several levels of $ref, but I
don't think it would be appropriate to add to dsa-port.yaml as this is
somewhat special to this switch.

> Documentation/devicetree/bindings/mfd/mscc,ocelot.example.dtb:
> soc@0: 'serdes@...d0000' does not match any of the regexes:
> '^ethernet-switch@[0-9a-f]+$', '^gpio@[0-9a-f]+$', '^mdio@[0-9a-f]+$',
> '^pinctrl@[0-9a-f]+$', 'pinctrl-[0-9]+'

Hm. I have probably cheated somewhat, but I think there are a few things
that need fixing here.

First, I think the existing binding should allow for a "syscon" subnode,
which in turn can then contain that serdes subnode (see
arch/mips/boot/dts/mscc/ocelot.dtsi). But when I then put my serdes node
inside that new mscc,ocelot-hsio node, I think the MFD driver is going
to warn, because that expects a subnode with the mscc,vsc7514-serdes
compatible. So that should be updated to expect a mscc,ocelot-hsio
subnode, and the naming changed s/serdes/hsio/. I'll have to test this
first, to see if the various drivers still find the regmap(s) they need.

Rasmus