[00/28] DT: Improve validation for Marvell SoCs

Message

Lubomir Rintel March 17, 2020, 9:38 a.m. UTC

Hello World,

chained to this message is a set of patches that improve coverage of Device
Tree validation for devices typically found on Marvell SoCs. It converts most
of the peripheral binding documentation to YAML and fixes up validation issues
in the SoC device trees.

It starts with fixing the issues:

  [PATCH 01/28] ARM: dts: kirkwood: Fix interrupt controller node name
  [PATCH 02/28] ARM: dts: dove: Fix interrupt controller node name
  [PATCH 03/28] ARM: dts: pxa168: Add missing address/size cells to i2c
  [PATCH 04/28] ARM: dts: pxa168: Fix the gpio interrupt cell number
  [PATCH 05/28] ARM: dts: pxa3xx: Fix up encoding of the /gpio
  [PATCH 06/28] ARM: dts: pxa910: Fix the gpio interrupt cell number
  [PATCH 07/28] ARM: dts: pxa*: Fix up encoding of the /rtc interrupts
  [PATCH 08/28] ARM: dts: mmp*: Fix up encoding of the /rtc interrupts
  [PATCH 09/28] ARM: dts: mmp3: fix L2 cache controller node name
  [PATCH 10/28] ARM: dts: mmp3: fix USB & USB PHY node names
  [PATCH 11/28] ARM: dts: berlin*: Fix up the SDHCI node names

Then the binding fixes follow.

When converting .txt binding files that were not written by myself,
I didn't include the SPDX license tag and set the maintaners: to the
devicetree@ list. The reason is that the original binding files don't
contain the information and I didn't want to speak for anyone else and
make it up.

If this is not the correct thing to do, or the respective binding
contributors want to clarify the licensing or be listed as maintainers,
please respond and I'll send an updated patch set. I'm also happy to
maintain any of these bindings.

  [PATCH 12/28] spi: dt-bindings: spi-controller: Slaves have no
  [PATCH 13/28] dt-bindings: serial: move Marvell compatible string to
  [PATCH 14/28] dt-bindings: arm: l2x0: Tauros 3 is PL310 compatible
  [PATCH 15/28] dt-bindings: arm: mrvl: Add missing compatible strings
  [PATCH 16/28] dt-bindings: Add "mrvl", a legacy vendor prefix for
  [PATCH 17/28] dt-bindings: mmc: Fix up clk-phase-sd-hs in an example
  [PATCH 18/28] dt-bindings: mmc: Fix node name in an example
  [PATCH 19/28] dt-bindings: mmc: Convert sdhci-pxa to json-schema
  [PATCH 20/28] dt-bindings: phy: Convert phy-mmp3-usb to json-schema
  [PATCH 21/28] dt-bindings: gpio: Convert mrvl-gpio to json-schema
  [PATCH 22/28] dt-bindings: i2c: Convert i2c-pxa to json-schema
  [PATCH 23/28] dt-bindings: interrupt-controller: Convert mrvl,intc to
  [PATCH 24/28] dt-bindings: media: Convert marvell,mmp2-ccic to
  [PATCH 25/28] dt-bindings: rtc: Convert sa1100-rtc to json-schema
  [PATCH 26/28] dt-bindings: spi: Convert spi-pxa2xx to json-schema
  [PATCH 27/28] dt-bindings: timer: Convert mrvl,mmp-timer to
  [PATCH 28/28] dt-bindings: usb: Convert ehci-mv to json-schema

None of the patches depends on any other and they can be applied in any
order.

Love,
Lubo

Comments

Mark Brown March 17, 2020, 1:19 p.m. UTC | #1

On Tue, Mar 17, 2020 at 10:38:54AM +0100, Lubomir Rintel wrote:

> None of the patches depends on any other and they can be applied in any
> order.

For future reference since this is a large set of mostly unrelated
changes it'd be as well to split it up via subsystem or something so
that the CC lists get reduced.

Andrew Lunn March 17, 2020, 1:46 p.m. UTC | #2

On Tue, Mar 17, 2020 at 10:38:54AM +0100, Lubomir Rintel wrote:
> Hello World,

Yah, that is an issue here. Marvell have a few different SoC families,
each with there own maintainers. Gregory and I tend to look after
'mvebu', aka orion5x, kirkwood, dove, berlin and a few others. All the
others are 'Somebody elses' problem'.

How do you think this patchset should get merged? Are we going to
split it up, just nominate one maintainer to merge the lot, or go
direct to arm-soc?

       Andrew

Alexandre Belloni March 17, 2020, 1:55 p.m. UTC | #3

On 17/03/2020 14:46:09+0100, Andrew Lunn wrote:
> On Tue, Mar 17, 2020 at 10:38:54AM +0100, Lubomir Rintel wrote:
> > Hello World,
> 
> Yah, that is an issue here. Marvell have a few different SoC families,
> each with there own maintainers. Gregory and I tend to look after
> 'mvebu', aka orion5x, kirkwood, dove, berlin and a few others. All the
> others are 'Somebody elses' problem'.
> 

Hum, berlin is not mvebu, it was the same BU as the MMP and it has been
sold to synopsys a while ago.

Andrew Lunn March 17, 2020, 1:59 p.m. UTC | #4

On Tue, Mar 17, 2020 at 02:55:59PM +0100, Alexandre Belloni wrote:
> On 17/03/2020 14:46:09+0100, Andrew Lunn wrote:
> > On Tue, Mar 17, 2020 at 10:38:54AM +0100, Lubomir Rintel wrote:
> > > Hello World,
> > 
> > Yah, that is an issue here. Marvell have a few different SoC families,
> > each with there own maintainers. Gregory and I tend to look after
> > 'mvebu', aka orion5x, kirkwood, dove, berlin and a few others. All the
> > others are 'Somebody elses' problem'.
> > 
> 
> Hum, berlin is not mvebu, it was the same BU as the MMP and it has been
> sold to synopsys a while ago.

Yes, the boundaries are a bit fluffy. At least the early work by
Sebastian was merged via the mvebu maintainers, even if it is not
technically part of mvebu.

This is also part of the discussion about how this lot actually gets
merged.

	   Andrew