Skip to contentSkip to conversation

ARM: dts: Last round of DT schema fixes

PATCH Applied Maxime Ripard 15 participants 125 messages Sep 1, 2021 – Oct 15, 2021 2 messages not in the archive

Subsystems (26)
lore
Share & tools
lore
#0 lore raw

v2 cover ARM: dts: Last round of DT schema fixes

Hi,

Here's another round of schema warnings fixes for the Allwinner platform.

There's a fair share of new schemas in there since the schema tools now warn when a compatible is not documented in a schema.

We don't have any warning anymore if we use the OPP binding Rob submitted, and since that means we have all our devices properly validated I don't expect more fixes now, aside from the usual bunch of regressions.

Let me know what you think,
Maxime

Maxime Ripard (52):
ASoC: dt-bindings: Add WM8978 Binding
ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema
ASoC: dt-bindings: Convert SPDIF Transmitter binding to a schema
ASoC: dt-bindings: Convert Simple Amplifier binding to a schema
dt-bindings: Convert Reserved Memory binding to a schema
dt-bindings: arm: Convert ARM CCI-400 binding to a schema
dt-bindings: bluetooth: broadcom: Fix clocks check
dt-bindings: bluetooth: realtek: Add missing max-speed
dt-bindings: clocks: Fix typo in the H6 compatible
dt-bindings: display: Move idk-1110wr to panel-lvds
dt-bindings: display: Move idk-2121wr to panel-lvds
dt-bindings: display: Move ee101ia-01d to panel-lvds
dt-bindings: display: aa104xd12: Remove unused vcc-supply
dt-bindings: display: aa104xd12: Fix data-mapping
dt-bindings: display: Move aa104xd12 to panel-lvds
dt-bindings: display: aa121td01: Remove unused vcc-supply
dt-bindings: display: aa121td01: Fix data-mapping
dt-bindings: display: Move aa121td01 to panel-lvds
dt-bindings: display: Move gktw70sdae4se to panel-lvds
dt-bindings: display: panel-lvds: Document missing panel compatibles
dt-bindings: gnss: Convert UBlox Neo-6M binding to a schema
dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema
dt-bindings: hwmon: Add IIO HWMON binding
dt-bindings: input: Convert Silead GSL1680 binding to a schema
dt-bindings: interconnect: sunxi: Add R40 MBUS compatible
dt-bindings: media: ti,cal: Fix example
dt-bindings: media: Convert OV5640 binding to a schema
dt-bindings: mfd: Convert X-Powers AC100 binding to a schema
dt-bindings: mfd: Convert X-Powers AXP binding to a schema
dt-bindings: mmc: Convert MMC Card binding to a schema
dt-bindings: net: dwmac: Fix typo in the R40 compatible
dt-bindings: net: wireless: Convert ESP ESP8089 binding to a schema
dt-bindings: regulator: Convert SY8106A binding to a schema
dt-bindings: sunxi: Add CPU Configuration Controller Binding
dt-bindings: sunxi: Add Allwinner A80 PRCM Binding
dt-bindings: usb: Convert SMSC USB3503 binding to a schema
dt-bindings: usb: dwc3: Fix usb-phy check
dt-bindings: w1: Convert 1-Wire GPIO binding to a schema
ARM: dts: sunxi: Rename power-supply names
ARM: dts: sunxi: Rename gpio pinctrl names
ARM: dts: sunxi: Fix OPP arrays
ARM: dts: sunxi: Fix OPPs node name
ARM: dts: sunxi: Fix the SPI NOR node names
ARM: dts: v3s: Remove useless DMA properties
ARM: dts: tbs711: Fix touchscreen compatible
ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible
arm64: dts: allwinner: h5: Fix GPU thermal zone node name
arm64: dts: allwinner: h6: Fix de3 parent clocks ordering
arm64: dts: allwinner: a100: Fix thermal zone node name
arm64: dts: allwinner: pinetab: Change regulator node name to avoid
warning
arm64: dts: allwinner: teres-i: Add missing reg
arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC

 .../devicetree/bindings/arm/arm,cci-400.yaml  | 216 ++++++++++
 .../bindings/arm/cci-control-port.yaml        |  38 ++
 Documentation/devicetree/bindings/arm/cci.txt | 224 ----------
 .../devicetree/bindings/arm/cpus.yaml         |   2 +
 .../arm/sunxi/allwinner,sun4i-a10-mbus.yaml   |   1 +
 .../sunxi/allwinner,sun6i-a31-cpuconfig.yaml  |  38 ++
 .../arm/sunxi/allwinner,sun9i-a80-prcm.yaml   |  33 ++
 .../clock/allwinner,sun8i-a83t-de2-clk.yaml   |   2 +-
 .../display/panel/advantech,idk-1110wr.yaml   |  69 ---
 .../display/panel/advantech,idk-2121wr.yaml   | 121 ------
 .../display/panel/innolux,ee101ia-01d.yaml    |  31 --
 .../bindings/display/panel/lvds.yaml          | 130 +++++-
 .../display/panel/mitsubishi,aa104xd12.yaml   |  75 ----
 .../display/panel/mitsubishi,aa121td01.yaml   |  74 ----
 .../display/panel/sgd,gktw70sdae4se.yaml      |  68 ---
 .../bindings/gnss/u-blox,neo-6m.yaml          |  62 +++
 .../devicetree/bindings/gnss/u-blox.txt       |  45 --
 .../devicetree/bindings/gpio/gpio-axp209.txt  |  75 ----
 .../bindings/gpio/x-powers,axp209-gpio.yaml   |  55 +++
 .../devicetree/bindings/hwmon/iio-hwmon.yaml  |  37 ++
 .../i2c/allwinner,sun6i-a31-p2wi.yaml         |   2 +-
 .../input/touchscreen/silead,gsl1680.yaml     |  91 ++++
 .../input/touchscreen/silead_gsl1680.txt      |  44 --
 .../devicetree/bindings/media/i2c/ov5640.txt  |  92 ----
 .../bindings/media/i2c/ovti,ov5640.yaml       | 154 +++++++
 .../devicetree/bindings/media/ti,cal.yaml     |   4 +-
 .../devicetree/bindings/mfd/ac100.txt         |  50 ---
 .../devicetree/bindings/mfd/axp20x.txt        | 273 ------------
 .../bindings/mfd/x-powers,ac100.yaml          | 116 +++++
 .../bindings/mfd/x-powers,axp152.yaml         | 400 ++++++++++++++++++
 .../devicetree/bindings/mmc/mmc-card.txt      |  30 --
 .../devicetree/bindings/mmc/mmc-card.yaml     |  48 +++
 .../bindings/mmc/mmc-controller.yaml          |   6 -
 .../net/allwinner,sun8i-a83t-emac.yaml        |   4 +-
 .../bindings/net/broadcom-bluetooth.yaml      |  17 +-
 .../bindings/net/realtek-bluetooth.yaml       |   2 +
 .../devicetree/bindings/net/snps,dwmac.yaml   |   6 +-
 .../bindings/net/wireless/esp,esp8089.txt     |  30 --
 .../bindings/net/wireless/esp,esp8089.yaml    |  43 ++
 .../bindings/regulator/silergy,sy8106a.yaml   |  52 +++
 .../bindings/regulator/sy8106a-regulator.txt  |  23 -
 .../reserved-memory/memory-region.yaml        |  40 ++
 .../reserved-memory/reserved-memory.txt       | 172 +-------
 .../reserved-memory/reserved-memory.yaml      |  96 +++++
 .../reserved-memory/shared-dma-pool.yaml      |  87 ++++
 .../devicetree/bindings/sound/bt-sco.txt      |  13 -
 .../bindings/sound/linux,bt-sco.yaml          |  38 ++
 .../bindings/sound/linux,spdif-dit.yaml       |  32 ++
 .../bindings/sound/simple-amplifier.txt       |  17 -
 .../sound/simple-audio-amplifier.yaml         |  45 ++
 .../bindings/sound/spdif-transmitter.txt      |  10 -
 .../devicetree/bindings/sound/wlf,wm8978.yaml |  58 +++
 .../devicetree/bindings/usb/smsc,usb3503.yaml | 108 +++++
 .../devicetree/bindings/usb/snps,dwc3.yaml    |  10 +-
 .../devicetree/bindings/usb/usb3503.txt       |  39 --
 .../devicetree/bindings/w1/w1-gpio.txt        |  27 --
 .../devicetree/bindings/w1/w1-gpio.yaml       |  44 ++
 arch/arm/boot/dts/axp209.dtsi                 |   6 +-
 arch/arm/boot/dts/axp22x.dtsi                 |   6 +-
 arch/arm/boot/dts/axp81x.dtsi                 |  10 +-
 .../arm/boot/dts/sun4i-a10-olinuxino-lime.dts |  11 +-
 arch/arm/boot/dts/sun4i-a10.dtsi              |  11 +-
 arch/arm/boot/dts/sun5i-a13.dtsi              |  15 +-
 arch/arm/boot/dts/sun6i-a31.dtsi              |  44 +-
 arch/arm/boot/dts/sun7i-a20-bananapi.dts      |  17 +-
 arch/arm/boot/dts/sun7i-a20.dtsi              |  34 +-
 arch/arm/boot/dts/sun8i-a33.dtsi              |   4 +-
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts     |   2 +-
 arch/arm/boot/dts/sun8i-a83t.dtsi             |   4 +-
 arch/arm/boot/dts/sun8i-h3.dtsi               |   4 +-
 arch/arm/boot/dts/sun8i-v3-sl631.dtsi         |   2 +-
 arch/arm/boot/dts/sun8i-v3s.dtsi              |   2 -
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts   |   2 +-
 .../boot/dts/sunxi-libretech-all-h3-it.dtsi   |   2 +-
 arch/arm64/boot/dts/allwinner/axp803.dtsi     |  10 +-
 .../arm64/boot/dts/allwinner/sun50i-a100.dtsi |   6 +-
 .../dts/allwinner/sun50i-a64-cpu-opp.dtsi     |   2 +-
 .../dts/allwinner/sun50i-a64-orangepi-win.dts |   2 +-
 .../boot/dts/allwinner/sun50i-a64-pinetab.dts |   2 +-
 .../boot/dts/allwinner/sun50i-a64-teres-i.dts |   3 +-
 .../boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi  |   2 +-
 .../boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  |   8 +-
 84 files changed, 2191 insertions(+), 1743 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/arm,cci-400.yaml
 create mode 100644 Documentation/devicetree/bindings/arm/cci-control-port.yaml
 delete mode 100644 Documentation/devicetree/bindings/arm/cci.txt
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
 create mode 100644 Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml
 delete mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt
 delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-axp209.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
 create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
 create mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
 delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
 delete mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml
 delete mode 100644 Documentation/devicetree/bindings/mfd/ac100.txt
 delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml
 create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
 delete mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.yaml
 delete mode 100644 Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt
 create mode 100644 Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml
 create mode 100644 Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml
 delete mode 100644 Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml
 delete mode 100644 Documentation/devicetree/bindings/sound/bt-sco.txt
 create mode 100644 Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
 create mode 100644 Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml
 delete mode 100644 Documentation/devicetree/bindings/sound/simple-amplifier.txt
 create mode 100644 Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml
 delete mode 100644 Documentation/devicetree/bindings/sound/spdif-transmitter.txt
 create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8978.yaml
 create mode 100644 Documentation/devicetree/bindings/usb/smsc,usb3503.yaml
 delete mode 100644 Documentation/devicetree/bindings/usb/usb3503.txt
 delete mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.txt
 create mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.yaml
Signature · 1 line
2.31.1

A message that is not in the archive (sent off-list or not yet received): 20210901091852.479202-1-maxime-R63rPqgGiG5yDzI6CaY1VQ@public.gmane.org

#2 lore raw

PATCH v2 5/52 dt-bindings: Convert Reserved Memory binding to a schema

The Reserved Memory mechanism is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Changes from v1:
- Fixed the license
- Added a mention that the file has moved
- Added a documentation for memory-region
- Split the reserved-memory binding in two: one for the generic part and one for shared-dma-pool

---
 .../reserved-memory/memory-region.yaml        |  40 ++++
 .../reserved-memory/reserved-memory.txt       | 172 +-----------------
 .../reserved-memory/reserved-memory.yaml      |  96 ++++++++++
 .../reserved-memory/shared-dma-pool.yaml      |  87 +++++++++
 4 files changed, 224 insertions(+), 171 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml
Documentation/devicetree/bindings/reserved-memory/memory-region.yaml new file +40 -0
new file mode 100644
index 000000000000..3f93d9f5aa2d
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/memory-region.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Reserved Memory Region Device Tree Binding
+
+maintainers:
+  - Devicetree Specification Mailing List <[email protected]>
+
+description: |
+  Regions in the /reserved-memory node may be referenced by other device
+  nodes by adding a memory-region property to the device node.
+
+select: true
+
+properties:
+  memory-region:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description: >
+      Phandle to a /reserved-memory child node assigned to the device.
+
+  memory-region-names:
+    $ref: /schemas/types.yaml#/definitions/string-array
+    description: >
+      A list of names, one for each corresponding entry in the
+      memory-region property
+
+additionalProperties: true
+
+examples:
+  - |
+    fb0: video@12300000 {
+        /* ... */
+        reg = <0x12300000 0x1000>;
+        memory-region = <&display_reserved>;
+    };
+
+...
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt +1 -171

172 lines not on this page · raw message

Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml new file +96 -0

96 lines not on this page · raw message

Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml new file +87 -0

87 lines not on this page · raw message

Signature · 1 line
2.31.1

A message that is not in the archive (sent off-list or not yet received): 20210901091852.479202-6-maxime-R63rPqgGiG5yDzI6CaY1VQ@public.gmane.org

#4 lore raw

Re: [PATCH v2 05/52] dt-bindings: Convert Reserved Memory binding to a schema

Quoted 8 lines · Maxime Ripard

The Reserved Memory mechanism is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Minor request. As device tree bindings are used and valid and applicable outside of Linux, it shouldn't be mentioned in the commit message either. This binding is just as valid for U-Boot, FreeBSD, etc as it is for Linux :) Thanks!

Signature · 1 line
Tom
#5 lore raw

Re: [PATCH v2 05/52] dt-bindings: Convert Reserved Memory binding to a schema

In reply to a message not in the archive
Quoted 17 lines · Maxime Ripard

The Reserved Memory mechanism is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Changes from v1:
- Fixed the license
- Added a mention that the file has moved
- Added a documentation for memory-region
- Split the reserved-memory binding in two: one for the generic part and one for shared-dma-pool

Quoted 10 lines
---
 .../reserved-memory/memory-region.yaml        |  40 ++++
 .../reserved-memory/reserved-memory.txt       | 172 +-----------------
 .../reserved-memory/reserved-memory.yaml      |  96 ++++++++++
 .../reserved-memory/shared-dma-pool.yaml      |  87 +++++++++
 4 files changed, 224 insertions(+), 171 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml

I reworked the commit msg and a couple of nits, and applied, thanks!

#6 lore raw

PATCH v2 1/52 ASoC: dt-bindings: Add WM8978 Binding

In reply to Maxime Ripard

Even though we had the wm8978 driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

---

Changes from v1:
- Changed the maintainers of the bindings

---
 .../devicetree/bindings/sound/wlf,wm8978.yaml | 58 +++++++++++++++++++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8978.yaml
Documentation/devicetree/bindings/sound/wlf,wm8978.yaml new file +58 -0
new file mode 100644
index 000000000000..944e5859c962
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/wlf,wm8978.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Wolfson WM8978 Codec Device Tree Bindings
+
+maintainers:
+  - [email protected]
+
+properties:
+  '#sound-dai-cells':
+    const: 0
+
+  compatible:
+    const: wlf,wm8978
+
+  reg:
+    maxItems: 1
+
+  spi-max-frequency:
+    maximum: 526000
+
+required:
+  - '#sound-dai-cells'
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    spi {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        codec@0 {
+            #sound-dai-cells = <0>;
+            compatible = "wlf,wm8978";
+            reg = <0>;
+            spi-max-frequency = <500000>;
+        };
+    };
+
+  - |
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        codec@0 {
+            #sound-dai-cells = <0>;
+            compatible = "wlf,wm8978";
+            reg = <0>;
+        };
+    };
+
+...
Signature · 1 line
2.31.1
Acked-by on v2 1/52
#7 lore raw

Re: [PATCH v2 01/52] ASoC: dt-bindings: Add WM8978 Binding

Quoted 12 lines · Maxime Ripard

Even though we had the wm8978 driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

Quoted 1 line

---

Thanks,
Charles

maintainer
#8 lore raw

Re: [PATCH v2 01/52] ASoC: dt-bindings: Add WM8978 Binding

In reply to Maxime Ripard
Quoted 3 lines · Maxime Ripard

Even though we had the wm8978 driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

What's the story with dependencies here? I don't have a cover letter or anything and there seem to be a bunch of tangentially related patches in a series here.

#9 lore raw

Re: [PATCH v2 01/52] ASoC: dt-bindings: Add WM8978 Binding

Hi Mark,

Quoted 8 lines · Mark Brown
Quoted 3 lines · Maxime Ripard

Even though we had the wm8978 driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

What's the story with dependencies here? I don't have a cover letter or anything and there seem to be a bunch of tangentially related patches in a series here.

There's no dependency, you can pick the ASoC patches safely

Maxime

maintainer
#10 lore raw

Re: [PATCH v2 01/52] ASoC: dt-bindings: Add WM8978 Binding

Quoted 7 lines · Maxime Ripard
Quoted 3 lines · Mark Brown

What's the story with dependencies here? I don't have a cover letter or anything and there seem to be a bunch of tangentially related patches in a series here.

There's no dependency, you can pick the ASoC patches safely

Oh, OK. In cases like this it's generally better to not combine random unrelated stuff into one series - as well as making it look like there are dependencies it can also cause problems for tooling (eg, b4 is going to want to fetch the whole series and my personal tooling doesn't like the same series going to more than one of the subsystems I maintain.

#11 lore raw

PATCH v2 2/52 ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema

In reply to Maxime Ripard

Bluetooth SCO Link are supported by Linux with a matching device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Changes from v1:
- Accept either a 0 or 1 #sound-dai-cells

---
 .../devicetree/bindings/sound/bt-sco.txt      | 13 -------
 .../bindings/sound/linux,bt-sco.yaml          | 38 +++++++++++++++++++
 2 files changed, 38 insertions(+), 13 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/sound/bt-sco.txt
 create mode 100644 Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
Documentation/devicetree/bindings/sound/bt-sco.txt deleted +0 -13
deleted file mode 100644
index 641edf75e184..000000000000
@@ -1,13 +0,0 @@
-Bluetooth-SCO audio CODEC
-
-This device support generic Bluetooth SCO link.
-
-Required properties:
-
-  - compatible : "delta,dfbmcs320" or "linux,bt-sco"
-
-Example:
-
-codec: bt_sco {
-	compatible = "delta,dfbmcs320";
-};
Documentation/devicetree/bindings/sound/linux,bt-sco.yaml new file +38 -0
new file mode 100644
index 000000000000..e3a1f485f664
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/linux,bt-sco.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bluetooth SCO Audio Codec Device Tree Bindings
+
+maintainers:
+  - Mark Brown <[email protected]>
+
+properties:
+  '#sound-dai-cells':
+    enum:
+      - 0
+
+      # For Wideband PCM
+      - 1
+
+  compatible:
+    enum:
+      - delta,dfbmcs320
+      - linux,bt-sco
+
+required:
+  - '#sound-dai-cells'
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+    codec {
+        #sound-dai-cells = <0>;
+        compatible = "linux,bt-sco";
+    };
+
+...
Signature · 1 line
2.31.1
maintainer Reviewed-by on v2 2/52
#12 lore raw

Re: [PATCH v2 02/52] ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema

Quoted 15 lines · Maxime Ripard

Bluetooth SCO Link are supported by Linux with a matching device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Quoted 9 lines

Changes from v1:
- Accept either a 0 or 1 #sound-dai-cells

---
 .../devicetree/bindings/sound/bt-sco.txt      | 13 -------
 .../bindings/sound/linux,bt-sco.yaml          | 38 +++++++++++++++++++
 2 files changed, 38 insertions(+), 13 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/sound/bt-sco.txt
 create mode 100644 Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
#13 lore raw

PATCH v2 3/52 ASoC: dt-bindings: Convert SPDIF Transmitter binding to a schema

In reply to Maxime Ripard

