* [PATCH v16 22/22] riscv: dts: starfive: add PCIe dts configuration for JH7110
From: Minda Chen @ 2024-03-28 9:18 UTC (permalink / raw)
To: Lorenzo Pieralisi, Conor Dooley, Krzysztof Wilczyński,
Rob Herring, Bjorn Helgaas, Thomas Gleixner, Daire McNamara,
Emil Renner Berthing, Krzysztof Kozlowski
Cc: devicetree, linux-kernel, linux-riscv, linux-pci, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Philipp Zabel, Mason Huo, Leyfoon Tan,
Kevin Xie, Minda Chen
In-Reply-To: <20240328091835.14797-1-minda.chen@starfivetech.com>
Add PCIe dts configuraion for JH7110 SoC platform.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../jh7110-starfive-visionfive-2.dtsi | 64 ++++++++++++++
arch/riscv/boot/dts/starfive/jh7110.dtsi | 86 +++++++++++++++++++
2 files changed, 150 insertions(+)
diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
index 45b58b6f3df8..de95e330a93c 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
@@ -330,6 +330,22 @@
status = "okay";
};
+&pcie0 {
+ perst-gpios = <&sysgpio 26 GPIO_ACTIVE_LOW>;
+ phys = <&pciephy0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_pins>;
+ status = "okay";
+};
+
+&pcie1 {
+ perst-gpios = <&sysgpio 28 GPIO_ACTIVE_LOW>;
+ phys = <&pciephy1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie1_pins>;
+ status = "okay";
+};
+
&pwmdac {
pinctrl-names = "default";
pinctrl-0 = <&pwmdac_pins>;
@@ -552,6 +568,54 @@
};
};
+ pcie0_pins: pcie0-0 {
+ clkreq-pins {
+ pinmux = <GPIOMUX(27, GPOUT_LOW,
+ GPOEN_DISABLE,
+ GPI_NONE)>;
+ bias-pull-down;
+ drive-strength = <2>;
+ input-enable;
+ input-schmitt-disable;
+ slew-rate = <0>;
+ };
+
+ wake-pins {
+ pinmux = <GPIOMUX(32, GPOUT_LOW,
+ GPOEN_DISABLE,
+ GPI_NONE)>;
+ bias-pull-up;
+ drive-strength = <2>;
+ input-enable;
+ input-schmitt-disable;
+ slew-rate = <0>;
+ };
+ };
+
+ pcie1_pins: pcie1-0 {
+ clkreq-pins {
+ pinmux = <GPIOMUX(29, GPOUT_LOW,
+ GPOEN_DISABLE,
+ GPI_NONE)>;
+ bias-pull-down;
+ drive-strength = <2>;
+ input-enable;
+ input-schmitt-disable;
+ slew-rate = <0>;
+ };
+
+ wake-pins {
+ pinmux = <GPIOMUX(21, GPOUT_LOW,
+ GPOEN_DISABLE,
+ GPI_NONE)>;
+ bias-pull-up;
+ drive-strength = <2>;
+ input-enable;
+ input-schmitt-disable;
+ slew-rate = <0>;
+ };
+ };
+
pwmdac_pins: pwmdac-0 {
pwmdac-pins {
pinmux = <GPIOMUX(33, GPOUT_SYS_PWMDAC_LEFT,
diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi
index 4a5708f7fcf7..f906b1ec8518 100644
--- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
@@ -1214,5 +1214,91 @@
#reset-cells = <1>;
power-domains = <&pwrc JH7110_PD_VOUT>;
};
+
+ pcie0: pcie@940000000 {
+ compatible = "starfive,jh7110-pcie";
+ reg = <0x9 0x40000000 0x0 0x1000000>,
+ <0x0 0x2b000000 0x0 0x100000>;
+ reg-names = "cfg", "apb";
+ linux,pci-domain = <0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0x0 0x30000000 0x0 0x30000000 0x0 0x08000000>,
+ <0xc3000000 0x9 0x00000000 0x9 0x00000000 0x0 0x40000000>;
+ interrupts = <56>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc0 0x1>,
+ <0x0 0x0 0x0 0x2 &pcie_intc0 0x2>,
+ <0x0 0x0 0x0 0x3 &pcie_intc0 0x3>,
+ <0x0 0x0 0x0 0x4 &pcie_intc0 0x4>;
+ msi-controller;
+ device_type = "pci";
+ starfive,stg-syscon = <&stg_syscon>;
+ bus-range = <0x0 0xff>;
+ clocks = <&syscrg JH7110_SYSCLK_NOC_BUS_STG_AXI>,
+ <&stgcrg JH7110_STGCLK_PCIE0_TL>,
+ <&stgcrg JH7110_STGCLK_PCIE0_AXI_MST0>,
+ <&stgcrg JH7110_STGCLK_PCIE0_APB>;
+ clock-names = "noc", "tl", "axi_mst0", "apb";
+ resets = <&stgcrg JH7110_STGRST_PCIE0_AXI_MST0>,
+ <&stgcrg JH7110_STGRST_PCIE0_AXI_SLV0>,
+ <&stgcrg JH7110_STGRST_PCIE0_AXI_SLV>,
+ <&stgcrg JH7110_STGRST_PCIE0_BRG>,
+ <&stgcrg JH7110_STGRST_PCIE0_CORE>,
+ <&stgcrg JH7110_STGRST_PCIE0_APB>;
+ reset-names = "mst0", "slv0", "slv", "brg",
+ "core", "apb";
+ status = "disabled";
+
+ pcie_intc0: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+
+ pcie1: pcie@9c0000000 {
+ compatible = "starfive,jh7110-pcie";
+ reg = <0x9 0xc0000000 0x0 0x1000000>,
+ <0x0 0x2c000000 0x0 0x100000>;
+ reg-names = "cfg", "apb";
+ linux,pci-domain = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0x0 0x38000000 0x0 0x38000000 0x0 0x08000000>,
+ <0xc3000000 0x9 0x80000000 0x9 0x80000000 0x0 0x40000000>;
+ interrupts = <57>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc1 0x1>,
+ <0x0 0x0 0x0 0x2 &pcie_intc1 0x2>,
+ <0x0 0x0 0x0 0x3 &pcie_intc1 0x3>,
+ <0x0 0x0 0x0 0x4 &pcie_intc1 0x4>;
+ msi-controller;
+ device_type = "pci";
+ starfive,stg-syscon = <&stg_syscon>;
+ bus-range = <0x0 0xff>;
+ clocks = <&syscrg JH7110_SYSCLK_NOC_BUS_STG_AXI>,
+ <&stgcrg JH7110_STGCLK_PCIE1_TL>,
+ <&stgcrg JH7110_STGCLK_PCIE1_AXI_MST0>,
+ <&stgcrg JH7110_STGCLK_PCIE1_APB>;
+ clock-names = "noc", "tl", "axi_mst0", "apb";
+ resets = <&stgcrg JH7110_STGRST_PCIE1_AXI_MST0>,
+ <&stgcrg JH7110_STGRST_PCIE1_AXI_SLV0>,
+ <&stgcrg JH7110_STGRST_PCIE1_AXI_SLV>,
+ <&stgcrg JH7110_STGRST_PCIE1_BRG>,
+ <&stgcrg JH7110_STGRST_PCIE1_CORE>,
+ <&stgcrg JH7110_STGRST_PCIE1_APB>;
+ reset-names = "mst0", "slv0", "slv", "brg",
+ "core", "apb";
+ status = "disabled";
+
+ pcie_intc1: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
};
};
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v5 4/7] dt-bindings: iio: accel: adxl345: Add spi-3wire
From: Krzysztof Kozlowski @ 2024-03-28 9:22 UTC (permalink / raw)
To: Lothar Rubusch, lars, Michael.Hennerich, jic23, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <20240327220320.15509-5-l.rubusch@gmail.com>
On 27/03/2024 23:03, Lothar Rubusch wrote:
> Add spi-3wire because the device allows to be configured for spi 3-wire
> communication.
>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
I don't understand why after my last message you still ignore my
feedback, but fine. I'll ignore this patchset.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/4] Add GPIO support for various PMICs
From: Linus Walleij @ 2024-03-28 9:25 UTC (permalink / raw)
To: Anjelique Melendez
Cc: andersson, konrad.dybcio, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-arm-msm, linux-gpio, devicetree, linux-kernel,
quic_subbaram, quic_collinsd, quic_jprakash
In-Reply-To: <20240326220628.2392802-1-quic_amelende@quicinc.com>
On Tue, Mar 26, 2024 at 11:07 PM Anjelique Melendez
<quic_amelende@quicinc.com> wrote:
> Add GPIO support for PMXR2230, PM6450, PMIH0108 and PMD8028
All patches applied for kernel v6.10!
Thanks!
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: hsi: hsi-client: convert to YAML
From: Krzysztof Kozlowski @ 2024-03-28 9:27 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel
In-Reply-To: <20240327-hsi-dt-binding-v2-1-110fab4c32ae@collabora.com>
On 27/03/2024 20:11, Sebastian Reichel wrote:
> Convert the legacy txt binding to modern YAML and rename from
> client-devices to hsi-client. Also the example got dropped,
> since this is a shared schema. No semantic change in the binding
> itself.
>
...
> +allOf:
> + - if:
> + required:
> + - hsi-mode
> + then:
> + properties:
> + hsi-rx-mode: false
> + hsi-tx-mode: false
> + - if:
> + required:
> + - hsi-rx-mode
> + then:
> + properties:
> + hsi-mode: false
Why do you still have this allOf? The point I was trying to make last
time, was that all your efforts to mutually exclude these properties can
be achieved with that one simple oneOf. That's why I linked you other
schemas as an example how to achieve this.
Could be that I miss here something, so why do you exactly need this allOf?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: hsi: nokia-modem: convert to YAML
From: Krzysztof Kozlowski @ 2024-03-28 9:28 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel
In-Reply-To: <20240327-hsi-dt-binding-v2-2-110fab4c32ae@collabora.com>
On 27/03/2024 20:11, Sebastian Reichel wrote:
> Convert the legacy txt binding to modern YAML.
> No semantic change.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> .../devicetree/bindings/hsi/nokia,modem.yaml | 106 +++++++++++++++++++++
> .../devicetree/bindings/hsi/nokia-modem.txt | 59 ------------
> 2 files changed, 106 insertions(+), 59 deletions(-)
>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: hsi: omap-ssi: convert to YAML
From: Krzysztof Kozlowski @ 2024-03-28 9:30 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel
In-Reply-To: <20240327-hsi-dt-binding-v2-3-110fab4c32ae@collabora.com>
On 27/03/2024 20:11, Sebastian Reichel wrote:
> Convert the legacy txt binding to modern YAML.
> There are a couple of semantic changes:
> - hsi-port@<addr> and ssi-port@<addr> node name
> changed to port@<addr>
> - ti,hwmods was marked as deprecated. This is supposed to go away
> once OMAP3 gets the same treatment as OMAP4.
> - changed ti,cawake-gpio to ti,cawake-gpios
> - describe peripheral requirements for the port node
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
...
> +
> + interrupt-names:
> + const: gdd_mpu
> +
> + ti,hwmods:
> + const: ssi
> + deprecated: true
> +
> +patternProperties:
> + "port@[0-9a-f]+":
Missing ^ and $.
> + type: object
> + additionalProperties: false
> +
> + properties:
> + compatible:
> + enum:
> + - ti,omap3-ssi-port
> + - ti,omap4-hsi-port
> +
> + reg:
> + items:
> + - description: TX registers
> + - description: RX registers
> +
> + reg-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + interrupts:
> + items:
> + - description: MPU interrupt 0
> + - description: MPU interrupt 1
> + minItems: 1
> +
> + ti,ssi-cawake-gpios:
> + description: GPIO signifying CAWAKE events
> + maxItems: 1
> +
> + patternProperties:
> + "^(modem|mcu)$":
> + type: object
additionalProperties: true
(I think I mentioned it last time)
> + $ref: /schemas/hsi/hsi-client.yaml#
> +
> + required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - ranges
> + - "#address-cells"
> + - "#size-cells"
> + - clocks
> + - clock-names
> + - interrupts
> + - interrupt-names
Rest looks good, thanks. With these two changes:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 4/7] ARM: dts: omap4: fix hsi-port node name
From: Krzysztof Kozlowski @ 2024-03-28 9:30 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel
In-Reply-To: <20240327-hsi-dt-binding-v2-4-110fab4c32ae@collabora.com>
On 27/03/2024 20:11, Sebastian Reichel wrote:
> The DT binding specifies, that the node names for the HSI ports should
> be just 'port@<address>' instead of 'hsi-port@<address>'.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 5/7] ARM: dts: omap3: fix ssi-port node name
From: Krzysztof Kozlowski @ 2024-03-28 9:30 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel
In-Reply-To: <20240327-hsi-dt-binding-v2-5-110fab4c32ae@collabora.com>
On 27/03/2024 20:11, Sebastian Reichel wrote:
> The DT binding specifies, that the node names for the SSI ports should
> be just 'port@<address>' instead of 'ssi-port@<address>'.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 6/7] ARM: dts: omap3: fix ti,ssi-cawake-gpio property name
From: Krzysztof Kozlowski @ 2024-03-28 9:30 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel
In-Reply-To: <20240327-hsi-dt-binding-v2-6-110fab4c32ae@collabora.com>
On 27/03/2024 20:11, Sebastian Reichel wrote:
> The SSI DT binding requires, that the canonical form "ti,ssi-cawake-gpios"
> is used instead of "ti,ssi-cawake-gpio".
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 7/7] ARM: dts: omap3: use generic node name for hsi clients
From: Krzysztof Kozlowski @ 2024-03-28 9:31 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel
In-Reply-To: <20240327-hsi-dt-binding-v2-7-110fab4c32ae@collabora.com>
On 27/03/2024 20:11, Sebastian Reichel wrote:
> The HSI peripheral node name should reflect the generic type of
> device for the node.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v16 02/22] PCI: microchip: Move pcie-microchip-host.c to plda directory
From: Minda Chen @ 2024-03-28 9:18 UTC (permalink / raw)
To: Lorenzo Pieralisi, Conor Dooley, Krzysztof Wilczyński,
Rob Herring, Bjorn Helgaas, Thomas Gleixner, Daire McNamara,
Emil Renner Berthing, Krzysztof Kozlowski
Cc: devicetree, linux-kernel, linux-riscv, linux-pci, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Philipp Zabel, Mason Huo, Leyfoon Tan,
Kevin Xie, Minda Chen
In-Reply-To: <20240328091835.14797-1-minda.chen@starfivetech.com>
Since Microchip Polarfire PCIe host is PLDA XpressRich IP, move to
PLDA directory. Prepare for refactoring the codes.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
---
MAINTAINERS | 4 ++--
drivers/pci/controller/Kconfig | 9 +--------
drivers/pci/controller/Makefile | 2 +-
drivers/pci/controller/plda/Kconfig | 14 ++++++++++++++
drivers/pci/controller/plda/Makefile | 2 ++
.../controller/{ => plda}/pcie-microchip-host.c | 2 +-
6 files changed, 21 insertions(+), 12 deletions(-)
create mode 100644 drivers/pci/controller/plda/Kconfig
create mode 100644 drivers/pci/controller/plda/Makefile
rename drivers/pci/controller/{ => plda}/pcie-microchip-host.c (99%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 06278f1db13f..dd158cc7b009 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17183,7 +17183,7 @@ M: Daire McNamara <daire.mcnamara@microchip.com>
L: linux-pci@vger.kernel.org
S: Supported
F: Documentation/devicetree/bindings/pci/microchip*
-F: drivers/pci/controller/*microchip*
+F: drivers/pci/controller/plda/*microchip*
PCIE DRIVER FOR QUALCOMM MSM
M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
@@ -18963,7 +18963,7 @@ F: drivers/clk/microchip/clk-mpfs*.c
F: drivers/firmware/microchip/mpfs-auto-update.c
F: drivers/i2c/busses/i2c-microchip-corei2c.c
F: drivers/mailbox/mailbox-mpfs.c
-F: drivers/pci/controller/pcie-microchip-host.c
+F: drivers/pci/controller/plda/pcie-microchip-host.c
F: drivers/pwm/pwm-microchip-core.c
F: drivers/reset/reset-mpfs.c
F: drivers/rtc/rtc-mpfs.c
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index e534c02ee34f..4d2c188f5835 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -215,14 +215,6 @@ config PCIE_MT7621
help
This selects a driver for the MediaTek MT7621 PCIe Controller.
-config PCIE_MICROCHIP_HOST
- tristate "Microchip AXI PCIe controller"
- depends on PCI_MSI && OF
- select PCI_HOST_COMMON
- help
- Say Y here if you want kernel to support the Microchip AXI PCIe
- Host Bridge driver.
-
config PCI_HYPERV_INTERFACE
tristate "Microsoft Hyper-V PCI Interface"
depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI
@@ -356,4 +348,5 @@ config PCIE_XILINX_CPM
source "drivers/pci/controller/cadence/Kconfig"
source "drivers/pci/controller/dwc/Kconfig"
source "drivers/pci/controller/mobiveil/Kconfig"
+source "drivers/pci/controller/plda/Kconfig"
endmenu
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index f2b19e6174af..038ccbd9e3ba 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -33,7 +33,6 @@ obj-$(CONFIG_PCIE_ROCKCHIP_EP) += pcie-rockchip-ep.o
obj-$(CONFIG_PCIE_ROCKCHIP_HOST) += pcie-rockchip-host.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_MEDIATEK_GEN3) += pcie-mediatek-gen3.o
-obj-$(CONFIG_PCIE_MICROCHIP_HOST) += pcie-microchip-host.o
obj-$(CONFIG_VMD) += vmd.o
obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
obj-$(CONFIG_PCI_LOONGSON) += pci-loongson.o
@@ -44,6 +43,7 @@ obj-$(CONFIG_PCIE_MT7621) += pcie-mt7621.o
# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
obj-y += dwc/
obj-y += mobiveil/
+obj-y += plda/
# The following drivers are for devices that use the generic ACPI
diff --git a/drivers/pci/controller/plda/Kconfig b/drivers/pci/controller/plda/Kconfig
new file mode 100644
index 000000000000..5cb3be4fc98c
--- /dev/null
+++ b/drivers/pci/controller/plda/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0
+
+menu "PLDA-based PCIe controllers"
+ depends on PCI
+
+config PCIE_MICROCHIP_HOST
+ tristate "Microchip AXI PCIe controller"
+ depends on PCI_MSI && OF
+ select PCI_HOST_COMMON
+ help
+ Say Y here if you want kernel to support the Microchip AXI PCIe
+ Host Bridge driver.
+
+endmenu
diff --git a/drivers/pci/controller/plda/Makefile b/drivers/pci/controller/plda/Makefile
new file mode 100644
index 000000000000..e1a265cbf91c
--- /dev/null
+++ b/drivers/pci/controller/plda/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PCIE_MICROCHIP_HOST) += pcie-microchip-host.o
diff --git a/drivers/pci/controller/pcie-microchip-host.c b/drivers/pci/controller/plda/pcie-microchip-host.c
similarity index 99%
rename from drivers/pci/controller/pcie-microchip-host.c
rename to drivers/pci/controller/plda/pcie-microchip-host.c
index 137fb8570ba2..cb09a8137e25 100644
--- a/drivers/pci/controller/pcie-microchip-host.c
+++ b/drivers/pci/controller/plda/pcie-microchip-host.c
@@ -18,7 +18,7 @@
#include <linux/pci-ecam.h>
#include <linux/platform_device.h>
-#include "../pci.h"
+#include "../../pci.h"
/* Number of MSI IRQs */
#define MC_MAX_NUM_MSI_IRQS 32
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards
From: Josua Mayer @ 2024-03-28 9:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <539eaf79-cff5-4bb7-84c8-7c9943c6d8ae@linaro.org>
Hi Krzysztof,
Thank you for all the comments so far!
Am 28.03.24 um 10:14 schrieb Krzysztof Kozlowski:
> On 27/03/2024 11:55, Josua Mayer wrote:
>
>>> I don't even understand what is your case.
>> I see :(
>> Yes there is a disconnect *somewhere*.
>>
> Your way of quoting, including removing blank lines, weird wrapping,
> does not make it easy to answer anything here. Use decent email client
> which solves all these problems.
>
>> I shall try again:
>> Marvell is selling two chips:
>> 1. CN9130, High-Performance Multi-Core CPU, System on Chip
>> (can be used alone)
> So this is the main SoC?
Correct.
>
>> 2. 88F8215, SouthBridge Communication Processor, System on Chip
>> (only usable in combination with a CN9130)
>>
>> Now, in terms of compatible string, what happens when a board
>> has multiples of these?
> Multiple of CN9130? 2x CN9130?
this specifically is an academic question,
the main point is multiple southbridges to one CN9130.
> Nothing happens, does not really matter.
> Anyway the compatible is just to uniquely identify the device for users,
> not represent some programming model, because there is no programming
> model of a board.
>
>>> What is 9131 and 9132?
>> I have no idea who came up with 9131 and 9132.
>> But explanation is given by Grzegorz Jaszczyk <jaz@semihalf.com>
>> when he submitted cn9131-db.dts (Marvell evaluation board):
>>
>> Extend the support of the CN9130 by adding an external CP115.
>> The last number indicates how many external CP115 are used.
> You use the compatibles in your patchset, so you should know, not me.I
> have zero knowledge, also actually almost zero interest, in learning
> your particular platform.
Fair enough.
> I tried to fixup some bindings and maintainers
> for Marvell: failed with not really helpful comments. Therefore I don't
> care anymore about Marvell.
>
> You <cut> should know what is this about and come
> with explanation to the community.
If I was to come up with something new, without looking at existing
Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
I would describe the hardware like this:
SolidRun "CN9131" SolidWAN board is comptible with:
- solidrun,cn9131-solidwan:
name of the carrier board, and name of the complete product
includes one southbridge chip, but I don't need to mention it?
- solidrun,cn9130-sr-som:
just the som, including 1x CN9130 SoC
- marvell,cn9130:
this is the SoC, internally combining AP+CP
AP *could* be mentioned, but I don't see a reason
> You<cut>r platform maintainers should know what is this about and come
> with explanation to the community.
Is there a way forward?
Would it be worth challenging the existing bindings by proposing (RFC)
specific changes in line with what I described above?
sincerely
Josua Mayer
^ permalink raw reply
* [PATCH v16 05/22] PCI: microchip: Rename two PCIe data structures
From: Minda Chen @ 2024-03-28 9:18 UTC (permalink / raw)
To: Lorenzo Pieralisi, Conor Dooley, Krzysztof Wilczyński,
Rob Herring, Bjorn Helgaas, Thomas Gleixner, Daire McNamara,
Emil Renner Berthing, Krzysztof Kozlowski
Cc: devicetree, linux-kernel, linux-riscv, linux-pci, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Philipp Zabel, Mason Huo, Leyfoon Tan,
Kevin Xie, Minda Chen
In-Reply-To: <20240328091835.14797-1-minda.chen@starfivetech.com>
Add PLDA PCIe related data structures by rename data structure name from
mc_* to plda_*.
axi_base_addr is stayed in struct mc_pcie since it's microchip its own
data.
The event interrupt code is still using struct mc_pcie because the event
interrupt code can not be re-used.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
---
.../pci/controller/plda/pcie-microchip-host.c | 96 ++++++++++---------
1 file changed, 53 insertions(+), 43 deletions(-)
diff --git a/drivers/pci/controller/plda/pcie-microchip-host.c b/drivers/pci/controller/plda/pcie-microchip-host.c
index c55ede80a6d0..df0736f688ce 100644
--- a/drivers/pci/controller/plda/pcie-microchip-host.c
+++ b/drivers/pci/controller/plda/pcie-microchip-host.c
@@ -22,7 +22,7 @@
#include "pcie-plda.h"
/* Number of MSI IRQs */
-#define MC_MAX_NUM_MSI_IRQS 32
+#define PLDA_MAX_NUM_MSI_IRQS 32
/* PCIe Bridge Phy and Controller Phy offsets */
#define MC_PCIE1_BRIDGE_ADDR 0x00008000u
@@ -179,25 +179,29 @@ struct event_map {
u32 event_bit;
};
-struct mc_msi {
+struct plda_msi {
struct mutex lock; /* Protect used bitmap */
struct irq_domain *msi_domain;
struct irq_domain *dev_domain;
u32 num_vectors;
u64 vector_phy;
- DECLARE_BITMAP(used, MC_MAX_NUM_MSI_IRQS);
+ DECLARE_BITMAP(used, PLDA_MAX_NUM_MSI_IRQS);
};
-struct mc_pcie {
- void __iomem *axi_base_addr;
+struct plda_pcie_rp {
struct device *dev;
struct irq_domain *intx_domain;
struct irq_domain *event_domain;
raw_spinlock_t lock;
- struct mc_msi msi;
+ struct plda_msi msi;
void __iomem *bridge_addr;
};
+struct mc_pcie {
+ struct plda_pcie_rp plda;
+ void __iomem *axi_base_addr;
+};
+
struct cause {
const char *sym;
const char *str;
@@ -313,7 +317,7 @@ static struct mc_pcie *port;
static void mc_pcie_enable_msi(struct mc_pcie *port, void __iomem *ecam)
{
- struct mc_msi *msi = &port->msi;
+ struct plda_msi *msi = &port->plda.msi;
u16 reg;
u8 queue_size;
@@ -336,10 +340,10 @@ static void mc_pcie_enable_msi(struct mc_pcie *port, void __iomem *ecam)
static void mc_handle_msi(struct irq_desc *desc)
{
- struct mc_pcie *port = irq_desc_get_handler_data(desc);
+ struct plda_pcie_rp *port = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
struct device *dev = port->dev;
- struct mc_msi *msi = &port->msi;
+ struct plda_msi *msi = &port->msi;
void __iomem *bridge_base_addr = port->bridge_addr;
unsigned long status;
u32 bit;
@@ -364,7 +368,7 @@ static void mc_handle_msi(struct irq_desc *desc)
static void mc_msi_bottom_irq_ack(struct irq_data *data)
{
- struct mc_pcie *port = irq_data_get_irq_chip_data(data);
+ struct plda_pcie_rp *port = irq_data_get_irq_chip_data(data);
void __iomem *bridge_base_addr = port->bridge_addr;
u32 bitpos = data->hwirq;
@@ -373,7 +377,7 @@ static void mc_msi_bottom_irq_ack(struct irq_data *data)
static void mc_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
{
- struct mc_pcie *port = irq_data_get_irq_chip_data(data);
+ struct plda_pcie_rp *port = irq_data_get_irq_chip_data(data);
phys_addr_t addr = port->msi.vector_phy;
msg->address_lo = lower_32_bits(addr);
@@ -400,8 +404,8 @@ static struct irq_chip mc_msi_bottom_irq_chip = {
static int mc_irq_msi_domain_alloc(struct irq_domain *domain, unsigned int virq,
unsigned int nr_irqs, void *args)
{
- struct mc_pcie *port = domain->host_data;
- struct mc_msi *msi = &port->msi;
+ struct plda_pcie_rp *port = domain->host_data;
+ struct plda_msi *msi = &port->msi;
unsigned long bit;
mutex_lock(&msi->lock);
@@ -425,8 +429,8 @@ static void mc_irq_msi_domain_free(struct irq_domain *domain, unsigned int virq,
unsigned int nr_irqs)
{
struct irq_data *d = irq_domain_get_irq_data(domain, virq);
- struct mc_pcie *port = irq_data_get_irq_chip_data(d);
- struct mc_msi *msi = &port->msi;
+ struct plda_pcie_rp *port = irq_data_get_irq_chip_data(d);
+ struct plda_msi *msi = &port->msi;
mutex_lock(&msi->lock);
@@ -456,11 +460,11 @@ static struct msi_domain_info mc_msi_domain_info = {
.chip = &mc_msi_irq_chip,
};
-static int mc_allocate_msi_domains(struct mc_pcie *port)
+static int mc_allocate_msi_domains(struct plda_pcie_rp *port)
{
struct device *dev = port->dev;
struct fwnode_handle *fwnode = of_node_to_fwnode(dev->of_node);
- struct mc_msi *msi = &port->msi;
+ struct plda_msi *msi = &port->msi;
mutex_init(&port->msi.lock);
@@ -484,7 +488,7 @@ static int mc_allocate_msi_domains(struct mc_pcie *port)
static void mc_handle_intx(struct irq_desc *desc)
{
- struct mc_pcie *port = irq_desc_get_handler_data(desc);
+ struct plda_pcie_rp *port = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
struct device *dev = port->dev;
void __iomem *bridge_base_addr = port->bridge_addr;
@@ -511,7 +515,7 @@ static void mc_handle_intx(struct irq_desc *desc)
static void mc_ack_intx_irq(struct irq_data *data)
{
- struct mc_pcie *port = irq_data_get_irq_chip_data(data);
+ struct plda_pcie_rp *port = irq_data_get_irq_chip_data(data);
void __iomem *bridge_base_addr = port->bridge_addr;
u32 mask = BIT(data->hwirq + PM_MSI_INT_INTX_SHIFT);
@@ -520,7 +524,7 @@ static void mc_ack_intx_irq(struct irq_data *data)
static void mc_mask_intx_irq(struct irq_data *data)
{
- struct mc_pcie *port = irq_data_get_irq_chip_data(data);
+ struct plda_pcie_rp *port = irq_data_get_irq_chip_data(data);
void __iomem *bridge_base_addr = port->bridge_addr;
unsigned long flags;
u32 mask = BIT(data->hwirq + PM_MSI_INT_INTX_SHIFT);
@@ -535,7 +539,7 @@ static void mc_mask_intx_irq(struct irq_data *data)
static void mc_unmask_intx_irq(struct irq_data *data)
{
- struct mc_pcie *port = irq_data_get_irq_chip_data(data);
+ struct plda_pcie_rp *port = irq_data_get_irq_chip_data(data);
void __iomem *bridge_base_addr = port->bridge_addr;
unsigned long flags;
u32 mask = BIT(data->hwirq + PM_MSI_INT_INTX_SHIFT);
@@ -625,21 +629,22 @@ static u32 local_events(struct mc_pcie *port)
return val;
}
-static u32 get_events(struct mc_pcie *port)
+static u32 get_events(struct plda_pcie_rp *port)
{
+ struct mc_pcie *mc_port = container_of(port, struct mc_pcie, plda);
u32 events = 0;
- events |= pcie_events(port);
- events |= sec_errors(port);
- events |= ded_errors(port);
- events |= local_events(port);
+ events |= pcie_events(mc_port);
+ events |= sec_errors(mc_port);
+ events |= ded_errors(mc_port);
+ events |= local_events(mc_port);
return events;
}
static irqreturn_t mc_event_handler(int irq, void *dev_id)
{
- struct mc_pcie *port = dev_id;
+ struct plda_pcie_rp *port = dev_id;
struct device *dev = port->dev;
struct irq_data *data;
@@ -655,7 +660,7 @@ static irqreturn_t mc_event_handler(int irq, void *dev_id)
static void mc_handle_event(struct irq_desc *desc)
{
- struct mc_pcie *port = irq_desc_get_handler_data(desc);
+ struct plda_pcie_rp *port = irq_desc_get_handler_data(desc);
unsigned long events;
u32 bit;
struct irq_chip *chip = irq_desc_get_chip(desc);
@@ -672,12 +677,13 @@ static void mc_handle_event(struct irq_desc *desc)
static void mc_ack_event_irq(struct irq_data *data)
{
- struct mc_pcie *port = irq_data_get_irq_chip_data(data);
+ struct plda_pcie_rp *port = irq_data_get_irq_chip_data(data);
+ struct mc_pcie *mc_port = container_of(port, struct mc_pcie, plda);
u32 event = data->hwirq;
void __iomem *addr;
u32 mask;
- addr = port->axi_base_addr + event_descs[event].base +
+ addr = mc_port->axi_base_addr + event_descs[event].base +
event_descs[event].offset;
mask = event_descs[event].mask;
mask |= event_descs[event].enb_mask;
@@ -687,13 +693,14 @@ static void mc_ack_event_irq(struct irq_data *data)
static void mc_mask_event_irq(struct irq_data *data)
{
- struct mc_pcie *port = irq_data_get_irq_chip_data(data);
+ struct plda_pcie_rp *port = irq_data_get_irq_chip_data(data);
+ struct mc_pcie *mc_port = container_of(port, struct mc_pcie, plda);
u32 event = data->hwirq;
void __iomem *addr;
u32 mask;
u32 val;
- addr = port->axi_base_addr + event_descs[event].base +
+ addr = mc_port->axi_base_addr + event_descs[event].base +
event_descs[event].mask_offset;
mask = event_descs[event].mask;
if (event_descs[event].enb_mask) {
@@ -717,13 +724,14 @@ static void mc_mask_event_irq(struct irq_data *data)
static void mc_unmask_event_irq(struct irq_data *data)
{
- struct mc_pcie *port = irq_data_get_irq_chip_data(data);
+ struct plda_pcie_rp *port = irq_data_get_irq_chip_data(data);
+ struct mc_pcie *mc_port = container_of(port, struct mc_pcie, plda);
u32 event = data->hwirq;
void __iomem *addr;
u32 mask;
u32 val;
- addr = port->axi_base_addr + event_descs[event].base +
+ addr = mc_port->axi_base_addr + event_descs[event].base +
event_descs[event].mask_offset;
mask = event_descs[event].mask;
@@ -811,7 +819,7 @@ static int mc_pcie_init_clks(struct device *dev)
return 0;
}
-static int mc_pcie_init_irq_domains(struct mc_pcie *port)
+static int mc_pcie_init_irq_domains(struct plda_pcie_rp *port)
{
struct device *dev = port->dev;
struct device_node *node = dev->of_node;
@@ -889,7 +897,7 @@ static void mc_pcie_setup_window(void __iomem *bridge_base_addr, u32 index,
}
static int mc_pcie_setup_windows(struct platform_device *pdev,
- struct mc_pcie *port)
+ struct plda_pcie_rp *port)
{
void __iomem *bridge_base_addr = port->bridge_addr;
struct pci_host_bridge *bridge = platform_get_drvdata(pdev);
@@ -970,7 +978,7 @@ static void mc_disable_interrupts(struct mc_pcie *port)
writel_relaxed(GENMASK(31, 0), bridge_base_addr + ISTATUS_HOST);
}
-static int mc_init_interrupts(struct platform_device *pdev, struct mc_pcie *port)
+static int mc_init_interrupts(struct platform_device *pdev, struct plda_pcie_rp *port)
{
struct device *dev = &pdev->dev;
int irq;
@@ -1043,12 +1051,12 @@ static int mc_platform_init(struct pci_config_window *cfg)
mc_pcie_enable_msi(port, cfg->win);
/* Configure non-config space outbound ranges */
- ret = mc_pcie_setup_windows(pdev, port);
+ ret = mc_pcie_setup_windows(pdev, &port->plda);
if (ret)
return ret;
/* Address translation is up; safe to enable interrupts */
- ret = mc_init_interrupts(pdev, port);
+ ret = mc_init_interrupts(pdev, &port->plda);
if (ret)
return ret;
@@ -1059,6 +1067,7 @@ static int mc_host_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
void __iomem *bridge_base_addr;
+ struct plda_pcie_rp *plda;
int ret;
u32 val;
@@ -1066,7 +1075,8 @@ static int mc_host_probe(struct platform_device *pdev)
if (!port)
return -ENOMEM;
- port->dev = dev;
+ plda = &port->plda;
+ plda->dev = dev;
port->axi_base_addr = devm_platform_ioremap_resource(pdev, 1);
if (IS_ERR(port->axi_base_addr))
@@ -1075,7 +1085,7 @@ static int mc_host_probe(struct platform_device *pdev)
mc_disable_interrupts(port);
bridge_base_addr = port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
- port->bridge_addr = bridge_base_addr;
+ plda->bridge_addr = bridge_base_addr;
/* Allow enabling MSI by disabling MSI-X */
val = readl(bridge_base_addr + PCIE_PCI_IRQ_DW0);
@@ -1087,10 +1097,10 @@ static int mc_host_probe(struct platform_device *pdev)
val &= NUM_MSI_MSGS_MASK;
val >>= NUM_MSI_MSGS_SHIFT;
- port->msi.num_vectors = 1 << val;
+ plda->msi.num_vectors = 1 << val;
/* Pick vector address from design */
- port->msi.vector_phy = readl_relaxed(bridge_base_addr + IMSI_ADDR);
+ plda->msi.vector_phy = readl_relaxed(bridge_base_addr + IMSI_ADDR);
ret = mc_pcie_init_clks(dev);
if (ret) {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/3] devicetree: phy: rockchip-emmc: Document changed strobe-pulldown property
From: Krzysztof Kozlowski @ 2024-03-28 9:37 UTC (permalink / raw)
To: dev, Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner,
Chris Ruehl, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Christopher Obbard, Alban Browaeys, Doug Anderson, Brian Norris,
Jensen Huang, linux-phy, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
In-Reply-To: <20240326-rk-default-enable-strobe-pulldown-v1-2-f410c71605c0@folker-schwesinger.de>
On 26/03/2024 19:54, Folker Schwesinger via B4 Relay wrote:
> From: Folker Schwesinger <dev@folker-schwesinger.de>
>
> Document the changes regarding the optional strobe-pulldown property.
> These changes are necessary as the default behavior of the driver was
> restored to the Rockchip kernel behavior of enabling the internal
> pulldown by default.
>
Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.
It's: dt-bindings: phy: rockchi.......
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: broadcom: bcmbca: bcm4908: set brcm,wp-not-connected
From: Rafał Miłecki @ 2024-03-28 9:37 UTC (permalink / raw)
To: Florian Fainelli
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, William Zhang,
Anand Gore, Kursad Oney, devicetree, linux-arm-kernel,
bcm-kernel-feedback-list, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
Every described BCM4908 board has WP pin not connected. This caused
problems for drivers since day 0 but there was no property to describe
that properly. Projects like OpenWrt were modifying Linux driver to deal
with it.
It's not clear if that is hardware limitation or just reference design
being copied over and over but this applies to all known / supported
BCM4908 boards. Handle it by marking WP as not connected by default.
Fixes: 2961f69f151c ("arm64: dts: broadcom: add BCM4908 and Asus GT-AC5300 early DTS files")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi | 1 +
arch/arm64/boot/dts/broadcom/bcmbca/bcm94908.dts | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi b/arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi
index e01cf4f54077..8b924812322c 100644
--- a/arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi
@@ -594,6 +594,7 @@ nand_controller: nand-controller@1800 {
reg-names = "nand", "nand-int-base";
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "nand_ctlrdy";
+ brcm,wp-not-connected;
status = "disabled";
nandcs: nand@0 {
diff --git a/arch/arm64/boot/dts/broadcom/bcmbca/bcm94908.dts b/arch/arm64/boot/dts/broadcom/bcmbca/bcm94908.dts
index 030ffa5364fb..e5b37643296b 100644
--- a/arch/arm64/boot/dts/broadcom/bcmbca/bcm94908.dts
+++ b/arch/arm64/boot/dts/broadcom/bcmbca/bcm94908.dts
@@ -34,7 +34,6 @@ &hsspi {
};
&nand_controller {
- brcm,wp-not-connected;
status = "okay";
};
--
2.35.3
^ permalink raw reply related
* Re: [PATCH v6 1/3] dt-bindings: mtd: Add Loongson-1 NAND Controller
From: Conor Dooley @ 2024-03-28 9:36 UTC (permalink / raw)
To: Keguang Zhang
Cc: Conor Dooley, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-mtd, linux-kernel, linux-mips, devicetree
In-Reply-To: <CAJhJPsX7Ds-UdFpTpLgFMW+rTGAgAYSKAieAMn12Z8RjNn-A8A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]
On Thu, Mar 28, 2024 at 04:54:59PM +0800, Keguang Zhang wrote:
> On Thu, Mar 28, 2024 at 12:23 AM Conor Dooley <conor@kernel.org> wrote:
> >
> > On Wed, Mar 27, 2024 at 06:43:59PM +0800, Keguang Zhang via B4 Relay wrote:
> > > From: Keguang Zhang <keguang.zhang@gmail.com>
> > >
> > > Add devicetree binding document for Loongson-1 NAND Controller.
> > >
> > > Signed-off-by: Keguang Zhang <keguang.zhang@gmail.com>
> > > ---
> > > Changes in v6:
> > > - A newly added patch
> > > ---
> > > .../devicetree/bindings/mtd/loongson,ls1x-nfc.yaml | 66 ++++++++++++++++++++++
> > > 1 file changed, 66 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/mtd/loongson,ls1x-nfc.yaml b/Documentation/devicetree/bindings/mtd/loongson,ls1x-nfc.yaml
> > > new file mode 100644
> > > index 000000000000..2494c7b3b506
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mtd/loongson,ls1x-nfc.yaml
> > > @@ -0,0 +1,66 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/mtd/loongson,ls1x-nfc.yaml#
> >
> > Please make the filename match the compatible.
> >
> Got it. I'll rename it to loongson,ls1-nfc.yaml and change the
> compatible as follows.
> compatible:
> items:
> - enum:
> - loongson,ls1a-nfc
> - loongson,ls1b-nfc
> - loongson,ls1c-nfc
> - const: loongson,ls1-nfc
No, please do not do this. Just call the file "ls1b-nfc".
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards
From: Krzysztof Kozlowski @ 2024-03-28 9:41 UTC (permalink / raw)
To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <5ea0feb4-4d7e-4a10-9254-b034e368e8ad@solid-run.com>
On 28/03/2024 10:33, Josua Mayer wrote:
>>
>>> 2. 88F8215, SouthBridge Communication Processor, System on Chip
>>> (only usable in combination with a CN9130)
>>>
>>> Now, in terms of compatible string, what happens when a board
>>> has multiples of these?
>> Multiple of CN9130? 2x CN9130?
> this specifically is an academic question,
> the main point is multiple southbridges to one CN9130.
I did not know to what you refer.
>>
>> You <cut> should know what is this about and come
>> with explanation to the community.
> If I was to come up with something new, without looking at existing
> Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> I would describe the hardware like this:
>
> SolidRun "CN9131" SolidWAN board is comptible with:
> - solidrun,cn9131-solidwan:
> name of the carrier board, and name of the complete product
> includes one southbridge chip, but I don't need to mention it?
> - solidrun,cn9130-sr-som:
> just the som, including 1x CN9130 SoC
> - marvell,cn9130:
> this is the SoC, internally combining AP+CP
> AP *could* be mentioned, but I don't see a reason
With an explanation in commit msg about not using other compatible
fallbacks, this looks good to me.
>
>> You<cut>r platform maintainers should know what is this about and come
>> with explanation to the community.
> Is there a way forward?
> Would it be worth challenging the existing bindings by proposing (RFC)
> specific changes in line with what I described above?
It all depends on "what" and "why" you want to do. I don't know.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/3] DisplayPort support for SM6350/SM7225
From: Luca Weiss @ 2024-03-28 9:42 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Sean Paul,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh,
Krishna Manikandan, Bjorn Andersson, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, Luca Weiss
Add the required changes to support DisplayPort (normally(?) available
via the USB-C connector) on the SM6350/SM7225 SoC.
This has been tested on a Fairphone 4 smartphone with additional changes
not included in this series (mostly just wiring up TCPM and the SBU
mux).
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Luca Weiss (3):
dt-bindings: display: msm: dp-controller: document SM8250 compatible
dt-bindings: display: msm: sm6350-mdss: document DP controller subnode
arm64: dts: qcom: sm6350: Add DisplayPort controller
.../bindings/display/msm/dp-controller.yaml | 1 +
.../bindings/display/msm/qcom,sm6350-mdss.yaml | 10 +++
arch/arm64/boot/dts/qcom/sm6350.dtsi | 88 ++++++++++++++++++++++
3 files changed, 99 insertions(+)
---
base-commit: 871760455183dc66b3e185f8d3ed2184cc9fac25
change-id: 20240328-sm6350-dp-41238153b448
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: display: msm: dp-controller: document SM8250 compatible
From: Luca Weiss @ 2024-03-28 9:42 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Sean Paul,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh,
Krishna Manikandan, Bjorn Andersson, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, Luca Weiss
In-Reply-To: <20240328-sm6350-dp-v1-0-215ca2b81c35@fairphone.com>
Add the compatible string for the DisplayPort controller on SM6350 which
is compatible with the one on SM8350.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index ae53cbfb2193..97993feda193 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -29,6 +29,7 @@ properties:
- qcom,sm8650-dp
- items:
- enum:
+ - qcom,sm6350-dp
- qcom,sm8150-dp
- qcom,sm8250-dp
- qcom,sm8450-dp
--
2.44.0
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: display: msm: sm6350-mdss: document DP controller subnode
From: Luca Weiss @ 2024-03-28 9:42 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Sean Paul,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh,
Krishna Manikandan, Bjorn Andersson, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, Luca Weiss
In-Reply-To: <20240328-sm6350-dp-v1-0-215ca2b81c35@fairphone.com>
Document the displayport controller subnode of the SM6350 MDSS.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
.../devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
index c9ba1fae8042..d91b8eca6aba 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
@@ -53,6 +53,16 @@ patternProperties:
compatible:
const: qcom,sm6350-dpu
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm6350-dp
+ - const: qcom,sm8350-dp
+
"^dsi@[0-9a-f]+$":
type: object
additionalProperties: true
--
2.44.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: qcom: sm6350: Add DisplayPort controller
From: Luca Weiss @ 2024-03-28 9:42 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Sean Paul,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh,
Krishna Manikandan, Bjorn Andersson, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, Luca Weiss
In-Reply-To: <20240328-sm6350-dp-v1-0-215ca2b81c35@fairphone.com>
Add the node for the DisplayPort controller found on the SM6350 SoC.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 88 ++++++++++++++++++++++++++++++++++++
1 file changed, 88 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index 24bcec3366ef..d7cf4b5ceea6 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -2033,6 +2033,14 @@ dpu_intf1_out: endpoint {
remote-endpoint = <&mdss_dsi0_in>;
};
};
+
+ port@2 {
+ reg = <2>;
+
+ dpu_intf0_out: endpoint {
+ remote-endpoint = <&mdss_dp_in>;
+ };
+ };
};
mdp_opp_table: opp-table {
@@ -2070,6 +2078,86 @@ opp-560000000 {
};
};
+ mdss_dp: displayport-controller@ae90000 {
+ compatible = "qcom,sm6350-dp", "qcom,sm8350-dp";
+ reg = <0 0xae90000 0 0x200>,
+ <0 0xae90200 0 0x200>,
+ <0 0xae90400 0 0x600>,
+ <0 0xae91000 0 0x400>,
+ <0 0xae91400 0 0x400>;
+ interrupt-parent = <&mdss>;
+ interrupts = <12>;
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_AUX_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_LINK_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+ assigned-clock-parents = <&usb_1_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+ <&usb_1_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+ phys = <&usb_1_qmpphy QMP_USB43DP_DP_PHY>;
+ phy-names = "dp";
+
+ #sound-dai-cells = <0>;
+
+ operating-points-v2 = <&dp_opp_table>;
+ power-domains = <&rpmhpd SM6350_CX>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dp_in: endpoint {
+ remote-endpoint = <&dpu_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dp_out: endpoint {
+ };
+ };
+ };
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
mdss_dsi0: dsi@ae94000 {
compatible = "qcom,sm6350-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0 0x0ae94000 0 0x400>;
--
2.44.0
^ permalink raw reply related
* Re: [PATCH 4/5] clk: qcom: Add camera clock controller driver for SM8150
From: Satya Priya Kakitapalli (Temp) @ 2024-03-28 9:42 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Bjorn Andersson, Konrad Dybcio,
Michael Turquette, Stephen Boyd, Abhishek Sahu, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Stephen Boyd, linux-arm-msm,
linux-clk, linux-kernel, devicetree, Ajit Pandey, Imran Shaik,
Taniya Das, Jagadeesh Kona
In-Reply-To: <CAA8EJpogCOQ4W26hkBm6v_yemZ2F30z2TsO5vLKLUqRKkfYxvg@mail.gmail.com>
On 3/8/2024 5:24 PM, Dmitry Baryshkov wrote:
> On Fri, 8 Mar 2024 at 12:47, Satya Priya Kakitapalli (Temp)
> <quic_skakitap@quicinc.com> wrote:
>>
>> On 3/6/2024 7:25 PM, Bryan O'Donoghue wrote:
>>> On 06/03/2024 08:30, Satya Priya Kakitapalli (Temp) wrote:
>>>>> Anyway I suspect the right thing to do is to define a
>>>>> titan_top_gdsc_clk with shared ops to "park" the GDSC clock to 19.2
>>>>> MHz instead of turning it off.
>>>>>
>>>>> You can get rid of the hard-coded always-on and indeed represent the
>>>>> clock in /sysfs - which is preferable IMO to just whacking registers
>>>>> to keep clocks always-on in probe anyway.
>>>>>
>>>>> Please try to define the titan_top_gdsc_clk as a shared_ops clock
>>>>> instead of hard coding to always on.
>>>>>
>>>> Defining the gdsc clk allows consumers to control it, we do not want
>>>> this clock to be disabled/controlled from consumers. Hence it is
>>>> better to not model this clock and just keep it always on from probe.
>>> Not if you mark it critical
>>>
>> Marking the clock as critical keeps the associated power domain
>> always-on which impacts power. For this reason we are not using
>> CLK_IS_CRITICAL and instead making them always on from probe.
> Please consider using pm_clk instead. This is a cleaner solution
> compared to keeping the clocks always on.
In this case i think we cannot use pm_clk because, the clock that we are
trying to keep always on here belongs to same camcc and it is not
possible to create a PM dependency with the same dev that is camcc itself.
>>> static struct clk_branch cam_cc_gdsc_clk = {
>>> .halt_reg = 0xc1e4,
>>> .halt_check = BRANCH_HALT,
>>> .clkr = {
>>> .enable_reg = 0xc1e4,
>>> .enable_mask = BIT(0),
>>> .hw.init = &(struct clk_init_data){
>>> .name = "cam_cc_gdsc_clk",
>>> .parent_hws = (const struct clk_hw*[]){
>>> &cam_cc_xo_clk_src.clkr.hw
>>> },
>>> .num_parents = 1,
>>> .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT,
>>> .ops = &clk_branch2_ops,
>>> },
>>> },
>>> };
>>>
>>> and then add this to your camss clocks
>>>
>>> <&clock_camcc CAM_CC_GDSC_CLK>;
>>>
>>> The practice we have of just whacking clocks always-on in the probe()
>>> of the clock driver feels lazy to me, leaving the broken cleanups we
>>> have aside.
>>>
>>> As a user of the system I'd rather see correct/complete data in
>>> /sys/kernel/debug/clk/clk_summary
>>>
>>> Anyway I'm fine with setting the clock always on, I can always send
>>> out a series to address this bug-bear myself.
>>>
>>> So yeah just fix the cleanup and then please feel free to add my
>>>
>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
^ permalink raw reply
* Re: [PATCH v1] ARM: dts: stm32: Update button on stm32mp135f-dk
From: Patrice CHOTARD @ 2024-03-28 9:44 UTC (permalink / raw)
To: robh+dt, Krzysztof Kozlowski, alexandre.torgue
Cc: linux-stm32, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20240328080105.3910099-1-patrice.chotard@foss.st.com>
This patch must be dropped, i made a mistake.
Sorry
Patrice
On 3/28/24 09:01, patrice.chotard@foss.st.com wrote:
> From: Patrice Chotard <patrice.chotard@foss.st.com>
>
> On schematics, 2 buttons are available on stm32mp135-dk board:
> _ button "user1" connected to GPIOA14
> _ button "user2" connected to GPIOA13
>
> Reflect that on device tree.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
> ---
> arch/arm/boot/dts/st/stm32mp135f-dk.dts | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/st/stm32mp135f-dk.dts b/arch/arm/boot/dts/st/stm32mp135f-dk.dts
> index 52171214a308..f7e03bc7eccb 100644
> --- a/arch/arm/boot/dts/st/stm32mp135f-dk.dts
> +++ b/arch/arm/boot/dts/st/stm32mp135f-dk.dts
> @@ -48,9 +48,15 @@ optee@dd000000 {
> gpio-keys {
> compatible = "gpio-keys";
>
> - button-user {
> - label = "User-PA13";
> + button-user-1 {
> + label = "User-1";
> linux,code = <BTN_1>;
> + gpios = <&gpioa 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> + };
> +
> + button-user-2 {
> + label = "User-2";
> + linux,code = <BTN_2>;
> gpios = <&gpioa 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> };
> };
^ permalink raw reply
* Re: [net-next,v4 0/2] ravb: Support describing the MDIO bus
From: Niklas Söderlund @ 2024-03-28 9:45 UTC (permalink / raw)
To: Sergey Shtylyov, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Claudiu Beznea, Yoshihiro Shimoda, Biju Das,
netdev, devicetree
Cc: linux-renesas-soc
In-Reply-To: <20240325153451.2366083-1-niklas.soderlund+renesas@ragnatech.se>
Hi netdev,
This series was marked as Deferred in patchwork. I just wonder why that
is? Patch 1/2 touches bindings so it could go thru the Renesas tree but
patch 2/2 touches the driver and depends on 1/2. Should not this whole
series go thru net-next?
I fear it might have been flagged as Deferred as v3 was posted on the
same day net-next closed and was therefore closed as Deferred.
On 2024-03-25 16:34:49 +0100, Niklas Söderlund wrote:
> Hello,
>
> This series adds support to the binding and driver of the Renesas
> Ethernet AVB to described the MDIO bus. Currently the driver uses the OF
> node of the device itself when registering the MDIO bus. This forces any
> MDIO bus properties the MDIO core should react on to be set on the
> device OF node. This is confusing and non of the MDIO bus properties are
> described in the Ethernet AVB bindings.
>
> Patch 1/2 extends the bindings with an optional mdio child-node to the
> device that can be used to contain the MDIO bus settings. While patch
> 2/2 changes the driver to use this node (if present) when registering
> the MDIO bus.
>
> If the new optional mdio child-node is not present the driver fallback
> to the old behavior and uses the device OF node like before. This change
> is fully backward compatible with existing usage of the bindings.
>
> For changelog see individual patches.
>
> Niklas Söderlund (2):
> dt-bindings: net: renesas,etheravb: Add optional MDIO bus node
> ravb: Add support for an optional MDIO mode
>
> .../devicetree/bindings/net/renesas,etheravb.yaml | 12 ++++++++++--
> drivers/net/ethernet/renesas/ravb_main.c | 9 ++++++++-
> 2 files changed, 18 insertions(+), 3 deletions(-)
>
> --
> 2.44.0
>
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards
From: Josua Mayer @ 2024-03-28 9:46 UTC (permalink / raw)
To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <68fd00b8-d6f1-463b-9d0d-b77bf9364f7f@linaro.org>
Am 28.03.24 um 10:41 schrieb Krzysztof Kozlowski:
> On 28/03/2024 10:33, Josua Mayer wrote:
>>>> 2. 88F8215, SouthBridge Communication Processor, System on Chip
>>>> (only usable in combination with a CN9130)
>>>>
>>>> Now, in terms of compatible string, what happens when a board
>>>> has multiples of these?
>>> Multiple of CN9130? 2x CN9130?
>> this specifically is an academic question,
>> the main point is multiple southbridges to one CN9130.
> I did not know to what you refer.
>
>>> You <cut> should know what is this about and come
>>> with explanation to the community.
>> If I was to come up with something new, without looking at existing
>> Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>> I would describe the hardware like this:
>>
>> SolidRun "CN9131" SolidWAN board is comptible with:
>> - solidrun,cn9131-solidwan:
>> name of the carrier board, and name of the complete product
>> includes one southbridge chip, but I don't need to mention it?
>> - solidrun,cn9130-sr-som:
>> just the som, including 1x CN9130 SoC
>> - marvell,cn9130:
>> this is the SoC, internally combining AP+CP
>> AP *could* be mentioned, but I don't see a reason
> With an explanation in commit msg about not using other compatible
> fallbacks, this looks good to me.
Great. So perhaps my next step will be a v2 with explanations.
>
>>> You<cut>r platform maintainers should know what is this about and come
>>> with explanation to the community.
>> Is there a way forward?
>> Would it be worth challenging the existing bindings by proposing (RFC)
>> specific changes in line with what I described above?
> It all depends on "what" and "why" you want to do. I don't know.
First priority is supporting the solidrun boards based on cn9130 soc,
which requires getting the bindings right (at least for these boards).
Changing the other bindings would only satisfy my desire for order,
but could get attention from other contributors to these platforms.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox