[net-next,v8,0/9] Create a binding for the Marvell MV88E6xxx DSA switches

Message ID 20231114-marvell-88e6152-wan-led-v8-0-50688741691b@linaro.org
Headers
Series Create a binding for the Marvell MV88E6xxx DSA switches |

Message

Linus Walleij Nov. 13, 2023, 11:35 p.m. UTC
  The Marvell switches are lacking DT bindings.

I need proper schema checking to add LED support to the
Marvell switch. Just how it is, it can't go on like this.

Some Device Tree fixes are included in the series, these
remove the major and most annoying warnings fallout noise:
some warnings remain, and these are of more serious nature,
such as missing phy-mode. They can be applied individually,
or to the networking tree with the rest of the patches.

Thanks to Andrew Lunn, Vladimir Oltean and Russell King
for excellent review and feedback!

This latest version employs special compatibles in the
odd ABI device trees.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Changes in v8:
- Restore ALL original switch node names in the Turris Mox, not just
  the top one. Put a comment above each not to change the node name.
- Add a special compatible for the Turris Mox switches, so that we
  can apply special rules for these ABI nodes.
- Add quirks to the bindings to deal with the special node names
  so we don't get unsolicited warnings about them from the checks.
  This is done so that people will not come and "fix the DTS files"
  so they break. We only have serious warnings after this.
- Add the quirks and updates to the nodes into separate patches
  for review.
- Link to v7: https://lore.kernel.org/r/20231024-marvell-88e6152-wan-led-v7-0-2869347697d1@linaro.org

Changes in v7:
- Fix the elaborate spacing to satisfy yamllint in the
  ports/ethernet-ports requirement.
- Link to v6: https://lore.kernel.org/r/20231024-marvell-88e6152-wan-led-v6-0-993ab0949344@linaro.org

Changes in v6:
- Fix ports/ethernet-ports requirement with proper indenting
  (hopefully).
- Link to v5: https://lore.kernel.org/r/20231023-marvell-88e6152-wan-led-v5-0-0e82952015a7@linaro.org

Changes in v5:
- Consistently rename switch@n to ethernet-switch@n in all cleanup patches
- Consistently rename ports to ethernet-ports in all cleanup patches
- Consistently rename all port@n to ethernet-port@n in all cleanup patches
- Consistently rename all phy@n to ethernet-phy@n in all cleanup patches
- Restore the nodename on the Turris MOX which has a U-Boot binary using the
  nodename as ABI, put in a blurb warning about this so no-one else tries
  to change it in the future.
- Drop dsa.yaml direct references where we reference dsa.yaml#/$defs/ethernet-ports
- Replace the conjured MV88E6xxx example by a better one based on imx6qdl
  plus strictly named nodes and added reset-gpios for a more complete example,
  and another example using the interrupt controller based on
  armada-381-netgear-gs110emx.dts
- Bump lineage to 2008 as Vladimir says the code was developed starting 2008.
- Link to v4: https://lore.kernel.org/r/20231018-marvell-88e6152-wan-led-v4-0-3ee0c67383be@linaro.org

Changes in v4:
- Rebase the series on top of Rob's series
  "dt-bindings: net: Child node schema cleanups" (or the hex numbered
  ports will not work)
- Fix up a whitespacing error corrupting v3...
- Add a new patch making the generic DSA binding require ports or
  ethernet-ports in the switch node.
- Drop any corrections of port@a in the patches.
- Drop oneOf in the compatible enum for mv88e6xxx
- Use ethernet-switch, ethernet-ports and ethernet-phy in the examples
- Transclude the dsa.yaml#/$defs/ethernet-ports define for ports
- Move the DTS and binding fixes first, before the actual bindings,
  so they apply without (too many) warnings as fallout.
- Drop stray colon in text.
- Drop example port in the mveusb binding.
- Link to v3: https://lore.kernel.org/r/20231016-marvell-88e6152-wan-led-v3-0-38cd449dfb15@linaro.org