The SPDIF Transmitter binding is used by Linux with a matching Device Tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---
 .../bindings/sound/linux,spdif-dit.yaml       | 32 +++++++++++++++++++
 .../bindings/sound/spdif-transmitter.txt      | 10 ------
 2 files changed, 32 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml
 delete mode 100644 Documentation/devicetree/bindings/sound/spdif-transmitter.txt
Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml new file +32 -0
new file mode 100644
index 000000000000..c6b070e1d014
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/linux,spdif-dit.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dummy SPDIF Transmitter Device Tree Bindings
+
+maintainers:
+  - Mark Brown <[email protected]>
+
+properties:
+  compatible:
+    const: linux,spdif-dit
+
+  "#sound-dai-cells":
+    const: 0
+
+required:
+  - "#sound-dai-cells"
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+    spdif-out {
+        #sound-dai-cells = <0>;
+        compatible = "linux,spdif-dit";
+    };
+
+...
Documentation/devicetree/bindings/sound/spdif-transmitter.txt deleted +0 -10
deleted file mode 100644
index 55a85841dd85..000000000000
@@ -1,10 +0,0 @@
-Device-Tree bindings for dummy spdif transmitter
-
-Required properties:
-	- compatible: should be "linux,spdif-dit".
-
-Example node:
-
-	codec: spdif-transmitter {
-		compatible = "linux,spdif-dit";
-	};
Signature · 1 line
2.31.1
#14 lore raw

PATCH v2 4/52 ASoC: dt-bindings: Convert Simple Amplifier binding to a schema

In reply to Maxime Ripard

Simple audio amplifiers are supported by Linux with a matching device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---
 .../bindings/sound/simple-amplifier.txt       | 17 -------
 .../sound/simple-audio-amplifier.yaml         | 45 +++++++++++++++++++
 2 files changed, 45 insertions(+), 17 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/sound/simple-amplifier.txt
 create mode 100644 Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml
Documentation/devicetree/bindings/sound/simple-amplifier.txt deleted +0 -17
deleted file mode 100644
index b1b097cc9b68..000000000000
@@ -1,17 +0,0 @@
-Simple Amplifier Audio Driver
-
-Required properties:
-- compatible : "dioo,dio2125" or "simple-audio-amplifier"
-
-Optional properties:
-- enable-gpios : the gpio connected to the enable pin of the simple amplifier
-- VCC-supply   : power supply for the device, as covered
-                 in Documentation/devicetree/bindings/regulator/regulator.txt
-
-Example:
-
-amp: analog-amplifier {
-	compatible = "simple-audio-amplifier";
-	VCC-supply = <&regulator>;
-	enable-gpios = <&gpio GPIOH_3 0>;
-};
Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml new file +45 -0

45 lines not on this page · raw message

Signature · 1 line
2.31.1
#15 lore raw

PATCH v2 6/52 dt-bindings: arm: Convert ARM CCI-400 binding to a schema

In reply to Maxime Ripard

The ARM CCI-400 Interconnect is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Lorenzo Pieralisi <[email protected]>

---

Changes from v1:
- Reduced the max number of interrupts
- Comented the pl330 compatible to avoid a warning
- Added cci-control-port to the cpus schemas

---
 .../devicetree/bindings/arm/arm,cci-400.yaml  | 216 +++++++++++++++++
 .../bindings/arm/cci-control-port.yaml        |  38 +++
 Documentation/devicetree/bindings/arm/cci.txt | 224 ------------------
 .../devicetree/bindings/arm/cpus.yaml         |   2 +
 4 files changed, 256 insertions(+), 224 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/arm,cci-400.yaml
 create mode 100644 Documentation/devicetree/bindings/arm/cci-control-port.yaml
 delete mode 100644 Documentation/devicetree/bindings/arm/cci.txt
Documentation/devicetree/bindings/arm/arm,cci-400.yaml new file +216 -0
new file mode 100644
index 000000000000..4682f991a5c8
@@ -0,0 +1,216 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,cci-400.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM CCI Cache Coherent Interconnect Device Tree Binding
+
+maintainers:
+  - Lorenzo Pieralisi <[email protected]>
+
+description: >
+  ARM multi-cluster systems maintain intra-cluster coherency through a cache
+  coherent interconnect (CCI) that is capable of monitoring bus transactions
+  and manage coherency, TLB invalidations and memory barriers.
+
+  It allows snooping and distributed virtual memory message broadcast across
+  clusters, through memory mapped interface, with a global control register
+  space and multiple sets of interface control registers, one per slave
+  interface.
+
+properties:
+  $nodename:
+    pattern: "^cci(@[0-9a-f]+)?$"
+
+  compatible:
+    enum:
+      - arm,cci-400
+      - arm,cci-500
+      - arm,cci-550
+
+  reg:
+    maxItems: 1
+    description: >
+      Specifies base physical address of CCI control registers common to all
+      interfaces.
+
+  "#address-cells": true
+  "#size-cells": true
+  ranges: true
+
+patternProperties:
+  "^slave-if@[0-9a-f]+$":
+    type: object
+
+    properties:
+      compatible:
+        const: arm,cci-400-ctrl-if
+
+      interface-type:
+        enum:
+          - ace
+          - ace-lite
+
+      reg:
+        maxItems: 1
+
+    required:
+      - compatible
+      - interface-type
+      - reg
+
+    additionalProperties: false
+
+  "^pmu@[0-9a-f]+$":
+    type: object
+
+    properties:
+      compatible:
+        oneOf:
+          - const: arm,cci-400-pmu,r0
+          - const: arm,cci-400-pmu,r1
+          - const: arm,cci-400-pmu
+            deprecated: true
+            description: >
+              Permitted only where OS has secure access to CCI registers
+          - const: arm,cci-500-pmu,r0
+          - const: arm,cci-550-pmu,r0
+
+      interrupts:
+        minItems: 1
+        maxItems: 8
+        description: >
+          List of counter overflow interrupts, one per counter. The interrupts
+          must be specified starting with the cycle counter overflow interrupt,
+          followed by counter0 overflow interrupt, counter1 overflow
+          interrupt,...  ,counterN overflow interrupt.
+
+          The CCI PMU has an interrupt signal for each counter. The number of
+          interrupts must be equal to the number of counters.
+
+      reg:
+        maxItems: 1
+
+    required:
+      - compatible
+      - interrupts
+      - reg
+
+    additionalProperties: false
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - compatible
+  - ranges
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+      / {
+          #address-cells = <2>;
+          #size-cells = <2>;
+
+          compatible = "arm,vexpress,v2p-ca15_a7", "arm,vexpress";
+          model = "V2P-CA15_CA7";
+          arm,hbi = <0x249>;
+          interrupt-parent = <&gic>;
+
+          /*
+           * This CCI node corresponds to a CCI component whose control
+           * registers sits at address 0x000000002c090000.
+           *
+           * CCI slave interface @0x000000002c091000 is connected to dma
+           * controller dma0.
+           *
+           * CCI slave interface @0x000000002c094000 is connected to CPUs
+           * {CPU0, CPU1};
+           *
+           * CCI slave interface @0x000000002c095000 is connected to CPUs
+           * {CPU2, CPU3};
+           */
+
+          cpus {
+              #size-cells = <0>;
+              #address-cells = <1>;
+
+              CPU0: cpu@0 {
+                  device_type = "cpu";
+                  compatible = "arm,cortex-a15";
+                  cci-control-port = <&cci_control1>;
+                  reg = <0x0>;
+              };
+
+              CPU1: cpu@1 {
+                  device_type = "cpu";
+                  compatible = "arm,cortex-a15";
+                  cci-control-port = <&cci_control1>;
+                  reg = <0x1>;
+              };
+
+              CPU2: cpu@100 {
+                  device_type = "cpu";
+                  compatible = "arm,cortex-a7";
+                  cci-control-port = <&cci_control2>;
+                  reg = <0x100>;
+              };
+
+              CPU3: cpu@101 {
+                  device_type = "cpu";
+                  compatible = "arm,cortex-a7";
+                  cci-control-port = <&cci_control2>;
+                  reg = <0x101>;
+              };
+          };
+
+          dma0: dma@3000000 {
+              /* compatible = "arm,pl330", "arm,primecell"; */
+              cci-control-port = <&cci_control0>;
+              reg = <0x0 0x3000000 0x0 0x1000>;
+              interrupts = <10>;
+              #dma-cells = <1>;
+              #dma-channels = <8>;
+              #dma-requests = <32>;
+          };
+
+          cci@2c090000 {
+              compatible = "arm,cci-400";
+              #address-cells = <1>;
+              #size-cells = <1>;
+              reg = <0x0 0x2c090000 0 0x1000>;
+              ranges = <0x0 0x0 0x2c090000 0x10000>;
+
+              cci_control0: slave-if@1000 {
+                  compatible = "arm,cci-400-ctrl-if";
+                  interface-type = "ace-lite";
+                  reg = <0x1000 0x1000>;
+              };
+
+              cci_control1: slave-if@4000 {
+                  compatible = "arm,cci-400-ctrl-if";
+                  interface-type = "ace";
+                  reg = <0x4000 0x1000>;
+              };
+
+              cci_control2: slave-if@5000 {
+                  compatible = "arm,cci-400-ctrl-if";
+                  interface-type = "ace";
+                  reg = <0x5000 0x1000>;
+              };
+
+              pmu@9000 {
+                  compatible = "arm,cci-400-pmu";
+                  reg = <0x9000 0x5000>;
+                  interrupts = <0 101 4>,
+                    <0 102 4>,
+                    <0 103 4>,
+                    <0 104 4>,
+                    <0 105 4>;
+              };
+          };
+      };
+
+...
Documentation/devicetree/bindings/arm/cci-control-port.yaml new file +38 -0
new file mode 100644
index 000000000000..c9114866213f
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/cci-control-port.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: CCI Interconnect Bus Masters binding
+
+maintainers:
+  - Lorenzo Pieralisi <[email protected]>
+
+description: |
+  Masters in the device tree connected to a CCI port (inclusive of CPUs
+  and their cpu nodes).
+
+select: true
+
+properties:
+  cci-control-port:
+    $ref: /schemas/types.yaml#/definitions/phandle
+
+additionalProperties: true
+
+examples:
+  - |
+    cpus {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        cpu@0 {
+            compatible = "arm,cortex-a15";
+            device_type = "cpu";
+            cci-control-port = <&cci_control1>;
+            reg = <0>;
+        };
+    };
+
+...
Documentation/devicetree/bindings/arm/cci.txt deleted +0 -224

224 lines not on this page · raw message

Documentation/devicetree/bindings/arm/cpus.yaml +2 -0
index 9a2432a88074..35b552ce8803 100644
@@ -240,6 +240,8 @@ properties:
       DMIPS/MHz, relative to highest capacity-dmips-mhz
       in the system.
 
+  cci-control-port: true
+
   dynamic-power-coefficient:
     $ref: '/schemas/types.yaml#/definitions/uint32'
     description:
Signature · 1 line
2.31.1
maintainer Applied
#16 lore raw

Re: [PATCH v2 06/52] dt-bindings: arm: Convert ARM CCI-400 binding to a schema

Quoted 15 lines · Maxime Ripard

The ARM CCI-400 Interconnect is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Lorenzo Pieralisi <[email protected]>

---

Changes from v1:
- Reduced the max number of interrupts
- Comented the pl330 compatible to avoid a warning
- Added cci-control-port to the cpus schemas

Quoted 10 lines
---
 .../devicetree/bindings/arm/arm,cci-400.yaml  | 216 +++++++++++++++++
 .../bindings/arm/cci-control-port.yaml        |  38 +++
 Documentation/devicetree/bindings/arm/cci.txt | 224 ------------------
 .../devicetree/bindings/arm/cpus.yaml         |   2 +
 4 files changed, 256 insertions(+), 224 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/arm,cci-400.yaml
 create mode 100644 Documentation/devicetree/bindings/arm/cci-control-port.yaml
 delete mode 100644 Documentation/devicetree/bindings/arm/cci.txt

Applied, thanks!

#17 lore raw

PATCH v2 7/52 dt-bindings: bluetooth: broadcom: Fix clocks check

In reply to Maxime Ripard

The original binding was mentioning that valid values for the clocks and clock-names property were one or two clocks from extclk, txco and lpo, with extclk being deprecated in favor of txco.

However, the current binding lists a valid array as extclk, txco and lpo, with either one or two items.

While this looks similar, it actually enforces that all the device trees use either ["extclk"], or ["extclk", "txco"]. That doesn't make much sense, since the two clocks are said to be equivalent, with one superseeding the other.

lpo is also not a valid clock anymore, and would be as the third clock of the list, while we could have only this clock in the previous binding (and in DTs).

Let's rework the clock clause to allow to have either:

- extclk, and mark it a deprecated
- txco alone
- lpo alone
- txco, lpo

While ["extclk", "lpo"] wouldn't be valid, it wasn't found in any device tree so it's not an issue in practice.

Similarly, ["lpo", "txco"] is still considered invalid, but it's generally considered as a best practice to fix the order of clocks.

---
 .../bindings/net/broadcom-bluetooth.yaml        | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml +15 -2
index fbdc2083bec4..5aac094fd217 100644
@@ -50,16 +50,29 @@ properties:
       by interrupts and "host-wakeup" interrupt-names
 
   clocks:
+    minItems: 1
     maxItems: 2
     description: 1 or 2 clocks as defined in clock-names below,
       in that order
 
   clock-names:
     description: Names of the 1 to 2 supplied clocks
-    items:
+    oneOf:
+      - const: extclk
+        deprecated: true
+        description: Deprecated in favor of txco
+
       - const: txco
+        description: >
+          external reference clock (not a standalone crystal)
+
       - const: lpo
-      - const: extclk
+        description: >
+          external low power 32.768 kHz clock
+
+      - items:
+          - const: txco
+          - const: lpo
 
   vbat-supply:
     description: phandle to regulator supply for VBAT
Signature · 1 line
2.31.1
Reviewed-by on v2 7/52
#18 lore raw

Re: [PATCH v2 07/52] dt-bindings: bluetooth: broadcom: Fix clocks check

Quoted 29 lines · Maxime Ripard

The original binding was mentioning that valid values for the clocks and clock-names property were one or two clocks from extclk, txco and lpo, with extclk being deprecated in favor of txco.

However, the current binding lists a valid array as extclk, txco and lpo, with either one or two items.

While this looks similar, it actually enforces that all the device trees use either ["extclk"], or ["extclk", "txco"]. That doesn't make much sense, since the two clocks are said to be equivalent, with one superseeding the other.

lpo is also not a valid clock anymore, and would be as the third clock of the list, while we could have only this clock in the previous binding (and in DTs).

Let's rework the clock clause to allow to have either:

- extclk, and mark it a deprecated
- txco alone
- lpo alone
- txco, lpo

While ["extclk", "lpo"] wouldn't be valid, it wasn't found in any device tree so it's not an issue in practice.

Similarly, ["lpo", "txco"] is still considered invalid, but it's generally considered as a best practice to fix the order of clocks.

Quoted 6 lines

Looks good to me!

Yours,
Linus Walleij

#19 lore raw

PATCH v2 8/52 dt-bindings: bluetooth: realtek: Add missing max-speed

In reply to Maxime Ripard

additionalProperties prevent any property not explicitly defined in the binding to be used. Yet, some serial properties like max-speed are valid and validated through the serial/serial.yaml binding.

Even though the ideal solution would be to use unevaluatedProperties instead, it's not pratical due to the way the bus bindings have been described. Let's add max-speed to remove the warning.

Cc Alistair Francis <[email protected]>
Cc "David S. Miller" <[email protected]>
Cc Jakub Kicinski <[email protected]>
Cc Vasily Khoruzhick <[email protected]>
---
 Documentation/devicetree/bindings/net/realtek-bluetooth.yaml | 2 ++
 1 file changed, 2 insertions(+)
Documentation/devicetree/bindings/net/realtek-bluetooth.yaml +2 -0
index 0634e69dd9a6..157d606bf9cb 100644
@@ -34,6 +34,8 @@ properties:
     maxItems: 1
     description: GPIO specifier, used to wakeup the host processor
 
+  max-speed: true
+
 required:
   - compatible
 
Signature · 1 line
2.31.1
#20 lore raw

PATCH v2 9/52 dt-bindings: clocks: Fix typo in the H6 compatible

In reply to Maxime Ripard

Even though both the driver and the device trees all use the allwinner,sun50i-h6-de3-clk, we documented the compatible as allwinner,sun50i-h6-de2-clk in the binding. Let's fix this.

---
 .../devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml +1 -1
index 3f995d2b30eb..e79eeac5f086 100644
@@ -24,7 +24,7 @@ properties:
       - const: allwinner,sun8i-v3s-de2-clk
       - const: allwinner,sun50i-a64-de2-clk
       - const: allwinner,sun50i-h5-de2-clk
-      - const: allwinner,sun50i-h6-de2-clk
+      - const: allwinner,sun50i-h6-de3-clk
       - items:
           - const: allwinner,sun8i-r40-de2-clk
           - const: allwinner,sun8i-h3-de2-clk
Signature · 1 line
2.31.1
maintainer Reviewed-by on v2 9/52
#21 lore raw

Re: [PATCH v2 09/52] dt-bindings: clocks: Fix typo in the H6 compatible

Dne sreda, 01. september 2021 ob 11:18:09 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

Even though both the driver and the device trees all use the allwinner,sun50i-h6-de3-clk, we documented the compatible as allwinner,sun50i-h6-de2-clk in the binding. Let's fix this.

Best regards,
Jernej

author Applied
#22 lore raw

Re: [PATCH v2 09/52] dt-bindings: clocks: Fix typo in the H6 compatible

Quoted 9 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:09 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

Even though both the driver and the device trees all use the allwinner,sun50i-h6-de3-clk, we documented the compatible as allwinner,sun50i-h6-de2-clk in the binding. Let's fix this.

Applied, thanks
Maxime

#23 lore raw

PATCH v2 10/52 dt-bindings: display: Move idk-1110wr to panel-lvds

In reply to Maxime Ripard

The Advantech IDK-2121WR Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding aside from a requirement on the data-mapping.

Let's move it to the generic panel-lvds binding

Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../display/panel/advantech,idk-1110wr.yaml   | 69 -------------------
 .../bindings/display/panel/lvds.yaml          | 22 ++++--
 2 files changed, 15 insertions(+), 76 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml deleted +0 -69
deleted file mode 100644
index 93878c2cd370..000000000000
@@ -1,69 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/panel/advantech,idk-1110wr.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Advantech IDK-1110WR 10.1" WSVGA LVDS Display Panel
-
-maintainers:
-  - Lad Prabhakar <[email protected]>
-  - Thierry Reding <[email protected]>
-
-allOf:
-  - $ref: lvds.yaml#
-
-properties:
-  compatible:
-    items:
-      - const: advantech,idk-1110wr
-      - {} # panel-lvds, but not listed here to avoid false select
-
-  data-mapping:
-    const: jeida-24
-
-  width-mm:
-    const: 223
-
-  height-mm:
-    const: 125
-
-  panel-timing: true
-  port: true
-
-additionalProperties: false
-
-required:
-  - compatible
-
-examples:
-  - |+
-    panel {
-      compatible = "advantech,idk-1110wr", "panel-lvds";
-
-      width-mm = <223>;
-      height-mm = <125>;
-
-      data-mapping = "jeida-24";
-
-      panel-timing {
-        /* 1024x600 @60Hz */
-        clock-frequency = <51200000>;
-        hactive = <1024>;
-        vactive = <600>;
-        hsync-len = <240>;
-        hfront-porch = <40>;
-        hback-porch = <40>;
-        vsync-len = <10>;
-        vfront-porch = <15>;
-        vback-porch = <10>;
-      };
-
-      port {
-        panel_in: endpoint {
-          remote-endpoint = <&lvds_encoder>;
-        };
-      };
-    };
-
-...
Documentation/devicetree/bindings/display/panel/lvds.yaml +15 -7
index 49460c9dceea..e4e49e06f302 100644
@@ -28,15 +28,23 @@ description: |+
 
 allOf:
   - $ref: panel-common.yaml#
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: advantech,idk-1110wr
+
+    then:
+      properties:
+        data-mapping:
+          const: jeida-24
 
 properties:
   compatible:
-    contains:
-      const: panel-lvds
-    description:
-      Shall contain "panel-lvds" in addition to a mandatory panel-specific
-      compatible string defined in individual panel bindings. The "panel-lvds"
-      value shall never be used on its own.
+    items:
+      - enum:
+          - advantech,idk-1110wr
+      - const: panel-lvds
 
   data-mapping:
     enum:
