mbox series

[v2,00/12] YAML conversion of several Freescale/PowerPC DT bindings

Message ID 20250207-ppcyaml-v2-0-8137b0c42526@posteo.net (mailing list archive)
Headers show
Series YAML conversion of several Freescale/PowerPC DT bindings | expand

Message

J. Neuschäfer via B4 Relay Feb. 7, 2025, 9:30 p.m. UTC
This is a spin-off of the series titled
"powerpc: MPC83xx cleanup and LANCOM NWAPP2 board".

During the development of that series, it became clear that many
devicetree bindings for Freescale MPC8xxx platforms are still in the old
plain-text format, or don't exist at all, and in any case don't mention
all valid compatible strings.

Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
---
Changes in v2:
- rebased on v6.14-rc1
- various style cleanups, both in YAML and in DTS examples
- minor improvements to the commit messages
- Link to v1: https://lore.kernel.org/r/20250126-ppcyaml-v1-0-50649f51c3dd@posteo.net

---
J. Neuschäfer (12):
      dt-bindings: powerpc: Add Freescale/NXP MPC83xx SoCs
      dt-bindings: ata: Convert fsl,pq-sata to YAML
      dt-bindings: crypto: Convert fsl,sec-2.0 to YAML
      dt-bindings: mfd: Convert fsl,mcu-mpc8349emitx to YAML
      dt-bindings: dma: Convert fsl,elo*-dma to YAML
      dt-bindings: pci: Convert fsl,mpc83xx-pcie to YAML
      dt-bindings: watchdog: Convert mpc8xxx-wdt to YAML
      dt-bindings: spi: Convert Freescale SPI bindings to YAML
      dt-bindings: memory-controllers: Convert fsl,elbc to YAML
      dt-bindings: memory-controllers: Add fsl,elbc-gpcm-uio
      dt-bindings: nand: Add fsl,elbc-fcm-nand
      dt-bindings: mtd: raw-nand-chip: Relax node name pattern

 .../devicetree/bindings/ata/fsl,pq-sata.yaml       |  59 ++++++
 Documentation/devicetree/bindings/ata/fsl-sata.txt |  28 ---
 .../devicetree/bindings/crypto/fsl,sec2.0.yaml     | 142 ++++++++++++++
 .../devicetree/bindings/crypto/fsl-sec2.txt        |  65 -------
 .../devicetree/bindings/dma/fsl,elo-dma.yaml       | 140 ++++++++++++++
 .../devicetree/bindings/dma/fsl,elo3-dma.yaml      | 123 +++++++++++++
 .../devicetree/bindings/dma/fsl,eloplus-dma.yaml   | 134 ++++++++++++++
 .../memory-controllers/fsl,elbc-gpcm-uio.yaml      |  59 ++++++
 .../bindings/memory-controllers/fsl,elbc.yaml      | 146 +++++++++++++++
 .../bindings/mfd/fsl,mcu-mpc8349emitx.yaml         |  53 ++++++
 .../devicetree/bindings/mtd/fsl,elbc-fcm-nand.yaml |  68 +++++++
 .../devicetree/bindings/mtd/raw-nand-chip.yaml     |   2 +-
 .../devicetree/bindings/pci/fsl,mpc8xxx-pci.yaml   | 115 ++++++++++++
 Documentation/devicetree/bindings/pci/fsl,pci.txt  |  27 ---
 .../devicetree/bindings/powerpc/fsl/dma.txt        | 204 ---------------------
 .../bindings/powerpc/fsl/fsl,mpc83xx.yaml          |  67 +++++++
 .../devicetree/bindings/powerpc/fsl/lbc.txt        |  43 -----
 .../bindings/powerpc/fsl/mcu-mpc8349emitx.txt      |  17 --
 .../devicetree/bindings/spi/fsl,espi.yaml          |  64 +++++++
 Documentation/devicetree/bindings/spi/fsl,spi.yaml |  73 ++++++++
 Documentation/devicetree/bindings/spi/fsl-spi.txt  |  62 -------
 .../devicetree/bindings/watchdog/mpc8xxx-wdt.txt   |  25 ---
 .../devicetree/bindings/watchdog/mpc8xxx-wdt.yaml  |  64 +++++++
 23 files changed, 1308 insertions(+), 472 deletions(-)