Changes in v3:
- Fix up a related mvusb example in a different binding that
  the scripts were complaining about.
- Fix up the wording on internal vs external MDIO buses in the
  mv88e6xxx binding document.
- Remove pointless label and put the right rev-mii into the
  MV88E6060 schema.
- Link to v2: https://lore.kernel.org/r/20231014-marvell-88e6152-wan-led-v2-0-7fca08b68849@linaro.org

Changes in v2:
- Break out a separate Marvell MV88E6060 binding file. I stand corrected.
- Drop the idea to rely on nodename mdio-external for the external
  MDIO bus, keep the compatible, drop patch for the driver.
- Fix more Marvell DT mistakes.
- Fix NXP DT mistakes in a separate patch.
- Fix Marvell ARM64 mistakes in a separate patch.
- Link to v1: https://lore.kernel.org/r/20231013-marvell-88e6152-wan-led-v1-0-0712ba99857c@linaro.org

---
Linus Walleij (9):
      dt-bindings: net: dsa: Require ports or ethernet-ports
      dt-bindings: net: mvusb: Fix up DSA example
      ARM: dts: marvell: Fix some common switch mistakes
      ARM: dts: nxp: Fix some common switch mistakes
      ARM64: dts: marvell: Fix some common switch mistakes
      dt-bindings: net: ethernet-switch: Accept special variants
      dt-bindings: marvell: Rewrite MV88E6xxx in schema
      ARM64: dts: Add special compatibles for the Turris Mox
      dt-bindings: marvell: Add Marvell MV88E6060 DSA schema

 Documentation/devicetree/bindings/net/dsa/dsa.yaml |   6 +
 .../bindings/net/dsa/marvell,mv88e6060.yaml        |  88 ++++++
 .../bindings/net/dsa/marvell,mv88e6xxx.yaml        | 337 +++++++++++++++++++++
 .../devicetree/bindings/net/dsa/marvell.txt        | 109 -------
 .../devicetree/bindings/net/ethernet-switch.yaml   |  23 +-
 .../devicetree/bindings/net/marvell,mvusb.yaml     |   7 +-
 MAINTAINERS                                        |   3 +-
 arch/arm/boot/dts/marvell/armada-370-rd.dts        |  24 +-
 .../dts/marvell/armada-381-netgear-gs110emx.dts    |  44 ++-
 .../dts/marvell/armada-385-clearfog-gtr-l8.dts     |  38 +--
 .../dts/marvell/armada-385-clearfog-gtr-s4.dts     |  22 +-
 arch/arm/boot/dts/marvell/armada-385-linksys.dtsi  |  18 +-
 .../boot/dts/marvell/armada-385-turris-omnia.dts   |  20 +-
 arch/arm/boot/dts/marvell/armada-388-clearfog.dts  |  20 +-
 .../boot/dts/marvell/armada-xp-linksys-mamba.dts   |  18 +-
 arch/arm/boot/dts/nxp/vf/vf610-zii-cfu1.dts        |  14 +-
 arch/arm/boot/dts/nxp/vf/vf610-zii-scu4-aib.dts    |  70 ++---
 arch/arm/boot/dts/nxp/vf/vf610-zii-spb4.dts        |  18 +-
 arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts    |  20 +-
 arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-spu3.dts   |  18 +-
 .../dts/marvell/armada-3720-espressobin-ultra.dts  |  14 +-
 .../boot/dts/marvell/armada-3720-espressobin.dtsi  |  20 +-
 .../boot/dts/marvell/armada-3720-gl-mv1000.dts     |  20 +-
 .../boot/dts/marvell/armada-3720-turris-mox.dts    |  97 +++---
 .../boot/dts/marvell/armada-7040-mochabin.dts      |  24 +-
 .../dts/marvell/armada-8040-clearfog-gt-8k.dts     |  22 +-
 arch/arm64/boot/dts/marvell/cn9130-crb.dtsi        |  42 ++-
 27 files changed, 745 insertions(+), 411 deletions(-)