@@ -112,6 +120,6 @@ oneOf:
   - required:
       - ports
 
-additionalProperties: true
+unevaluatedProperties: false
 
 ...
Signature · 1 line
2.31.1
maintainer
#24 lore raw

Re: [PATCH v2 10/52] dt-bindings: display: Move idk-1110wr to panel-lvds

Quoted 5 lines · Maxime Ripard

The Advantech IDK-2121WR Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding aside from a requirement on the data-mapping.

Let's move it to the generic panel-lvds binding

I'm concerned this change means we can only have LVDS panel schemas in lvds.yaml. Having another LVDS panel schema means 2 things. First, they can't have a 'panel-lvds' compatible. That's probably fine. Second, they will still need to define 'data-mapping' (unless implied) and will need to include it from somewhere. So we still need a common LVDS properties schema and panel schema(s).

Rob

#25 lore raw

PATCH v2 11/52 dt-bindings: display: Move idk-2121wr to panel-lvds

In reply to Maxime Ripard

The Advantech IDK-2121WR Device Tree binding uses most of the panel-lvds binding, aside from a requirement on the data-mapping and the definition of the dual link binding.

The LVDS dual link binding applies to any panel with a dual-link setup, and thus could be made generic, and we can move the data-mapping requirement to a conditional.

Let's move it to the generic panel-lvds binding

Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../display/panel/advantech,idk-2121wr.yaml   | 121 ------------------
 .../bindings/display/panel/lvds.yaml          |  88 ++++++++++++-
 2 files changed, 87 insertions(+), 122 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml deleted +0 -121
deleted file mode 100644
index 67682fe77f10..000000000000
@@ -1,121 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/panel/advantech,idk-2121wr.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Advantech IDK-2121WR 21.5" Full-HD dual-LVDS panel
-
-maintainers:
-  - Lad Prabhakar <[email protected]>
-  - Thierry Reding <[email protected]>
-
-description: |
-  The IDK-2121WR from Advantech is a Full-HD dual-LVDS panel.
-  A dual-LVDS interface is a dual-link connection with even pixels traveling
-  on one link, and with odd pixels traveling on the other link.
-
-  The panel expects odd pixels on the first port, and even pixels on the
-  second port, therefore the ports must be marked accordingly (with either
-  dual-lvds-odd-pixels or dual-lvds-even-pixels).
-
-properties:
-  compatible:
-    items:
-      - const: advantech,idk-2121wr
-      - {} # panel-lvds, but not listed here to avoid false select
-
-  width-mm:
-    const: 476
-
-  height-mm:
-    const: 268
-
-  data-mapping:
-    const: vesa-24
-
-  panel-timing: true
-
-  ports:
-    $ref: /schemas/graph.yaml#/properties/ports
-
-    properties:
-      port@0:
-        $ref: /schemas/graph.yaml#/$defs/port-base
-        unevaluatedProperties: false
-        description: The sink for odd pixels.
-        properties:
-          dual-lvds-odd-pixels: true
-
-        required:
-          - dual-lvds-odd-pixels
-
-      port@1:
-        $ref: /schemas/graph.yaml#/$defs/port-base
-        unevaluatedProperties: false
-        description: The sink for even pixels.
-        properties:
-          dual-lvds-even-pixels: true
-
-        required:
-          - dual-lvds-even-pixels
-
-    required:
-      - port@0
-      - port@1
-
-additionalProperties: false
-
-required:
-  - compatible
-  - width-mm
-  - height-mm
-  - data-mapping
-  - panel-timing
-  - ports
-
-examples:
-  - |+
-    panel-lvds {
-      compatible = "advantech,idk-2121wr", "panel-lvds";
-
-      width-mm = <476>;
-      height-mm = <268>;
-
-      data-mapping = "vesa-24";
-
-      panel-timing {
-        clock-frequency = <148500000>;
-        hactive = <1920>;
-        vactive = <1080>;
-        hsync-len = <44>;
-        hfront-porch = <88>;
-        hback-porch = <148>;
-        vfront-porch = <4>;
-        vback-porch = <36>;
-        vsync-len = <5>;
-      };
-
-      ports {
-        #address-cells = <1>;
-        #size-cells = <0>;
-
-        port@0 {
-          reg = <0>;
-          dual-lvds-odd-pixels;
-          panel_in0: endpoint {
-            remote-endpoint = <&lvds0_out>;
-          };
-        };
-
-        port@1 {
-          reg = <1>;
-          dual-lvds-even-pixels;
-          panel_in1: endpoint {
-            remote-endpoint = <&lvds1_out>;
-          };
-        };
-      };
-    };
-
-...
Documentation/devicetree/bindings/display/panel/lvds.yaml +87 -1

109 lines not on this page · raw message

Signature · 1 line
2.31.1
#26 lore raw

PATCH v2 12/52 dt-bindings: display: Move ee101ia-01d to panel-lvds

In reply to Maxime Ripard

The Innolux EE101IA-01D Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding. Let's move it to the generic panel-lvds binding

Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../display/panel/innolux,ee101ia-01d.yaml    | 31 -------------------
 .../bindings/display/panel/lvds.yaml          |  1 +
 2 files changed, 1 insertion(+), 31 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml deleted +0 -31
deleted file mode 100644
index a69681e724cb..000000000000
@@ -1,31 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/panel/innolux,ee101ia-01d.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
-
-maintainers:
-  - Heiko Stuebner <[email protected]>
-  - Thierry Reding <[email protected]>
-
-allOf:
-  - $ref: lvds.yaml#
-
-properties:
-  compatible:
-    items:
-      - const: innolux,ee101ia-01d
-      - {} # panel-lvds, but not listed here to avoid false select
-
-  backlight: true
-  enable-gpios: true
-  power-supply: true
-  width-mm: true
-  height-mm: true
-  panel-timing: true
-  port: true
-
-additionalProperties: false
-...
Documentation/devicetree/bindings/display/panel/lvds.yaml +1 -0
index 9b3b329e4e67..91a6d97a96e0 100644
@@ -59,6 +59,7 @@ properties:
       - enum:
           - advantech,idk-1110wr
           - advantech,idk-2121wr
+          - innolux,ee101ia-01d
       - const: panel-lvds
 
   data-mapping:
Signature · 1 line
2.31.1
#27 lore raw

PATCH v2 13/52 dt-bindings: display: aa104xd12: Remove unused vcc-supply

In reply to Maxime Ripard

The Mitsubishi AA140XD12 Device Tree Binding was requiring a vcc-supply property. However, neither the existing device trees using that binding, nor the driver were actually using that property which is also redundant with power-supply. Let's just drop it.

Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../bindings/display/panel/mitsubishi,aa104xd12.yaml         | 5 -----
 1 file changed, 5 deletions(-)
Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml +0 -5
index b5e7ee230fa6..b595edd58bbb 100644
@@ -19,9 +19,6 @@ properties:
       - const: mitsubishi,aa104xd12
       - {} # panel-lvds, but not listed here to avoid false select
 
-  vcc-supply:
-    description: Reference to the regulator powering the panel VCC pins.
-
   data-mapping:
     const: jeida-24
 
@@ -38,14 +35,12 @@ additionalProperties: false
 
 required:
   - compatible
