On Wed, Mar 19 2025, "Rob Herring (Arm)" <robh@xxxxxxxxxx> 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@xxxxxxxxx> >> --- >> .../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@71010000: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@71010000: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@710d0000' 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