---
base-commit: 1c9be5fea84e409542a186893d219bf7cff22f5a
change-id: 20231008-marvell-88e6152-wan-led-88c43b7fd2fd

Best regards,
  

Comments

Andrew Lunn Nov. 14, 2023, 9:50 p.m. UTC | #1
On Tue, Nov 14, 2023 at 12:35:55AM +0100, Linus Walleij wrote:
> The Marvell switches are lacking DT bindings.
> 
> I need proper schema checking to add LED support to the
> Marvell switch. Just how it is, it can't go on like this.
> 
> Some Device Tree fixes are included in the series, these
> remove the major and most annoying warnings fallout noise:
> some warnings remain, and these are of more serious nature,
> such as missing phy-mode. They can be applied individually,
> or to the networking tree with the rest of the patches.
> 
> Thanks to Andrew Lunn, Vladimir Oltean and Russell King
> for excellent review and feedback!
> 
> This latest version employs special compatibles in the
> odd ABI device trees.

So i have one open question. How do we merge this?

Can we just take it all through the DT tree?

    Andrew
  
Linus Walleij Nov. 15, 2023, 9:50 a.m. UTC | #2
On Tue, Nov 14, 2023 at 10:50 PM Andrew Lunn <andrew@lunn.ch> wrote:

> So i have one open question. How do we merge this?
>
> Can we just take it all through the DT tree?

If we don't expect the affected DTS files to have orthogonal
modifications we certainly could, if the respective subarch
mainatiners are OK with it and can ACK that approach.

For Marvell that's you I guess :)

For NXP VF that's Shawn Guo, Shawn are you OK with
these changes going through the net tree?

Yours,
Linus Walleij
  
Linus Walleij Nov. 26, 2023, 8:17 p.m. UTC | #3
On Wed, Nov 15, 2023 at 10:50 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Nov 14, 2023 at 10:50 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > So i have one open question. How do we merge this?
> >
> > Can we just take it all through the DT tree?
>
> If we don't expect the affected DTS files to have orthogonal
> modifications we certainly could, if the respective subarch
> mainatiners are OK with it and can ACK that approach.
>
> For Marvell that's you I guess :)
>
> For NXP VF that's Shawn Guo, Shawn are you OK with
> these changes going through the net tree?

Shawn is busy I guess, but looking at the activity in arch/arm/boot/dts/nxp
iIt seems pretty risk-free to apply.

An alternative is to simply apply all but patch 4/9 (the NXP patch), because
the rest is Andrew territory.

Yours,
Linus Walleij
  
Andrew Lunn Nov. 26, 2023, 9:06 p.m. UTC | #4
> Shawn is busy I guess, but looking at the activity in arch/arm/boot/dts/nxp
> iIt seems pretty risk-free to apply.
> 
> An alternative is to simply apply all but patch 4/9 (the NXP patch), because
> the rest is Andrew territory.

Could you split it into two patchsets? Gregory and I can deal with all
the Marvell patches.

    Andrew
  
Linus Walleij Nov. 27, 2023, 2:20 p.m. UTC | #5
On Sun, Nov 26, 2023 at 10:06 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > Shawn is busy I guess, but looking at the activity in arch/arm/boot/dts/nxp
> > iIt seems pretty risk-free to apply.
> >
> > An alternative is to simply apply all but patch 4/9 (the NXP patch), because
> > the rest is Andrew territory.
>
> Could you split it into two patchsets? Gregory and I can deal with all
> the Marvell patches.

OK good idea. Actually three:

1. Bindings only (for netdev/dsa)
2. Marvell cleanups (for DTS files/SoCs)
3. The NXP cleanup patch

Yours,
Linus Walleij