-  - vcc-supply
 
 examples:
   - |+
 
     panel {
       compatible = "mitsubishi,aa104xd12", "panel-lvds";
-      vcc-supply = <&vcc_3v3>;
 
       width-mm = <210>;
       height-mm = <158>;
Signature · 1 line
2.31.1
maintainer Acked-by on v2 13/52
#28 lore raw

Re: [PATCH v2 13/52] dt-bindings: display: aa104xd12: Remove unused vcc-supply

Quoted 5 lines · Maxime Ripard

The Mitsubishi AA140XD12 Device Tree Binding was requiring a vcc-supply property. However, neither the existing device trees using that binding, nor the driver were actually using that property which is also redundant with power-supply. Let's just drop it.

Quoted 9 lines
Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../bindings/display/panel/mitsubishi,aa104xd12.yaml         | 5 -----
 1 file changed, 5 deletions(-)
#29 lore raw

PATCH v2 14/52 dt-bindings: display: aa104xd12: Fix data-mapping

In reply to Maxime Ripard

The Mitsubishi AA140XD12 Device Tree Binding was requiring a data-mapping property value which was set to another value in the existing Device Trees. Fix this.

Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../bindings/display/panel/mitsubishi,aa104xd12.yaml          | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml +2 -2
index b595edd58bbb..2d1c85e377cd 100644
@@ -20,7 +20,7 @@ properties:
       - {} # panel-lvds, but not listed here to avoid false select
 
   data-mapping:
-    const: jeida-24
+    const: jeida-18
 
   width-mm:
     const: 210
@@ -45,7 +45,7 @@ examples:
       width-mm = <210>;
       height-mm = <158>;
 
-      data-mapping = "jeida-24";
+      data-mapping = "jeida-18";
 
       panel-timing {
         /* 1024x768 @65Hz */
Signature · 1 line
2.31.1
maintainer Acked-by on v2 14/52
#30 lore raw

Re: [PATCH v2 14/52] dt-bindings: display: aa104xd12: Fix data-mapping

Quoted 4 lines · Maxime Ripard

The Mitsubishi AA140XD12 Device Tree Binding was requiring a data-mapping property value which was set to another value in the existing Device Trees. Fix this.

Quoted 9 lines
Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../bindings/display/panel/mitsubishi,aa104xd12.yaml          | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
#31 lore raw

PATCH v2 15/52 dt-bindings: display: Move aa104xd12 to panel-lvds

In reply to Maxime Ripard

The Mitsubishi AA104XD12 Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding aside from a requirement on the data-mapping.

Let's move it to the generic panel-lvds binding

Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../bindings/display/panel/lvds.yaml          | 12 ++++
 .../display/panel/mitsubishi,aa104xd12.yaml   | 70 -------------------
 2 files changed, 12 insertions(+), 70 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
Documentation/devicetree/bindings/display/panel/lvds.yaml +12 -0
index 91a6d97a96e0..09a818a60f2e 100644
@@ -28,6 +28,17 @@ description: |+
 
 allOf:
   - $ref: panel-common.yaml#
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: mitsubishi,aa104xd12
+
+    then:
+      properties:
+        data-mapping:
+          const: jeida-18
+
   - if:
       properties:
         compatible:
@@ -60,6 +71,7 @@ properties:
           - advantech,idk-1110wr
           - advantech,idk-2121wr
           - innolux,ee101ia-01d
+          - mitsubishi,aa104xd12
       - const: panel-lvds
 
   data-mapping:
Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml deleted +0 -70

70 lines not on this page · raw message

Signature · 1 line
2.31.1
#32 lore raw

PATCH v2 16/52 dt-bindings: display: aa121td01: Remove unused vcc-supply

In reply to Maxime Ripard

The Mitsubishi AA121TD01 Device Tree Binding was requiring a vcc-supply property. However, neither the existing device trees using that binding, nor the driver were actually using that property which is also redundant with power-supply. Let's just drop it.

Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../bindings/display/panel/mitsubishi,aa121td01.yaml         | 5 -----
 1 file changed, 5 deletions(-)
Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml +0 -5
index 977c50a85b67..b0f1d4eff12d 100644
@@ -19,9 +19,6 @@ properties:
       - const: mitsubishi,aa121td01
       - {} # panel-lvds, but not listed here to avoid false select
 
-  vcc-supply:
-    description: Reference to the regulator powering the panel VCC pins.
-
   data-mapping:
     const: jeida-24
 
@@ -38,13 +35,11 @@ additionalProperties: false
 
 required:
   - compatible
-  - vcc-supply
 
 examples:
   - |+
     panel {
       compatible = "mitsubishi,aa121td01", "panel-lvds";
-      vcc-supply = <&vcc_3v3>;
 
       width-mm = <261>;
       height-mm = <163>;
Signature · 1 line
2.31.1
maintainer Acked-by on v2 16/52
#33 lore raw

Re: [PATCH v2 16/52] dt-bindings: display: aa121td01: Remove unused vcc-supply

Quoted 5 lines · Maxime Ripard

The Mitsubishi AA121TD01 Device Tree Binding was requiring a vcc-supply property. However, neither the existing device trees using that binding, nor the driver were actually using that property which is also redundant with power-supply. Let's just drop it.

Quoted 9 lines
Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../bindings/display/panel/mitsubishi,aa121td01.yaml         | 5 -----
 1 file changed, 5 deletions(-)
#34 lore raw

PATCH v2 17/52 dt-bindings: display: aa121td01: Fix data-mapping

In reply to Maxime Ripard

The Mitsubishi AA121TD01 Device Tree Binding was requiring a data-mapping property value which was set to another value in the existing Device Trees. Fix this.

Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../bindings/display/panel/mitsubishi,aa121td01.yaml          | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml +2 -2
index b0f1d4eff12d..467a0ed4d444 100644
@@ -20,7 +20,7 @@ properties:
       - {} # panel-lvds, but not listed here to avoid false select
 
   data-mapping:
-    const: jeida-24
+    const: jeida-18
 
   width-mm:
     const: 261
@@ -44,7 +44,7 @@ examples:
       width-mm = <261>;
       height-mm = <163>;
 
-      data-mapping = "jeida-24";
+      data-mapping = "jeida-18";
 
       panel-timing {
         /* 1280x800 @60Hz */
Signature · 1 line
2.31.1
maintainer Acked-by on v2 17/52
#35 lore raw

Re: [PATCH v2 17/52] dt-bindings: display: aa121td01: Fix data-mapping

Quoted 4 lines · Maxime Ripard

The Mitsubishi AA121TD01 Device Tree Binding was requiring a data-mapping property value which was set to another value in the existing Device Trees. Fix this.

Quoted 9 lines
Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../bindings/display/panel/mitsubishi,aa121td01.yaml          | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
#36 lore raw

PATCH v2 18/52 dt-bindings: display: Move aa121td01 to panel-lvds

In reply to Maxime Ripard

The Mitsubishi AA121TD01 Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding aside from a requirement on the data-mapping.

Let's move it to the generic panel-lvds binding

Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../bindings/display/panel/lvds.yaml          |  5 +-
 .../display/panel/mitsubishi,aa121td01.yaml   | 69 -------------------
 2 files changed, 4 insertions(+), 70 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
Documentation/devicetree/bindings/display/panel/lvds.yaml +4 -1
index 09a818a60f2e..22f6cf1e134d 100644
@@ -32,7 +32,9 @@ allOf:
       properties:
         compatible:
           contains:
-            const: mitsubishi,aa104xd12
+            enum:
+              - mitsubishi,aa104xd12
+              - mitsubishi,aa121td01
 
     then:
       properties:
@@ -72,6 +74,7 @@ properties:
           - advantech,idk-2121wr
           - innolux,ee101ia-01d
           - mitsubishi,aa104xd12
+          - mitsubishi,aa121td01
       - const: panel-lvds
 
   data-mapping:
Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml deleted +0 -69

69 lines not on this page · raw message

Signature · 1 line
2.31.1
#37 lore raw

PATCH v2 19/52 dt-bindings: display: Move gktw70sdae4se to panel-lvds

In reply to Maxime Ripard

The Solomon Goldentek Display GKTW70SDAE4SE Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding aside from a requirement on the data-mapping.

Let's move it to the generic panel-lvds binding

Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 .../bindings/display/panel/lvds.yaml          |  2 +
 .../display/panel/sgd,gktw70sdae4se.yaml      | 68 -------------------
 2 files changed, 2 insertions(+), 68 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
Documentation/devicetree/bindings/display/panel/lvds.yaml +2 -0
index 22f6cf1e134d..1563d57bc793 100644
@@ -35,6 +35,7 @@ allOf:
             enum:
               - mitsubishi,aa104xd12
               - mitsubishi,aa121td01
+              - sgd,gktw70sdae4se
 
     then:
       properties:
@@ -75,6 +76,7 @@ properties:
           - innolux,ee101ia-01d
           - mitsubishi,aa104xd12
           - mitsubishi,aa121td01
+          - sgd,gktw70sdae4se
       - const: panel-lvds
 
   data-mapping:
Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml deleted +0 -68

68 lines not on this page · raw message

Signature · 1 line
2.31.1
#38 lore raw

PATCH v2 20/52 dt-bindings: display: panel-lvds: Document missing panel compatibles

In reply to Maxime Ripard

A few panel-lvds compatibles were never documented. Let's add them.

Cc Laurent Pinchart <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Thierry Reding <[email protected]>
---
 Documentation/devicetree/bindings/display/panel/lvds.yaml | 2 ++
 1 file changed, 2 insertions(+)
Documentation/devicetree/bindings/display/panel/lvds.yaml +2 -0
index 1563d57bc793..b2e8f5b263d7 100644
@@ -73,10 +73,12 @@ properties:
       - enum:
           - advantech,idk-1110wr
           - advantech,idk-2121wr
+          - auo,b101ew05
           - innolux,ee101ia-01d
           - mitsubishi,aa104xd12
           - mitsubishi,aa121td01
           - sgd,gktw70sdae4se
+          - tbs,a711-panel
       - const: panel-lvds
 
   data-mapping:
Signature · 1 line
2.31.1
#39 lore raw

PATCH v2 21/52 dt-bindings: gnss: Convert UBlox Neo-6M binding to a schema

In reply to Maxime Ripard

The UBlox Neo 6M is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Changes from v1:
- Fixed a typo
- Fixed the example node name

---
 .../bindings/gnss/u-blox,neo-6m.yaml          | 62 +++++++++++++++++++
 .../devicetree/bindings/gnss/u-blox.txt       | 45 --------------
 2 files changed, 62 insertions(+), 45 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml
 delete mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt
Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml new file +62 -0
new file mode 100644
index 000000000000..396101a223e7
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gnss/u-blox,neo-6m.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: U-blox GNSS Receiver Device Tree Bindings
+
+maintainers:
+  - Johan Hovold <[email protected]>
+
+description: >
+  The U-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
+
+properties:
+  compatible:
+    enum:
+      - u-blox,neo-6m
+      - u-blox,neo-8
+      - u-blox,neo-m8
+
+  reg:
+    description: >
+      The DDC Slave Address, SPI chip select address, the number of the USB hub
+      port or the USB host-controller port to which this device is attached,
+      depending on the bus used. Required for the DDC, SPI or USB busses.
+
+  vcc-supply:
+    description: >
+      Main voltage regulator
+
+  timepulse-gpios:
+    maxItems: 1
+    description: >
+      Time pulse GPIO
+
+  u-blox,extint-gpios:
+    maxItems: 1
+    description: >
+      GPIO connected to the "external interrupt" input pin
+  
+  v-bckp-supply:
+    description: >
+      Backup voltage regulator
+
+  current-speed: true
+
+required:
+  - compatible
+  - vcc-supply
+
+additionalProperties: false
+
+examples:
+  - |
+    serial {
+        gnss {
+            compatible = "u-blox,neo-8";
+            v-bckp-supply = <&gnss_v_bckp_reg>;
+            vcc-supply = <&gnss_vcc_reg>;
+        };
+    };
Documentation/devicetree/bindings/gnss/u-blox.txt deleted +0 -45

45 lines not on this page · raw message

Signature · 1 line
2.31.1
maintainer Applied
#40 lore raw

Re: [PATCH v2 21/52] dt-bindings: gnss: Convert UBlox Neo-6M binding to a schema

Quoted 14 lines · Maxime Ripard

The UBlox Neo 6M is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Changes from v1:
- Fixed a typo
- Fixed the example node name

Quoted 7 lines
---
 .../bindings/gnss/u-blox,neo-6m.yaml          | 62 +++++++++++++++++++
 .../devicetree/bindings/gnss/u-blox.txt       | 45 --------------
 2 files changed, 62 insertions(+), 45 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml
 delete mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt

Applied, thanks!

#41 lore raw

PATCH v2 22/52 dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema

In reply to Maxime Ripard

The X-Powers AXP PMICs feature a GPIO Controller supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Bartosz Golaszewski <[email protected]>
Cc Chen-Yu Tsai <[email protected]>
Cc Linus Walleij <[email protected]>

---

Changes from v1:
- Removed the example and moved it in the mfd schema

---
 .../devicetree/bindings/gpio/gpio-axp209.txt  | 75 -------------------
 .../bindings/gpio/x-powers,axp209-gpio.yaml   | 55 ++++++++++++++
 2 files changed, 55 insertions(+), 75 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-axp209.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
Documentation/devicetree/bindings/gpio/gpio-axp209.txt deleted +0 -75
deleted file mode 100644
index fc42b2caa06d..000000000000
@@ -1,75 +0,0 @@
-AXP209 GPIO & pinctrl controller
-
-This driver follows the usual GPIO bindings found in
-Documentation/devicetree/bindings/gpio/gpio.txt
-
-This driver follows the usual pinctrl bindings found in
-Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-This driver employs the per-pin muxing pattern.
-
-Required properties:
-- compatible: Should be one of:
-	- "x-powers,axp209-gpio"
-	- "x-powers,axp813-gpio"
-- #gpio-cells: Should be two. The first cell is the pin number and the
-  second is the GPIO flags.
-- gpio-controller: Marks the device node as a GPIO controller.
-
-This node must be a subnode of the axp20x PMIC, documented in
-Documentation/devicetree/bindings/mfd/axp20x.txt
-
-Example:
-
-axp209: pmic@34 {
-	compatible = "x-powers,axp209";
-	reg = <0x34>;
-	interrupt-parent = <&nmi_intc>;
-	interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-	interrupt-controller;
-	#interrupt-cells = <1>;
-
-	axp_gpio: gpio {
-		compatible = "x-powers,axp209-gpio";
-		gpio-controller;
-		#gpio-cells = <2>;
-	};
-};
-
-The GPIOs can be muxed to other functions and therefore, must be a subnode of
-axp_gpio.
-
-Example:
-
-&axp_gpio {
-	gpio0_adc: gpio0-adc {
-		pins = "GPIO0";
-		function = "adc";
-	};
-};
-
-&example_node {
-	pinctrl-names = "default";
-	pinctrl-0 = <&gpio0_adc>;
-};
-
-GPIOs and their functions
--------------------------
-
-Each GPIO is independent from the other (i.e. GPIO0 in gpio_in function does
-not force GPIO1 and GPIO2 to be in gpio_in function as well).
-
-axp209
-------
-GPIO	|	Functions
-------------------------
-GPIO0	|	gpio_in, gpio_out, ldo, adc
-GPIO1	|	gpio_in, gpio_out, ldo, adc
-GPIO2	|	gpio_in, gpio_out
-
-axp813
-------
-GPIO	|	Functions
-------------------------
-GPIO0	|	gpio_in, gpio_out, ldo, adc
-GPIO1	|	gpio_in, gpio_out, ldo
Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml new file +55 -0

55 lines not on this page · raw message

Signature · 1 line
2.31.1
maintainer Reviewed-by on v2 22/52
#42 lore raw

Re: [PATCH v2 22/52] dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema

Quoted 14 lines · Maxime Ripard

The X-Powers AXP PMICs feature a GPIO Controller supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Bartosz Golaszewski <[email protected]>
Cc Chen-Yu Tsai <[email protected]>
Cc Linus Walleij <[email protected]>

---

Quoted 9 lines

Changes from v1:
- Removed the example and moved it in the mfd schema

---
 .../devicetree/bindings/gpio/gpio-axp209.txt  | 75 -------------------
 .../bindings/gpio/x-powers,axp209-gpio.yaml   | 55 ++++++++++++++
 2 files changed, 55 insertions(+), 75 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-axp209.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml

This needs to be applied with the MFD schema.

Acked-by on v2 22/52
#43 lore raw

Re: [PATCH v2 22/52] dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema

In reply to Maxime Ripard
Quoted 7 lines · Maxime Ripard

The X-Powers AXP PMICs feature a GPIO Controller supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Quoted 8 lines
Cc Bartosz Golaszewski <[email protected]>
Cc Chen-Yu Tsai <[email protected]>
Cc Linus Walleij <[email protected]>

---

#44 lore raw

PATCH v2 23/52 dt-bindings: hwmon: Add IIO HWMON binding

In reply to Maxime Ripard

Even though we had the iio-hwmon driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

Cc Guenter Roeck <[email protected]>
Cc Jean Delvare <[email protected]>
Cc Jonathan Cameron <[email protected]>

---

Changes from v1:
- Reduced the maximum number of io-channels, and added a comment for the limitation

---
 .../devicetree/bindings/hwmon/iio-hwmon.yaml  | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml new file +37 -0
new file mode 100644
index 000000000000..f5a6cc3efd33
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: ADC-attached Hardware Sensor Device Tree Bindings
+
+maintainers:
+  - Jonathan Cameron <[email protected]>
+
+description: >
+  Bindings for hardware monitoring devices connected to ADC controllers
+  supporting the Industrial I/O bindings.
+
+properties:
+  compatible:
+    const: iio-hwmon
+
+  io-channels:
+    minItems: 1
+    maxItems: 8 # Should be enough
+    description: >
+      List of phandles to ADC channels to read the monitoring values
+
+required:
+  - compatible
+  - io-channels
+
+additionalProperties: false
+
+examples:
+  - |
+      iio-hwmon {
+          compatible = "iio-hwmon";
+          io-channels = <&adc 1>, <&adc 2>;
+      };
Signature · 1 line
2.31.1
maintainer Reviewed-by on v2 23/52
#45 lore raw

Re: [PATCH v2 23/52] dt-bindings: hwmon: Add IIO HWMON binding

Quoted 12 lines · Maxime Ripard

Even though we had the iio-hwmon driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

Cc Guenter Roeck <[email protected]>
Cc Jean Delvare <[email protected]>
Cc Jonathan Cameron <[email protected]>

---

Quoted 8 lines

Changes from v1:
- Reduced the maximum number of io-channels, and added a comment for the limitation

---
 .../devicetree/bindings/hwmon/iio-hwmon.yaml  | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
maintainer
#46 lore raw

Re: [PATCH v2 23/52] dt-bindings: hwmon: Add IIO HWMON binding

In reply to Maxime Ripard
Quoted 10 lines · Maxime Ripard

Even though we had the iio-hwmon driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

Applied (assuming this is supposed to be pushed through hwmon).

Thanks,
Guenter

#47 lore raw

PATCH v2 24/52 dt-bindings: input: Convert Silead GSL1680 binding to a schema

In reply to Maxime Ripard

The Silead GSL1680 Touchscreen Controller is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Changes from v1:
- Added maximum to the number of fingers

---
 .../input/touchscreen/silead,gsl1680.yaml     | 91 +++++++++++++++++++
 .../input/touchscreen/silead_gsl1680.txt      | 44 ---------
 2 files changed, 91 insertions(+), 44 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
 delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml new file +91 -0
new file mode 100644
index 000000000000..cc064696ac28
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/silead,gsl1680.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silead GSL1680 Touchscreen Controller Device Tree Bindings
+
+maintainers:
+  - Dmitry Torokhov <[email protected]>
+
+allOf:
+  - $ref: touchscreen.yaml#
+
+properties:
+  compatible:
+    enum:
+      - silead,gsl1680
+      - silead,gsl1688
+      - silead,gsl3670
+      - silead,gsl3675
+      - silead,gsl3692
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  power-gpios:
+    maxItems: 1
+
+  firmware:
+    $ref: /schemas/types.yaml#/definitions/string
+    description: >
+      File basename for board specific firmware
+
+  silead,max-fingers:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 5
+    description: >
+      Maximum number of fingers the touchscreen can detect
+
+  silead,home-button:
+    type: boolean
+    description: >
+      Does the device have a capacitive home-button build into the
+      touchscreen?
+
+  avdd-supply:
+    description: >
+      Regulator phandle for controller AVDD
+
+  vddio-supply:
+    description: >
+      Regulator phandle for controller VDDIO
+
+unevaluatedProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - power-gpios
+  - touchscreen-size-x
+  - touchscreen-size-y
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        touchscreen@40 {
+            compatible = "silead,gsl1680";
+            reg = <0x40>;
+            interrupt-parent = <&pio>;
+            interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>;
+            power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>;
+            touchscreen-size-x = <480>;
+            touchscreen-size-y = <800>;
+            touchscreen-inverted-x;
+            touchscreen-swapped-x-y;
+            silead,max-fingers = <5>;
+        };
+    };
+
+...
Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt deleted +0 -44

44 lines not on this page · raw message

Signature · 1 line
2.31.1
maintainer
#48 lore raw

Re: [PATCH v2 24/52] dt-bindings: input: Convert Silead GSL1680 binding to a schema

Quoted 50 lines · Maxime Ripard

The Silead GSL1680 Touchscreen Controller is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Changes from v1:
- Added maximum to the number of fingers

---
 .../input/touchscreen/silead,gsl1680.yaml     | 91 +++++++++++++++++++
 .../input/touchscreen/silead_gsl1680.txt      | 44 ---------
 2 files changed, 91 insertions(+), 44 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
 delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml new file +23 -0
new file mode 100644
index 000000000000..cc064696ac28
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/silead,gsl1680.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silead GSL1680 Touchscreen Controller Device Tree Bindings
+
+maintainers:
+  - Dmitry Torokhov <[email protected]>
+
+allOf:
+  - $ref: touchscreen.yaml#
+
+properties:
+  compatible:
+    enum:
+      - silead,gsl1680
+      - silead,gsl1688
+      - silead,gsl3670
+      - silead,gsl3675
+      - silead,gsl3692
+

Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml line 33

Quoted 10 lines
Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml new file +10 -0
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  power-gpios:
+    maxItems: 1
+
+  firmware:

Should be 'firmware-name'

Quoted 112 lines
Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml new file +58 -0
+    $ref: /schemas/types.yaml#/definitions/string
+    description: >
+      File basename for board specific firmware
+
+  silead,max-fingers:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 5
+    description: >
+      Maximum number of fingers the touchscreen can detect
+
+  silead,home-button:
+    type: boolean
+    description: >
+      Does the device have a capacitive home-button build into the
+      touchscreen?
+
+  avdd-supply:
+    description: >
+      Regulator phandle for controller AVDD
+
+  vddio-supply:
+    description: >
+      Regulator phandle for controller VDDIO
+
+unevaluatedProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - power-gpios
+  - touchscreen-size-x
+  - touchscreen-size-y
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        touchscreen@40 {
+            compatible = "silead,gsl1680";
+            reg = <0x40>;
+            interrupt-parent = <&pio>;
+            interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>;
+            power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>;
+            touchscreen-size-x = <480>;
+            touchscreen-size-y = <800>;
+            touchscreen-inverted-x;
+            touchscreen-swapped-x-y;
+            silead,max-fingers = <5>;
+        };
+    };
+
+...
Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt deleted +0 -44
deleted file mode 100644
index d67e558e5ab5..000000000000
@@ -1,44 +0,0 @@
-* GSL 1680 touchscreen controller
-
-Required properties:
-- compatible		  : Must be one of the following, depending on the model:
-			    "silead,gsl1680"
-			    "silead,gsl1688"
-			    "silead,gsl3670"
-			    "silead,gsl3675"
-			    "silead,gsl3692"
-- reg			  : I2C slave address of the chip (0x40)
-- interrupts		  : interrupt specification for the gsl1680 interrupt
-- power-gpios		  : Specification for the pin connected to the gsl1680's
-			    shutdown input. This needs to be driven high to take the
-			    gsl1680 out of its low power state
-- touchscreen-size-x	  : See touchscreen.txt
-- touchscreen-size-y	  : See touchscreen.txt
-
-Optional properties:
-- firmware-name		  : File basename (string) for board specific firmware
-- touchscreen-inverted-x  : See touchscreen.txt
-- touchscreen-inverted-y  : See touchscreen.txt
-- touchscreen-swapped-x-y : See touchscreen.txt
-- silead,max-fingers	  : maximum number of fingers the touchscreen can detect
-- silead,home-button	  : Boolean, set to true on devices which have a
-			    capacitive home-button build into the touchscreen
-- vddio-supply		  : regulator phandle for controller VDDIO
-- avdd-supply		  : regulator phandle for controller AVDD
-
-Example:
-
-i2c@00000000 {
-	gsl1680: touchscreen@40 {
-		compatible = "silead,gsl1680";
-		reg = <0x40>;
-		interrupt-parent = <&pio>;
-		interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>;
-		power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>;
-		touchscreen-size-x = <480>;
-		touchscreen-size-y = <800>;
-		touchscreen-inverted-x;
-		touchscreen-swapped-x-y;
-		silead,max-fingers = <5>;
-	};
-};
Signature · 1 line
2.31.1
#49 lore raw

PATCH v2 25/52 dt-bindings: interconnect: sunxi: Add R40 MBUS compatible

In reply to Maxime Ripard

The R40 MBUS compatible was introduced recently but it was never documented.

---
 .../devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml  | 1 +
 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml +1 -0
index e713a6fe4cf7..29c9961ee2d8 100644
@@ -30,6 +30,7 @@ properties:
     enum:
       - allwinner,sun5i-a13-mbus
       - allwinner,sun8i-h3-mbus
+      - allwinner,sun8i-r40-mbus
       - allwinner,sun50i-a64-mbus
 
   reg:
Signature · 1 line
2.31.1
author Applied
#51 lore raw

Re: (subset) [PATCH v2 25/52] dt-bindings: interconnect: sunxi: Add R40 MBUS compatible

In reply to Maxime Ripard
Quoted 4 lines · Maxime Ripard

The R40 MBUS compatible was introduced recently but it was never documented.

Applied to sunxi/linux.git (sunxi/dt-for-5.16).

Thanks!
Maxime

#52 lore raw

PATCH v2 26/52 dt-bindings: media: ti,cal: Fix example

In reply to Maxime Ripard

The OV5640 sensor used in the example doesn't follow the binding and omits the regulators. Add some to make the example valid.

---
 Documentation/devicetree/bindings/media/ti,cal.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/media/ti,cal.yaml +3 -1
index 65177cd69514..66c5d392fa75 100644
@@ -154,7 +154,9 @@ examples:
         camera-sensor@3c {
                compatible = "ovti,ov5640";
                reg = <0x3c>;
-
+               AVDD-supply = <&reg_2p8v>;
+               DOVDD-supply = <&reg_1p8v>;
+               DVDD-supply = <&reg_1p5v>;
                clocks = <&clk_ov5640_fixed>;
                clock-names = "xclk";
 
Signature · 1 line
2.31.1
maintainer Applied
#53 lore raw

Re: [PATCH v2 26/52] dt-bindings: media: ti,cal: Fix example

Quoted 8 lines · Maxime Ripard

The OV5640 sensor used in the example doesn't follow the binding and omits the regulators. Add some to make the example valid.

---
 Documentation/devicetree/bindings/media/ti,cal.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Applied, thanks!

#54 lore raw

PATCH v2 27/52 dt-bindings: media: Convert OV5640 binding to a schema

In reply to Maxime Ripard

The Omnivision OV5640 is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Mauro Carvalho Chehab <[email protected]>
Cc Steve Longerbeam <[email protected]>
---
 .../devicetree/bindings/media/i2c/ov5640.txt  |  92 -----------
 .../bindings/media/i2c/ovti,ov5640.yaml       | 154 ++++++++++++++++++
 2 files changed, 154 insertions(+), 92 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml
Documentation/devicetree/bindings/media/i2c/ov5640.txt deleted +0 -92
deleted file mode 100644
index c97c2f2da12d..000000000000
@@ -1,92 +0,0 @@
-* Omnivision OV5640 MIPI CSI-2 / parallel sensor
-
-Required Properties:
-- compatible: should be "ovti,ov5640"
-- clocks: reference to the xclk input clock.
-- clock-names: should be "xclk".
-- DOVDD-supply: Digital I/O voltage supply, 1.8 volts
-- AVDD-supply: Analog voltage supply, 2.8 volts
-- DVDD-supply: Digital core voltage supply, 1.5 volts
-
-Optional Properties:
-- reset-gpios: reference to the GPIO connected to the reset pin, if any.
-	       This is an active low signal to the OV5640.
-- powerdown-gpios: reference to the GPIO connected to the powerdown pin,
-		   if any. This is an active high signal to the OV5640.
-- rotation: as defined in
-	    Documentation/devicetree/bindings/media/video-interfaces.txt,
-	    valid values are 0 (sensor mounted upright) and 180 (sensor
-	    mounted upside down).
-
-The device node must contain one 'port' child node for its digital output
-video port, in accordance with the video interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-OV5640 can be connected to a MIPI CSI-2 bus or a parallel bus endpoint.
-
-Endpoint node required properties for CSI-2 connection are:
-- remote-endpoint: a phandle to the bus receiver's endpoint node.
-- clock-lanes: should be set to <0> (clock lane on hardware lane 0)
-- data-lanes: should be set to <1> or <1 2> (one or two CSI-2 lanes supported)
-
-Endpoint node required properties for parallel connection are:
-- remote-endpoint: a phandle to the bus receiver's endpoint node.
-- bus-width: shall be set to <8> for 8 bits parallel bus
-	     or <10> for 10 bits parallel bus
-- data-shift: shall be set to <2> for 8 bits parallel bus
-	      (lines 9:2 are used) or <0> for 10 bits parallel bus
-- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
-- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
-- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
-	       signal.
-
-Examples:
-
-&i2c1 {
-	ov5640: camera@3c {
-		compatible = "ovti,ov5640";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_ov5640>;
-		reg = <0x3c>;
-		clocks = <&clks IMX6QDL_CLK_CKO>;
-		clock-names = "xclk";
-		DOVDD-supply = <&vgen4_reg>; /* 1.8v */
-		AVDD-supply = <&vgen3_reg>;  /* 2.8v */
-		DVDD-supply = <&vgen2_reg>;  /* 1.5v */
-		powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
-		reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
-		rotation = <180>;
-
-		port {
-			/* MIPI CSI-2 bus endpoint */
-			ov5640_to_mipi_csi2: endpoint {
-				remote-endpoint = <&mipi_csi2_from_ov5640>;
-				clock-lanes = <0>;
-				data-lanes = <1 2>;
-			};
-		};
-	};
-};
-
-&i2c1 {
-	ov5640: camera@3c {
-		compatible = "ovti,ov5640";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_ov5640>;
-		reg = <0x3c>;
-		clocks = <&clk_ext_camera>;
-		clock-names = "xclk";
-
-		port {
-			/* Parallel bus endpoint */
-			ov5640_to_parallel: endpoint {
-				remote-endpoint = <&parallel_from_ov5640>;
-				bus-width = <8>;
-				data-shift = <2>; /* lines 9:2 are used */
-				hsync-active = <0>;
-				vsync-active = <0>;
-				pclk-sample = <1>;
-			};
-		};
-	};
-};
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml new file +154 -0

154 lines not on this page · raw message

Signature · 1 line
2.31.1
maintainer
#55 lore raw

Re: [PATCH v2 27/52] dt-bindings: media: Convert OV5640 binding to a schema

Quoted 165 lines · Maxime Ripard

The Omnivision OV5640 is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Mauro Carvalho Chehab <[email protected]>
Cc Steve Longerbeam <[email protected]>
---
 .../devicetree/bindings/media/i2c/ov5640.txt  |  92 -----------
 .../bindings/media/i2c/ovti,ov5640.yaml       | 154 ++++++++++++++++++
 2 files changed, 154 insertions(+), 92 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml
Documentation/devicetree/bindings/media/i2c/ov5640.txt deleted +0 -92
deleted file mode 100644
index c97c2f2da12d..000000000000
@@ -1,92 +0,0 @@
-* Omnivision OV5640 MIPI CSI-2 / parallel sensor
-
-Required Properties:
-- compatible: should be "ovti,ov5640"
-- clocks: reference to the xclk input clock.
-- clock-names: should be "xclk".
-- DOVDD-supply: Digital I/O voltage supply, 1.8 volts
-- AVDD-supply: Analog voltage supply, 2.8 volts
-- DVDD-supply: Digital core voltage supply, 1.5 volts
-
-Optional Properties:
-- reset-gpios: reference to the GPIO connected to the reset pin, if any.
-	       This is an active low signal to the OV5640.
-- powerdown-gpios: reference to the GPIO connected to the powerdown pin,
-		   if any. This is an active high signal to the OV5640.
-- rotation: as defined in
-	    Documentation/devicetree/bindings/media/video-interfaces.txt,
-	    valid values are 0 (sensor mounted upright) and 180 (sensor
-	    mounted upside down).
-
-The device node must contain one 'port' child node for its digital output
-video port, in accordance with the video interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-OV5640 can be connected to a MIPI CSI-2 bus or a parallel bus endpoint.
-
-Endpoint node required properties for CSI-2 connection are:
-- remote-endpoint: a phandle to the bus receiver's endpoint node.
-- clock-lanes: should be set to <0> (clock lane on hardware lane 0)
-- data-lanes: should be set to <1> or <1 2> (one or two CSI-2 lanes supported)
-
-Endpoint node required properties for parallel connection are:
-- remote-endpoint: a phandle to the bus receiver's endpoint node.
-- bus-width: shall be set to <8> for 8 bits parallel bus
-	     or <10> for 10 bits parallel bus
-- data-shift: shall be set to <2> for 8 bits parallel bus
-	      (lines 9:2 are used) or <0> for 10 bits parallel bus
-- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
-- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
-- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
-	       signal.
-
-Examples:
-
-&i2c1 {
-	ov5640: camera@3c {
-		compatible = "ovti,ov5640";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_ov5640>;
-		reg = <0x3c>;
-		clocks = <&clks IMX6QDL_CLK_CKO>;
-		clock-names = "xclk";
-		DOVDD-supply = <&vgen4_reg>; /* 1.8v */
-		AVDD-supply = <&vgen3_reg>;  /* 2.8v */
-		DVDD-supply = <&vgen2_reg>;  /* 1.5v */
-		powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
-		reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
-		rotation = <180>;
-
-		port {
-			/* MIPI CSI-2 bus endpoint */
-			ov5640_to_mipi_csi2: endpoint {
-				remote-endpoint = <&mipi_csi2_from_ov5640>;
-				clock-lanes = <0>;
-				data-lanes = <1 2>;
-			};
-		};
-	};
-};
-
-&i2c1 {
-	ov5640: camera@3c {
-		compatible = "ovti,ov5640";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_ov5640>;
-		reg = <0x3c>;
-		clocks = <&clk_ext_camera>;
-		clock-names = "xclk";
-
-		port {
-			/* Parallel bus endpoint */
-			ov5640_to_parallel: endpoint {
-				remote-endpoint = <&parallel_from_ov5640>;
-				bus-width = <8>;
-				data-shift = <2>; /* lines 9:2 are used */
-				hsync-active = <0>;
-				vsync-active = <0>;
-				pclk-sample = <1>;
-			};
-		};
-	};
-};
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml new file +44 -0
new file mode 100644
index 000000000000..0283b1895a75
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov5640.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV5640 Image Sensor Device Tree Bindings
+
+maintainers:
+  - Steve Longerbeam <[email protected]>
+
+allOf:
+  - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+  compatible:
+    const: ovti,ov5640
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    description: XCLK Input Clock
+
+  clock-names:
+    const: xclk
+
+  AVDD-supply:
+    description: Analog voltage supply, 2.8 volts
+
+  DVDD-supply:
+    description: Digital core voltage supply, 1.5 volts
+
+  DOVDD-supply:
+    description: Digital I/O voltage supply, 1.8 volts
+
+  powerdown-gpios:
+    maxItems: 1
+    description: >
+      Reference to the GPIO connected to the powerdown pin, if any.
+
+  reset-gpios:
+    maxItems: 1
+    description: >

Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml line 54

Quoted 10 lines
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml new file +10 -0
+      Reference to the GPIO connected to the reset pin, if any.
+
+  rotation:
+    enum: 
+      - 0
+      - 180
+
+  port:
+    description: Digital Output Port
+    $ref: /schemas/graph.yaml#/properties/port

This needs to be /schemas/graph.yaml#/$defs/port-base

Otherwise, it will fail when we start checking unevaluatedProperties.

Quoted 104 lines
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml new file +100 -0
+    additionalProperties: false
+
+    properties:
+      endpoint:
+        $ref: /schemas/media/video-interfaces.yaml#
+        unevaluatedProperties: false
+
+        properties:
+          clock-lanes:
+            const: 0
+
+          data-lanes:
+            minItems: 1
+            maxItems: 2
+            items:
+              enum: [1, 2]
+
+          bus-width:
+            enum: [8, 10]
+
+          data-shift:
+            enum: [0, 2]
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - AVDD-supply
+  - DVDD-supply
+  - DOVDD-supply
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+      #include <dt-bindings/clock/imx6qdl-clock.h>
+      #include <dt-bindings/gpio/gpio.h>
+
+      i2c {
+          #address-cells = <1>;
+          #size-cells = <0>;
+
+          camera@3c {
+              compatible = "ovti,ov5640";
+              pinctrl-names = "default";
+              pinctrl-0 = <&pinctrl_ov5640>;
+              reg = <0x3c>;
+              clocks = <&clks IMX6QDL_CLK_CKO>;
+              clock-names = "xclk";
+              DOVDD-supply = <&vgen4_reg>; /* 1.8v */
+              AVDD-supply = <&vgen3_reg>;  /* 2.8v */
+              DVDD-supply = <&vgen2_reg>;  /* 1.5v */
+              powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+              reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+              rotation = <180>;
+
+              port {
+                  /* MIPI CSI-2 bus endpoint */
+                  ov5640_to_mipi_csi2: endpoint {
+                      remote-endpoint = <&mipi_csi2_from_ov5640>;
+                      clock-lanes = <0>;
+                      data-lanes = <1 2>;
+                  };
+              };
+          };
+      };
+
+  - |
+      i2c {
+          #address-cells = <1>;
+          #size-cells = <0>;
+
+          camera@3c {
+              compatible = "ovti,ov5640";
+              pinctrl-names = "default";
+              pinctrl-0 = <&pinctrl_ov5640>;
+              reg = <0x3c>;
+              clocks = <&clk_ext_camera>;
+              clock-names = "xclk";
+              DOVDD-supply = <&vgen4_reg>; /* 1.8v */
+              AVDD-supply = <&vgen3_reg>;  /* 2.8v */
+              DVDD-supply = <&vgen2_reg>;  /* 1.5v */
+
+              port {
+                  /* Parallel bus endpoint */
+                  ov5640_to_parallel: endpoint {
+                      remote-endpoint = <&parallel_from_ov5640>;
+                      bus-width = <8>;
+                      data-shift = <2>; /* lines 9:2 are used */
+                      hsync-active = <0>;
+                      vsync-active = <0>;
+                      pclk-sample = <1>;
+                  };
+              };
+          };
+      };
+
+...
Signature · 1 line
2.31.1
#56 lore raw

Re: [PATCH v2 27/52] dt-bindings: media: Convert OV5640 binding to a schema

In reply to Maxime Ripard

Hi Maxime,

Quoted 10 lines · Maxime Ripard

The Omnivision OV5640 is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Mauro Carvalho Chehab <[email protected]>
Cc Steve Longerbeam <[email protected]>

Thanks for your patch!

Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml line 49

Quoted 6 lines
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml new file +3 -0
 
+  rotation:
+    enum:
+      - 0

git am: warning: 1 line adds whitespace errors.

Quoted 1 line

+ - 180

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

#57 lore raw

PATCH v2 28/52 dt-bindings: mfd: Convert X-Powers AC100 binding to a schema

In reply to Maxime Ripard

The X-Powers AC100 hybrid devices are supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Changes from v1:
- Added maximum number of clocks properties

---
 .../devicetree/bindings/mfd/ac100.txt         |  50 --------
 .../bindings/mfd/x-powers,ac100.yaml          | 116 ++++++++++++++++++
 2 files changed, 116 insertions(+), 50 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mfd/ac100.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml
Documentation/devicetree/bindings/mfd/ac100.txt deleted +0 -50
deleted file mode 100644
index dff219f07493..000000000000
@@ -1,50 +0,0 @@
-X-Powers AC100 Codec/RTC IC Device Tree bindings
-
-AC100 is a audio codec and RTC subsystem combo IC. The 2 parts are
-separated, including power supplies and interrupt lines, but share
-a common register address space and host interface.
-
-Required properties:
-- compatible: "x-powers,ac100"
-- reg: The I2C slave address or RSB hardware address for the chip
-- sub-nodes:
-  - codec
-    - compatible:		"x-powers,ac100-codec"
-    - interrupts:		SoC NMI / GPIO interrupt connected to the
-    				IRQ_AUDIO pin
-    - #clock-cells:		Shall be 0
-    - clock-output-names:	"4M_adda"
-
-    - see clock/clock-bindings.txt for common clock bindings
-
-  - rtc
-    - compatible:		"x-powers,ac100-rtc"
-    - clocks:			A phandle to the codec's "4M_adda" clock
-    - #clock-cells:		Shall be 1
-    - clock-output-names:	"cko1_rtc", "cko2_rtc", "cko3_rtc"
-
-    - see clock/clock-bindings.txt for common clock bindings
-
-Example:
-
-ac100: codec@e89 {
-	compatible = "x-powers,ac100";
-	reg = <0xe89>;
-
-	ac100_codec: codec {
-		compatible = "x-powers,ac100-codec";
-		interrupt-parent = <&r_pio>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_LOW>; /* PL9 */
-		#clock-cells = <0>;
-		clock-output-names = "4M_adda";
-	};
-
-	ac100_rtc: rtc {
-		compatible = "x-powers,ac100-rtc";
-		interrupt-parent = <&nmi_intc>;
-		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-		clocks = <&ac100_codec>;
-		#clock-cells = <1>;
-		clock-output-names = "cko1_rtc", "cko2_rtc", "cko3_rtc";
-	};
-};
Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml new file +116 -0

116 lines not on this page · raw message

Signature · 1 line
2.31.1
maintainer Reviewed-by on v2 28/52
#58 lore raw

Re: [PATCH v2 28/52] dt-bindings: mfd: Convert X-Powers AC100 binding to a schema

Quoted 12 lines · Maxime Ripard

The X-Powers AC100 hybrid devices are supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Quoted 9 lines

Changes from v1:
- Added maximum number of clocks properties

---
 .../devicetree/bindings/mfd/ac100.txt         |  50 --------
 .../bindings/mfd/x-powers,ac100.yaml          | 116 ++++++++++++++++++
 2 files changed, 116 insertions(+), 50 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mfd/ac100.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml
#59 lore raw

PATCH v2 29/52 dt-bindings: mfd: Convert X-Powers AXP binding to a schema

In reply to Maxime Ripard

The X-Powers AXP PMICs are supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Chen-Yu Tsai <[email protected]>
Cc Lee Jones <[email protected]>

---

Changes from v1:
- Add GPIO example
- Remove the limitation on regulator-ramp-delay

---
 .../i2c/allwinner,sun6i-a31-p2wi.yaml         |   2 +-
 .../devicetree/bindings/mfd/axp20x.txt        | 273 ------------
 .../bindings/mfd/x-powers,axp152.yaml         | 400 ++++++++++++++++++
 3 files changed, 401 insertions(+), 274 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml +1 -1
index 6097e8ac46c1..1b03810d4b4d 100644
@@ -55,7 +55,7 @@ examples:
         #size-cells = <0>;
 
         axp221: pmic@68 {
-            compatible = "x-powers,axp221";
+            /* compatible = "x-powers,axp221"; */
             reg = <0x68>;
         };
     };
Documentation/devicetree/bindings/mfd/axp20x.txt deleted +0 -273

273 lines not on this page · raw message

Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml new file +400 -0

400 lines not on this page · raw message

Signature · 1 line
2.31.1
maintainer Reviewed-by on v2 29/52
#60 lore raw

Re: [PATCH v2 29/52] dt-bindings: mfd: Convert X-Powers AXP binding to a schema

Quoted 15 lines · Maxime Ripard

The X-Powers AXP PMICs are supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Chen-Yu Tsai <[email protected]>
Cc Lee Jones <[email protected]>

---

Changes from v1:
- Add GPIO example
- Remove the limitation on regulator-ramp-delay

Quoted 8 lines
---
 .../i2c/allwinner,sun6i-a31-p2wi.yaml         |   2 +-
 .../devicetree/bindings/mfd/axp20x.txt        | 273 ------------
 .../bindings/mfd/x-powers,axp152.yaml         | 400 ++++++++++++++++++
 3 files changed, 401 insertions(+), 274 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml

Note that the gpio child schema needs to be applied with this one.

#61 lore raw

Re: [PATCH v2 29/52] dt-bindings: mfd: Convert X-Powers AXP binding to a schema

Quoted 25 lines · Rob Herring
Quoted 15 lines · Maxime Ripard

The X-Powers AXP PMICs are supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Chen-Yu Tsai <[email protected]>
Cc Lee Jones <[email protected]>

---

Changes from v1:
- Add GPIO example
- Remove the limitation on regulator-ramp-delay

Quoted 8 lines
---
 .../i2c/allwinner,sun6i-a31-p2wi.yaml         |   2 +-
 .../devicetree/bindings/mfd/axp20x.txt        | 273 ------------
 .../bindings/mfd/x-powers,axp152.yaml         | 400 ++++++++++++++++++
 3 files changed, 401 insertions(+), 274 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
Quoted 3 lines

Note that the gpio child schema needs to be applied with this one.

Not sure I'm in possession of that.

Signature · 4 lines
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
#62 lore raw

Re: [PATCH v2 29/52] dt-bindings: mfd: Convert X-Powers AXP binding to a schema

Quoted 27 lines · Lee Jones
Quoted 25 lines · Rob Herring
Quoted 23 lines · Maxime Ripard

The X-Powers AXP PMICs are supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Chen-Yu Tsai <[email protected]>
Cc Lee Jones <[email protected]>

---

Changes from v1:
- Add GPIO example
- Remove the limitation on regulator-ramp-delay

---
 .../i2c/allwinner,sun6i-a31-p2wi.yaml         |   2 +-
 .../devicetree/bindings/mfd/axp20x.txt        | 273 ------------
 .../bindings/mfd/x-powers,axp152.yaml         | 400 ++++++++++++++++++
 3 files changed, 401 insertions(+), 274 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
Quoted 5 lines
Quoted 3 lines

Note that the gpio child schema needs to be applied with this one.

Not sure I'm in possession of that.

So, how do you want to merge that? Through the DT tree?

Maxime

maintainer
#63 lore raw

Re: [PATCH v2 29/52] dt-bindings: mfd: Convert X-Powers AXP binding to a schema

Quoted 29 lines · Maxime Ripard
Quoted 27 lines · Lee Jones
Quoted 25 lines · Rob Herring
Quoted 23 lines · Maxime Ripard

The X-Powers AXP PMICs are supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Chen-Yu Tsai <[email protected]>
Cc Lee Jones <[email protected]>

---

Changes from v1:
- Add GPIO example
- Remove the limitation on regulator-ramp-delay

---
 .../i2c/allwinner,sun6i-a31-p2wi.yaml         |   2 +-
 .../devicetree/bindings/mfd/axp20x.txt        | 273 ------------
 .../bindings/mfd/x-powers,axp152.yaml         | 400 ++++++++++++++++++
 3 files changed, 401 insertions(+), 274 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

Note that the gpio child schema needs to be applied with this one.

Not sure I'm in possession of that.

So, how do you want to merge that? Through the DT tree?

Resend the MFD and child patches in a series to Lee.

Rob

#64 lore raw

PATCH v2 30/52 dt-bindings: mmc: Convert MMC Card binding to a schema

In reply to Maxime Ripard

MMC Cards can have an optional Device Tree binding to add non-discoverable properties.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Some of these properties were already described in the MMC controller binding, even though they are not generic and do not apply to any device, so we took the occasion to fix this.

---

Changes from v1:
- Fixed additionalProperties

---
 .../devicetree/bindings/mmc/mmc-card.txt      | 30 ------------
 .../devicetree/bindings/mmc/mmc-card.yaml     | 48 +++++++++++++++++++
 .../bindings/mmc/mmc-controller.yaml          |  6 ---
 3 files changed, 48 insertions(+), 36 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.yaml
Documentation/devicetree/bindings/mmc/mmc-card.txt deleted +0 -30
deleted file mode 100644
index 8d2d71758907..000000000000
@@ -1,30 +0,0 @@
-mmc-card / eMMC bindings
-------------------------
-
-This documents describes the devicetree bindings for a mmc-host controller
-child node describing a mmc-card / an eMMC, see "Use of Function subnodes"
-in mmc.txt
-
-Required properties:
--compatible : Must be "mmc-card"
--reg        : Must be <0>
-
-Optional properties:
--broken-hpi : Use this to indicate that the mmc-card has a broken hpi
-              implementation, and that hpi should not be used
-
-Example:
-
-&mmc2 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&mmc2_pins_a>;
-	vmmc-supply = <&reg_vcc3v3>;
-	bus-width = <8>;
-	non-removable;
-
-	mmccard: mmccard@0 {
-		reg = <0>;
-		compatible = "mmc-card";
-		broken-hpi;
-	};
-};
Documentation/devicetree/bindings/mmc/mmc-card.yaml new file +48 -0

48 lines not on this page · raw message

Documentation/devicetree/bindings/mmc/mmc-controller.yaml +0 -6
index 25ac8e200970..513f3c8758aa 100644
@@ -333,12 +333,6 @@ patternProperties:
               subnode describes. A value of 0 denotes the memory SD
               function, values from 1 to 7 denote the SDIO functions.
 
-      broken-hpi:
-        $ref: /schemas/types.yaml#/definitions/flag
-        description:
-          Use this to indicate that the mmc-card has a broken hpi
-          implementation, and that hpi should not be used.
-
     required:
       - reg
 
Signature · 1 line
2.31.1
maintainer Reviewed-by on v2 30/52
#65 lore raw

Re: [PATCH v2 30/52] dt-bindings: mmc: Convert MMC Card binding to a schema

Quoted 18 lines · Maxime Ripard

MMC Cards can have an optional Device Tree binding to add non-discoverable properties.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Some of these properties were already described in the MMC controller binding, even though they are not generic and do not apply to any device, so we took the occasion to fix this.

---

Changes from v1:
- Fixed additionalProperties

Quoted 8 lines
---
 .../devicetree/bindings/mmc/mmc-card.txt      | 30 ------------
 .../devicetree/bindings/mmc/mmc-card.yaml     | 48 +++++++++++++++++++
 .../bindings/mmc/mmc-controller.yaml          |  6 ---
 3 files changed, 48 insertions(+), 36 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.yaml
Applied
#66 lore raw

Re: [PATCH v2 30/52] dt-bindings: mmc: Convert MMC Card binding to a schema

In reply to Maxime Ripard
Quoted 7 lines · Maxime Ripard

MMC Cards can have an optional Device Tree binding to add non-discoverable properties.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Quoted 8 lines

Some of these properties were already described in the MMC controller binding, even though they are not generic and do not apply to any device, so we took the occasion to fix this.

Queued for v5.16 on the temporary devel branch, thanks!

Kind regards
Uffe

Quoted 122 lines

---

Changes from v1:
- Fixed additionalProperties

---
 .../devicetree/bindings/mmc/mmc-card.txt      | 30 ------------
 .../devicetree/bindings/mmc/mmc-card.yaml     | 48 +++++++++++++++++++
 .../bindings/mmc/mmc-controller.yaml          |  6 ---
 3 files changed, 48 insertions(+), 36 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.yaml
Documentation/devicetree/bindings/mmc/mmc-card.txt deleted +0 -30
deleted file mode 100644
index 8d2d71758907..000000000000
@@ -1,30 +0,0 @@
-mmc-card / eMMC bindings
-------------------------
-
-This documents describes the devicetree bindings for a mmc-host controller
-child node describing a mmc-card / an eMMC, see "Use of Function subnodes"
-in mmc.txt
-
-Required properties:
--compatible : Must be "mmc-card"
--reg        : Must be <0>
-
-Optional properties:
--broken-hpi : Use this to indicate that the mmc-card has a broken hpi
-              implementation, and that hpi should not be used
-
-Example:
-
-&mmc2 {
-       pinctrl-names = "default";
-       pinctrl-0 = <&mmc2_pins_a>;
-       vmmc-supply = <&reg_vcc3v3>;
-       bus-width = <8>;
-       non-removable;
-
-       mmccard: mmccard@0 {
-               reg = <0>;
-               compatible = "mmc-card";
-               broken-hpi;
-       };
-};
Documentation/devicetree/bindings/mmc/mmc-card.yaml new file +48 -0
new file mode 100644
index 000000000000..b17d454442b3
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/mmc-card.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MMC Card / eMMC Generic Device Tree Bindings
+
+maintainers:
+  - Ulf Hansson <[email protected]>
+
+description: |
+  This documents describes the devicetree bindings for a mmc-host controller
+  child node describing a mmc-card / an eMMC.
+
+properties:
+  compatible:
+    const: mmc-card
+
+  reg:
+    const: 0
+
+  broken-hpi:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      Use this to indicate that the mmc-card has a broken hpi
+      implementation, and that hpi should not be used.
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    mmc {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        card@0 {
+            compatible = "mmc-card";
+            reg = <0>;
+            broken-hpi;
+        };
+    };
+
+...
Documentation/devicetree/bindings/mmc/mmc-controller.yaml +0 -7
index 25ac8e200970..513f3c8758aa 100644
@@ -333,12 +333,6 @@ patternProperties:
               subnode describes. A value of 0 denotes the memory SD
               function, values from 1 to 7 denote the SDIO functions.
 
-      broken-hpi:
-        $ref: /schemas/types.yaml#/definitions/flag
-        description:
-          Use this to indicate that the mmc-card has a broken hpi
-          implementation, and that hpi should not be used.
-
     required:
       - reg
 
--

2.31.1

#67 lore raw

PATCH v2 31/52 dt-bindings: net: dwmac: Fix typo in the R40 compatible

In reply to Maxime Ripard

Even though both the driver and the device trees all use the allwinner,sun8i-r40-gmac compatible, we documented the compatible as allwinner,sun8i-r40-emac in the binding. Let's fix this.

Cc Alexandre Torgue <[email protected]>
Cc "David S. Miller" <[email protected]>
Cc Giuseppe Cavallaro <[email protected]>
Cc Jakub Kicinski <[email protected]>
Cc Jose Abreu <[email protected]>
---
 .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml  | 4 ++--
 Documentation/devicetree/bindings/net/snps,dwmac.yaml       | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)
Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml +2 -2
index 7f2578d48e3f..9919d1912cc1 100644
@@ -15,7 +15,7 @@ properties:
     oneOf:
       - const: allwinner,sun8i-a83t-emac
       - const: allwinner,sun8i-h3-emac