---
base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
change-id: 20250126-ppcyaml-680ccd8b3fc2

Best regards,

Comments

Mark Brown Feb. 7, 2025, 9:38 p.m. UTC | #1
On Fri, Feb 07, 2025 at 10:30:17PM +0100, J. Neuschäfer via B4 Relay wrote:

> This is a spin-off of the series titled
> "powerpc: MPC83xx cleanup and LANCOM NWAPP2 board".

> During the development of that series, it became clear that many
> devicetree bindings for Freescale MPC8xxx platforms are still in the old
> plain-text format, or don't exist at all, and in any case don't mention
> all valid compatible strings.

What's the story with dependencies here - why is all this stuff in one
series?  Normally I'd expect bindings conversions to be standalone.
J. Neuschäfer Feb. 8, 2025, 2:20 a.m. UTC | #2
On Fri, Feb 07, 2025 at 09:38:05PM +0000, Mark Brown wrote:
> On Fri, Feb 07, 2025 at 10:30:17PM +0100, J. Neuschäfer via B4 Relay wrote:
> 
> > This is a spin-off of the series titled
> > "powerpc: MPC83xx cleanup and LANCOM NWAPP2 board".
> 
> > During the development of that series, it became clear that many
> > devicetree bindings for Freescale MPC8xxx platforms are still in the old
> > plain-text format, or don't exist at all, and in any case don't mention
> > all valid compatible strings.
> 
> What's the story with dependencies here - why is all this stuff in one
> series?

The patches are independent of each other, except for the four elbc/nand
patches. They are in the same series because they came up during the
same project and achieve similar goals, but it isn't necessary.


> Normally I'd expect bindings conversions to be standalone.

Noted.


J. Neuschäfer
Mark Brown Feb. 10, 2025, 12:59 p.m. UTC | #3
On Sat, Feb 08, 2025 at 02:20:47AM +0000, J. Neuschäfer wrote:
> On Fri, Feb 07, 2025 at 09:38:05PM +0000, Mark Brown wrote:

> > What's the story with dependencies here - why is all this stuff in one
> > series?

> The patches are independent of each other, except for the four elbc/nand
> patches. They are in the same series because they came up during the
> same project and achieve similar goals, but it isn't necessary.

Please don't do this, it just makes it harder to merge things since it
makes it look like there's cross tree merges needed when that's not the
case, complicating merging, and puts the entire series in everyone's
inbox which makes things more noisy.
J. Neuschäfer Feb. 10, 2025, 3:57 p.m. UTC | #4
On Mon, Feb 10, 2025 at 12:59:35PM +0000, Mark Brown wrote:
> On Sat, Feb 08, 2025 at 02:20:47AM +0000, J. Neuschäfer wrote:
> > On Fri, Feb 07, 2025 at 09:38:05PM +0000, Mark Brown wrote:
> 
> > > What's the story with dependencies here - why is all this stuff in one
> > > series?
> 
> > The patches are independent of each other, except for the four elbc/nand
> > patches. They are in the same series because they came up during the
> > same project and achieve similar goals, but it isn't necessary.
> 
> Please don't do this, it just makes it harder to merge things since it
> makes it look like there's cross tree merges needed when that's not the
> case, complicating merging, and puts the entire series in everyone's
> inbox which makes things more noisy.

How should I proceed with this series, in your opinion?
I see potential advantages (less of the issues you describe) and
disadvantages (somewhat harder to track patches) of splitting it up
before sending v3.

(Outside of this series, the conclusion is clear and simple)


J. Neuschäfer
Mark Brown Feb. 10, 2025, 4:19 p.m. UTC | #5
On Mon, Feb 10, 2025 at 03:57:42PM +0000, J. Neuschäfer wrote:
> On Mon, Feb 10, 2025 at 12:59:35PM +0000, Mark Brown wrote:

> > Please don't do this, it just makes it harder to merge things since it
> > makes it look like there's cross tree merges needed when that's not the
> > case, complicating merging, and puts the entire series in everyone's
> > inbox which makes things more noisy.

> How should I proceed with this series, in your opinion?
> I see potential advantages (less of the issues you describe) and
> disadvantages (somewhat harder to track patches) of splitting it up
> before sending v3.

I'd rather that at least the SPI stuff were sent separately (well,
ideally what you've done already is fine and it doesn't need a resend at
all).