This adds minimal support for the MediaTek 8365 SOC and the EVK reference
board, allowing the board to boot to initramfs with serial port I/O.
v3:
- Remove a number of components that are not yet supported (they will
come back alongside the corresponding drivers)
- Address issues found by dt_binding_check (mostly fixing pinctrl
bindings)
- Address issues pointed out in comments
- Reorder patches
v2:
- Add missing dt-bindings documentation
- Small cleanups addressing issues in v1 pointed out by Krzysztof Kozlowski
From: Fabien Parent <[email protected]>
This adds minimal support for the Mediatek 8365 SOC and the EVK reference
board, allowing the board to boot to initramfs with serial port I/O.
Signed-off-by: Fabien Parent <[email protected]>
[[email protected]: Removed parts depending on drivers that aren't upstream yet, cleanups, add L2 cache]
Signed-off-by: Bernhard Rosenkränzer <[email protected]>
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
arch/arm64/boot/dts/mediatek/mt8365-evk.dts | 163 ++++++++++
arch/arm64/boot/dts/mediatek/mt8365.dtsi | 344 ++++++++++++++++++++
3 files changed, 508 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8365-evk.dts
create mode 100644 arch/arm64/boot/dts/mediatek/mt8365.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 0ec90cb3ef289..e668fd50a3326 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -46,4 +46,5 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8195-cherry-tomato-r2.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8195-cherry-tomato-r3.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8195-demo.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8195-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8365-evk.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8516-pumpkin.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
new file mode 100644
index 0000000000000..972843f9e4e9d
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021-2022 BayLibre, SAS.
+ * Authors:
+ * Fabien Parent <[email protected]>
+ * Bernhard Rosenkränzer <[email protected]>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/mt8365-pinfunc.h>
+#include "mt8365.dtsi"
+
+/ {
+ model = "MediaTek MT8365 Open Platform EVK";
+ compatible = "mediatek,mt8365-evk", "mediatek,mt8365";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+ };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ input-name = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_keys>;
+
+ key-volume-up {
+ gpios = <&pio 24 GPIO_ACTIVE_LOW>;
+ label = "volume_up";
+ linux,code = <KEY_VOLUMEUP>;
+ wakeup-source;
+ debounce-interval = <15>;
+ };
+ };
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0xc0000000>;
+ };
+
+ usb_otg_vbus: regulator-0 {
+ compatible = "regulator-fixed";
+ regulator-name = "otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&pio 16 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 12 MiB reserved for OP-TEE (BL32)
+ * +-----------------------+ 0x43e0_0000
+ * | SHMEM 2MiB |
+ * +-----------------------+ 0x43c0_0000
+ * | | TA_RAM 8MiB |
+ * + TZDRAM +--------------+ 0x4340_0000
+ * | | TEE_RAM 2MiB |
+ * +-----------------------+ 0x4320_0000
+ */
+ optee_reserved: optee@43200000 {
+ no-map;
+ reg = <0 0x43200000 0 0x00c00000>;
+ };
+ };
+};
+
+&pio {
+ gpio_keys: gpio-keys-pins {
+ pins {
+ pinmux = <MT8365_PIN_24_KPCOL0__FUNC_KPCOL0>;
+ bias-pull-up;
+ input-enable;
+ };
+ };
+
+ uart0_pins: uart0-pins {
+ pins {
+ pinmux = <MT8365_PIN_35_URXD0__FUNC_URXD0>,
+ <MT8365_PIN_36_UTXD0__FUNC_UTXD0>;
+ };
+ };
+
+ uart1_pins: uart1-pins {
+ pins {
+ pinmux = <MT8365_PIN_37_URXD1__FUNC_URXD1>,
+ <MT8365_PIN_38_UTXD1__FUNC_UTXD1>;
+ };
+ };
+
+ uart2_pins: uart2-pins {
+ pins {
+ pinmux = <MT8365_PIN_39_URXD2__FUNC_URXD2>,
+ <MT8365_PIN_40_UTXD2__FUNC_UTXD2>;
+ };
+ };
+
+ usb_pins: usb-pins {
+ pins-id {
+ pinmux = <MT8365_PIN_17_GPIO17__FUNC_GPIO17>;
+ input-enable;
+ bias-pull-up;
+ };
+
+ pins-usb0-vbus {
+ pinmux = <MT8365_PIN_16_GPIO16__FUNC_USB_DRVVBUS>;
+ output-high;
+ };
+
+ pin-usb1-vbus {
+ pinmux = <MT8365_PIN_18_GPIO18__FUNC_GPIO18>;
+ output-high;
+ };
+ };
+
+ pwm_pins: pwm-pins {
+ pins {
+ pinmux = <MT8365_PIN_19_DISP_PWM__FUNC_PWM_A>,
+ <MT8365_PIN_116_I2S_BCK__FUNC_PWM_C>;
+ };
+ };
+};
+
+&pwm {
+ pinctrl-0 = <&pwm_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-0 = <&uart0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-0 = <&uart1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-0 = <&uart2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8365.dtsi b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
new file mode 100644
index 0000000000000..64a77ce0a810d
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * (C) 2018 MediaTek Inc.
+ * Copyright (C) 2022 BayLibre SAS
+ * Fabien Parent <[email protected]>
+ * Bernhard Rosenkränzer <[email protected]>
+ */
+#include <dt-bindings/clock/mediatek,mt8365-clk.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/phy/phy.h>
+#include <dt-bindings/thermal/thermal.h>
+
+/ {
+ compatible = "mediatek,mt8365";
+ interrupt-parent = <&sysirq>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus: cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0: cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ core2 {
+ cpu = <&cpu2>;
+ };
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0>;
+ #cooling-cells = <2>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1>;
+ #cooling-cells = <2>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x2>;
+ #cooling-cells = <2>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x3>;
+ #cooling-cells = <2>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ clk26m: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ clock-output-names = "clk26m";
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 128 KiB reserved for ARM Trusted Firmware (BL31) */
+ bl31_secmon_reserved: secmon@43000000 {
+ no-map;
+ reg = <0 0x43000000 0 0x20000>;
+ };
+ };
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "simple-bus";
+ ranges;
+
+ gic: interrupt-controller@c000000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <4>;
+ interrupt-parent = <&gic>;
+ interrupt-controller;
+ reg = <0 0x0c000000 0 0x80000>, <0 0x0c080000 0 0x80000>;
+
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ topckgen: syscon@10000000 {
+ compatible = "mediatek,mt8365-topckgen", "syscon";
+ reg = <0 0x10000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ infracfg: syscon@10001000 {
+ compatible = "mediatek,mt8365-infracfg", "syscon";
+ reg = <0 0x10001000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ pericfg: syscon@10003000 {
+ compatible = "mediatek,mt8365-pericfg", "syscon";
+ reg = <0 0x10003000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ syscfg_pctl: syscfg-pctl@10005000 {
+ compatible = "mediatek,mt8365-syscfg", "syscon";
+ reg = <0 0x10005000 0 0x1000>;
+ };
+
+ pio: pinctrl@1000b000 {
+ compatible = "mediatek,mt8365-pinctrl";
+ reg = <0 0x1000b000 0 0x1000>;
+ mediatek,pctl-regmap = <&syscfg_pctl>;
+ pins-are-numbered;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ apmixedsys: syscon@1000c000 {
+ compatible = "mediatek,mt8365-apmixedsys", "syscon";
+ reg = <0 0x1000c000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ keypad: keypad@10010000 {
+ compatible = "mediatek,mt6779-keypad";
+ reg = <0 0x10010000 0 0x1000>;
+ wakeup-source;
+ interrupts = <GIC_SPI 124 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&clk26m>;
+ clock-names = "kpd";
+ status = "disabled";
+ };
+
+ mcucfg: syscon@10200000 {
+ compatible = "mediatek,mt8365-mcucfg", "syscon";
+ reg = <0 0x10200000 0 0x2000>;
+ #clock-cells = <1>;
+ };
+
+ sysirq: interrupt-controller@10200a80 {
+ compatible = "mediatek,mt8365-sysirq", "mediatek,mt6577-sysirq";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
+ reg = <0 0x10200a80 0 0x20>;
+ };
+
+ infracfg_nao: infracfg@1020e000 {
+ compatible = "mediatek,mt8365-infracfg", "syscon";
+ reg = <0 0x1020e000 0 0x1000>;
+ };
+
+ rng: rng@1020f000 {
+ compatible = "mediatek,mt8365-rng", "mediatek,mt7623-rng";
+ reg = <0 0x1020f000 0 0x100>;
+ clocks = <&infracfg CLK_IFR_TRNG>;
+ clock-names = "rng";
+ };
+
+ apdma: dma-controller@11000280 {
+ compatible = "mediatek,mt8365-uart-dma", "mediatek,mt6577-uart-dma";
+ reg = <0 0x11000280 0 0x80>,
+ <0 0x11000300 0 0x80>,
+ <0 0x11000380 0 0x80>,
+ <0 0x11000400 0 0x80>,
+ <0 0x11000580 0 0x80>,
+ <0 0x11000600 0 0x80>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 46 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 47 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 48 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 51 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 52 IRQ_TYPE_LEVEL_LOW>;
+ dma-requests = <6>;
+ clocks = <&infracfg CLK_IFR_AP_DMA>;
+ clock-names = "apdma";
+ #dma-cells = <1>;
+ };
+
+ uart0: serial@11002000 {
+ compatible = "mediatek,mt8365-uart", "mediatek,mt6577-uart";
+ reg = <0 0x11002000 0 0x1000>;
+ interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&clk26m>, <&infracfg CLK_IFR_UART0>;
+ clock-names = "baud", "bus";
+ dmas = <&apdma 0>, <&apdma 1>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ uart1: serial@11003000 {
+ compatible = "mediatek,mt8365-uart", "mediatek,mt6577-uart";
+ reg = <0 0x11003000 0 0x1000>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&clk26m>, <&infracfg CLK_IFR_UART1>;
+ clock-names = "baud", "bus";
+ dmas = <&apdma 2>, <&apdma 3>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ uart2: serial@11004000 {
+ compatible = "mediatek,mt8365-uart", "mediatek,mt6577-uart";
+ reg = <0 0x11004000 0 0x1000>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&clk26m>, <&infracfg CLK_IFR_UART2>;
+ clock-names = "baud", "bus";
+ dmas = <&apdma 4>, <&apdma 5>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ pwm: pwm@11006000 {
+ compatible = "mediatek,mt8365-pwm";
+ reg = <0 0x11006000 0 0x1000>;
+ #pwm-cells = <2>;
+ interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_IFR_PWM_HCLK>,
+ <&infracfg CLK_IFR_PWM>,
+ <&infracfg CLK_IFR_PWM1>,
+ <&infracfg CLK_IFR_PWM2>,
+ <&infracfg CLK_IFR_PWM3>;
+ clock-names = "top", "main", "pwm1", "pwm2", "pwm3";
+ };
+
+ spi: spi@1100a000 {
+ compatible = "mediatek,mt8365-spi", "mediatek,mt7622-spi";
+ reg = <0 0x1100a000 0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_UNIVPLL2_D4>,
+ <&topckgen CLK_TOP_SPI_SEL>,
+ <&infracfg CLK_IFR_SPI0>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
+ ssusb: usb@11201000 {
+ compatible = "mediatek,mt8365-mtu3", "mediatek,mtu3";
+ reg = <0 0x11201000 0 0x2e00>, <0 0x11203e00 0 0x0100>;
+ reg-names = "mac", "ippc";
+ interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_LOW>;
+ phys = <&u2port0 PHY_TYPE_USB2>,
+ <&u2port1 PHY_TYPE_USB2>;
+ clocks = <&topckgen CLK_TOP_SSUSB_TOP_CK_EN>,
+ <&infracfg CLK_IFR_SSUSB_REF>,
+ <&infracfg CLK_IFR_SSUSB_SYS>,
+ <&infracfg CLK_IFR_ICUSB>;
+ clock-names = "sys_ck", "ref_ck", "mcu_ck", "dma_ck";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ usb_host: usb@11200000 {
+ compatible = "mediatek,mt8365-xhci", "mediatek,mtk-xhci";
+ reg = <0 0x11200000 0 0x1000>;
+ reg-names = "mac";
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_SSUSB_TOP_CK_EN>,
+ <&infracfg CLK_IFR_SSUSB_REF>,
+ <&infracfg CLK_IFR_SSUSB_SYS>,
+ <&infracfg CLK_IFR_ICUSB>,
+ <&infracfg CLK_IFR_SSUSB_XHCI>;
+ clock-names = "sys_ck", "ref_ck", "mcu_ck",
+ "dma_ck", "xhci_ck";
+ status = "disabled";
+ };
+ };
+
+ u3phy: phy@11cc0000 {
+ compatible = "mediatek,mt8365-tphy", "mediatek,generic-tphy-v2";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ #phy-cells = <1>;
+ ranges;
+
+ u2port0: usb-phy@11cc0000 {
+ reg = <0 0x11cc0000 0 0x400>;
+ clocks = <&topckgen CLK_TOP_SSUSB_PHY_CK_EN>,
+ <&topckgen CLK_TOP_USB20_48M_EN>;
+ clock-names = "ref", "da_ref";
+ #phy-cells = <1>;
+ };
+
+ u2port1: usb-phy@11cc1000 {
+ reg = <0 0x11cc1000 0 0x400>;
+ clocks = <&topckgen CLK_TOP_SSUSB_PHY_CK_EN>,
+ <&topckgen CLK_TOP_USB20_48M_EN>;
+ clock-names = "ref", "da_ref";
+ #phy-cells = <1>;
+ };
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW 0>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW 0>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW 0>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW 0>;
+ };
+};
--
2.38.1
From: Fabien Parent <[email protected]>
Add binding documentation for the MT8365 SoC.
Signed-off-by: Fabien Parent <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Bernhard Rosenkränzer <[email protected]>
---
Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
index 939623867a646..3b92725bbc99b 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
@@ -34,6 +34,7 @@ properties:
- mediatek,mt8188-xhci
- mediatek,mt8192-xhci
- mediatek,mt8195-xhci
+ - mediatek,mt8365-xhci
- const: mediatek,mtk-xhci
reg:
--
2.38.1
Add binding documentation of mediatek,sysirq for mt8365 SoC.
Signed-off-by: Bernhard Rosenkränzer <[email protected]>
---
.../devicetree/bindings/interrupt-controller/mediatek,sysirq.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
index 84ced3f4179b9..3ffc60184e445 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
@@ -25,6 +25,7 @@ Required properties:
"mediatek,mt6577-sysirq": for MT6577
"mediatek,mt2712-sysirq", "mediatek,mt6577-sysirq": for MT2712
"mediatek,mt2701-sysirq", "mediatek,mt6577-sysirq": for MT2701
+ "mediatek,mt8365-sysirq", "mediatek,mt6577-sysirq": for MT8365
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Use the same format as specified by GIC in arm,gic.txt.
- reg: Physical base address of the intpol registers and length of memory
--
2.38.1
From: Fabien Parent <[email protected]>
Add binding documentation for the MT8365 SoC.
Signed-off-by: Fabien Parent <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Bernhard Rosenkränzer <[email protected]>
---
Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
index 80750b0f458a8..25934871a4d85 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
@@ -27,6 +27,7 @@ properties:
- mediatek,mt8188-mtu3
- mediatek,mt8192-mtu3
- mediatek,mt8195-mtu3
+ - mediatek,mt8365-mtu3
- const: mediatek,mtu3
reg:
--
2.38.1
Add bindings for the Mediatek mt8365-evk board.
Signed-off-by: Bernhard Rosenkränzer <[email protected]>
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 7642f9350d2c0..a9c18fc7905c0 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -243,6 +243,10 @@ properties:
- enum:
- mediatek,mt8183-pumpkin
- const: mediatek,mt8183
+ - items:
+ - enum:
+ - mediatek,mt8365-evk
+ - const: mediatek, mt8365
- items:
- enum:
- mediatek,mt8516-pumpkin
--
2.38.1
Add devicetree bindings for Mediatek MT8365 pinctrl driver.
Signed-off-by: Bernhard Rosenkränzer <[email protected]>
---
.../pinctrl/mediatek,mt8365-pinctrl.yaml | 202 ++++++++++++++++++
1 file changed, 202 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml
new file mode 100644
index 0000000000000..7758644da302a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml
@@ -0,0 +1,202 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8365-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT8365 Pin Controller
+
+maintainers:
+ - Zhiyong Tao <[email protected]>
+ - Bernhard Rosenkränzer <[email protected]>
+
+description: |+
+ The MediaTek's MT8365 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt8365-pinctrl
+
+ reg:
+ maxItems: 1
+
+ mediatek,pctl-regmap:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ maxItems: 1
+ minItems: 1
+ maxItems: 2
+ description: |
+ Should be phandles of the syscfg node.
+
+ pins-are-numbered:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ Specify the subnodes are using numbered pinmux to specify pins.
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description: |
+ Number of cells in GPIO specifier. Since the generic GPIO
+ binding is used, the amount of cells must be specified as 2. See the below
+ mentioned gpio binding representation for description of particular cells.
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+ patternProperties:
+ 'pins':
+ type: object
+ additionalProperties: false
+ description: |
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+ $ref: "/schemas/pinctrl/pincfg-node.yaml"
+
+ properties:
+ pinmux:
+ description:
+ integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are
+ defined as macros in <soc>-pinfunc.h directly.
+
+ bias-disable: true
+
+ bias-pull-up:
+ description: |
+ Besides generic pinconfig options, it can be used as the pull up
+ settings for 2 pull resistors, R0 and R1. User can configure those
+ special pins.
+
+ bias-pull-down: true
+
+ input-enable: true
+
+ input-disable: true
+
+ output-low: true
+
+ output-high: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ mediatek,drive-strength-adv:
+ description: |
+ Describe the specific driving setup property.
+ For I2C pins, the existing generic driving setup can only support
+ 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they
+ can support 0.125/0.25/0.5/1mA adjustment. If we enable specific
+ driving setup, the existing generic setup will be disabled.
+ The specific driving setup is controlled by E1E0EN.
+ When E1=0/E0=0, the strength is 0.125mA.
+ When E1=0/E0=1, the strength is 0.25mA.
+ When E1=1/E0=0, the strength is 0.5mA.
+ When E1=1/E0=1, the strength is 1mA.
+ EN is used to enable or disable the specific driving setup.
+ Valid arguments are described as below:
+ 0: (E1, E0, EN) = (0, 0, 0)
+ 1: (E1, E0, EN) = (0, 0, 1)
+ 2: (E1, E0, EN) = (0, 1, 0)
+ 3: (E1, E0, EN) = (0, 1, 1)
+ 4: (E1, E0, EN) = (1, 0, 0)
+ 5: (E1, E0, EN) = (1, 0, 1)
+ 6: (E1, E0, EN) = (1, 1, 0)
+ 7: (E1, E0, EN) = (1, 1, 1)
+ So the valid arguments are from 0 to 7.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ mediatek,pull-up-adv:
+ description: |
+ Pull up setings for 2 pull resistors, R0 and R1. User can
+ configure those special pins. Valid arguments are described as below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ mediatek,pull-down-adv:
+ description: |
+ Pull down settings for 2 pull resistors, R0 and R1. User can
+ configure those special pins. Valid arguments are described as below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ mediatek,tdsel:
+ description: |
+ An integer describing the steps for output level shifter duty
+ cycle when asserted (high pulse width adjustment). Valid arguments
+ are from 0 to 15.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ mediatek,rdsel:
+ description: |
+ An integer describing the steps for input level shifter duty cycle
+ when asserted (high pulse width adjustment). Valid arguments are
+ from 0 to 63.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - pinmux
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/pinctrl/mt8365-pinfunc.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pio: pinctrl@1000b000 {
+ compatible = "mediatek,mt8365-pinctrl";
+ reg = <0 0x1000b000 0 0x1000>;
+ mediatek,pctl-regmap = <&syscfg_pctl>;
+ pins-are-numbered;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+ pio-pins {
+ pins {
+ pinmux = <MT8365_PIN_59_SDA1__FUNC_SDA1_0>, <MT8365_PIN_60_SCL1__FUNC_SCL1_0>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ bias-pull-up;
+ };
+ };
+ };
+ };
--
2.38.1
Document Mediatek mt8365-syscfg
Signed-off-by: Bernhard Rosenkränzer <[email protected]>
---
Documentation/devicetree/bindings/mfd/syscon.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index 1b01bd0104316..7beeb0abc4db0 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -50,6 +50,7 @@ properties:
- marvell,armada-3700-usb2-host-misc
- mediatek,mt8135-pctl-a-syscfg
- mediatek,mt8135-pctl-b-syscfg
+ - mediatek,mt8365-syscfg
- microchip,lan966x-cpu-syscon
- microchip,sparx5-cpu-syscon
- mstar,msc313-pmsleep
--
2.38.1
On 17/11/2022 22:03, Bernhard Rosenkränzer wrote:
> Add binding documentation of mediatek,sysirq for mt8365 SoC.
>
> Signed-off-by: Bernhard Rosenkränzer <[email protected]>
> ---
Acked-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
On 17/11/2022 22:03, Bernhard Rosenkränzer wrote:
> Document Mediatek mt8365-syscfg
>
> Signed-off-by: Bernhard Rosenkränzer <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
On 17/11/2022 22:03, Bernhard Rosenkränzer wrote:
> Add bindings for the Mediatek mt8365-evk board.
>
> Signed-off-by: Bernhard Rosenkränzer <[email protected]>
> ---
> Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index 7642f9350d2c0..a9c18fc7905c0 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -243,6 +243,10 @@ properties:
> - enum:
> - mediatek,mt8183-pumpkin
> - const: mediatek,mt8183
> + - items:
> + - enum:
> + - mediatek,mt8365-evk
> + - const: mediatek, mt8365
Still wrong compatible.
Best regards,
Krzysztof
On 17/11/2022 22:03, Bernhard Rosenkränzer wrote:
> Add devicetree bindings for Mediatek MT8365 pinctrl driver.
>
> Signed-off-by: Bernhard Rosenkränzer <[email protected]>
Thank you for your patch. There is something to discuss/improve.
> +
> + pins-are-numbered:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
> + Specify the subnodes are using numbered pinmux to specify pins.
Why would you name pins differently per board? And why this different
naming of the same pins is a property of hardware?
This looks like something to drop.
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> + description: |
> + Number of cells in GPIO specifier. Since the generic GPIO
> + binding is used, the amount of cells must be specified as 2. See the below
> + mentioned gpio binding representation for description of particular cells.
> +
> + interrupt-controller: true
> +
> + interrupts:
> + maxItems: 1
> +
> + "#interrupt-cells":
> + const: 2
> +
> +required:
> + - compatible
> + - reg
> + - gpio-controller
> + - "#gpio-cells"
> +
> +allOf:
> + - $ref: pinctrl.yaml#
> +
> +patternProperties:
patternProperties go before "required:" block.
> + '-pins$':
> + type: object
> + additionalProperties: false
> + patternProperties:
> + 'pins':
How about anchoring it to either prefix or suffix? ^pins or pins$.
> + type: object
> + additionalProperties: false
> + description: |
> + A pinctrl node should contain at least one subnode representing the
> + pinctrl groups available on the machine. Each subnode will list the
> + pins it needs, and how they should be configured, with regard to muxer
> + configuration, pullups, drive strength, input enable/disable and input
> + schmitt.
> + $ref: "/schemas/pinctrl/pincfg-node.yaml"
Drop quotes.
> +
> + properties:
> + pinmux:
> + description:
> + integer array, represents gpio pin number and mux setting.
> + Supported pin number and mux varies for different SoCs, and are
> + defined as macros in <soc>-pinfunc.h directly.
> +
> + bias-disable: true
> +
> + bias-pull-up:
> + description: |
> + Besides generic pinconfig options, it can be used as the pull up
> + settings for 2 pull resistors, R0 and R1. User can configure those
> + special pins.
> +
> + bias-pull-down: true
> +
> + input-enable: true
> +
> + input-disable: true
> +
> + output-low: true
> +
> + output-high: true
> +
> + input-schmitt-enable: true
> +
> + input-schmitt-disable: true
> +
> + mediatek,drive-strength-adv:
> + description: |
> + Describe the specific driving setup property.
> + For I2C pins, the existing generic driving setup can only support
> + 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they
> + can support 0.125/0.25/0.5/1mA adjustment. If we enable specific
> + driving setup, the existing generic setup will be disabled.
> + The specific driving setup is controlled by E1E0EN.
> + When E1=0/E0=0, the strength is 0.125mA.
> + When E1=0/E0=1, the strength is 0.25mA.
> + When E1=1/E0=0, the strength is 0.5mA.
> + When E1=1/E0=1, the strength is 1mA.
> + EN is used to enable or disable the specific driving setup.
> + Valid arguments are described as below:
> + 0: (E1, E0, EN) = (0, 0, 0)
> + 1: (E1, E0, EN) = (0, 0, 1)
> + 2: (E1, E0, EN) = (0, 1, 0)
> + 3: (E1, E0, EN) = (0, 1, 1)
> + 4: (E1, E0, EN) = (1, 0, 0)
> + 5: (E1, E0, EN) = (1, 0, 1)
> + 6: (E1, E0, EN) = (1, 1, 0)
> + 7: (E1, E0, EN) = (1, 1, 1)
> + So the valid arguments are from 0 to 7.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3, 4, 5, 6, 7]
> +
> + mediatek,pull-up-adv:
> + description: |
> + Pull up setings for 2 pull resistors, R0 and R1. User can
> + configure those special pins. Valid arguments are described as below:
> + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
> + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
> + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
> + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3]
> +
> + mediatek,pull-down-adv:
> + description: |
> + Pull down settings for 2 pull resistors, R0 and R1. User can
> + configure those special pins. Valid arguments are described as below:
> + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
> + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
> + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
> + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3]
> +
> + mediatek,tdsel:
> + description: |
> + An integer describing the steps for output level shifter duty
> + cycle when asserted (high pulse width adjustment). Valid arguments
> + are from 0 to 15.
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + mediatek,rdsel:
> + description: |
> + An integer describing the steps for input level shifter duty cycle
> + when asserted (high pulse width adjustment). Valid arguments are
> + from 0 to 63.
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + required:
> + - pinmux
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/pinctrl/mt8365-pinfunc.h>
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + pio: pinctrl@1000b000 {
> + compatible = "mediatek,mt8365-pinctrl";
> + reg = <0 0x1000b000 0 0x1000>;
> + mediatek,pctl-regmap = <&syscfg_pctl>;
> + pins-are-numbered;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
Blank line
> + pio-pins {
> + pins {
> + pinmux = <MT8365_PIN_59_SDA1__FUNC_SDA1_0>, <MT8365_PIN_60_SCL1__FUNC_SCL1_0>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + bias-pull-up;
> + };
> + };
> + };
> + };
Best regards,
Krzysztof
Hi Krzysztof,
Krzysztof Kozlowski <[email protected]> writes:
> On 17/11/2022 22:03, Bernhard Rosenkränzer wrote:
>> Add devicetree bindings for Mediatek MT8365 pinctrl driver.
>>
>> Signed-off-by: Bernhard Rosenkränzer <[email protected]>
>
> Thank you for your patch. There is something to discuss/improve.
>
>> +
>> + pins-are-numbered:
>> + $ref: /schemas/types.yaml#/definitions/flag
>> + description: |
>> + Specify the subnodes are using numbered pinmux to specify pins.
>
> Why would you name pins differently per board? And why this different
> naming of the same pins is a property of hardware?
>
> This looks like something to drop.
Yeah, having this as a flag kind of implies that this could be present
for some boards but not others. But in practice, the driver requires it
to be present or just fails[1]. What's the right way to describe that?
We're just trying to add a binding that reflects the existing driver.
We also noticed that there's another documented binding with this
same flag[2] where similiarily, the driver simply requires it to be
present[2].
So is the way this flag is documented in the stm32 binding OK for the
mediatek one also? If not, what would you suggest?
Thanks for the review,
Kevin
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/mediatek/pinctrl-mtk-common.c#n1053
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml#n37
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/stm32/pinctrl-stm32.c#n1499
Bernhard Rosenkränzer <[email protected]> writes:
> From: Fabien Parent <[email protected]>
>
> This adds minimal support for the Mediatek 8365 SOC and the EVK reference
> board, allowing the board to boot to initramfs with serial port I/O.
>
> Signed-off-by: Fabien Parent <[email protected]>
> [[email protected]: Removed parts depending on drivers that aren't upstream yet, cleanups, add L2 cache]
> Signed-off-by: Bernhard Rosenkränzer <[email protected]>
Tested-by: Kevin Hilman <[email protected]>
Boot tested on mt8365-evk and works well. When this lands we can get
finally this board into KernelCI. :)
Kevin
On 18/11/2022 20:52, Kevin Hilman wrote:
> Hi Krzysztof,
>
> Krzysztof Kozlowski <[email protected]> writes:
>
>> On 17/11/2022 22:03, Bernhard Rosenkränzer wrote:
>>> Add devicetree bindings for Mediatek MT8365 pinctrl driver.
>>>
>>> Signed-off-by: Bernhard Rosenkränzer <[email protected]>
>>
>> Thank you for your patch. There is something to discuss/improve.
>>
>>> +
>>> + pins-are-numbered:
>>> + $ref: /schemas/types.yaml#/definitions/flag
>>> + description: |
>>> + Specify the subnodes are using numbered pinmux to specify pins.
>>
>> Why would you name pins differently per board? And why this different
>> naming of the same pins is a property of hardware?
>>
>> This looks like something to drop.
>
> Yeah, having this as a flag kind of implies that this could be present
> for some boards but not others. But in practice, the driver requires it
> to be present or just fails[1]. What's the right way to describe that?
> We're just trying to add a binding that reflects the existing driver.
Uh, what an interesting property. What's the point of it then? Why
failing to probe on a missing property which does nothing else?
The solution is also to drop that property from the driver.
> We also noticed that there's another documented binding with this
> same flag[2] where similiarily, the driver simply requires it to be
> present[2].
>
> So is the way this flag is documented in the stm32 binding OK for the
> mediatek one also? If not, what would you suggest?
I would like to understand why do we need this property and what is
described by it. Because if it's purpose is only to fail or not fail
driver probe, then we should just drop it everywhere.
>
Best regards,
Krzysztof
Hi Krzysztof,
On Sun, Nov 20, 2022 at 11:40 AM Krzysztof Kozlowski
<[email protected]> wrote:
> >>> + pins-are-numbered:
> >
> > Yeah, having this as a flag kind of implies that this could be present
> > for some boards but not others. But in practice, the driver requires it
> > to be present or just fails[1]. What's the right way to describe that?
> > We're just trying to add a binding that reflects the existing driver.
>
> Uh, what an interesting property. What's the point of it then? Why
> failing to probe on a missing property which does nothing else?
I couldn't find any other use of it in the kernel, and also checked
u-boot (where the property also appears in some devicetree files, but
isn't used anywhere).
Both the MTK and STM drivers use it just to refuse it if it isn't there.
Unfortunately "git blame" only shows pins-are-numbered being added as
part of a larger commit ("add the driver"), so there's no "add check
for pins-are-numbered because xyz" commit message.
I can think of 3 possible explanations, but none of them are good:
1. It's something that had a purpose at some point, but doesn't
anymore (but that would likely leave some trace in "git blame"...)
2. It's something that was added in preparation for another patch (but
I can't find any queued/suggested patches that make use of it)
3. It's for the sake of userland -- check if pins-are-numbered is set
(which will be true for MTK and STM because these drivers enforce it,
false for anything else because the schemas don't mention it) and then
do different things. But this seems unlikely as well, the usual
suspects (libgpiod and friends) don't do any such lookup, and there
are ways to look up pins without that property - and I'd expect pins
are numbered on many controllers outside of MTK and STM, so looking up
that property would give a false response there.
> I would like to understand why do we need this property and what is
> described by it.
Same here...
> Because if it's purpose is only to fail or not fail
> driver probe, then we should just drop it everywhere.
Agreed (and I think more likely than not, that is the only purpose),
but probably a "add support for another board" patchset isn't the
right context for that.
I can prepare a "remove pins-are-numbered" patchset, but given it will
likely take time to track down someone who knows why this was added in
the first place, I don't think it should block the MT8365 patchset.
Best regards
bero
On Sun, Nov 20, 2022 at 3:38 PM Bernhard Rosenkränzer <[email protected]> wrote:
> I can prepare a "remove pins-are-numbered" patchset
... and I did.
https://lore.kernel.org/linux-devicetree/[email protected]/
Best regards
bero
On 21/11/2022 02:58, Bernhard Rosenkränzer wrote:
> On Sun, Nov 20, 2022 at 3:38 PM Bernhard Rosenkränzer <[email protected]> wrote:
>> I can prepare a "remove pins-are-numbered" patchset
>
> ... and I did.
> https://lore.kernel.org/linux-devicetree/[email protected]/
Awesome, thank you!
Best regards,
Krzysztof