-      - const: allwinner,sun8i-r40-emac
+      - const: allwinner,sun8i-r40-gmac
       - const: allwinner,sun8i-v3s-emac
       - const: allwinner,sun50i-a64-emac
       - items:
@@ -91,7 +91,7 @@ allOf:
         compatible:
           contains:
             enum:
-              - allwinner,sun8i-r40-emac
+              - allwinner,sun8i-r40-gmac
 
     then:
       properties:
Documentation/devicetree/bindings/net/snps,dwmac.yaml +3 -3
index 42689b7d03a2..3de8bca418f0 100644
@@ -49,7 +49,7 @@ properties:
         - allwinner,sun7i-a20-gmac
         - allwinner,sun8i-a83t-emac
         - allwinner,sun8i-h3-emac
-        - allwinner,sun8i-r40-emac
+        - allwinner,sun8i-r40-gmac
         - allwinner,sun8i-v3s-emac
         - allwinner,sun50i-a64-emac
         - loongson,ls2k-dwmac
@@ -316,7 +316,7 @@ allOf:
               - allwinner,sun7i-a20-gmac
               - allwinner,sun8i-a83t-emac
               - allwinner,sun8i-h3-emac
-              - allwinner,sun8i-r40-emac
+              - allwinner,sun8i-r40-gmac
               - allwinner,sun8i-v3s-emac
               - allwinner,sun50i-a64-emac
               - ingenic,jz4775-mac
@@ -364,7 +364,7 @@ allOf:
               - allwinner,sun7i-a20-gmac
               - allwinner,sun8i-a83t-emac
               - allwinner,sun8i-h3-emac
-              - allwinner,sun8i-r40-emac
+              - allwinner,sun8i-r40-gmac
               - allwinner,sun8i-v3s-emac
               - allwinner,sun50i-a64-emac
               - loongson,ls2k-dwmac
Signature · 1 line
2.31.1
maintainer Reviewed-by on v2 31/52
#68 lore raw

Re: [PATCH v2 31/52] dt-bindings: net: dwmac: Fix typo in the R40 compatible

Dne sreda, 01. september 2021 ob 11:18:31 CEST je Maxime Ripard napisal(a):

Quoted 4 lines

Even though both the driver and the device trees all use the allwinner,sun8i-r40-gmac compatible, we documented the compatible as allwinner,sun8i-r40-emac in the binding. Let's fix this.

Quoted 8 lines
Cc Alexandre Torgue <[email protected]>
Cc "David S. Miller" <[email protected]>
Cc Giuseppe Cavallaro <[email protected]>
Cc Jakub Kicinski <[email protected]>
Cc Jose Abreu <[email protected]>

Best regards,
Jernej

#69 lore raw

PATCH v2 32/52 dt-bindings: net: wireless: Convert ESP ESP8089 binding to a schema

In reply to Maxime Ripard

The ESP8089 Wireless Chip is supported by Linux (through an out-of-tree driver) thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---
 .../bindings/net/wireless/esp,esp8089.txt     | 30 -------------
 .../bindings/net/wireless/esp,esp8089.yaml    | 43 +++++++++++++++++++
 2 files changed, 43 insertions(+), 30 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt
 create mode 100644 Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml
Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt deleted +0 -30
deleted file mode 100644
index 6830c4786f8a..000000000000
@@ -1,30 +0,0 @@
-Espressif ESP8089 wireless SDIO devices
-
-This node provides properties for controlling the ESP8089 wireless device.
-The node is expected to be specified as a child node to the SDIO controller
-that connects the device to the system.
-
-Required properties:
-
- - compatible : Should be "esp,esp8089".
-
-Optional properties:
- - esp,crystal-26M-en: Integer value for the crystal_26M_en firmware parameter
-
-Example:
-
-&mmc1 {
-	#address-cells = <1>;
-	#size-cells = <0>;
-
-	vmmc-supply = <&reg_dldo1>;
-	mmc-pwrseq = <&wifi_pwrseq>;
-	bus-width = <4>;
-	non-removable;
-
-	esp8089: sdio_wifi@1 {
-		compatible = "esp,esp8089";
-		reg = <1>;
-		esp,crystal-26M-en = <2>;
-	};
-};
Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml new file +43 -0

43 lines not on this page · raw message

Signature · 1 line
2.31.1
#70 lore raw

PATCH v2 33/52 dt-bindings: regulator: Convert SY8106A binding to a schema

In reply to Maxime Ripard

The Silergy SY8106A is a regulator controlled through i2c supported by Linux with a matching device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Icenowy Zheng <[email protected]>
Cc Liam Girdwood <[email protected]>
Cc Mark Brown <[email protected]>
Cc Ondrej Jirman <[email protected]>
---
 .../bindings/regulator/silergy,sy8106a.yaml   | 52 +++++++++++++++++++
 .../bindings/regulator/sy8106a-regulator.txt  | 23 --------
 2 files changed, 52 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml
 delete mode 100644 Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml new file +52 -0
new file mode 100644
index 000000000000..a52a67c869b5
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/silergy,sy8106a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silergy SY8106A Voltage Regulator Device Tree Bindings
+
+maintainers:
+  - Ondrej Jirman <[email protected]>
+
+allOf:
+  - $ref: regulator.yaml#
+
+properties:
+  compatible:
+    const: silergy,sy8106a
+
+  reg:
+    maxItems: 1
+
+  silergy,fixed-microvolt:
+    description: >
+      The voltage when I2C regulating is disabled (set by external resistor
+      like a fixed voltage)
+
+required:
+  - compatible
+  - reg
+  - silergy,fixed-microvolt
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        regulator@65 {
+            compatible = "silergy,sy8106a";
+            reg = <0x65>;
+            regulator-name = "sy8106a-vdd";
+            silergy,fixed-microvolt = <1200000>;
+            regulator-min-microvolt = <1000000>;
+            regulator-max-microvolt = <1400000>;
+            regulator-boot-on;
+            regulator-always-on;
+        };
+    };
+
+...
Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt deleted +0 -23
deleted file mode 100644
index 39a8ca73f572..000000000000
@@ -1,23 +0,0 @@
-SY8106A Voltage regulator
-
-Required properties:
-- compatible: Must be "silergy,sy8106a"
-- reg: I2C slave address - must be <0x65>
-- silergy,fixed-microvolt - the voltage when I2C regulating is disabled (set
-  by external resistor like a fixed voltage)
-
-Any property defined as part of the core regulator binding, defined in
-./regulator.txt, can also be used.
-
-Example:
-
-	sy8106a {
-		compatible = "silergy,sy8106a";
-		reg = <0x65>;
-		regulator-name = "sy8106a-vdd";
-		silergy,fixed-microvolt = <1200000>;
-		regulator-min-microvolt = <1000000>;
-		regulator-max-microvolt = <1400000>;
-		regulator-boot-on;
-		regulator-always-on;
-	};
Signature · 1 line
2.31.1
#71 lore raw

PATCH v2 34/52 dt-bindings: sunxi: Add CPU Configuration Controller Binding

In reply to Maxime Ripard

Even though we've used the CPU configuration driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

---
 .../sunxi/allwinner,sun6i-a31-cpuconfig.yaml  | 38 +++++++++++++++++++
 1 file changed, 38 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml
Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml new file +38 -0
new file mode 100644
index 000000000000..f3878e0b3cc4
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner CPU Configuration Controller Device Tree Bindings
+
+maintainers:
+  - Chen-Yu Tsai <[email protected]>
+  - Maxime Ripard <[email protected]>
+
+properties:
+  compatible:
+    enum:
+      - allwinner,sun6i-a31-cpuconfig
+      - allwinner,sun8i-a23-cpuconfig
+      - allwinner,sun8i-a83t-cpucfg
+      - allwinner,sun8i-a83t-r-cpucfg
+      - allwinner,sun9i-a80-cpucfg
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+      cpucfg@1f01c00 {
+          compatible = "allwinner,sun6i-a31-cpuconfig";
+          reg = <0x01f01c00 0x300>;
+      };
+
+...
Signature · 1 line
2.31.1
maintainer Reviewed-by on v2 34/52
#72 lore raw

Re: [PATCH v2 34/52] dt-bindings: sunxi: Add CPU Configuration Controller Binding

Dne sreda, 01. september 2021 ob 11:18:34 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

Even though we've used the CPU configuration driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

Best regards,
Jernej

author Applied
#73 lore raw

Re: [PATCH v2 34/52] dt-bindings: sunxi: Add CPU Configuration Controller Binding

Quoted 9 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:34 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

Even though we've used the CPU configuration driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

Applied, thanks
Maxime

#74 lore raw

PATCH v2 35/52 dt-bindings: sunxi: Add Allwinner A80 PRCM Binding

In reply to Maxime Ripard

Even though we've used the A80 PRCM driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

---
 .../arm/sunxi/allwinner,sun9i-a80-prcm.yaml   | 33 +++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml
Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml new file +33 -0
new file mode 100644
index 000000000000..668aadbfe4c0
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/sunxi/allwinner,sun9i-a80-prcm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A80 PRCM Device Tree Bindings
+
+maintainers:
+  - Chen-Yu Tsai <[email protected]>
+  - Maxime Ripard <[email protected]>
+
+properties:
+  compatible:
+    const: allwinner,sun9i-a80-prcm
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+      prcm@8001400 {
+          compatible = "allwinner,sun9i-a80-prcm";
+          reg = <0x08001400 0x200>;
+      };
+
+...
Signature · 1 line
2.31.1
maintainer Reviewed-by on v2 35/52
#75 lore raw

Re: [PATCH v2 35/52] dt-bindings: sunxi: Add Allwinner A80 PRCM Binding

Dne sreda, 01. september 2021 ob 11:18:35 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

Even though we've used the A80 PRCM driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

Best regards,
Jernej

author Applied
#76 lore raw

Re: [PATCH v2 35/52] dt-bindings: sunxi: Add Allwinner A80 PRCM Binding

Quoted 9 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:35 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

Even though we've used the A80 PRCM driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.

Applied, thanks
Maxime

#77 lore raw

PATCH v2 36/52 dt-bindings: usb: Convert SMSC USB3503 binding to a schema

In reply to Maxime Ripard

The SMSC USB3503 USB Hub Controller is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Changes from v1:
- Added maximum number of items for clocks and gpios
- Fixed the example node name

---
 .../devicetree/bindings/usb/smsc,usb3503.yaml | 108 ++++++++++++++++++
 .../devicetree/bindings/usb/usb3503.txt       |  39 -------
 2 files changed, 108 insertions(+), 39 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/smsc,usb3503.yaml
 delete mode 100644 Documentation/devicetree/bindings/usb/usb3503.txt
Documentation/devicetree/bindings/usb/smsc,usb3503.yaml new file +108 -0
new file mode 100644
index 000000000000..39228a506b93
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/smsc,usb3503.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SMSC USB3503 High-Speed Hub Controller Device Tree Bindings
+
+maintainers:
+  - Dongjin Kim <[email protected]>
+
+properties:
+  compatible:
+    enum:
+      - smsc,usb3503
+      - smsc,usb3503a
+
+  reg:
+    maxItems: 1
+
+  connect-gpios:
+    maxItems: 1
+    description: >
+      GPIO for connect
+
+  intn-gpios:
+    maxItems: 1
+    description: >
+      GPIO for interrupt
+
+  reset-gpios:
+    maxItems: 1
+    description: >
+      GPIO for reset
+
+  disabled-ports:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 1
+    maxItems: 3
+    items:
+      minimum: 1
+      maximum: 3
+    description: >
+      Specifies the ports unused using their port number. Do not describe this
+      property if all ports have to be enabled.
+
+  initial-mode:
+    enum: [1, 2]
+    description: >
+      Specifies initial mode. 1 for Hub mode, 2 for standby mode.
+
+  clocks:
+    maxItems: 1
+    description: >
+      Clock used for driving REFCLK signal. If not provided the driver assumes
+      that clock signal is always available, its rate is specified by REF_SEL
+      pins and a value from the primary reference clock frequencies table is
+      used.
+
+  clock-names:
+    const: refclk
+
+  refclk-frequency:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: >
+      Frequency of the REFCLK signal as defined by REF_SEL pins. If not
+      provided, driver will not set rate of the REFCLK signal and assume that a
+      value from the primary reference clock frequencies table is used.
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+      i2c {
+          #address-cells = <1>;
+          #size-cells = <0>;
+        
+          usb-hub@8 {
+              compatible = "smsc,usb3503";
+              reg = <0x08>;
+              connect-gpios = <&gpx3 0 1>;
+              disabled-ports = <2 3>;
+              intn-gpios = <&gpx3 4 1>;
+              reset-gpios = <&gpx3 5 1>;
+              initial-mode = <1>;
+              clocks = <&clks 80>;
+              clock-names = "refclk";
+          };
+      };
+
+  - |
+      #include <dt-bindings/gpio/gpio.h>
+
+      usb-hub {
+          /* I2C is not connected */
+          compatible = "smsc,usb3503";
+          initial-mode = <1>; /* initialize in HUB mode */
+          disabled-ports = <1>;
+          intn-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+          reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
+          connect-gpios = <&pio 4 17 GPIO_ACTIVE_HIGH>; /* PE17 */
+          refclk-frequency = <19200000>;
+      };
+
+...
Documentation/devicetree/bindings/usb/usb3503.txt deleted +0 -39
deleted file mode 100644
index 057dd384d473..000000000000
@@ -1,39 +0,0 @@
-SMSC USB3503 High-Speed Hub Controller
-
-Required properties:
-- compatible: Should be "smsc,usb3503" or "smsc,usb3503a".
-
-Optional properties:
-- reg: Specifies the i2c slave address, it is required and should be 0x08
-       if I2C is used.
-- connect-gpios: Should specify GPIO for connect.
-- disabled-ports: Should specify the ports unused.
-	'1' or '2' or '3' are available for this property to describe the port
-	number. 1~3 property values are possible to be described.
-	Do not describe this property if all ports have to be enabled.
-- intn-gpios: Should specify GPIO for interrupt.
-- reset-gpios: Should specify GPIO for reset.
-- initial-mode: Should specify initial mode.
-                (1 for HUB mode, 2 for STANDBY mode)
-- refclk: Clock used for driving REFCLK signal (optional, if not provided
-	the driver assumes that clock signal is always available, its
-	rate is specified by REF_SEL pins and a value from the primary
-	reference clock frequencies table is used). Use clocks and
-	clock-names in order to assign it
-- refclk-frequency: Frequency of the REFCLK signal as defined by REF_SEL
-	pins (optional, if not provided, driver will not set rate of the
-	REFCLK signal and assume that a value from the primary reference
-	clock frequencies table is used)
-
-Examples:
-	usb3503@8 {
-		compatible = "smsc,usb3503";
-		reg = <0x08>;
-		connect-gpios = <&gpx3 0 1>;
-		disabled-ports = <2 3>;
-		intn-gpios = <&gpx3 4 1>;
-		reset-gpios = <&gpx3 5 1>;
-		initial-mode = <1>;
-		clocks = <&clks 80>;
-		clock-names = "refclk";
-	};
Signature · 1 line
2.31.1
maintainer Reviewed-by on v2 36/52
#78 lore raw

Re: [PATCH v2 36/52] dt-bindings: usb: Convert SMSC USB3503 binding to a schema

Quoted 16 lines · Maxime Ripard

The SMSC USB3503 USB Hub Controller is supported by Linux thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

---

Changes from v1:
- Added maximum number of items for clocks and gpios
- Fixed the example node name

Quoted 7 lines
---
 .../devicetree/bindings/usb/smsc,usb3503.yaml | 108 ++++++++++++++++++
 .../devicetree/bindings/usb/usb3503.txt       |  39 -------
 2 files changed, 108 insertions(+), 39 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/smsc,usb3503.yaml
 delete mode 100644 Documentation/devicetree/bindings/usb/usb3503.txt
#79 lore raw

PATCH v2 37/52 dt-bindings: usb: dwc3: Fix usb-phy check

In reply to Maxime Ripard

The original binding was allowing any combination of usb2-phy and usb3-phy in the phys and phy-names properties.

However, the current binding enforces that those properties must be a list of usb2-phy and usb3-phy, with exactly one element, effectively making usb2-phy the only value being valid.

Let's rework the properties description to allow either one or two element picked with values either usb2-phy or usb3-phy. The rest of the tooling makes sure that we don't get any duplicate value, so this should be what we want.

Cc Felipe Balbi <[email protected]>
Cc Greg Kroah-Hartman <[email protected]>
---
 Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
Documentation/devicetree/bindings/usb/snps,dwc3.yaml +5 -5
index 078fb7889593..c1c970073681 100644
@@ -73,15 +73,15 @@ properties:
 
   phys:
     minItems: 1
-    items:
-      - description: USB2/HS PHY
-      - description: USB3/SS PHY
+    maxItems: 2
 
   phy-names:
     minItems: 1
+    maxItems: 2
     items:
-      - const: usb2-phy
-      - const: usb3-phy
+      enum:
+        - usb2-phy
+        - usb3-phy
 
   resets:
     minItems: 1
Signature · 1 line
2.31.1
#80 lore raw

Re: [PATCH v2 37/52] dt-bindings: usb: dwc3: Fix usb-phy check

Quoted 25 lines · Maxime Ripard

The original binding was allowing any combination of usb2-phy and usb3-phy in the phys and phy-names properties.

However, the current binding enforces that those properties must be a list of usb2-phy and usb3-phy, with exactly one element, effectively making usb2-phy the only value being valid.

Let's rework the properties description to allow either one or two element picked with values either usb2-phy or usb3-phy. The rest of the tooling makes sure that we don't get any duplicate value, so this should be what we want.

Cc Felipe Balbi <[email protected]>
Cc Greg Kroah-Hartman <[email protected]>
---
 Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
Documentation/devicetree/bindings/usb/snps,dwc3.yaml +0 -0
index 078fb7889593..c1c970073681 100644

Documentation/devicetree/bindings/usb/snps,dwc3.yaml properties: · line 76

Quoted 7 lines
Documentation/devicetree/bindings/usb/snps,dwc3.yaml +1 -3
@@ -73,15 +73,15 @@ properties:
 
   phys:
     minItems: 1
-    items:
-      - description: USB2/HS PHY
-      - description: USB3/SS PHY
+    maxItems: 2

I'm not sure you should enforce a maximum of 2 PHYs. Some systems may use more than one USB2 PHY to take care of different parts of the USB link.

IIRC N900 was a USB2-only system which shipped with two USB2 PHYs: one handling the communication proper and one handling charger detection and the like.

Signature · 6 lines
balbi

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
maintainer
#81 lore raw

Re: [PATCH v2 37/52] dt-bindings: usb: dwc3: Fix usb-phy check

Quoted 29 lines · Felipe Balbi
Quoted 26 lines · Maxime Ripard

The original binding was allowing any combination of usb2-phy and usb3-phy in the phys and phy-names properties.

However, the current binding enforces that those properties must be a list of usb2-phy and usb3-phy, with exactly one element, effectively making usb2-phy the only value being valid.

Let's rework the properties description to allow either one or two element picked with values either usb2-phy or usb3-phy. The rest of the tooling makes sure that we don't get any duplicate value, so this should be what we want.

Cc Felipe Balbi <[email protected]>
Cc Greg Kroah-Hartman <[email protected]>
---
 Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
Documentation/devicetree/bindings/usb/snps,dwc3.yaml +0 -0
index 078fb7889593..c1c970073681 100644
@@ -73,15 +73,15 @@ properties:
 
Quoted 10 lines

Documentation/devicetree/bindings/usb/snps,dwc3.yaml properties: · line 76

Quoted 6 lines
Documentation/devicetree/bindings/usb/snps,dwc3.yaml +1 -3
   phys:
     minItems: 1
-    items:
-      - description: USB2/HS PHY
-      - description: USB3/SS PHY
+    maxItems: 2

I'm not sure you should enforce a maximum of 2 PHYs. Some systems may use more than one USB2 PHY to take care of different parts of the USB link.

It was already limited to 2. This change doesn't change that.

Rob

maintainer Reviewed-by on v2 37/52
#82 lore raw

Re: [PATCH v2 37/52] dt-bindings: usb: dwc3: Fix usb-phy check

In reply to Maxime Ripard
Quoted 12 lines · Maxime Ripard

The original binding was allowing any combination of usb2-phy and usb3-phy in the phys and phy-names properties.

However, the current binding enforces that those properties must be a list of usb2-phy and usb3-phy, with exactly one element, effectively making usb2-phy the only value being valid.

Let's rework the properties description to allow either one or two element picked with values either usb2-phy or usb3-phy. The rest of the tooling makes sure that we don't get any duplicate value, so this should be what we want.

Quoted 8 lines
Cc Felipe Balbi <[email protected]>
Cc Greg Kroah-Hartman <[email protected]>
---
 Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
#83 lore raw

PATCH v2 38/52 dt-bindings: w1: Convert 1-Wire GPIO binding to a schema

In reply to Maxime Ripard

Bitbanged 1-Wire buses are supported by Linux thanks to their device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Daniel Mack <[email protected]>
Cc Evgeniy Polyakov <[email protected]>

---

Changes from v1:
- Changed additionalproperties to make sure all the other items in the schema are nodes

---
 .../devicetree/bindings/w1/w1-gpio.txt        | 27 ------------
 .../devicetree/bindings/w1/w1-gpio.yaml       | 44 +++++++++++++++++++
 2 files changed, 44 insertions(+), 27 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.txt
 create mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.yaml
Documentation/devicetree/bindings/w1/w1-gpio.txt deleted +0 -27
deleted file mode 100644
index 3d6554eac240..000000000000
@@ -1,27 +0,0 @@
-w1-gpio devicetree bindings
-
-Required properties:
-
- - compatible: "w1-gpio"
- - gpios: one or two GPIO specs:
-		- the first one is used as data I/O pin
-		- the second one is optional. If specified, it is used as
-		  enable pin for an external pin pullup.
-
-Optional properties:
-
- - linux,open-drain: if specified, the data pin is considered in
-		     open-drain mode.
-
-Also refer to the generic w1.txt document.
-
-Examples:
-
-	onewire {
-		compatible = "w1-gpio";
-		gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
-
-		battery {
-			// ...
-		};
-	};
Documentation/devicetree/bindings/w1/w1-gpio.yaml new file +44 -0

44 lines not on this page · raw message

Signature · 1 line
2.31.1
maintainer Applied
#84 lore raw

Re: [PATCH v2 38/52] dt-bindings: w1: Convert 1-Wire GPIO binding to a schema

Quoted 15 lines · Maxime Ripard

Bitbanged 1-Wire buses are supported by Linux thanks to their device tree binding.

Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.

Cc Daniel Mack <[email protected]>
Cc Evgeniy Polyakov <[email protected]>

---

Changes from v1:
- Changed additionalproperties to make sure all the other items in the schema are nodes

Quoted 7 lines
---
 .../devicetree/bindings/w1/w1-gpio.txt        | 27 ------------
 .../devicetree/bindings/w1/w1-gpio.yaml       | 44 +++++++++++++++++++
 2 files changed, 44 insertions(+), 27 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.txt
 create mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.yaml

Applied, thanks!

#85 lore raw

PATCH v2 39/52 ARM: dts: sunxi: Rename power-supply names

In reply to Maxime Ripard

The name of our PMIC power supply names conflict with the generic regulator supply check that matches anything called *-supply, including the nodes, and then makes sure it's a phandle.

A node is obviously not a phandle, so let's change our power supplies names to avoid any conflict.

---
 arch/arm/boot/dts/axp209.dtsi             | 6 +++---
 arch/arm/boot/dts/axp22x.dtsi             | 6 +++---
 arch/arm/boot/dts/axp81x.dtsi             | 6 +++---
 arch/arm64/boot/dts/allwinner/axp803.dtsi | 6 +++---
 4 files changed, 12 insertions(+), 12 deletions(-)
arch/arm/boot/dts/axp209.dtsi +3 -3
index 0d9ff12bdf28..ca240cd6f6c3 100644
@@ -53,7 +53,7 @@ &axp209 {
 	interrupt-controller;
 	#interrupt-cells = <1>;
 
-	ac_power_supply: ac-power-supply {
+	ac_power_supply: ac-power {
 		compatible = "x-powers,axp202-ac-power-supply";
 		status = "disabled";
 	};
@@ -69,7 +69,7 @@ axp_gpio: gpio {
 		#gpio-cells = <2>;
 	};
 
-	battery_power_supply: battery-power-supply {
+	battery_power_supply: battery-power {
 		compatible = "x-powers,axp209-battery-power-supply";
 		status = "disabled";
 	};
@@ -112,7 +112,7 @@ reg_ldo5: ldo5 {
 		};
 	};
 
-	usb_power_supply: usb-power-supply {
+	usb_power_supply: usb-power {
 		compatible = "x-powers,axp202-usb-power-supply";
 		status = "disabled";
 	};
arch/arm/boot/dts/axp22x.dtsi +3 -3
index 65a07a67aca9..a020c12b2884 100644
@@ -52,7 +52,7 @@ &axp22x {
 	interrupt-controller;
 	#interrupt-cells = <1>;
 
-	ac_power_supply: ac-power-supply {
+	ac_power_supply: ac-power {
 		compatible = "x-powers,axp221-ac-power-supply";
 		status = "disabled";
 	};
@@ -62,7 +62,7 @@ axp_adc: adc {
 		#io-channel-cells = <1>;
 	};
 
-	battery_power_supply: battery-power-supply {
+	battery_power_supply: battery-power {
 		compatible = "x-powers,axp221-battery-power-supply";
 		status = "disabled";
 	};
@@ -163,7 +163,7 @@ reg_drivevbus: drivevbus {
 		};
 	};
 
-	usb_power_supply: usb_power_supply {
+	usb_power_supply: usb-power {
 		compatible = "x-powers,axp221-usb-power-supply";
 		status = "disabled";
 	};
arch/arm/boot/dts/axp81x.dtsi +3 -3
index 1dfeeceabf4c..63fb9811b453 100644
@@ -48,7 +48,7 @@ &axp81x {
 	interrupt-controller;
 	#interrupt-cells = <1>;
 
-	ac_power_supply: ac-power-supply {
+	ac_power_supply: ac-power {
 		compatible = "x-powers,axp813-ac-power-supply";
 		status = "disabled";
 	};
@@ -74,7 +74,7 @@ gpio1_ldo: gpio1-ldo {
 		};
 	};
 
-	battery_power_supply: battery-power-supply {
+	battery_power_supply: battery-power {
 		compatible = "x-powers,axp813-battery-power-supply";
 		status = "disabled";
 	};
@@ -172,7 +172,7 @@ reg_drivevbus: drivevbus {
 		};
 	};
 
-	usb_power_supply: usb-power-supply {
+	usb_power_supply: usb-power {
 		compatible = "x-powers,axp813-usb-power-supply";
 	};
 };
arch/arm64/boot/dts/allwinner/axp803.dtsi +3 -3
index 10e9186a76bf..61402057e107 100644
@@ -10,7 +10,7 @@ &axp803 {
 	interrupt-controller;
 	#interrupt-cells = <1>;
 
-	ac_power_supply: ac-power-supply {
+	ac_power_supply: ac-power {
 		compatible = "x-powers,axp803-ac-power-supply",
 			     "x-powers,axp813-ac-power-supply";
 		status = "disabled";
@@ -37,7 +37,7 @@ gpio1_ldo: gpio1-ldo {
 		};
 	};
 
-	battery_power_supply: battery-power-supply {
+	battery_power_supply: battery-power {
 		compatible = "x-powers,axp803-battery-power-supply",
 			     "x-powers,axp813-battery-power-supply";
 		status = "disabled";
@@ -147,7 +147,7 @@ reg_drivevbus: drivevbus {
 		};
 	};
 
-	usb_power_supply: usb-power-supply {
+	usb_power_supply: usb-power {
 		compatible = "x-powers,axp803-usb-power-supply",
 			     "x-powers,axp813-usb-power-supply";
 		status = "disabled";
Signature · 1 line
2.31.1
maintainer Acked-by on v2 39/52
#86 lore raw

Re: [PATCH v2 39/52] ARM: dts: sunxi: Rename power-supply names

Dne sreda, 01. september 2021 ob 11:18:39 CEST je Maxime Ripard napisal(a):

Quoted 8 lines

The name of our PMIC power supply names conflict with the generic regulator supply check that matches anything called *-supply, including the nodes, and then makes sure it's a phandle.

A node is obviously not a phandle, so let's change our power supplies names to avoid any conflict.

Best regards,
Jernej

author Applied
#87 lore raw

Re: [PATCH v2 39/52] ARM: dts: sunxi: Rename power-supply names

Quoted 11 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:39 CEST je Maxime Ripard napisal(a):

Quoted 8 lines

The name of our PMIC power supply names conflict with the generic regulator supply check that matches anything called *-supply, including the nodes, and then makes sure it's a phandle.

A node is obviously not a phandle, so let's change our power supplies names to avoid any conflict.

Applied, thanks
Maxime

#88 lore raw

PATCH v2 40/52 ARM: dts: sunxi: Rename gpio pinctrl names

In reply to Maxime Ripard

We've had a pinctrl node name convention for a while now, let's follow it for the AXP pinctrl nodes as well.

---
 arch/arm/boot/dts/axp81x.dtsi             | 4 ++--
 arch/arm64/boot/dts/allwinner/axp803.dtsi | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
arch/arm/boot/dts/axp81x.dtsi +2 -2
index 63fb9811b453..b93387b0c1c3 100644
@@ -63,12 +63,12 @@ axp_gpio: gpio {
 		gpio-controller;
 		#gpio-cells = <2>;
 
-		gpio0_ldo: gpio0-ldo {
+		gpio0_ldo: gpio0-ldo-pin {
 			pins = "GPIO0";
 			function = "ldo";
 		};
 
-		gpio1_ldo: gpio1-ldo {
+		gpio1_ldo: gpio1-ldo-pin {
 			pins = "GPIO1";
 			function = "ldo";
 		};
arch/arm64/boot/dts/allwinner/axp803.dtsi +2 -2
index 61402057e107..578ef368e2b4 100644
@@ -26,12 +26,12 @@ axp_gpio: gpio {
 		gpio-controller;
 		#gpio-cells = <2>;
 
-		gpio0_ldo: gpio0-ldo {
+		gpio0_ldo: gpio0-ldo-pin {
 			pins = "GPIO0";
 			function = "ldo";
 		};
 
-		gpio1_ldo: gpio1-ldo {
+		gpio1_ldo: gpio1-ldo-pin {
 			pins = "GPIO1";
 			function = "ldo";
 		};
Signature · 1 line
2.31.1
author Applied
#90 lore raw

Re: [PATCH v2 40/52] ARM: dts: sunxi: Rename gpio pinctrl names

Quoted 7 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:40 CEST je Maxime Ripard napisal(a):

Quoted 4 lines

We've had a pinctrl node name convention for a while now, let's follow it for the AXP pinctrl nodes as well.

Applied, thanks
Maxime

#91 lore raw

PATCH v2 41/52 ARM: dts: sunxi: Fix OPP arrays

In reply to Maxime Ripard

Even though it translates to the same thing down to the binary level, we should have an array of 2 number cells to describe each OPP, which in turns create a validation warning.

Let's fix this.

---
 .../arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 11 +++--
 arch/arm/boot/dts/sun4i-a10.dtsi              | 11 +++--
 arch/arm/boot/dts/sun5i-a13.dtsi              | 15 +++----
 arch/arm/boot/dts/sun6i-a31.dtsi              | 44 +++++++++----------
 arch/arm/boot/dts/sun7i-a20-bananapi.dts      | 17 ++++---
 arch/arm/boot/dts/sun7i-a20.dtsi              | 34 +++++++-------
 6 files changed, 61 insertions(+), 71 deletions(-)
arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts +5 -6
index ad0e25af45be..83d283cf6633 100644
@@ -91,12 +91,11 @@ &cpu0 {
 	/*
 	 * The A10-Lime is known to be unstable when running at 1008 MHz
 	 */
-	operating-points = <
-		/* kHz    uV */
-		912000  1350000
-		864000  1300000
-		624000  1250000
-		>;
+	operating-points =
+		/* kHz	  uV */
+		<912000	1350000>,
+		<864000	1300000>,
+		<624000	1250000>;
 };
 
 &de {
arch/arm/boot/dts/sun4i-a10.dtsi +5 -6
index 1c5a666c54b5..51a6464aab9a 100644
@@ -115,13 +115,12 @@ cpu0: cpu@0 {
 			reg = <0x0>;
 			clocks = <&ccu CLK_CPU>;
 			clock-latency = <244144>; /* 8 32k periods */
-			operating-points = <
+			operating-points =
 				/* kHz	  uV */
-				1008000 1400000
-				912000	1350000
-				864000	1300000
-				624000	1250000
-				>;
+				<1008000 1400000>,
+				<912000	1350000>,
+				<864000	1300000>,
+				<624000	1250000>;
 			#cooling-cells = <2>;
 		};
 	};
arch/arm/boot/dts/sun5i-a13.dtsi +7 -8
index 7075e10911d5..3325ab07094a 100644
@@ -102,15 +102,14 @@ &ccu {
 
 &cpu0 {
 	clock-latency = <244144>; /* 8 32k periods */
-	operating-points = <
+	operating-points =
 		/* kHz	  uV */
-		1008000 1400000
-		912000	1350000
-		864000	1300000
-		624000	1200000
-		576000	1200000
-		432000	1200000
-		>;
+		<1008000 1400000>,
+		<912000 1350000>,
+		<864000 1300000>,
+		<624000 1200000>,
+		<576000 1200000>,
+		<432000 1200000>;
 	#cooling-cells = <2>;
 };
 
arch/arm/boot/dts/sun6i-a31.dtsi +20 -24

72 lines not on this page · raw message

arch/arm/boot/dts/sun7i-a20-bananapi.dts +8 -9
index 9d792d7a0f92..46ecf9db2324 100644
@@ -104,16 +104,15 @@ &codec {
 
 &cpu0 {
 	cpu-supply = <&reg_dcdc2>;
-	operating-points = <
+	operating-points =
 		/* kHz	  uV */
-		960000	1400000
-		912000	1400000
-		864000	1350000
-		720000	1250000
-		528000	1150000
-		312000	1100000
-		144000	1050000
-		>;
+		<960000	1400000>,
+		<912000	1400000>,
+		<864000	1350000>,
+		<720000	1250000>,
+		<528000	1150000>,
+		<312000	1100000>,
+		<144000	1050000>;
 };
 
 &de {
arch/arm/boot/dts/sun7i-a20.dtsi +16 -18
index 5a40e0280665..5574299685ab 100644
@@ -106,16 +106,15 @@ cpu0: cpu@0 {
 			reg = <0>;
 			clocks = <&ccu CLK_CPU>;
 			clock-latency = <244144>; /* 8 32k periods */
-			operating-points = <
+			operating-points =
 				/* kHz	  uV */
-				960000	1400000
-				912000	1400000
-				864000	1300000
-				720000	1200000
-				528000	1100000
-				312000	1000000
-				144000	1000000
-				>;
+				<960000	1400000>,
+				<912000	1400000>,
+				<864000	1300000>,
+				<720000	1200000>,
+				<528000	1100000>,
+				<312000	1000000>,
+				<144000	1000000>;
 			#cooling-cells = <2>;
 		};
 
@@ -125,16 +124,15 @@ cpu1: cpu@1 {
 			reg = <1>;
 			clocks = <&ccu CLK_CPU>;
 			clock-latency = <244144>; /* 8 32k periods */
-			operating-points = <
+			operating-points =
 				/* kHz	  uV */
-				960000	1400000
-				912000	1400000
-				864000	1300000
-				720000	1200000
-				528000	1100000
-				312000	1000000
-				144000	1000000
-				>;
+				<960000	1400000>,
+				<912000	1400000>,
+				<864000	1300000>,
+				<720000	1200000>,
+				<528000	1100000>,
+				<312000	1000000>,
+				<144000	1000000>;
 			#cooling-cells = <2>;
 		};
 	};
Signature · 1 line
2.31.1
maintainer Acked-by on v2 41/52
#92 lore raw

Re: [PATCH v2 41/52] ARM: dts: sunxi: Fix OPP arrays

Dne sreda, 01. september 2021 ob 11:18:41 CEST je Maxime Ripard napisal(a):

Quoted 7 lines

Even though it translates to the same thing down to the binary level, we should have an array of 2 number cells to describe each OPP, which in turns create a validation warning.

Let's fix this.

Best regards,
Jernej

author Applied
#93 lore raw

Re: [PATCH v2 41/52] ARM: dts: sunxi: Fix OPP arrays

Quoted 10 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:41 CEST je Maxime Ripard napisal(a):

Quoted 7 lines

Even though it translates to the same thing down to the binary level, we should have an array of 2 number cells to describe each OPP, which in turns create a validation warning.

Let's fix this.

Applied, thanks

#94 lore raw

PATCH v2 42/52 ARM: dts: sunxi: Fix OPPs node name

In reply to Maxime Ripard

The operating-points-v2 nodes are named inconsistently, but mostly either opp_table0 or gpu-opp-table. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called opp-table-*. Let's fix it.

---
 arch/arm/boot/dts/sun8i-a33.dtsi                      | 4 ++--
 arch/arm/boot/dts/sun8i-a83t.dtsi                     | 4 ++--
 arch/arm/boot/dts/sun8i-h3.dtsi                       | 4 ++--
 arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi  | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi  | 2 +-
 6 files changed, 9 insertions(+), 9 deletions(-)
arch/arm/boot/dts/sun8i-a33.dtsi +2 -2
index 2beddbb3c518..b3d1bdfb5118 100644
@@ -46,7 +46,7 @@
 #include <dt-bindings/thermal/thermal.h>
 
 / {
-	cpu0_opp_table: opp_table0 {
+	cpu0_opp_table: opp-table-cpu {
 		compatible = "operating-points-v2";
 		opp-shared;
 
@@ -164,7 +164,7 @@ iio-hwmon {
 		io-channels = <&ths>;
 	};
 
-	mali_opp_table: gpu-opp-table {
+	mali_opp_table: opp-table-gpu {
 		compatible = "operating-points-v2";
 
 		opp-144000000 {
arch/arm/boot/dts/sun8i-a83t.dtsi +2 -2
index ac97eac91349..82fdb04122ca 100644
@@ -200,7 +200,7 @@ de: display-engine {
 		status = "disabled";
 	};
 
-	cpu0_opp_table: opp_table0 {
+	cpu0_opp_table: opp-table-cluster0 {
 		compatible = "operating-points-v2";
 		opp-shared;
 
@@ -253,7 +253,7 @@ opp-1200000000 {
 		};
 	};
 
-	cpu1_opp_table: opp_table1 {
+	cpu1_opp_table: opp-table-cluster1 {
 		compatible = "operating-points-v2";
 		opp-shared;
 
arch/arm/boot/dts/sun8i-h3.dtsi +2 -2
index 4e89701df91f..ae4f933abb89 100644
@@ -44,7 +44,7 @@
 #include <dt-bindings/thermal/thermal.h>
 
 / {
-	cpu0_opp_table: opp_table0 {
+	cpu0_opp_table: opp-table-cpu {
 		compatible = "operating-points-v2";
 		opp-shared;
 
@@ -112,7 +112,7 @@ cpu3: cpu@3 {
 		};
 	};
 
-	gpu_opp_table: gpu-opp-table {
+	gpu_opp_table: opp-table-gpu {
 		compatible = "operating-points-v2";
 
 		opp-120000000 {
arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi +1 -1
index 578c37490d90..e39db51eb448 100644
@@ -4,7 +4,7 @@
  */
 
 / {
-	cpu0_opp_table: opp_table0 {
+	cpu0_opp_table: opp-table-cpu {
 		compatible = "operating-points-v2";
 		opp-shared;
 
arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi +1 -1
index b2657201957e..1afad8b437d7 100644
@@ -2,7 +2,7 @@
 // Copyright (C) 2020 Chen-Yu Tsai <[email protected]>
 
 / {
-	cpu_opp_table: cpu-opp-table {
+	cpu_opp_table: opp-table-cpu {
 		compatible = "operating-points-v2";
 		opp-shared;
 
arch/arm64/boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi +1 -1
index 8c6e8536b69f..0baf0f8e4d27 100644
@@ -3,7 +3,7 @@
 // Copyright (C) 2020 Clément Péron <[email protected]>
 
 / {
-	cpu_opp_table: cpu-opp-table {
+	cpu_opp_table: opp-table-cpu {
 		compatible = "allwinner,sun50i-h6-operating-points";
 		nvmem-cells = <&cpu_speed_grade>;
 		opp-shared;
Signature · 1 line
2.31.1
maintainer Acked-by on v2 42/52
#95 lore raw

Re: [PATCH v2 42/52] ARM: dts: sunxi: Fix OPPs node name

Dne sreda, 01. september 2021 ob 11:18:42 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

The operating-points-v2 nodes are named inconsistently, but mostly either opp_table0 or gpu-opp-table. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called opp-table-*. Let's fix it.

Best regards,
Jernej

author Applied
#96 lore raw

Re: [PATCH v2 42/52] ARM: dts: sunxi: Fix OPPs node name

Quoted 9 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:42 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

The operating-points-v2 nodes are named inconsistently, but mostly either opp_table0 or gpu-opp-table. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called opp-table-*. Let's fix it.

Applied, thanks
Maxime

#97 lore raw

PATCH v2 43/52 ARM: dts: sunxi: Fix the SPI NOR node names

In reply to Maxime Ripard

According to the SPI NOR bindings, the flash node names are supposed to be flash@<address>. Let's fix our users to use that new scheme.

---
 arch/arm/boot/dts/sun8i-v3-sl631.dtsi                     | 2 +-
 arch/arm/boot/dts/sunxi-libretech-all-h3-it.dtsi          | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
arch/arm/boot/dts/sun8i-v3-sl631.dtsi +1 -1
index e0d2a31efc7f..6f93f8c49f84 100644
@@ -115,7 +115,7 @@ &reg_ldo2 {
 &spi0 {
 	status = "okay";
 
-	spi-flash@0 {
+	flash@0 {
 		reg = <0>;
 		compatible = "jedec,spi-nor";
 		spi-max-frequency = <50000000>;
arch/arm/boot/dts/sunxi-libretech-all-h3-it.dtsi +1 -1
index 204fba3614f9..50d328c2a84d 100644
@@ -156,7 +156,7 @@ &r_pio {
 &spi0 {
 	status = "okay";
 
-	spiflash@0 {
+	flash@0 {
 		compatible = "jedec,spi-nor";
 		reg = <0>;
 		spi-max-frequency = <50000000>;
arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts +1 -1
index 097a5511523a..c519d9fa6967 100644
@@ -343,7 +343,7 @@ &sound {
 &spi0 {
 	status = "okay";
 
-	spi-flash@0 {
+	flash@0 {
 		compatible = "mxicy,mx25l1606e", "jedec,spi-nor";
 		reg = <0>;
 		spi-max-frequency = <80000000>;
Signature · 1 line
2.31.1
maintainer Acked-by on v2 43/52
#98 lore raw

Re: [PATCH v2 43/52] ARM: dts: sunxi: Fix the SPI NOR node names

Dne sreda, 01. september 2021 ob 11:18:43 CEST je Maxime Ripard napisal(a):

Quoted 4 lines

According to the SPI NOR bindings, the flash node names are supposed to be flash@<address>. Let's fix our users to use that new scheme.

Best regards,
Jernej

author Applied
#99 lore raw

Re: [PATCH v2 43/52] ARM: dts: sunxi: Fix the SPI NOR node names

Quoted 7 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:43 CEST je Maxime Ripard napisal(a):

Quoted 4 lines

According to the SPI NOR bindings, the flash node names are supposed to be flash@<address>. Let's fix our users to use that new scheme.

Applied, thanks
Maxime

#100 lore raw

PATCH v2 44/52 ARM: dts: v3s: Remove useless DMA properties

In reply to Maxime Ripard

The crypto engine binding doesn't allow for any DMA property, yet the v3s define some. Remove them.

---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 2 --
 1 file changed, 2 deletions(-)
arch/arm/boot/dts/sun8i-v3s.dtsi +0 -2
index b30bc1a25ebb..44382e36e825 100644
@@ -285,8 +285,6 @@ crypto@1c15000 {
 			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&ccu CLK_BUS_CE>, <&ccu CLK_CE>;
 			clock-names = "ahb", "mod";
-			dmas = <&dma 16>, <&dma 16>;
-			dma-names = "rx", "tx";
 			resets = <&ccu RST_BUS_CE>;
 			reset-names = "ahb";
 		};
Signature · 1 line
2.31.1
maintainer
#101 lore raw

Re: [PATCH v2 44/52] ARM: dts: v3s: Remove useless DMA properties

Hi Maxime!

Dne sreda, 01. september 2021 ob 11:18:44 CEST je Maxime Ripard napisal(a):

arch/arm/boot/dts/sun8i-

Quoted 9 lines

The crypto engine binding doesn't allow for any DMA property, yet the v3s define some. Remove them.

---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 2 --
 1 file changed, 2 deletions(-)
arch/arm/boot/dts/sun8i- renamed from arch/arm/boot/dts/sun8i-v3s.dtsi +0 -0

v3s.dtsi

arch/arm/boot/dts/sun8i-v3s.dtsi crypto@1c15000 { · line 285

Quoted 5 lines

index b30bc1a25ebb..44382e36e825 100644

arch/arm/boot/dts/sun8i-v3s.dtsi +0 -0
@@ -285,8 +285,6 @@ crypto@1c15000 {
 			interrupts = <GIC_SPI 80 

IRQ_TYPE_LEVEL_HIGH>;

arch/arm/boot/dts/sun8i-v3s.dtsi crypto@1c15000 { · line 289

Quoted 4 lines
arch/arm/boot/dts/sun8i-v3s.dtsi +0 -2
 			clocks = <&ccu CLK_BUS_CE>, <&ccu CLK_CE>;
 			clock-names = "ahb", "mod";
-			dmas = <&dma 16>, <&dma 16>;
-			dma-names = "rx", "tx";

Since V3s documentation mentions those DMA channels, wouldn't be better to update bindings instead?

Best regards,
Jernej

Quoted 7 lines
arch/arm/boot/dts/sun8i-v3s.dtsi +0 -0
 			resets = <&ccu RST_BUS_CE>;
 			reset-names = "ahb";
 		};
Signature · 1 line
2.31.1
#102 lore raw

PATCH v2 45/52 ARM: dts: tbs711: Fix touchscreen compatible

In reply to Maxime Ripard

The edt,edt-ft5x06 compatible has never been a valid compatible according to the binding. Let's change for one that is.

---
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts +1 -1
index 7fe2a584ddf9..a7d4ca308990 100644
@@ -169,7 +169,7 @@ &i2c0 {
 	status = "okay";
 
 	touchscreen@38 {
-		compatible = "edt,edt-ft5x06";
+		compatible = "edt,edt-ft5206";
 		reg = <0x38>;
 		interrupt-parent = <&r_pio>;
 		interrupts = <0 7 IRQ_TYPE_EDGE_FALLING>; /* PL7 */
Signature · 1 line
2.31.1
author Applied
#104 lore raw

Re: [PATCH v2 45/52] ARM: dts: tbs711: Fix touchscreen compatible

Quoted 7 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:45 CEST je Maxime Ripard napisal(a):

Quoted 4 lines

The edt,edt-ft5x06 compatible has never been a valid compatible according to the binding. Let's change for one that is.

Applied, thanks
Maxime

#105 lore raw

PATCH v2 46/52 ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible

In reply to Maxime Ripard

The dumb-vga-dac and adi,adv7123 compatibles are not supposed to be used together according to the binding.

Since the corpro gm7123 is a drop-in replacement for the adv7123, let's remove dumb-vga-dac from our compatible list.

---
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts +1 -1
index 1fe251ea94bc..c8ca8cb7f5c9 100644
@@ -87,7 +87,7 @@ vga_con_in: endpoint {
 	};
 
 	vga-dac {
-		compatible = "corpro,gm7123", "adi,adv7123", "dumb-vga-dac";
+		compatible = "corpro,gm7123", "adi,adv7123";
 		vdd-supply = <&reg_dcdc1>;
 
 		ports {
Signature · 1 line
2.31.1
maintainer Acked-by on v2 46/52
#106 lore raw

Re: [PATCH v2 46/52] ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible

Dne sreda, 01. september 2021 ob 11:18:46 CEST je Maxime Ripard napisal(a):

Quoted 8 lines

The dumb-vga-dac and adi,adv7123 compatibles are not supposed to be used together according to the binding.

Since the corpro gm7123 is a drop-in replacement for the adv7123, let's remove dumb-vga-dac from our compatible list.

Best regards,
Jernej

author Applied
#107 lore raw

Re: [PATCH v2 46/52] ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible

Quoted 11 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:46 CEST je Maxime Ripard napisal(a):

Quoted 8 lines

The dumb-vga-dac and adi,adv7123 compatibles are not supposed to be used together according to the binding.

Since the corpro gm7123 is a drop-in replacement for the adv7123, let's remove dumb-vga-dac from our compatible list.

Applied, thanks
Maxime

#108 lore raw

PATCH v2 47/52 arm64: dts: allwinner: h5: Fix GPU thermal zone node name

In reply to Maxime Ripard

The GPU thermal zone is named gpu_thermal. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.

---
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi +1 -1
index 578a63dedf46..9988e87ea7b3 100644
@@ -217,7 +217,7 @@ cpu-hot-limit {
 			};
 		};
 
-		gpu_thermal {
+		gpu-thermal {
 			polling-delay-passive = <0>;
 			polling-delay = <0>;
 			thermal-sensors = <&ths 1>;
Signature · 1 line
2.31.1
maintainer Acked-by on v2 47/52
#109 lore raw

Re: [PATCH v2 47/52] arm64: dts: allwinner: h5: Fix GPU thermal zone node name

Dne sreda, 01. september 2021 ob 11:18:47 CEST je Maxime Ripard napisal(a):

Quoted 5 lines

The GPU thermal zone is named gpu_thermal. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.

Best regards,
Jernej

author Applied
#110 lore raw

Re: [PATCH v2 47/52] arm64: dts: allwinner: h5: Fix GPU thermal zone node name

Quoted 8 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:47 CEST je Maxime Ripard napisal(a):

Quoted 5 lines

The GPU thermal zone is named gpu_thermal. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.

Applied, thanks
Maxime

#111 lore raw

PATCH v2 48/52 arm64: dts: allwinner: h6: Fix de3 parent clocks ordering

In reply to Maxime Ripard

While it doesn't really matter from a functional point of view in this driver's case, it's usually a good practice to list the clocks in a driver in the same driver across all its users.

The H6 is using the inverse order than all the other users, so let's make it consistent.

---
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi +4 -4
index 30d396e8c762..46ed529a4dc2 100644
@@ -119,10 +119,10 @@ bus@1000000 {
 			display_clocks: clock@0 {
 				compatible = "allwinner,sun50i-h6-de3-clk";
 				reg = <0x0 0x10000>;
-				clocks = <&ccu CLK_DE>,
-					 <&ccu CLK_BUS_DE>;
-				clock-names = "mod",
-					      "bus";
+				clocks = <&ccu CLK_BUS_DE>,
+					 <&ccu CLK_DE>;
+				clock-names = "bus",
+					      "mod";
 				resets = <&ccu RST_BUS_DE>;
 				#clock-cells = <1>;
 				#reset-cells = <1>;
Signature · 1 line
2.31.1
maintainer Acked-by on v2 48/52
#112 lore raw

Re: [PATCH v2 48/52] arm64: dts: allwinner: h6: Fix de3 parent clocks ordering

Dne sreda, 01. september 2021 ob 11:18:48 CEST je Maxime Ripard napisal(a):

Quoted 8 lines

While it doesn't really matter from a functional point of view in this driver's case, it's usually a good practice to list the clocks in a driver in the same driver across all its users.

The H6 is using the inverse order than all the other users, so let's make it consistent.

Best regards,
Jernej

author Applied
#113 lore raw

Re: [PATCH v2 48/52] arm64: dts: allwinner: h6: Fix de3 parent clocks ordering

Quoted 11 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:48 CEST je Maxime Ripard napisal(a):

Quoted 8 lines

While it doesn't really matter from a functional point of view in this driver's case, it's usually a good practice to list the clocks in a driver in the same driver across all its users.

The H6 is using the inverse order than all the other users, so let's make it consistent.

Applied, thanks
Maxime

#114 lore raw

PATCH v2 49/52 arm64: dts: allwinner: a100: Fix thermal zone node name

In reply to Maxime Ripard

The thermal zones one the A100 are called $device-thermal-zone.

However, the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.

---
 arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi +3 -3
index cc321c04f121..f6d7d7f7fdab 100644
@@ -343,19 +343,19 @@ r_i2c1: i2c@7081800 {
 	};
 
 	thermal-zones {
-		cpu-thermal-zone {
+		cpu-thermal {
 			polling-delay-passive = <0>;
 			polling-delay = <0>;
 			thermal-sensors = <&ths 0>;
 		};
 
-		ddr-thermal-zone {
+		ddr-thermal {
 			polling-delay-passive = <0>;
 			polling-delay = <0>;
 			thermal-sensors = <&ths 2>;
 		};
 
-		gpu-thermal-zone {
+		gpu-thermal {
 			polling-delay-passive = <0>;
 			polling-delay = <0>;
 			thermal-sensors = <&ths 1>;
Signature · 1 line
2.31.1
maintainer Acked-by on v2 49/52
#115 lore raw

Re: [PATCH v2 49/52] arm64: dts: allwinner: a100: Fix thermal zone node name

Dne sreda, 01. september 2021 ob 11:18:49 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

The thermal zones one the A100 are called $device-thermal-zone.

However, the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.

Best regards,
Jernej

author Applied
#116 lore raw

Re: [PATCH v2 49/52] arm64: dts: allwinner: a100: Fix thermal zone node name

Quoted 10 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:49 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

The thermal zones one the A100 are called $device-thermal-zone.

However, the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.

Applied, thanks
Maxime

#117 lore raw

PATCH v2 50/52 arm64: dts: allwinner: pinetab: Change regulator node name to avoid warning

In reply to Maxime Ripard

The fixed regulator clock name has a unit address, but no reg property, which generates a warning in DTC. Change its name to remove its useless unit address.

---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts +1 -1
index 7ef96f9ff7ae..6a4af14718f5 100644
@@ -77,7 +77,7 @@ speaker_amp: audio-amplifier {
 		sound-name-prefix = "Speaker Amp";
 	};
 
-	vdd_bl: regulator@0 {
+	vdd_bl: regulator {
 		compatible = "regulator-fixed";
 		regulator-name = "bl-3v3";
 		regulator-min-microvolt = <3300000>;
Signature · 1 line
2.31.1
maintainer Acked-by on v2 50/52
#118 lore raw

Re: [PATCH v2 50/52] arm64: dts: allwinner: pinetab: Change regulator node name to avoid warning

Dne sreda, 01. september 2021 ob 11:18:50 CEST je Maxime Ripard napisal(a):

Quoted 5 lines

The fixed regulator clock name has a unit address, but no reg property, which generates a warning in DTC. Change its name to remove its useless unit address.

Best regards,
Jernej

author Applied
#119 lore raw

Re: [PATCH v2 50/52] arm64: dts: allwinner: pinetab: Change regulator node name to avoid warning

Quoted 8 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:50 CEST je Maxime Ripard napisal(a):

Quoted 5 lines

The fixed regulator clock name has a unit address, but no reg property, which generates a warning in DTC. Change its name to remove its useless unit address.

Applied, thanks
Maxime

#120 lore raw

PATCH v2 51/52 arm64: dts: allwinner: teres-i: Add missing reg

In reply to Maxime Ripard

The anx6345 bridge mandates that the input port is named port@0. Since we have a unit-address, this implies that we need a reg property with the same value, but it was found to be missing in the Teres-I device tree. Make sure it's there.

---
 arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 2 ++
 1 file changed, 2 insertions(+)
arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts +2 -0
index 45e1abdf70a0..52e032f7fb68 100644
@@ -139,6 +139,8 @@ ports {
 			#size-cells = <0>;
 
 			port@0 {
+				reg = <0>;
+
 				anx6345_in: endpoint {
 					remote-endpoint = <&tcon0_out_anx6345>;
 				};
Signature · 1 line
2.31.1
maintainer Acked-by on v2 51/52
#121 lore raw

Re: [PATCH v2 51/52] arm64: dts: allwinner: teres-i: Add missing reg

Dne sreda, 01. september 2021 ob 11:18:51 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

The anx6345 bridge mandates that the input port is named port@0. Since we have a unit-address, this implies that we need a reg property with the same value, but it was found to be missing in the Teres-I device tree. Make sure it's there.

Best regards,
Jernej

author Applied
#122 lore raw

Re: [PATCH v2 51/52] arm64: dts: allwinner: teres-i: Add missing reg

Quoted 9 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:51 CEST je Maxime Ripard napisal(a):

Quoted 6 lines

The anx6345 bridge mandates that the input port is named port@0. Since we have a unit-address, this implies that we need a reg property with the same value, but it was found to be missing in the Teres-I device tree. Make sure it's there.

Applied, thanks
Maxime

#123 lore raw

PATCH v2 52/52 arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC

In reply to Maxime Ripard

Neither the binding nor the driver make any use of the wakeup-source property for the AXP803. Remove it.

---
 arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 1 -
 1 file changed, 1 deletion(-)
arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts +0 -1
index 52e032f7fb68..aef571acd67f 100644
@@ -208,7 +208,6 @@ axp803: pmic@3a3 {
 		reg = <0x3a3>;
 		interrupt-parent = <&r_intc>;
 		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_LOW>;
-		wakeup-source;
 	};
 };
 
Signature · 1 line
2.31.1
maintainer Acked-by on v2 52/52
#124 lore raw

Re: [PATCH v2 52/52] arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC

Dne sreda, 01. september 2021 ob 11:18:52 CEST je Maxime Ripard napisal(a):

Quoted 4 lines

Neither the binding nor the driver make any use of the wakeup-source property for the AXP803. Remove it.

Best regards,
Jernej

author Applied
#125 lore raw

Re: [PATCH v2 52/52] arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC

Quoted 7 lines · Jernej Škrabec

Dne sreda, 01. september 2021 ob 11:18:52 CEST je Maxime Ripard napisal(a):

Quoted 4 lines

Neither the binding nor the driver make any use of the wakeup-source property for the AXP803. Remove it.

Applied, thanks
Maxime

maintainer
#126 lore raw

Re: (subset) [PATCH v2 00/52] ARM: dts: Last round of DT schema fixes

In reply to Maxime Ripard
Quoted 10 lines · Maxime Ripard

Here's another round of schema warnings fixes for the Allwinner platform.

There's a fair share of new schemas in there since the schema tools now warn when a compatible is not documented in a schema.

We don't have any warning anymore if we use the OPP binding Rob submitted, and since that means we have all our devices properly validated I don't expect more fixes now, aside from the usual bunch of regressions.

[...]

Applied to

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[01/52] ASoC: dt-bindings: Add WM8978 Binding

        commit: 5bd5699c494f42a3c23e377bb35be5d716b85012
[02/52] ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema
        commit: 6ef239699102580b104bfca11d9b94abfbc8caec
[03/52] ASoC: dt-bindings: Convert SPDIF Transmitter binding to a schema
        commit: 1c02b74ba20838ba194850beb0adfc6b5e11bb2a
[04/52] ASoC: dt-bindings: Convert Simple Amplifier binding to a schema
        commit: 50a41ce8c56d07f42a97112077acbaeda8b86ed9

All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying to this mail.

Thanks,
Mark