Re: [PATCH] dt-bindings: correct white-spaces in examples
On Fri, Nov 24, 2023 at 10:21:21AM +0100, Krzysztof Kozlowski wrote:
> Use only one and exactly one space around '=' in DTS example.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Merging idea: Rob's DT.
> Should apply cleanly on Rob's for-next.
> ---
> .../devicetree/bindings/auxdisplay/hit,hd44780.yaml | 2 +-
> .../devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml | 2 +-
> Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml | 6 +++---
> .../devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml | 2 +-
> .../devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml | 2 +-
> .../interrupt-controller/st,stih407-irq-syscfg.yaml | 4 ++--
> Documentation/devicetree/bindings/mmc/arm,pl18x.yaml | 2 +-
> Documentation/devicetree/bindings/net/sff,sfp.yaml| 2 +-
> .../devicetree/bindings/pci/toshiba,visconti-pcie.yaml| 2 +-
> .../bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 6 +++---
> .../devicetree/bindings/power/supply/richtek,rt9455.yaml | 8
> .../devicetree/bindings/regulator/mps,mp5416.yaml | 4 ++--
> .../devicetree/bindings/regulator/mps,mpq7920.yaml| 4 ++--
> .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 8
> 14 files changed, 27 insertions(+), 27 deletions(-)
>
[nip]
> diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> index 624984d51c10..7f8d98226437 100644
> --- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> +++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> @@ -125,7 +125,7 @@ examples:
> clk25m: clock-oscillator-25m {
>compatible = "fixed-clock";
>#clock-cells = <0>;
> - clock-frequency = <2500>;
> + clock-frequency = <2500>;
>clock-output-names = "clk25m";
> };
> ...
For Baikal-T1 CCU PLL DT-schema
Acked-by: Serge Semin
-Serge(y)
[PATCH RESEND v8 0/7] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
st of Ccecipients. Link: https://lore.kernel.org/linux-usb/20210210172850.20849-1-sergey.se...@baikalelectronics.ru Link: https://lore.kernel.org/linux-usb/20210212205521.14280-1-sergey.se...@baikalelectronics.ru Changelog v7: - Replace "of_get_child_by_name(np, "usb") ?: of_get_child_by_name(np, "dwc3");" pattern with using of_get_compatible_child() method in the Qcom DWC3 driver. - Drop the patches: [PATCH v6 01/10] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name [PATCH v6 02/10] arm: dts: keystone: Correct DWC USB3 compatible string [PATCH v6 06/10] arm: dts: keystone: Harmonize DWC USB3 DT nodes name since they have been applied to the corresponding maintainers repos. - Cleanup the list of recipients. - Rebase onto kernel 5.12-rc4. Link: https://lore.kernel.org/lkml/20210324204836.29668-1-sergey.se...@baikalelectronics.ru/ Changelog v8: - Just resend. Cc: Khuong Dinh Cc: Patrice Chotard Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linux-arm-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-snps-...@lists.infradead.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Serge Semin (7): arc: dts: Harmonize EHCI/OHCI DT nodes name arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name arm64: dts: apm: Harmonize DWC USB3 DT nodes name usb: dwc3: qcom: Detect DWC3 DT-nodes using compatible string arm64: dts: qcom: Harmonize DWC USB3 DT nodes name arch/arc/boot/dts/axc003.dtsi| 4 ++-- arch/arc/boot/dts/axc003_idu.dtsi| 4 ++-- arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++-- arch/arc/boot/dts/hsdk.dts | 4 ++-- arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +- arch/arm/boot/dts/lpc18xx.dtsi | 4 ++-- arch/arm/boot/dts/stih407-family.dtsi| 2 +- arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++-- arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++--- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++-- arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++-- arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +- arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +- arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +- arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +- arch/powerpc/boot/dts/akebono.dts| 6 +++--- drivers/usb/dwc3/dwc3-qcom.c | 2 +- 20 files changed, 35 insertions(+), 35 deletions(-) -- 2.30.1
[PATCH RESEND v8 7/7] arm64: dts: qcom: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
Reviewed-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++--
arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++--
arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +-
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
9 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index defcbd15edf9..34e97da98270 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -1064,7 +1064,7 @@ {
status = "okay";
extcon = <_id>;
- dwc3@760 {
+ usb@760 {
extcon = <_id>;
dr_mode = "otg";
maximum-speed = "high-speed";
@@ -1075,7 +1075,7 @@ {
status = "okay";
extcon = <_id>;
- dwc3@6a0 {
+ usb@6a0 {
extcon = <_id>;
dr_mode = "otg";
};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index a32e5e79ab0b..7df4eb710aae 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -427,7 +427,7 @@ usb_0: usb@8af8800 {
resets = < GCC_USB0_BCR>;
status = "disabled";
- dwc_0: dwc3@8a0 {
+ dwc_0: usb@8a0 {
compatible = "snps,dwc3";
reg = <0x8a0 0xcd00>;
interrupts = ;
@@ -468,7 +468,7 @@ usb_1: usb@8cf8800 {
resets = < GCC_USB1_BCR>;
status = "disabled";
- dwc_1: dwc3@8c0 {
+ dwc_1: usb@8c0 {
compatible = "snps,dwc3";
reg = <0x8c0 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index ce430ba9c118..9eb31b3e6ee7 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -1772,7 +1772,7 @@ usb3: usb@6af8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
- dwc3@6a0 {
+ usb@6a0 {
compatible = "snps,dwc3";
reg = <0x06a0 0xcc00>;
interrupts = <0 131 IRQ_TYPE_LEVEL_HIGH>;
@@ -1983,7 +1983,7 @@ usb2: usb@76f8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
- dwc3@760 {
+ usb@760 {
compatible = "snps,dwc3";
reg = <0x0760 0xcc00>;
interrupts = <0 138 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 1f2e93aa6553..9141c5d09b59 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -1962,7 +1962,7 @@ usb3: usb@a8f8800 {
resets = < GCC_USB_30_BCR>;
- usb3_dwc3: dwc3@a80 {
+ usb3_dwc3: usb@a80 {
compatible = "snps,dwc3";
reg = <0x0a80 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index a80c578484ba..f8a55307b855 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -337,7 +337,7 @@ _phy_sec {
{
status = "okay";
- dwc3@758 {
+ usb@758 {
dr_mode = "host";
};
};
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
inde
[PATCH RESEND v8 5/7] arm64: dts: apm: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named despite of the warning comment about possible backward
compatibility issues.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++--
arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index a83c82c50e29..832dd85b00bd 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -597,8 +597,8 @@ serial0: serial@1060 {
interrupts = <0x0 0x4c 0x4>;
};
- /* Do not change dwusb name, coded for backward compatibility */
- usb0: dwusb@1900 {
+ /* Node-name might need to be coded as dwusb for backward
compatibility */
+ usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1900 0x0 0x10>;
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 0f37e77f5459..1520a945b7f9 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -923,8 +923,8 @@ sata3: sata@1a80 {
phy-names = "sata-phy";
};
- /* Do not change dwusb name, coded for backward compatibility */
- usb0: dwusb@1900 {
+ /* Node-name might need to be coded as dwusb for backward
compatibility */
+ usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1900 0x0 0x10>;
@@ -933,7 +933,7 @@ usb0: dwusb@1900 {
dr_mode = "host";
};
- usb1: dwusb@1980 {
+ usb1: usb@1980 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1980 0x0 0x10>;
--
2.30.1
[PATCH RESEND v8 6/7] usb: dwc3: qcom: Detect DWC3 DT-nodes using compatible string
In accordance with the USB HCD/DRD schema all the USB controllers are
supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the
existing DT-nodes will be renamed in a subsequent patch let's fix the DWC3
Qcom-specific code to detect the DWC3 sub-node just by checking its
compatible string to match the "snps,dwc3". The semantic of the code
won't change seeing all the DWC USB3 nodes are supposed to have the
compatible property with any of those strings set.
Signed-off-by: Serge Semin
---
Changelog v7:
- Replace "of_get_child_by_name(np, "usb") ?: of_get_child_by_name(np, "dwc3");"
pattern with using of_get_compatible_child() method.
- Discard Bjorn Andersson Reviewed-by tag since the patch content
has been changed.
---
drivers/usb/dwc3/dwc3-qcom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index fcaf04483ad0..617a1be88371 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -644,7 +644,7 @@ static int dwc3_qcom_of_register_core(struct
platform_device *pdev)
struct device *dev = >dev;
int ret;
- dwc3_np = of_get_child_by_name(np, "dwc3");
+ dwc3_np = of_get_compatible_child(np, "snps,dwc3");
if (!dwc3_np) {
dev_err(dev, "failed to find dwc3 core child\n");
return -ENODEV;
--
2.30.1
[PATCH RESEND v8 1/7] arc: dts: Harmonize EHCI/OHCI DT nodes name
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin
Acked-by: Alexey Brodkin
Acked-by: Krzysztof Kozlowski
---
arch/arc/boot/dts/axc003.dtsi| 4 ++--
arch/arc/boot/dts/axc003_idu.dtsi| 4 ++--
arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++--
arch/arc/boot/dts/hsdk.dts | 4 ++--
arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +-
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index cd1edcf4f95e..3434c8131ecd 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -103,11 +103,11 @@ ethernet@18000 {
dma-coherent;
};
- ehci@4 {
+ usb@4 {
dma-coherent;
};
- ohci@6 {
+ usb@6 {
dma-coherent;
};
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi
b/arch/arc/boot/dts/axc003_idu.dtsi
index 70779386ca79..67556f4b7057 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -110,11 +110,11 @@ ethernet@18000 {
dma-coherent;
};
- ehci@4 {
+ usb@4 {
dma-coherent;
};
- ohci@6 {
+ usb@6 {
dma-coherent;
};
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 99d3e7175bf7..b64435385304 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -87,13 +87,13 @@ gmac: ethernet@18000 {
mac-address = [00 00 00 00 00 00]; /* Filled in by
U-Boot */
};
- ehci@4 {
+ usb@4 {
compatible = "generic-ehci";
reg = < 0x4 0x100 >;
interrupts = < 8 >;
};
- ohci@6 {
+ usb@6 {
compatible = "generic-ohci";
reg = < 0x6 0x100 >;
interrupts = < 8 >;
diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
index dcaa44e408ac..fdd4f7f635d3 100644
--- a/arch/arc/boot/dts/hsdk.dts
+++ b/arch/arc/boot/dts/hsdk.dts
@@ -234,7 +234,7 @@ phy0: ethernet-phy@0 { /* Micrel KSZ9031 */
};
};
- ohci@6 {
+ usb@6 {
compatible = "snps,hsdk-v1.0-ohci", "generic-ohci";
reg = <0x6 0x100>;
interrupts = <15>;
@@ -242,7 +242,7 @@ ohci@6 {
dma-coherent;
};
- ehci@4 {
+ usb@4 {
compatible = "snps,hsdk-v1.0-ehci", "generic-ehci";
reg = <0x4 0x100>;
interrupts = <15>;
diff --git a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
index cbb179770293..90a412026e64 100644
--- a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
@@ -46,7 +46,7 @@ ethernet@18000 {
clock-names = "stmmaceth";
};
- ehci@4 {
+ usb@4 {
compatible = "generic-ehci";
reg = < 0x4 0x100 >;
interrupts = < 8 >;
--
2.30.1
[PATCH RESEND v8 2/7] arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin
Acked-by: Vladimir Zapolskiy
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/lpc18xx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 10b8249b8ab6..82ffd7b0ad8a 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -121,7 +121,7 @@ mmcsd: mmcsd@40004000 {
status = "disabled";
};
- usb0: ehci@40006100 {
+ usb0: usb@40006100 {
compatible = "nxp,lpc1850-ehci", "generic-ehci";
reg = <0x40006100 0x100>;
interrupts = <8>;
@@ -133,7 +133,7 @@ usb0: ehci@40006100 {
status = "disabled";
};
- usb1: ehci@40007100 {
+ usb1: usb@40007100 {
compatible = "nxp,lpc1850-ehci", "generic-ehci";
reg = <0x40007100 0x100>;
interrupts = <9>;
--
2.30.1
[PATCH RESEND v8 4/7] arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
Reviewed-by: Patrice Chotard
---
arch/arm/boot/dts/stih407-family.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index 23a1746f3baa..2352f76b5a69 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -681,7 +681,7 @@ st_dwc3: dwc3@8f94000 {
status = "disabled";
- dwc3: dwc3@990 {
+ dwc3: usb@990 {
compatible = "snps,dwc3";
reg = <0x0990 0x10>;
interrupts = ;
--
2.30.1
[PATCH RESEND v8 3/7] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
---
arch/powerpc/boot/dts/akebono.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/akebono.dts
b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@301 {
interrupts = <93 2>;
};
- EHCI0: ehci@3001000 {
+ EHCI0: usb@3001000 {
compatible = "ibm,476gtr-ehci", "generic-ehci";
reg = <0x300 0x1000 0x0 0x1>;
interrupt-parent = <>;
@@ -140,14 +140,14 @@ SD0: sd@300 {
interrupt-parent = <>;
};
- OHCI0: ohci@3001001 {
+ OHCI0: usb@3001001 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1001 0x0 0x1>;
interrupt-parent = <>;
interrupts = <89 1>;
};
- OHCI1: ohci@3001002 {
+ OHCI1: usb@3001002 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1002 0x0 0x1>;
interrupt-parent = <>;
--
2.30.1
Re: [PATCH v2 01/13] gpio: Add Elba SoC gpio driver for spi cs control
On Sun, Mar 28, 2021 at 06:59:26PM -0700, Brad Larson wrote:
> This GPIO driver is for the Pensando Elba SoC which
> provides control of four chip selects on two SPI busses.
>
> Signed-off-by: Brad Larson
> ---
> drivers/gpio/Kconfig | 6 ++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-elba-spics.c | 114 +
> 3 files changed, 121 insertions(+)
> create mode 100644 drivers/gpio/gpio-elba-spics.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index e3607ec4c2e8..4720459b24f5 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -241,6 +241,12 @@ config GPIO_EIC_SPRD
> help
> Say yes here to support Spreadtrum EIC device.
>
> +config GPIO_ELBA_SPICS
> + bool "Pensando Elba SPI chip-select"
> + depends on (ARCH_PENSANDO_ELBA_SOC || COMPILE_TEST)
> + help
> + Say yes here to support the Penasndo Elba SoC SPI chip-select driver
> +
> config GPIO_EM
> tristate "Emma Mobile GPIO"
> depends on (ARCH_EMEV2 || COMPILE_TEST) && OF_GPIO
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index c58a90a3c3b1..c5c7acad371b 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
> obj-$(CONFIG_GPIO_DLN2) += gpio-dln2.o
> obj-$(CONFIG_GPIO_DWAPB) += gpio-dwapb.o
> obj-$(CONFIG_GPIO_EIC_SPRD) += gpio-eic-sprd.o
> +obj-$(CONFIG_GPIO_ELBA_SPICS)+= gpio-elba-spics.o
> obj-$(CONFIG_GPIO_EM)+= gpio-em.o
> obj-$(CONFIG_GPIO_EP93XX)+= gpio-ep93xx.o
> obj-$(CONFIG_GPIO_EXAR) += gpio-exar.o
> diff --git a/drivers/gpio/gpio-elba-spics.c b/drivers/gpio/gpio-elba-spics.c
> new file mode 100644
> index ..351bbaeea033
> --- /dev/null
> +++ b/drivers/gpio/gpio-elba-spics.c
> @@ -0,0 +1,114 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Pensando Elba SoC SPI chip select driver
> + *
> + * Copyright (c) 2020-2021, Pensando Systems Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +//#include
> +#include
> +#include
> +#include
> +
> +/*
> + * pin: 32| 10
> + * bit: 7--6--5--4|---3--2--1--0
> + * cs1 cs1_ovr cs0 cs0_ovr | cs1 cs1_ovr cs0 cs0_ovr
> + * ssi1| ssi0
> + */
> +#define SPICS_PIN_SHIFT(pin) (2 * (pin))
> +#define SPICS_MASK(pin) (0x3 << SPICS_PIN_SHIFT(pin))
> +#define SPICS_SET(pin, val) val) << 1) | 0x1) << SPICS_PIN_SHIFT(pin))
> +
> +struct elba_spics_priv {
> + void __iomem *base;
> + spinlock_t lock;
> + struct gpio_chip chip;
> +};
> +
> +static int elba_spics_get_value(struct gpio_chip *chip, unsigned int pin)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static void elba_spics_set_value(struct gpio_chip *chip,
> + unsigned int pin, int value)
> +{
> + struct elba_spics_priv *p = gpiochip_get_data(chip);
> + unsigned long flags;
> + u32 tmp;
> +
> + /* select chip select from register */
> + spin_lock_irqsave(>lock, flags);
> + tmp = readl_relaxed(p->base);
> + tmp = (tmp & ~SPICS_MASK(pin)) | SPICS_SET(pin, value);
> + writel_relaxed(tmp, p->base);
> + spin_unlock_irqrestore(>lock, flags);
> +}
> +
> +static int elba_spics_direction_input(struct gpio_chip *chip, unsigned int
> pin)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static int elba_spics_direction_output(struct gpio_chip *chip,
> + unsigned int pin, int value)
> +{
> + elba_spics_set_value(chip, pin, value);
> + return 0;
> +}
> +
> +static int elba_spics_probe(struct platform_device *pdev)
> +{
> + struct elba_spics_priv *p;
> + struct resource *res;
> + int ret = 0;
> +
> + p = devm_kzalloc(>dev, sizeof(*p), GFP_KERNEL);
> + if (!p)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + p->base = devm_ioremap_resource(>dev, res);
In accordance with the DTS-node this is just a single register
0x307c2468-0x307c24C picked from some bigger block, which most likely
belongs to something like a system controller. PCIe node has got
another register from there "0x307c2480-0x307c2484/* MS CFG_WDT */",
and some BSM device too "0x307c2080-0x307c2084". Please consider using
syscon instead of directly requesting the resource here.
-Sergey
> + if (IS_ERR(p->base))
> + return PTR_ERR(p->base);
> + spin_lock_init(>lock);
> + platform_set_drvdata(pdev, p);
> +
> + p->chip.ngpio = 4; /* 2 cs pins for spi0, and 2 for spi1 */
> + p->chip.base = -1;
> + p->chip.direction_input = elba_spics_direction_input;
> + p->chip.direction_output = elba_spics_direction_output;
> + p->chip.get = elba_spics_get_value;
> + p->chip.set =
Re: [PATCH v2 03/13] spi: dw: Add support for Pensando Elba SoC SPI
On Sun, Mar 28, 2021 at 06:59:28PM -0700, Brad Larson wrote:
> The Pensando Elba SoC uses a GPIO based chip select
> for two DW SPI busses with each bus having two
> chip selects.
>
> Signed-off-by: Brad Larson
> ---
> drivers/spi/spi-dw-mmio.c | 28 +++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
> index 17c06039a74d..c323a5ceecb8 100644
> --- a/drivers/spi/spi-dw-mmio.c
> +++ b/drivers/spi/spi-dw-mmio.c
> @@ -56,7 +56,7 @@ struct dw_spi_mscc {
> /*
> * The Designware SPI controller (referred to as master in the documentation)
> * automatically deasserts chip select when the tx fifo is empty. The chip
> - * selects then needs to be either driven as GPIOs or, for the first 4 using
> the
> + * selects then needs to be either driven as GPIOs or, for the first 4 using
> * the SPI boot controller registers. the final chip select is an OR gate
> * between the Designware SPI controller and the SPI boot controller.
> */
> @@ -237,6 +237,31 @@ static int dw_spi_canaan_k210_init(struct
> platform_device *pdev,
> return 0;
> }
>
> +static void dw_spi_elba_set_cs(struct spi_device *spi, bool enable)
> +{
> + struct dw_spi *dws = spi_master_get_devdata(spi->master);
> +
> + if (!enable) {
Please, be more attentive to the review-comments given to you before
resending a new patchset. One more time. This version of set_cs won't
work for Active-high CS. Each SPI controller working with GPIO-based
chip-select is marked as supporting that feature. So your DW
SPI controller won't be able to work correctly with SPI-devices
activated by active-high chip-select signal. Note default
dw_spi_set_cs() callback supports that.
-Sergey
> + /*
> + * Using a GPIO-based chip-select, the DW SPI
> + * controller still needs its own CS bit selected
> + * to start the serial engine. On Elba the specific
> + * CS doesn't matter to start the serial engine,
> + * so using CS0.
> + */
> + dw_writel(dws, DW_SPI_SER, BIT(0));
> + } else {
> + dw_writel(dws, DW_SPI_SER, 0);
> + }
> +}
> +
> +static int dw_spi_elba_init(struct platform_device *pdev,
> + struct dw_spi_mmio *dwsmmio)
> +{
> + dwsmmio->dws.set_cs = dw_spi_elba_set_cs;
> + return 0;
> +}
> +
> static int dw_spi_mmio_probe(struct platform_device *pdev)
> {
> int (*init_func)(struct platform_device *pdev,
> @@ -351,6 +376,7 @@ static const struct of_device_id dw_spi_mmio_of_match[] =
> {
> { .compatible = "intel,keembay-ssi", .data = dw_spi_keembay_init},
> { .compatible = "microchip,sparx5-spi", dw_spi_mscc_sparx5_init},
> { .compatible = "canaan,k210-spi", dw_spi_canaan_k210_init},
> + { .compatible = "pensando,elba-spi", .data = dw_spi_elba_init},
> { /* end of table */}
> };
> MODULE_DEVICE_TABLE(of, dw_spi_mmio_of_match);
> --
> 2.17.1
>
Re: [PATCH v2 07/13] arm64: dts: Add Pensando Elba SoC support
Rob,
Could you give your opinion on my comment regarding the nodes
layout in this dts-file. I was told to fix a similar problem in one of
patches submitted by me some time ago. Please see my last comment in
this message.
On Sun, Mar 28, 2021 at 06:59:32PM -0700, Brad Larson wrote:
> Add Pensando common and Elba SoC specific device nodes
>
> Signed-off-by: Brad Larson
> ---
> arch/arm64/boot/dts/Makefile | 1 +
> arch/arm64/boot/dts/pensando/Makefile | 6 +
> arch/arm64/boot/dts/pensando/elba-16core.dtsi | 170 ++
> .../boot/dts/pensando/elba-asic-common.dtsi | 112 +++
> arch/arm64/boot/dts/pensando/elba-asic.dts| 7 +
> .../boot/dts/pensando/elba-flash-parts.dtsi | 78 +
> arch/arm64/boot/dts/pensando/elba.dtsi| 310 ++
> 7 files changed, 684 insertions(+)
> create mode 100644 arch/arm64/boot/dts/pensando/Makefile
> create mode 100644 arch/arm64/boot/dts/pensando/elba-16core.dtsi
> create mode 100644 arch/arm64/boot/dts/pensando/elba-asic-common.dtsi
> create mode 100644 arch/arm64/boot/dts/pensando/elba-asic.dts
> create mode 100644 arch/arm64/boot/dts/pensando/elba-flash-parts.dtsi
> create mode 100644 arch/arm64/boot/dts/pensando/elba.dtsi
>
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index f1173cd93594..c85db0a097fe 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -19,6 +19,7 @@ subdir-y += marvell
> subdir-y += mediatek
> subdir-y += microchip
> subdir-y += nvidia
> +subdir-y += pensando
> subdir-y += qcom
> subdir-y += realtek
> subdir-y += renesas
> diff --git a/arch/arm64/boot/dts/pensando/Makefile
> b/arch/arm64/boot/dts/pensando/Makefile
> new file mode 100644
> index ..0c2c0961e64a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/pensando/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_ARCH_PENSANDO_ELBA_SOC) += elba-asic.dtb
> +
> +always-y := $(dtb-y)
> +subdir-y := $(dts-dirs)
> +clean-files := *.dtb
> diff --git a/arch/arm64/boot/dts/pensando/elba-16core.dtsi
> b/arch/arm64/boot/dts/pensando/elba-16core.dtsi
> new file mode 100644
> index ..a6c47899b69a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/pensando/elba-16core.dtsi
> @@ -0,0 +1,170 @@
> +
> +/ {
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 { cpu = <>; };
> + core1 { cpu = <>; };
> + core2 { cpu = <>; };
> + core3 { cpu = <>; };
> + };
> + cluster1 {
> + core0 { cpu = <>; };
> + core1 { cpu = <>; };
> + core2 { cpu = <>; };
> + core3 { cpu = <>; };
> + };
> + cluster2 {
> + core0 { cpu = <>; };
> + core1 { cpu = <>; };
> + core2 { cpu = <>; };
> + core3 { cpu = <>; };
> + };
> + cluster3 {
> + core0 { cpu = <>; };
> + core1 { cpu = <>; };
> + core2 { cpu = <>; };
> + core3 { cpu = <>; };
> + };
> + };
> +
> + // CLUSTER 0
What does chackpatch.pl tell you about C++ comment?
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0 0x0>;
> + enable-method = "spin-table";
> + next-level-cache = <_0>;
> + };
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0 0x1>;
> + enable-method = "spin-table";
> + next-level-cache = <_0>;
> + };
> + cpu2: cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0 0x2>;
> + enable-method = "spin-table";
> + next-level-cache = <_0>;
> + };
> + cpu3: cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0 0x3>;
> + enable-method = "spin-table";
> + next-level-cache = <_0>;
> + };
> +
> + l2_0: l2-cache0 {
> + compatible = "cache";
> + };
> +
> + //
Re: [PATCH v2 00/13] Support Pensando Elba SoC
Hi Brad On Sun, Mar 28, 2021 at 06:59:25PM -0700, Brad Larson wrote: > This series enables support for Pensando Elba SoC based platforms. > The Elba SoC has the following features: > > - Sixteen ARM64 A72 cores > - Dual DDR 4/5 memory controllers > - 32 lanes of PCIe Gen3/4 to the Host > - Network interfaces: Dual 200GE, Quad 100GE, 50GE, 25GE, 10GE and > also a single 1GE management port. > - Storage/crypto offloads and 144 programmable P4 cores. > - QSPI and EMMC for SoC storage > - Two SPI interfaces for peripheral management > - I2C bus for platform management > > See below for an overview of changes since v1. > > == Patch overview == > > - 01Fix typo, return code value and log message. > - 03Remove else clause, intrinsic DW chip-select is never used. > - 08-11 Split out dts and bindings to sub-patches > - 10Converted existing cadence-quadspi.txt to YAML schema > - 13New driver should use That would be super-useful if each changelog entry was also added to the individual patches below "---" splitter. -Sergey > > Brad Larson (13): > gpio: Add Elba SoC gpio driver for spi cs control > spi: cadence-quadspi: Add QSPI support for Pensando Elba SoC > spi: dw: Add support for Pensando Elba SoC SPI > spidev: Add Pensando CPLD compatible > mmc: sdhci-cadence: Add Pensando Elba SoC support > arm64: Add config for Pensando SoC platforms > arm64: dts: Add Pensando Elba SoC support > dt-bindings: Add pensando vendor prefix > dt-bindings: mmc: Add Pensando Elba SoC binding > dt-bindings: spi: cadence-qspi: Add support for Pensando Elba SoC > dt-bindings: gpio: Add Pensando Elba SoC support > MAINTAINERS: Add entry for PENSANDO > gpio: Use linux/gpio/driver.h > > .../bindings/gpio/pensando,elba-spics.yaml| 50 +++ > .../devicetree/bindings/mmc/cdns,sdhci.yaml | 1 + > .../bindings/spi/cadence-quadspi.txt | 68 > .../bindings/spi/cadence-quadspi.yaml | 153 + > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > MAINTAINERS | 9 + > arch/arm64/Kconfig.platforms | 5 + > arch/arm64/boot/dts/Makefile | 1 + > arch/arm64/boot/dts/pensando/Makefile | 6 + > arch/arm64/boot/dts/pensando/elba-16core.dtsi | 170 ++ > .../boot/dts/pensando/elba-asic-common.dtsi | 112 +++ > arch/arm64/boot/dts/pensando/elba-asic.dts| 7 + > .../boot/dts/pensando/elba-flash-parts.dtsi | 78 + > arch/arm64/boot/dts/pensando/elba.dtsi| 310 ++ > drivers/gpio/Kconfig | 6 + > drivers/gpio/Makefile | 1 + > drivers/gpio/gpio-elba-spics.c| 113 +++ > drivers/mmc/host/Kconfig | 15 + > drivers/mmc/host/Makefile | 1 + > drivers/mmc/host/sdhci-cadence-elba.c | 137 > drivers/mmc/host/sdhci-cadence.c | 81 +++-- > drivers/mmc/host/sdhci-cadence.h | 68 > drivers/spi/spi-cadence-quadspi.c | 9 + > drivers/spi/spi-dw-mmio.c | 28 +- > drivers/spi/spidev.c | 1 + > 25 files changed, 1321 insertions(+), 111 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/gpio/pensando,elba-spics.yaml > delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt > create mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.yaml > create mode 100644 arch/arm64/boot/dts/pensando/Makefile > create mode 100644 arch/arm64/boot/dts/pensando/elba-16core.dtsi > create mode 100644 arch/arm64/boot/dts/pensando/elba-asic-common.dtsi > create mode 100644 arch/arm64/boot/dts/pensando/elba-asic.dts > create mode 100644 arch/arm64/boot/dts/pensando/elba-flash-parts.dtsi > create mode 100644 arch/arm64/boot/dts/pensando/elba.dtsi > create mode 100644 drivers/gpio/gpio-elba-spics.c > create mode 100644 drivers/mmc/host/sdhci-cadence-elba.c > create mode 100644 drivers/mmc/host/sdhci-cadence.h > > -- > 2.17.1 >
Re: [PATCH v7 1/3] usb: dwc3: qcom: Add missing DWC3 OF node refcount decrement
On Fri, Mar 26, 2021 at 02:34:23PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Mar 24, 2021 at 03:18:58PM +0300, Serge Semin wrote:
> > Hi Greg,
> >
> > On Tue, Mar 23, 2021 at 12:29:17PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Feb 18, 2021 at 06:40:51PM +0300, Serge Semin wrote:
> > > > On Thu, Feb 18, 2021 at 04:32:29PM +0100, Greg Kroah-Hartman wrote:
> > > > > On Thu, Feb 18, 2021 at 06:29:04PM +0300, Serge Semin wrote:
> > > > > > Bjorn, Greg, Felippe, Andy,
> > > > > > Any comments on this series? Bjorn, Greg you asked me to resend the
> > > > > > patches related with the DW USB3 node name change. I did as you
> > > > > > said,
> > > > > > but no news since then. I'd be glad to have this patch accepted in
> > > > > > some -next repo and forget about it.
> > > > >
> > > >
> > > > > Sorry, but it's the merge window right now and I can't add anything
> > > > > new
> > > > > until 5.12-rc1 is out. So can you wait until then?
> > > >
> > > > Well, I don't think there is another choice but to wait now.)
> > > > Hopefully the patchset won't be forgotten when the merge window closes
> > > > as that happened with the original series...
> > >
> >
> > > Can you resend this if still needed? I don't see them in my queue...
> >
> > I see the very first patch of this series has already been merged in
> > somewhere between v5.12-rc3 and v5.12-rc2. See commit 1cffb1c66499 ("usb:
> > dwc3: qcom: Add missing DWC3 OF node refcount decrement"). But the rest of
> > the patches still hanging up unattended. I'll resend them in a few minutes.
> > Could you merge them in too?
>
> Do you have a lore.kernel.org link to your resend, I don't see it...
I've got the rest two patches back to the main series and resent it
two days ago:
https://lore.kernel.org/lkml/20210324204836.29668-1-sergey.se...@baikalelectronics.ru/
See the last two patches there.
They have been part of the main series from the very first time I
submitted it. But two months ago Bjorn asked me to detach Qcom-related
ones and resubmit to take into account his comment. Since then I
didn't hear any new update neither on these three patches nor on the
main series except you merging in the very first Qcom-related patch
(usb: dwc3: qcom: Add missing DWC3 OF node refcount decrement). Since
even being detached the patches left unattended I've decided to
combine them back to ease the re-submission process.
Note the patchset has been re-submitting for about five months
already with no comments for the last three versions.
-Sergey
>
> thanks,
>
> greg k-h
[PATCH v7 7/7] arm64: dts: qcom: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
Reviewed-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++--
arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++--
arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +-
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
9 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index defcbd15edf9..34e97da98270 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -1064,7 +1064,7 @@ {
status = "okay";
extcon = <_id>;
- dwc3@760 {
+ usb@760 {
extcon = <_id>;
dr_mode = "otg";
maximum-speed = "high-speed";
@@ -1075,7 +1075,7 @@ {
status = "okay";
extcon = <_id>;
- dwc3@6a0 {
+ usb@6a0 {
extcon = <_id>;
dr_mode = "otg";
};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index a32e5e79ab0b..7df4eb710aae 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -427,7 +427,7 @@ usb_0: usb@8af8800 {
resets = < GCC_USB0_BCR>;
status = "disabled";
- dwc_0: dwc3@8a0 {
+ dwc_0: usb@8a0 {
compatible = "snps,dwc3";
reg = <0x8a0 0xcd00>;
interrupts = ;
@@ -468,7 +468,7 @@ usb_1: usb@8cf8800 {
resets = < GCC_USB1_BCR>;
status = "disabled";
- dwc_1: dwc3@8c0 {
+ dwc_1: usb@8c0 {
compatible = "snps,dwc3";
reg = <0x8c0 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index ce430ba9c118..9eb31b3e6ee7 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -1772,7 +1772,7 @@ usb3: usb@6af8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
- dwc3@6a0 {
+ usb@6a0 {
compatible = "snps,dwc3";
reg = <0x06a0 0xcc00>;
interrupts = <0 131 IRQ_TYPE_LEVEL_HIGH>;
@@ -1983,7 +1983,7 @@ usb2: usb@76f8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
- dwc3@760 {
+ usb@760 {
compatible = "snps,dwc3";
reg = <0x0760 0xcc00>;
interrupts = <0 138 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 1f2e93aa6553..9141c5d09b59 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -1962,7 +1962,7 @@ usb3: usb@a8f8800 {
resets = < GCC_USB_30_BCR>;
- usb3_dwc3: dwc3@a80 {
+ usb3_dwc3: usb@a80 {
compatible = "snps,dwc3";
reg = <0x0a80 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index a80c578484ba..f8a55307b855 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -337,7 +337,7 @@ _phy_sec {
{
status = "okay";
- dwc3@758 {
+ usb@758 {
dr_mode = "host";
};
};
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
inde
[PATCH v7 3/7] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
---
arch/powerpc/boot/dts/akebono.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/akebono.dts
b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@301 {
interrupts = <93 2>;
};
- EHCI0: ehci@3001000 {
+ EHCI0: usb@3001000 {
compatible = "ibm,476gtr-ehci", "generic-ehci";
reg = <0x300 0x1000 0x0 0x1>;
interrupt-parent = <>;
@@ -140,14 +140,14 @@ SD0: sd@300 {
interrupt-parent = <>;
};
- OHCI0: ohci@3001001 {
+ OHCI0: usb@3001001 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1001 0x0 0x1>;
interrupt-parent = <>;
interrupts = <89 1>;
};
- OHCI1: ohci@3001002 {
+ OHCI1: usb@3001002 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1002 0x0 0x1>;
interrupt-parent = <>;
--
2.30.1
[PATCH v7 1/7] arc: dts: Harmonize EHCI/OHCI DT nodes name
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin
Acked-by: Alexey Brodkin
Acked-by: Krzysztof Kozlowski
---
arch/arc/boot/dts/axc003.dtsi| 4 ++--
arch/arc/boot/dts/axc003_idu.dtsi| 4 ++--
arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++--
arch/arc/boot/dts/hsdk.dts | 4 ++--
arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +-
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index cd1edcf4f95e..3434c8131ecd 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -103,11 +103,11 @@ ethernet@18000 {
dma-coherent;
};
- ehci@4 {
+ usb@4 {
dma-coherent;
};
- ohci@6 {
+ usb@6 {
dma-coherent;
};
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi
b/arch/arc/boot/dts/axc003_idu.dtsi
index 70779386ca79..67556f4b7057 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -110,11 +110,11 @@ ethernet@18000 {
dma-coherent;
};
- ehci@4 {
+ usb@4 {
dma-coherent;
};
- ohci@6 {
+ usb@6 {
dma-coherent;
};
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 99d3e7175bf7..b64435385304 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -87,13 +87,13 @@ gmac: ethernet@18000 {
mac-address = [00 00 00 00 00 00]; /* Filled in by
U-Boot */
};
- ehci@4 {
+ usb@4 {
compatible = "generic-ehci";
reg = < 0x4 0x100 >;
interrupts = < 8 >;
};
- ohci@6 {
+ usb@6 {
compatible = "generic-ohci";
reg = < 0x6 0x100 >;
interrupts = < 8 >;
diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
index dcaa44e408ac..fdd4f7f635d3 100644
--- a/arch/arc/boot/dts/hsdk.dts
+++ b/arch/arc/boot/dts/hsdk.dts
@@ -234,7 +234,7 @@ phy0: ethernet-phy@0 { /* Micrel KSZ9031 */
};
};
- ohci@6 {
+ usb@6 {
compatible = "snps,hsdk-v1.0-ohci", "generic-ohci";
reg = <0x6 0x100>;
interrupts = <15>;
@@ -242,7 +242,7 @@ ohci@6 {
dma-coherent;
};
- ehci@4 {
+ usb@4 {
compatible = "snps,hsdk-v1.0-ehci", "generic-ehci";
reg = <0x4 0x100>;
interrupts = <15>;
diff --git a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
index cbb179770293..90a412026e64 100644
--- a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
@@ -46,7 +46,7 @@ ethernet@18000 {
clock-names = "stmmaceth";
};
- ehci@4 {
+ usb@4 {
compatible = "generic-ehci";
reg = < 0x4 0x100 >;
interrupts = < 8 >;
--
2.30.1
[PATCH v7 6/7] usb: dwc3: qcom: Detect DWC3 DT-nodes using compatible string
In accordance with the USB HCD/DRD schema all the USB controllers are
supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the
existing DT-nodes will be renamed in a subsequent patch let's fix the DWC3
Qcom-specific code to detect the DWC3 sub-node just by checking its
compatible string to match the "snps,dwc3". The semantic of the code
won't change seeing all the DWC USB3 nodes are supposed to have the
compatible property with any of those strings set.
Signed-off-by: Serge Semin
---
Changelog v7:
- Replace "of_get_child_by_name(np, "usb") ?: of_get_child_by_name(np, "dwc3");"
pattern with using of_get_compatible_child() method.
- Discard Bjorn Andersson Reviewed-by tag since the patch content
has been changed.
---
drivers/usb/dwc3/dwc3-qcom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index fcaf04483ad0..617a1be88371 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -644,7 +644,7 @@ static int dwc3_qcom_of_register_core(struct
platform_device *pdev)
struct device *dev = >dev;
int ret;
- dwc3_np = of_get_child_by_name(np, "dwc3");
+ dwc3_np = of_get_compatible_child(np, "snps,dwc3");
if (!dwc3_np) {
dev_err(dev, "failed to find dwc3 core child\n");
return -ENODEV;
--
2.30.1
[PATCH v7 5/7] arm64: dts: apm: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named despite of the warning comment about possible backward
compatibility issues.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++--
arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index a83c82c50e29..832dd85b00bd 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -597,8 +597,8 @@ serial0: serial@1060 {
interrupts = <0x0 0x4c 0x4>;
};
- /* Do not change dwusb name, coded for backward compatibility */
- usb0: dwusb@1900 {
+ /* Node-name might need to be coded as dwusb for backward
compatibility */
+ usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1900 0x0 0x10>;
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 0f37e77f5459..1520a945b7f9 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -923,8 +923,8 @@ sata3: sata@1a80 {
phy-names = "sata-phy";
};
- /* Do not change dwusb name, coded for backward compatibility */
- usb0: dwusb@1900 {
+ /* Node-name might need to be coded as dwusb for backward
compatibility */
+ usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1900 0x0 0x10>;
@@ -933,7 +933,7 @@ usb0: dwusb@1900 {
dr_mode = "host";
};
- usb1: dwusb@1980 {
+ usb1: usb@1980 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1980 0x0 0x10>;
--
2.30.1
[PATCH v7 0/7] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
st of Ccecipients. Link: https://lore.kernel.org/linux-usb/20210210172850.20849-1-sergey.se...@baikalelectronics.ru Link: https://lore.kernel.org/linux-usb/20210212205521.14280-1-sergey.se...@baikalelectronics.ru Changelog v7: - Replace "of_get_child_by_name(np, "usb") ?: of_get_child_by_name(np, "dwc3");" pattern with using of_get_compatible_child() method in the Qcom DWC3 driver. - Drop the patches: [PATCH v6 01/10] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name [PATCH v6 02/10] arm: dts: keystone: Correct DWC USB3 compatible string [PATCH v6 06/10] arm: dts: keystone: Harmonize DWC USB3 DT nodes name since they have been applied to the corresponding maintainers repos. - Cleanup the list of recipients. - Rebase onto kernel 5.12-rc4. Cc: Khuong Dinh Cc: Patrice Chotard Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linux-arm-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-snps-...@lists.infradead.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Serge Semin (7): arc: dts: Harmonize EHCI/OHCI DT nodes name arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name arm64: dts: apm: Harmonize DWC USB3 DT nodes name usb: dwc3: qcom: Detect DWC3 DT-nodes using compatible string arm64: dts: qcom: Harmonize DWC USB3 DT nodes name arch/arc/boot/dts/axc003.dtsi| 4 ++-- arch/arc/boot/dts/axc003_idu.dtsi| 4 ++-- arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++-- arch/arc/boot/dts/hsdk.dts | 4 ++-- arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +- arch/arm/boot/dts/lpc18xx.dtsi | 4 ++-- arch/arm/boot/dts/stih407-family.dtsi| 2 +- arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++-- arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++--- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++-- arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++-- arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +- arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +- arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +- arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +- arch/powerpc/boot/dts/akebono.dts| 6 +++--- drivers/usb/dwc3/dwc3-qcom.c | 2 +- 20 files changed, 35 insertions(+), 35 deletions(-) -- 2.30.1
[PATCH v7 4/7] arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
Reviewed-by: Patrice Chotard
---
arch/arm/boot/dts/stih407-family.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index 23a1746f3baa..2352f76b5a69 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -681,7 +681,7 @@ st_dwc3: dwc3@8f94000 {
status = "disabled";
- dwc3: dwc3@990 {
+ dwc3: usb@990 {
compatible = "snps,dwc3";
reg = <0x0990 0x10>;
interrupts = ;
--
2.30.1
[PATCH v7 2/7] arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin
Acked-by: Vladimir Zapolskiy
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/lpc18xx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 10b8249b8ab6..82ffd7b0ad8a 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -121,7 +121,7 @@ mmcsd: mmcsd@40004000 {
status = "disabled";
};
- usb0: ehci@40006100 {
+ usb0: usb@40006100 {
compatible = "nxp,lpc1850-ehci", "generic-ehci";
reg = <0x40006100 0x100>;
interrupts = <8>;
@@ -133,7 +133,7 @@ usb0: ehci@40006100 {
status = "disabled";
};
- usb1: ehci@40007100 {
+ usb1: usb@40007100 {
compatible = "nxp,lpc1850-ehci", "generic-ehci";
reg = <0x40007100 0x100>;
interrupts = <9>;
--
2.30.1
Re: [PATCH v1 1/1] dmaengine: dw: Make it dependent to HAVE_IOMEM
Hi Andy
On Wed, Mar 24, 2021 at 02:18:22PM +0200, Andy Shevchenko wrote:
> Some architectures do not provide devm_*() APIs. Hence make the driver
> dependent on HAVE_IOMEM.
You must have meant "HAS_IOMEM", right?
-Sergey
>
> Fixes: dbde5c2934d1 ("dw_dmac: use devm_* functions to simplify code")
> Reported-by: kernel test robot
> Signed-off-by: Andy Shevchenko
> ---
> drivers/dma/dw/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/dma/dw/Kconfig b/drivers/dma/dw/Kconfig
> index e5162690de8f..dd4b56669d9f 100644
> --- a/drivers/dma/dw/Kconfig
> +++ b/drivers/dma/dw/Kconfig
> @@ -10,6 +10,7 @@ config DW_DMAC_CORE
>
> config DW_DMAC
> tristate "Synopsys DesignWare AHB DMA platform driver"
> + depends on HAVE_IOMEM
> select DW_DMAC_CORE
> help
> Support the Synopsys DesignWare AHB DMA controller. This
> @@ -18,6 +19,7 @@ config DW_DMAC
> config DW_DMAC_PCI
> tristate "Synopsys DesignWare AHB DMA PCI driver"
> depends on PCI
> + depends on HAVE_IOMEM
> select DW_DMAC_CORE
> help
> Support the Synopsys DesignWare AHB DMA controller on the
> --
> 2.30.2
>
Re: [PATCH v7 1/3] usb: dwc3: qcom: Add missing DWC3 OF node refcount decrement
Hi Greg,
On Tue, Mar 23, 2021 at 12:29:17PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Feb 18, 2021 at 06:40:51PM +0300, Serge Semin wrote:
> > On Thu, Feb 18, 2021 at 04:32:29PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Feb 18, 2021 at 06:29:04PM +0300, Serge Semin wrote:
> > > > Bjorn, Greg, Felippe, Andy,
> > > > Any comments on this series? Bjorn, Greg you asked me to resend the
> > > > patches related with the DW USB3 node name change. I did as you said,
> > > > but no news since then. I'd be glad to have this patch accepted in
> > > > some -next repo and forget about it.
> > >
> >
> > > Sorry, but it's the merge window right now and I can't add anything new
> > > until 5.12-rc1 is out. So can you wait until then?
> >
> > Well, I don't think there is another choice but to wait now.)
> > Hopefully the patchset won't be forgotten when the merge window closes
> > as that happened with the original series...
>
> Can you resend this if still needed? I don't see them in my queue...
I see the very first patch of this series has already been merged in
somewhere between v5.12-rc3 and v5.12-rc2. See commit 1cffb1c66499 ("usb:
dwc3: qcom: Add missing DWC3 OF node refcount decrement"). But the rest of
the patches still hanging up unattended. I'll resend them in a few minutes.
Could you merge them in too?
-Sergey
>
> thanks,
>
> greg k-h
Re: [PATCH v3] MIPS: kernel: Reserve exception base early to prevent corruption
Hi Thomas
On Mon, Mar 08, 2021 at 10:24:47AM +0100, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in FDT being corrupted.
>
> Before the cited commit, early allocations would be in the [kernel_end,
> RAM_END] range, but after commit they would be within [RAM_START +
> PAGE_SIZE, RAM_END].
>
> The custom exception base handler that is installed by
> bmips_ebase_setup() done for BMIPS5000 CPUs ends-up trampling on the
> memory region allocated by unflatten_and_copy_device_tree() thus
> corrupting the FDT used by the kernel.
>
> To fix this, we need to perform an early reservation of the custom
> exception space. Additional we reserve the first 4k (1k for R3k) for
> either normal exception vector space (legacy CPUs) or special vectors
> like cache exceptions.
>
> Huge thanks to Serge for analysing and proposing a solution to this
> issue.
Reviewed-by: Serge Semin
-Sergey
>
> Fixes: 2dcb39645441 ("memblock: do not start bottom-up allocations with
> kernel_end")
> Reported-by: Kamal Dasu
> Debugged-by: Serge Semin
> Signed-off-by: Thomas Bogendoerfer
> ---
> Changes in v3:
> - always reserve the first 4k for all CPUs (1k for R3k)
>
> Changes in v2:
> - do only memblock reservation in reserve_exception_space()
> - reserve 0..0x400 for all CPUs without ebase register and
>to addtional reserve_exception_space for BMIPS CPUs
>
> arch/mips/include/asm/traps.h| 3 +++
> arch/mips/kernel/cpu-probe.c | 6 ++
> arch/mips/kernel/cpu-r3k-probe.c | 3 +++
> arch/mips/kernel/traps.c | 10 +-
> 4 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/arch/mips/include/asm/traps.h b/arch/mips/include/asm/traps.h
> index 6aa8f126a43d..b710e76c9c65 100644
> --- a/arch/mips/include/asm/traps.h
> +++ b/arch/mips/include/asm/traps.h
> @@ -24,8 +24,11 @@ extern void (*board_ebase_setup)(void);
> extern void (*board_cache_error_setup)(void);
>
> extern int register_nmi_notifier(struct notifier_block *nb);
> +extern void reserve_exception_space(phys_addr_t addr, unsigned long size);
> extern char except_vec_nmi[];
>
> +#define VECTORSPACING 0x100 /* for EI/VI mode */
> +
> #define nmi_notifier(fn, pri)
> \
> ({ \
> static struct notifier_block fn##_nb = {\
> diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
> index 9a89637b4ecf..b71892064f27 100644
> --- a/arch/mips/kernel/cpu-probe.c
> +++ b/arch/mips/kernel/cpu-probe.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "fpu-probe.h"
> @@ -1628,6 +1629,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> c->cputype = CPU_BMIPS3300;
> __cpu_name[cpu] = "Broadcom BMIPS3300";
> set_elf_platform(cpu, "bmips3300");
> + reserve_exception_space(0x400, VECTORSPACING * 64);
> break;
> case PRID_IMP_BMIPS43XX: {
> int rev = c->processor_id & PRID_REV_MASK;
> @@ -1638,6 +1640,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> __cpu_name[cpu] = "Broadcom BMIPS4380";
> set_elf_platform(cpu, "bmips4380");
> c->options |= MIPS_CPU_RIXI;
> + reserve_exception_space(0x400, VECTORSPACING * 64);
> } else {
> c->cputype = CPU_BMIPS4350;
> __cpu_name[cpu] = "Broadcom BMIPS4350";
> @@ -1654,6 +1657,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> __cpu_name[cpu] = "Broadcom BMIPS5000";
> set_elf_platform(cpu, "bmips5000");
> c->options |= MIPS_CPU_ULRI | MIPS_CPU_RIXI;
> + reserve_exception_space(0x1000, VECTORSPACING * 64);
> break;
> }
> }
> @@ -2133,6 +2137,8 @@ void cpu_probe(void)
> if (cpu == 0)
> __ua_limit = ~((1ull << cpu_vmbits) - 1);
> #endif
> +
> + reserve_exception_space(0, 0x1000);
> }
>
> void cpu_report(void)
> diff --git a/arch/mips/kernel/cpu-r3k-probe.c
> b/arch/mips/kernel/cpu-r3k-probe.c
>
Re: [PATCH v2] MIPS: kernel: Reserve exception base early to prevent corruption
On Sun, Mar 07, 2021 at 10:20:01PM +0100, Thomas Bogendoerfer wrote:
> On Sun, Mar 07, 2021 at 11:06:12PM +0300, Serge Semin wrote:
> > > +
> > > + if (cpu_has_mips_r2_r6)
> > > + reserve_exception_space(0, 0x400);
> >
> > Are you sure it shouldn't be (!cpu_has_mips_r2_r6)?. What I see here
> > contradicts to what is said in Changelog v2.
>
> d'oh, of course it has to be !cpu_has_mips_r2_r6.
>
> > Anyway regarding the problem in general. AFAICS the next code uses the
> > lowest memory to place some specific exception handlers:
> > board_cache_error_setup pointer:
> > arch/mips/mm/c-r4k.c: r4k_cache_error_setup() - SiByte CPUs: CPU_SB1,
> > CPU_SB1A (up to 0x180)
> > arch/mips/mm/c-octeon.c: octeon_cache_error_setup() - Cavium CPU:
> > CPU_CAVIUM_OCTEON (up to 0x180)
> > board_nmi_handler_setup pointer:
> > arch/mips/kernel/smp-bmips.c: bmips_nmi_handler_setup() - Broadcom CPU:
> > CPU_BMIPS (up to 0x400)
> > arch/mips/loongson2ef/common/init.c: mips_nmi_setup() - Loongson 2E CPU:
> > MACH_LOONGSON2EF (up to 0x400)
> > arch/mips/loongson64/init.c: mips_nmi_setup() - Loongson 64 CPU:
> > MACH_LOONGSON64 (up to 0x400, VEIC:0xB00)
> > arch/mips/mti-malta/malta-init.c: mips_nmi_setup() - Malta CPU:
> > MIPS_MALTA (up to 0x400, VEIC: 0xB00)
> > arch/mips/pistachio/init.c: mips_nmi_setup() - Pistachio CPU:
> > MACH_PISTACHIO (up to 0x400, VEIC: 0xB00)
> > board_ejtag_handler_setup:
> > arch/mips/mti-malta/malta-init.c: mips_ejtag_setup() - Malta CPU:
> > MIPS_MALTA (up to 0x380, VEIC: 0xa80)
> > arch/mips/pistachio/init.c: mips_ejtag_setup() - Pistachio CPU:
> > MACH_PISTACHIO (up to 0x380, VEIC: 0xa80)
> > bmips_ebase_setup:
> > arch/mips/kernel/smp-bmips.c: bmips_ebase_setup() - Broadcom CPU:
> > CPU_BMIPS (up to 0x400 - NMI/reset, and 0x1000 - normal)
> > plat_mem_setup:
> > arch/mips/bmips/setup.c: bcm63xx_fixup_cpu1() - Broadcom CPU: CPU_BMIPS
> > (up to 0x220)
> >
> >
> > Are you sure all of them have "cpu_has_mips_r2_r6" macro returning
> > true (false) in order to safely use the lowest region in accordance
> > with the conditional statement you've added?
>
> some of them are not R2 (SB1), others are. So best bet would be to
> simply reserve the first 0x1000 bytes for every CPU and special handling
> for the BMIPS case. Does this cover all cases ?
I can't say for sure whether it will cover all the cases/platforms. I
visually analysed all the
board_{nmi_handler,ejtag_handler,ebase,cache_error}_setup callbacks
implementation in MIPS arch to create the list above. Exception vectors or
some other stuff can be setup in some other platform-specific manner. But at
least reserving a memory below PAGE_SIZE would get the situation partly back
to before the memory below the kernel stopped being reserved. Hopefully
one page will be enough for the platforms, which relied on that rule. The
rest or them sooner or later will manifest itself as it has happened with
Broadcom.
-Sergey
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.[ RFC1925, 2.3 ]
Re: [PATCH -next] bus: bt1-apb: remove duplicate include
Hi Arnd, Could you merge this patch in via your repo? On Wed, Aug 19, 2020 at 10:43:51AM +0800, Wang Hai wrote: > Remove linux/clk.h which is included more than once > > Reported-by: Hulk Robot > Signed-off-by: Wang Hai Acked-by: Serge Semin -Sergey > --- > drivers/bus/bt1-apb.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/bus/bt1-apb.c b/drivers/bus/bt1-apb.c > index b25ff941e7c7..74b1b712ef3a 100644 > --- a/drivers/bus/bt1-apb.c > +++ b/drivers/bus/bt1-apb.c > @@ -22,7 +22,6 @@ > #include > #include > #include > -#include > #include > > #define APB_EHB_ISR 0x00 > -- > 2.17.1 >
Re: [PATCH v2] MIPS: kernel: Reserve exception base early to prevent corruption
Hi Thomas.
I thought we'd discuss it in v1, but since you've sent v2 please see
my comment below.
On Sat, Mar 06, 2021 at 09:29:09AM +0100, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in FDT being corrupted.
>
> Before the cited commit, early allocations would be in the [kernel_end,
> RAM_END] range, but after commit they would be within [RAM_START +
> PAGE_SIZE, RAM_END].
>
> The custom exception base handler that is installed by
> bmips_ebase_setup() done for BMIPS5000 CPUs ends-up trampling on the
> memory region allocated by unflatten_and_copy_device_tree() thus
> corrupting the FDT used by the kernel.
>
> To fix this, we need to perform an early reservation of the custom
> exception space. So we reserve it already in cpu_probe() for the CPUs
> where this is fixed. For CPU with an ebase config register allocation
> of exception space will be done in trap_init().
>
> Huge thanks to Serget for analysing and proposing a solution to this
> issue.
>
> Fixes: 2dcb39645441 ("memblock: do not start bottom-up allocations with
> kernel_end")
> Reported-by: Kamal Dasu
> Debugged-by: Serge Semin
> Signed-off-by: Thomas Bogendoerfer
> ---
> Changes in v2:
> - do only memblock reservation in reserve_exception_space()
> - reserve 0..0x400 for all CPUs without ebase register and
>to addtional reserve_exception_space for BMIPS CPUs
>
> arch/mips/include/asm/traps.h| 3 +++
> arch/mips/kernel/cpu-probe.c | 7 +++
> arch/mips/kernel/cpu-r3k-probe.c | 3 +++
> arch/mips/kernel/traps.c | 10 +-
> 4 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/arch/mips/include/asm/traps.h b/arch/mips/include/asm/traps.h
> index 6aa8f126a43d..b710e76c9c65 100644
> --- a/arch/mips/include/asm/traps.h
> +++ b/arch/mips/include/asm/traps.h
> @@ -24,8 +24,11 @@ extern void (*board_ebase_setup)(void);
> extern void (*board_cache_error_setup)(void);
>
> extern int register_nmi_notifier(struct notifier_block *nb);
> +extern void reserve_exception_space(phys_addr_t addr, unsigned long size);
> extern char except_vec_nmi[];
>
> +#define VECTORSPACING 0x100 /* for EI/VI mode */
> +
> #define nmi_notifier(fn, pri)
> \
> ({ \
> static struct notifier_block fn##_nb = {\
> diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
> index 9a89637b4ecf..b565bc4b900d 100644
> --- a/arch/mips/kernel/cpu-probe.c
> +++ b/arch/mips/kernel/cpu-probe.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "fpu-probe.h"
> @@ -1628,6 +1629,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> c->cputype = CPU_BMIPS3300;
> __cpu_name[cpu] = "Broadcom BMIPS3300";
> set_elf_platform(cpu, "bmips3300");
> + reserve_exception_space(0x400, VECTORSPACING * 64);
> break;
> case PRID_IMP_BMIPS43XX: {
> int rev = c->processor_id & PRID_REV_MASK;
> @@ -1638,6 +1640,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> __cpu_name[cpu] = "Broadcom BMIPS4380";
> set_elf_platform(cpu, "bmips4380");
> c->options |= MIPS_CPU_RIXI;
> + reserve_exception_space(0x400, VECTORSPACING * 64);
> } else {
> c->cputype = CPU_BMIPS4350;
> __cpu_name[cpu] = "Broadcom BMIPS4350";
> @@ -1654,6 +1657,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> __cpu_name[cpu] = "Broadcom BMIPS5000";
> set_elf_platform(cpu, "bmips5000");
> c->options |= MIPS_CPU_ULRI | MIPS_CPU_RIXI;
> + reserve_exception_space(0x1000, VECTORSPACING * 64);
> break;
> }
> }
> @@ -2133,6 +2137,9 @@ void cpu_probe(void)
> if (cpu == 0)
> __ua_limit = ~((1ull << cpu_vmbits) - 1);
> #endif
> +
> + if (cpu_has_mips_r2_r6)
> + reserve_exception_space(0, 0x400);
Are you sure it shouldn't be (!cpu_has_mips_r2_r6)?. What I see here
contradicts to what is said in Chang
Re: [PATCH 1/8] gpio: Add Elba SoC gpio driver for spi cs control
Hello Linus,
I started reviewing from the DW APB SPI driver part of this series,
that's why I suggested to remove the CS callback from there seeing it
doesn't really differ much from the generic one. But after looking at
the dts file and in this driver I think that the alterations layout
needs to be a bit different.
This module looks more like being a part of a SoC System Controller
seeing it's just a single register. Corresponding pins seem like
being multiplexed between SPI controller and GPO (being directly driven
by setting a bit in the corresponding register). See the next comment.
On Thu, Mar 04, 2021 at 09:29:33AM +0100, Linus Walleij wrote:
> Hi Brad,
>
> thanks for your patch!
>
> On Thu, Mar 4, 2021 at 4:42 AM Brad Larson wrote:
>
> > This GPIO driver is for the Pensando Elba SoC which
> > provides control of four chip selects on two SPI busses.
> >
> > Signed-off-by: Brad Larson
> (...)
>
> > +#include
>
> Use this in new drivers:
> #include
>
> > + * pin: 32| 10
> > + * bit: 7--6--5--4|---3--2--1--0
> > + * cs1 cs1_ovr cs0 cs0_ovr | cs1 cs1_ovr cs0 cs0_ovr
> > + *ssi1| ssi0
> > + */
> > +#define SPICS_PIN_SHIFT(pin) (2 * (pin))
> > +#define SPICS_MASK(pin)(0x3 << SPICS_PIN_SHIFT(pin))
> > +#define SPICS_SET(pin, val)val) << 1) | 0x1) <<
> > SPICS_PIN_SHIFT(pin))
>
> So 2 bits per GPIO line in one register? (Nice doc!)
I suppose the first bit is the CS-pin-override flag. So when it's set
the output is directly driven by the second bit, otherwise the
corresponding DW APB SPI controller drives it. That's how the
multiplexing is implemented here.
>
> > +struct elba_spics_priv {
> > + void __iomem *base;
> > + spinlock_t lock;
> > + struct gpio_chip chip;
> > +};
> > +
> > +static int elba_spics_get_value(struct gpio_chip *chip, unsigned int pin)
> > +{
> > + return -ENXIO;
> > +}
>
> Write a comment that the chip only supports output mode,
> because it repurposes SPI CS pins as generic GPIO out,
> maybe at the top of the file?
>
> I suppose these systems also actually (ab)use the SPI cs
> for things that are not really SPI CS?
I haven't noticed that in the dts file submitted by Brad. So most
likely these are just CS pins, which can be either automatically
driven by the DW APB SPI controller (yeah, DW APB SPI controller
doesn't provide a way to directly set he native CS value, it
sets the CS value low automatically when starts SPI xfers) or can be
manually set low/high by means of that SPI-CS register.
> Because otherwise
> this could just be part of the SPI driver (native chip select).
That's what I suggested in my comment to the patch
[PATCH 7/8] arm64: dts: Add Pensando Elba SoC support
in this series. Although imho it's better to be done by means
of a System Controller.
-Sergey
>
> > +static const struct of_device_id ebla_spics_of_match[] = {
> > + { .compatible = "pensando,elba-spics" },
>
> Have you documented this?
>
> Other than that this is a nice and complete driver.
>
> Yours,
> Linus Walleij
Re: [PATCH 7/8] arm64: dts: Add Pensando Elba SoC support
On Wed, Mar 03, 2021 at 07:41:40PM -0800, Brad Larson wrote:
> Add Pensando common and Elba SoC specific device nodes
> and corresponding binding documentation.
This also needs to be split up into sub-patches seeing these are
unrelated changes like device bindings update, new platform DT file.
Note text-based bindings are deprecated in favor of the DT schemas.
Also note dts needs to pass dtbs_check validation. So all new HW/DT
nodes need to be reflected in the DT-schemas. See [1] for details.
[1] Documentation/devicetree/writing-schema.rst
>
> Signed-off-by: Brad Larson
> ---
> .../bindings/gpio/pensando,elba-spics.txt | 24 ++
> .../devicetree/bindings/mmc/cdns,sdhci.yaml | 2 +-
> .../bindings/spi/cadence-quadspi.txt | 1 +
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> arch/arm64/boot/dts/Makefile | 1 +
> arch/arm64/boot/dts/pensando/Makefile | 6 +
> arch/arm64/boot/dts/pensando/elba-16core.dtsi | 171 ++
> .../boot/dts/pensando/elba-asic-common.dtsi | 113 +++
> arch/arm64/boot/dts/pensando/elba-asic.dts| 8 +
> .../boot/dts/pensando/elba-flash-parts.dtsi | 80 +
> arch/arm64/boot/dts/pensando/elba.dtsi| 310 ++
> 11 files changed, 717 insertions(+), 1 deletion(-)
> create mode 100644
> Documentation/devicetree/bindings/gpio/pensando,elba-spics.txt
> create mode 100644 arch/arm64/boot/dts/pensando/Makefile
> create mode 100644 arch/arm64/boot/dts/pensando/elba-16core.dtsi
> create mode 100644 arch/arm64/boot/dts/pensando/elba-asic-common.dtsi
> create mode 100644 arch/arm64/boot/dts/pensando/elba-asic.dts
> create mode 100644 arch/arm64/boot/dts/pensando/elba-flash-parts.dtsi
> create mode 100644 arch/arm64/boot/dts/pensando/elba.dtsi
>
> diff --git a/Documentation/devicetree/bindings/gpio/pensando,elba-spics.txt
> b/Documentation/devicetree/bindings/gpio/pensando,elba-spics.txt
> new file mode 100644
> index ..30f5f3275238
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/pensando,elba-spics.txt
> @@ -0,0 +1,24 @@
> +Pensando Elba SPI Chip Select Driver
> +
> +The Pensando Elba ASIC provides four SPI bus chip selects
> +
> +Required properties:
> +- compatible: Should be "pensando,elba-spics"
> +- reg: Address range of spics controller
> +- gpio-controller: Marks the device node as gpio controller
> +- #gpio-cells: Must be 2
> +
> +Example:
> +---
> +spics: spics@307c2468 {
> +compatible = "pensando,elba-spics";
> +reg = <0x0 0x307c2468 0x0 0x4>;
> +gpio-controller;
> +#gpio-cells = <2>;
> +};
> +
> + {
> +num-cs = <4>;
> +cs-gpios = < 0 0>, < 1 0>, < 1 0>, < 7 0>;
> + ...
> +}
> diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> index af7442f73881..645ae696ba24 100644
> --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> @@ -122,7 +122,7 @@ unevaluatedProperties: false
> examples:
>- |
> emmc: mmc@5a00 {
> -compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
> +compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc",
> "pensando,elba-emmc";
Alas it's not enough. New HW compatible strings shall be defined in the
binding schema.
> reg = <0x5a00 0x400>;
> interrupts = <0 78 4>;
> clocks = < 4>;
> diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> index 8ace832a2d80..dbb346b2b1d7 100644
> --- a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> +++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
> @@ -6,6 +6,7 @@ Required properties:
> For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
> For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor".
> For Intel LGM SoC - "intel,lgm-qspi", "cdns,qspi-nor".
> + For Pensando SoC - "pensando,cdns-qspi".
What about converting this file to DT-schema and adding new HW
bindings in there?
> - reg : Contains two entries, each of which is a tuple consisting of a
> physical address and length. The first entry is the address and
> length of the controller register set. The second entry is the
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index f6064d84a424..9a21d780c5e1 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -850,6 +850,8 @@ patternProperties:
> description: Parallax Inc.
>"^pda,.*":
> description: Precision Design Associates, Inc.
> + "^pensando,.*":
> +description: Pensando Systems Inc.
>"^pericom,.*":
> description: Pericom Technology Inc.
>"^pervasive,.*":
> diff --git
Re: [PATCH 3/8] spi: dw: Add support for Pensando Elba SoC SPI
Hello Brad.
Thanks for the patch. See my comments below.
On Wed, Mar 03, 2021 at 07:41:36PM -0800, Brad Larson wrote:
> The Pensando Elba SoC uses a GPIO based chip select
> for two DW SPI busses with each bus having two
> chip selects.
I see a contradiction here. Normally GPIO-based chip-select is a
property of a platform, but not a SoC/CPU/MCU/etc. Most of the time
SoC SPI interfaces still get to have native CS pins, while at some
platform configurations (like in case of DW APB SPI, which doesn't
provide a way to directly toggle its native CSs) it's easier or even
safer to use GPIOs as CS signals. Of course theoretically a SoC could
be synthesized so it doesn't have native CS output pins, but only some
virtual internal CS flags, but I've never seen such. Anyway according
to the custom CS method below it's not your case because you still
provide support for SPI-devices handled by native CS (else branch in
the if (spi->cs_gpiod) {} else {} statement).
>
> Signed-off-by: Brad Larson
> ---
> drivers/spi/spi-dw-mmio.c | 35 ++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
> index 17c06039a74d..417bd2125c07 100644
> --- a/drivers/spi/spi-dw-mmio.c
> +++ b/drivers/spi/spi-dw-mmio.c
> @@ -56,7 +56,7 @@ struct dw_spi_mscc {
> /*
> * The Designware SPI controller (referred to as master in the documentation)
> * automatically deasserts chip select when the tx fifo is empty. The chip
> - * selects then needs to be either driven as GPIOs or, for the first 4 using
> the
> + * selects then needs to be either driven as GPIOs or, for the first 4 using
> * the SPI boot controller registers. the final chip select is an OR gate
> * between the Designware SPI controller and the SPI boot controller.
> */
> @@ -237,6 +237,38 @@ static int dw_spi_canaan_k210_init(struct
> platform_device *pdev,
> return 0;
> }
>
> +static void dw_spi_elba_set_cs(struct spi_device *spi, bool enable)
> +{
> + struct dw_spi *dws = spi_master_get_devdata(spi->master);
> +
> + if (!enable) {
> + if (spi->cs_gpiod) {
> + /*
> + * Using a GPIO-based chip-select, the DW SPI
> + * controller still needs its own CS bit selected
> + * to start the serial engine. On Elba the specific
> + * CS doesn't matter, so use CS0.
> + */
> + dw_writel(dws, DW_SPI_SER, BIT(0));
> + } else {
> + /*
> + * Using the intrinsic DW chip-select; set the
> + * appropriate CS.
> + */
> + dw_writel(dws, DW_SPI_SER, BIT(spi->chip_select));
> + }
> - } else
+ } else {
> + dw_writel(dws, DW_SPI_SER, 0);
+ } /* See [1] */
> +}
The custom CS-method above doesn't look much different from the
dw_spi_set_cs() method defined in the spi-dw-core.o driver, except
having at least two problems:
1) It assumes that "enable" argument means the CS-enabling flag, while
in fact it's the CS-level which depending on the SPI_CS_HIGH flag
set/cleared will be 1/0 respectively if CS is supposed to be enabled.
That aspect has already been fixed in the dw_spi_set_cs() method.
2) The method enables CS[0] if GPIO-CS is used for a particular SPI
device. That will cause problems for a GPIO/native CS intermixed case
of having for instance one SPI-device connected to native CS[0] and
another one - to a GPIO. So trying to communicate with the second SPI
device you'll end up having the native CS[0] activated too thus
having an SPI transfer sent to two SPI-device at the same time.
Of course that's not what you'd want.
Anyway I don't really see why you even need a custom CS method here. A
generic method dw_spi_set_cs() shall work for your SPI interface.
If I am wrong, please explain why. Did you try the generic CS method
on your platform?
[1] Placing Braces and Spaces. Chapter 3).
Documentation/process/coding-style.rst
> +
> +static int dw_spi_elba_init(struct platform_device *pdev,
> + struct dw_spi_mmio *dwsmmio)
> +{
> + dwsmmio->dws.set_cs = dw_spi_elba_set_cs;
> +
> + return 0;
> +}
> +
> static int dw_spi_mmio_probe(struct platform_device *pdev)
> {
> int (*init_func)(struct platform_device *pdev,
> @@ -351,6 +383,7 @@ static const struct of_device_id dw_spi_mmio_of_match[] =
> {
> { .compatible = "intel,keembay-ssi", .data = dw_spi_keembay_init},
> { .compatible = "microchip,sparx5-spi", dw_spi_mscc_sparx5_init},
> { .compatible = "canaan,k210-spi", dw_spi_canaan_k210_init},
> + { .compatible = "pensando,elba-spi", .data = dw_spi_elba_init },
If you agree with me and remove the custom CS-method defined above in
this patch, then all you'll need is just to add "pensando,elba-spi" here
with
Re: [PATCH] MIPS: kernel: Reserve exception base early to prevent corruption
Hello Thomas,
Thanks for the patch. My comments are below.
On Wed, Mar 03, 2021 at 07:57:13PM +0100, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in FDT being corrupted.
>
> Before the cited commit, early allocations would be in the [kernel_end,
> RAM_END] range, but after commit they would be within [RAM_START +
> PAGE_SIZE, RAM_END].
>
> The custom exception base handler that is installed by
> bmips_ebase_setup() done for BMIPS5000 CPUs ends-up trampling on the
> memory region allocated by unflatten_and_copy_device_tree() thus
> corrupting the FDT used by the kernel.
>
> To fix this, we need to perform an early reservation of the custom
> exception space. So we reserve it already in cpu_probe() for the CPUs
> where this is fixed. For CPU with an ebase config register allocation
> of exception space will be done in trap_init().
>
> Huge thanks to Serget for analysing and proposing a solution to this
> issue.
>
> Fixes: Fixes: 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end")
Fixes tag is used twice.
> Debugged-by: Serge Semin
> Reported-by: Kamal Dasu
I'd switch these tags order. First it was reported, then the
problem was debugged. I suppose it would be also nice to add
Florian under the second Reported-by tag if he doesn't mind. I haven't
seen any Kamal' email message, but a report posted by Florian only.
> Signed-off-by: Thomas Bogendoerfer
> ---
> arch/mips/include/asm/traps.h| 4
> arch/mips/kernel/cpu-probe.c | 7 +++
> arch/mips/kernel/cpu-r3k-probe.c | 3 +++
> arch/mips/kernel/smp-bmips.c | 9 +
> arch/mips/kernel/traps.c | 31 ---
> 5 files changed, 31 insertions(+), 23 deletions(-)
>
> diff --git a/arch/mips/include/asm/traps.h b/arch/mips/include/asm/traps.h
> index 6aa8f126a43d..d74d829e1655 100644
> --- a/arch/mips/include/asm/traps.h
> +++ b/arch/mips/include/asm/traps.h
> @@ -24,7 +24,11 @@ extern void (*board_ebase_setup)(void);
> extern void (*board_cache_error_setup)(void);
>
> extern int register_nmi_notifier(struct notifier_block *nb);
> +extern void reserve_exception_space(unsigned long addr, unsigned long size);
> extern char except_vec_nmi[];
> +extern unsigned long ebase_size;
> +
> +#define VECTORSPACING 0x100 /* for EI/VI mode */
>
> #define nmi_notifier(fn, pri)
> \
> ({ \
> diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
> index 9a89637b4ecf..effc45cbb351 100644
> --- a/arch/mips/kernel/cpu-probe.c
> +++ b/arch/mips/kernel/cpu-probe.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "fpu-probe.h"
> @@ -1628,6 +1629,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> c->cputype = CPU_BMIPS3300;
> __cpu_name[cpu] = "Broadcom BMIPS3300";
> set_elf_platform(cpu, "bmips3300");
> + reserve_exception_space(0x8400, VECTORSPACING * 64);
> break;
> case PRID_IMP_BMIPS43XX: {
> int rev = c->processor_id & PRID_REV_MASK;
> @@ -1638,6 +1640,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> __cpu_name[cpu] = "Broadcom BMIPS4380";
> set_elf_platform(cpu, "bmips4380");
> c->options |= MIPS_CPU_RIXI;
> + reserve_exception_space(0x8400, VECTORSPACING * 64);
> } else {
> c->cputype = CPU_BMIPS4350;
> __cpu_name[cpu] = "Broadcom BMIPS4350";
> @@ -1654,6 +1657,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> __cpu_name[cpu] = "Broadcom BMIPS5000";
> set_elf_platform(cpu, "bmips5000");
> c->options |= MIPS_CPU_ULRI | MIPS_CPU_RIXI;
> + reserve_exception_space(0x80001000, VECTORSPACING * 64);
> break;
> }
> }
> @@ -2133,6 +2137,9 @@ void cpu_probe(void)
> if (cpu == 0)
> __ua_limit = ~((1ull << cpu_vmbits) - 1);
> #endif
> +
> + if (ebase_size == 0 && !cpu_has_mips_r2_r6)
> + reserv
Re: [PATCH] MIPS: BMIPS: Reserve exception base to prevent corruption
On Mon, Mar 01, 2021 at 08:19:38PM -0800, Florian Fainelli wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in FDT being corrupted.
>
> Before the cited commit, early allocations would be in the [kernel_end,
> RAM_END] range, but after commit they would be within [RAM_START +
> PAGE_SIZE, RAM_END].
>
> The custom exception base handler that is installed by
> bmips_ebase_setup() done for BMIPS5000 CPUs ends-up trampling on the
> memory region allocated by unflatten_and_copy_device_tree() thus
> corrupting the FDT used by the kernel.
>
> To fix this, we need to perform an early reservation of the custom
> exception that is going to be installed and this needs to happen at
> plat_mem_setup() time to ensure that unflatten_and_copy_device_tree()
> finds a space that is suitable, away from reserved memory.
>
> Huge thanks to Serget for analysing and proposing a solution to this
> issue.
>
> Fixes: Fixes: 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end")
> Debugged-by: Serge Semin
> Reported-by: Kamal Dasu
I'd change the order of these two tags...
> Signed-off-by: Florian Fainelli
> ---
> Thomas,
>
> This is intended as a stop-gap solution for 5.12-rc1 and to be picked up
> by the stable team for 5.11. We should find a safer way to avoid these
> problems for 5.13 maybe.
Thomas, could you join the discussion? If we had a more clever
solution to reserve the exceptions table for each possibly affected
platform this patch could have been omitted.
>
> arch/mips/bmips/setup.c | 22 ++
> arch/mips/include/asm/traps.h | 2 ++
> 2 files changed, 24 insertions(+)
>
> diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
> index 31bcfa4e08b9..0088bd45b892 100644
> --- a/arch/mips/bmips/setup.c
> +++ b/arch/mips/bmips/setup.c
> @@ -149,6 +149,26 @@ void __init plat_time_init(void)
> mips_hpt_frequency = freq;
> }
>
> +static void __init bmips_ebase_reserve(void)
> +{
> + phys_addr_t base, size = VECTORSPACING * 64;
> +
> + switch (current_cpu_type()) {
> + default:
> + case CPU_BMIPS4350:
> + return;
> + case CPU_BMIPS3300:
> + case CPU_BMIPS4380:
> + base = 0x0400;
> + break;
> + case CPU_BMIPS5000:
> + base = 0x1000;
> + break;
> + }
> +
> + memblock_reserve(base, size);
> +}
> +
> void __init plat_mem_setup(void)
> {
> void *dtb;
> @@ -169,6 +189,8 @@ void __init plat_mem_setup(void)
>
> __dt_setup_arch(dtb);
>
> + bmips_ebase_reserve();
> +
> for (q = bmips_quirk_list; q->quirk_fn; q++) {
> if (of_flat_dt_is_compatible(of_get_flat_dt_root(),
>q->compatible)) {
> diff --git a/arch/mips/include/asm/traps.h b/arch/mips/include/asm/traps.h
> index 6aa8f126a43d..0ba6bb7f9618 100644
> --- a/arch/mips/include/asm/traps.h
> +++ b/arch/mips/include/asm/traps.h
> @@ -14,6 +14,8 @@
> #define MIPS_BE_FIXUP1 /* return to the fixup code */
> #define MIPS_BE_FATAL2 /* treat as an unrecoverable
> error */
>
> +#define VECTORSPACING 0x100 /* for EI/VI mode */
What about the same macro declared in arch/mips/kernel/traps.c? I'd suggest
to remove it from there and explicitly #include this header file into
the arch/mips/bmips/setup.c file.
-Sergey
> +
> extern void (*board_be_init)(void);
> extern int (*board_be_handler)(struct pt_regs *regs, int is_fixup);
>
> --
> 2.25.1
>
Re: [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end
On Mon, Mar 01, 2021 at 08:09:52PM -0800, Florian Fainelli wrote: > > > On 3/1/2021 1:22 AM, Serge Semin wrote: > > On Sun, Feb 28, 2021 at 07:50:45PM -0800, Florian Fainelli wrote: > >> Hi Serge, > >> > >> On 2/28/2021 3:08 PM, Serge Semin wrote: > >>> Hi folks, > >>> What you've got here seems a more complicated problem than it > >>> could originally look like. Please, see my comments below. > >>> > >>> (Note I've discarded some of the email logs, which of no interest > >>> to the discovered problem. Please also note that I haven't got any > >>> Broadcom hardware to test out a solution suggested below.) > >>> > >>> On Sun, Feb 28, 2021 at 10:19:51AM -0800, Florian Fainelli wrote: > >>>> Hi Mike, > >>>> > >>>> On 2/28/2021 1:00 AM, Mike Rapoport wrote: > >>>>> Hi Florian, > >>>>> > >>>>> On Sat, Feb 27, 2021 at 08:18:47PM -0800, Florian Fainelli wrote: > >>>>>> > >>> > >>>>>> [...] > >>> > >>>>>> > >>>>>> Hi Roman, Thomas and other linux-mips folks, > >>>>>> > >>>>>> Kamal and myself have been unable to boot v5.11 on MIPS since this > >>>>>> commit, reverting it makes our MIPS platforms boot successfully. We do > >>>>>> not see a warning like this one in the commit message, instead what > >>>>>> happens appear to be a corrupted Device Tree which prevents the parsing > >>>>>> of the "rdb" node and leading to the interrupt controllers not being > >>>>>> registered, and the system eventually not booting. > >>>>>> > >>>>>> The Device Tree is built-into the kernel image and resides at > >>>>>> arch/mips/boot/dts/brcm/bcm97435svmb.dts. > >>>>>> > >>>>>> Do you have any idea what could be wrong with MIPS specifically here? > >>> > >>> Most likely the problem you've discovered has been there for quite > >>> some time. The patch you are referring to just caused it to be > >>> triggered by extending the early allocation range. See before that > >>> patch was accepted the early memory allocations had been performed > >>> in the range: > >>> [kernel_end, RAM_END]. > >>> The patch changed that, so the early allocations are done within > >>> [RAM_START + PAGE_SIZE, RAM_END]. > >>> > >>> In normal situations it's safe to do that as long as all the critical > >>> memory regions (including the memory residing a space below the > >>> kernel) have been reserved. But as soon as a memory with some critical > >>> structures haven't been reserved, the kernel may allocate it to be used > >>> for instance for early initializations with obviously unpredictable but > >>> most of the times unpleasant consequences. > >>> > >>>>> > >>>>> Apparently there is a memblock allocation in one of the functions called > >>>>> from arch_mem_init() between plat_mem_setup() and > >>>>> early_init_fdt_reserve_self(). > >>> > >>> Mike, alas according to the log provided by Florian that's not the reason > >>> of the problem. Please, see my considerations below. > >>> > >>>> [...] > >>>> > >>>> [0.00] Linux version 5.11.0-g5695e5161974 (florian@localhost) > >>>> (mipsel-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #84 SMP Sun > >>>> Feb 28 10:01:50 PST 2021 > >>>> [0.00] CPU0 revision is: 00025b00 (Broadcom BMIPS5200) > >>>> [0.00] FPU revision is: 00130001 > >>> > >>>> [0.00] memblock_add: [0x-0x0fff] > >>>> early_init_dt_scan_memory+0x160/0x1e0 > >>>> [0.00] memblock_add: [0x2000-0x4fff] > >>>> early_init_dt_scan_memory+0x160/0x1e0 > >>>> [0.00] memblock_add: [0x9000-0xcfff] > >>>> early_init_dt_scan_memory+0x160/0x1e0 > >>> > >>> Here the memory has been added to the memblock allocator. > >>> > >>>> [0.00] MIPS: machine is Broadcom BCM97435SVMB > >>>> [0.00] earlycon: ns16550a0 at MMIO32 0x10406b00 (options '') > >>>> [0.00]
Re: [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end
On Mon, Mar 01, 2021 at 07:55:21PM -0800, Roman Gushchin wrote: > On Mon, Mar 01, 2021 at 11:45:42AM +0200, Mike Rapoport wrote: > > On Sun, Feb 28, 2021 at 07:50:45PM -0800, Florian Fainelli wrote: > > > Hi Serge, > > > > > > On 2/28/2021 3:08 PM, Serge Semin wrote: > > > > Hi folks, > > > > What you've got here seems a more complicated problem than it > > > > could originally look like. Please, see my comments below. > > > > > > > > (Note I've discarded some of the email logs, which of no interest > > > > to the discovered problem. Please also note that I haven't got any > > > > Broadcom hardware to test out a solution suggested below.) > > > > > > > > On Sun, Feb 28, 2021 at 10:19:51AM -0800, Florian Fainelli wrote: > > > >> Hi Mike, > > > >> > > > >> On 2/28/2021 1:00 AM, Mike Rapoport wrote: > > > >>> Hi Florian, > > > >>> > > > >>> On Sat, Feb 27, 2021 at 08:18:47PM -0800, Florian Fainelli wrote: > > > >>>> > > > > > > > >>>> [...] > > > > > > > >>>> > > > >>>> Hi Roman, Thomas and other linux-mips folks, > > > >>>> > > > >>>> Kamal and myself have been unable to boot v5.11 on MIPS since this > > > >>>> commit, reverting it makes our MIPS platforms boot successfully. We > > > >>>> do > > > >>>> not see a warning like this one in the commit message, instead what > > > >>>> happens appear to be a corrupted Device Tree which prevents the > > > >>>> parsing > > > >>>> of the "rdb" node and leading to the interrupt controllers not being > > > >>>> registered, and the system eventually not booting. > > > >>>> > > > >>>> The Device Tree is built-into the kernel image and resides at > > > >>>> arch/mips/boot/dts/brcm/bcm97435svmb.dts. > > > >>>> > > > >>>> Do you have any idea what could be wrong with MIPS specifically here? > > > > > > > > Most likely the problem you've discovered has been there for quite > > > > some time. The patch you are referring to just caused it to be > > > > triggered by extending the early allocation range. See before that > > > > patch was accepted the early memory allocations had been performed > > > > in the range: > > > > [kernel_end, RAM_END]. > > > > The patch changed that, so the early allocations are done within > > > > [RAM_START + PAGE_SIZE, RAM_END]. > > > > > > > > In normal situations it's safe to do that as long as all the critical > > > > memory regions (including the memory residing a space below the > > > > kernel) have been reserved. But as soon as a memory with some critical > > > > structures haven't been reserved, the kernel may allocate it to be used > > > > for instance for early initializations with obviously unpredictable but > > > > most of the times unpleasant consequences. > > > > > > > >>> > > > >>> Apparently there is a memblock allocation in one of the functions > > > >>> called > > > >>> from arch_mem_init() between plat_mem_setup() and > > > >>> early_init_fdt_reserve_self(). > > > > > > > > Mike, alas according to the log provided by Florian that's not the > > > > reason > > > > of the problem. Please, see my considerations below. > > > > > > > >> [...] > > > >> > > > >> [0.00] Linux version 5.11.0-g5695e5161974 (florian@localhost) > > > >> (mipsel-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #84 SMP Sun > > > >> Feb 28 10:01:50 PST 2021 > > > >> [0.00] CPU0 revision is: 00025b00 (Broadcom BMIPS5200) > > > >> [0.00] FPU revision is: 00130001 > > > > > > > >> [0.00] memblock_add: [0x-0x0fff] > > > >> early_init_dt_scan_memory+0x160/0x1e0 > > > >> [0.00] memblock_add: [0x2000-0x4fff] > > > >> early_init_dt_scan_memory+0x160/0x1e0 > > > >> [0.00] memblock_add: [0x9000-0xcfff] > > > >> early_init_dt_scan_memory+0x160/0x1e0 > > > > > > > >
Re: [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end
On Sun, Feb 28, 2021 at 07:50:45PM -0800, Florian Fainelli wrote: > Hi Serge, > > On 2/28/2021 3:08 PM, Serge Semin wrote: > > Hi folks, > > What you've got here seems a more complicated problem than it > > could originally look like. Please, see my comments below. > > > > (Note I've discarded some of the email logs, which of no interest > > to the discovered problem. Please also note that I haven't got any > > Broadcom hardware to test out a solution suggested below.) > > > > On Sun, Feb 28, 2021 at 10:19:51AM -0800, Florian Fainelli wrote: > >> Hi Mike, > >> > >> On 2/28/2021 1:00 AM, Mike Rapoport wrote: > >>> Hi Florian, > >>> > >>> On Sat, Feb 27, 2021 at 08:18:47PM -0800, Florian Fainelli wrote: > >>>> > > > >>>> [...] > > > >>>> > >>>> Hi Roman, Thomas and other linux-mips folks, > >>>> > >>>> Kamal and myself have been unable to boot v5.11 on MIPS since this > >>>> commit, reverting it makes our MIPS platforms boot successfully. We do > >>>> not see a warning like this one in the commit message, instead what > >>>> happens appear to be a corrupted Device Tree which prevents the parsing > >>>> of the "rdb" node and leading to the interrupt controllers not being > >>>> registered, and the system eventually not booting. > >>>> > >>>> The Device Tree is built-into the kernel image and resides at > >>>> arch/mips/boot/dts/brcm/bcm97435svmb.dts. > >>>> > >>>> Do you have any idea what could be wrong with MIPS specifically here? > > > > Most likely the problem you've discovered has been there for quite > > some time. The patch you are referring to just caused it to be > > triggered by extending the early allocation range. See before that > > patch was accepted the early memory allocations had been performed > > in the range: > > [kernel_end, RAM_END]. > > The patch changed that, so the early allocations are done within > > [RAM_START + PAGE_SIZE, RAM_END]. > > > > In normal situations it's safe to do that as long as all the critical > > memory regions (including the memory residing a space below the > > kernel) have been reserved. But as soon as a memory with some critical > > structures haven't been reserved, the kernel may allocate it to be used > > for instance for early initializations with obviously unpredictable but > > most of the times unpleasant consequences. > > > >>> > >>> Apparently there is a memblock allocation in one of the functions called > >>> from arch_mem_init() between plat_mem_setup() and > >>> early_init_fdt_reserve_self(). > > > > Mike, alas according to the log provided by Florian that's not the reason > > of the problem. Please, see my considerations below. > > > >> [...] > >> > >> [0.00] Linux version 5.11.0-g5695e5161974 (florian@localhost) > >> (mipsel-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #84 SMP Sun > >> Feb 28 10:01:50 PST 2021 > >> [0.00] CPU0 revision is: 00025b00 (Broadcom BMIPS5200) > >> [0.00] FPU revision is: 00130001 > > > >> [0.00] memblock_add: [0x-0x0fff] > >> early_init_dt_scan_memory+0x160/0x1e0 > >> [0.00] memblock_add: [0x2000-0x4fff] > >> early_init_dt_scan_memory+0x160/0x1e0 > >> [0.00] memblock_add: [0x9000-0xcfff] > >> early_init_dt_scan_memory+0x160/0x1e0 > > > > Here the memory has been added to the memblock allocator. > > > >> [0.00] MIPS: machine is Broadcom BCM97435SVMB > >> [0.00] earlycon: ns16550a0 at MMIO32 0x10406b00 (options '') > >> [0.00] printk: bootconsole [ns16550a0] enabled > > > >> [0.00] memblock_reserve: [0x00aa7600-0x00aaa0a0] > >> setup_arch+0x128/0x69c > > > > Here the fdt memory has been reserved. (Note it's built into the > > kernel.) > > > >> [0.00] memblock_reserve: [0x0001-0x018313cf] > >> setup_arch+0x1f8/0x69c > > > > Here the kernel itself together with built-in dtb have been reserved. > > So far so good. > > > >> [0.00] Initrd not found or empty - disabling initrd > > > >> [0.00] memblock_alloc_try_nid: 10913 bytes align=0x40 nid=-1 > >> from=0x max_addr=0x > >> early_init_dt_alloc_me
Re: [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end
Hi folks, What you've got here seems a more complicated problem than it could originally look like. Please, see my comments below. (Note I've discarded some of the email logs, which of no interest to the discovered problem. Please also note that I haven't got any Broadcom hardware to test out a solution suggested below.) On Sun, Feb 28, 2021 at 10:19:51AM -0800, Florian Fainelli wrote: > Hi Mike, > > On 2/28/2021 1:00 AM, Mike Rapoport wrote: > > Hi Florian, > > > > On Sat, Feb 27, 2021 at 08:18:47PM -0800, Florian Fainelli wrote: > >> > >> [...] > >> > >> Hi Roman, Thomas and other linux-mips folks, > >> > >> Kamal and myself have been unable to boot v5.11 on MIPS since this > >> commit, reverting it makes our MIPS platforms boot successfully. We do > >> not see a warning like this one in the commit message, instead what > >> happens appear to be a corrupted Device Tree which prevents the parsing > >> of the "rdb" node and leading to the interrupt controllers not being > >> registered, and the system eventually not booting. > >> > >> The Device Tree is built-into the kernel image and resides at > >> arch/mips/boot/dts/brcm/bcm97435svmb.dts. > >> > >> Do you have any idea what could be wrong with MIPS specifically here? Most likely the problem you've discovered has been there for quite some time. The patch you are referring to just caused it to be triggered by extending the early allocation range. See before that patch was accepted the early memory allocations had been performed in the range: [kernel_end, RAM_END]. The patch changed that, so the early allocations are done within [RAM_START + PAGE_SIZE, RAM_END]. In normal situations it's safe to do that as long as all the critical memory regions (including the memory residing a space below the kernel) have been reserved. But as soon as a memory with some critical structures haven't been reserved, the kernel may allocate it to be used for instance for early initializations with obviously unpredictable but most of the times unpleasant consequences. > > > > Apparently there is a memblock allocation in one of the functions called > > from arch_mem_init() between plat_mem_setup() and > > early_init_fdt_reserve_self(). Mike, alas according to the log provided by Florian that's not the reason of the problem. Please, see my considerations below. > [...] > > [0.00] Linux version 5.11.0-g5695e5161974 (florian@localhost) > (mipsel-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #84 SMP Sun > Feb 28 10:01:50 PST 2021 > [0.00] CPU0 revision is: 00025b00 (Broadcom BMIPS5200) > [0.00] FPU revision is: 00130001 > [0.00] memblock_add: [0x-0x0fff] > early_init_dt_scan_memory+0x160/0x1e0 > [0.00] memblock_add: [0x2000-0x4fff] > early_init_dt_scan_memory+0x160/0x1e0 > [0.00] memblock_add: [0x9000-0xcfff] > early_init_dt_scan_memory+0x160/0x1e0 Here the memory has been added to the memblock allocator. > [0.00] MIPS: machine is Broadcom BCM97435SVMB > [0.00] earlycon: ns16550a0 at MMIO32 0x10406b00 (options '') > [0.00] printk: bootconsole [ns16550a0] enabled > [0.00] memblock_reserve: [0x00aa7600-0x00aaa0a0] > setup_arch+0x128/0x69c Here the fdt memory has been reserved. (Note it's built into the kernel.) > [0.00] memblock_reserve: [0x0001-0x018313cf] > setup_arch+0x1f8/0x69c Here the kernel itself together with built-in dtb have been reserved. So far so good. > [0.00] Initrd not found or empty - disabling initrd > [0.00] memblock_alloc_try_nid: 10913 bytes align=0x40 nid=-1 > from=0x max_addr=0x > early_init_dt_alloc_memory_arch+0x40/0x84 > [0.00] memblock_reserve: [0x1000-0x3aa0] > memblock_alloc_range_nid+0xf8/0x198 > [0.00] memblock_alloc_try_nid: 32680 bytes align=0x4 nid=-1 > from=0x max_addr=0x > early_init_dt_alloc_memory_arch+0x40/0x84 > [0.00] memblock_reserve: [0x3aa4-0xba4b] > memblock_alloc_range_nid+0xf8/0x198 The log above most likely belongs to the call-chain: setup_arch() +-> arch_mem_init() +-> device_tree_init() - BMIPS specific method +-> unflatten_and_copy_device_tree() So to speak here we've copied the fdt from the original space [0x00aa7600-0x00aaa0a0] into [0x1000-0x3aa0] and unflattened it to [0x3aa4-0xba4b]. The problem is that a bit later the next call-chain is performed: setup_arch() +-> plat_smp_setup() +-> mp_ops->smp_setup(); - registered by prom_init()->register_bmips_smp_ops(); +-> if (!board_ebase_setup) board_ebase_setup = _ebase_setup; So at the moment of the CPU traps initialization the bmips_ebase_setup() method is called. What trap_init() does isn't compatible with the allocation performed by the unflatten_and_copy_device_tree() method. See the next comment. > [0.00] memblock_alloc_try_nid: 25 bytes align=0x4 nid=-1 > from=0x
Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode
On Sat, Feb 20, 2021 at 04:49:22PM +0100, Andrew Lunn wrote: > > If in doubt, leaving the patch as is would be fine with me. > > The patch is O.K. as is, no need to export something so simple for a > single users. When the next user come along, we can reconsider. Ok. Thanks for clarification. I performed some additional tests to make sure the bug was on the PHY side. They proved my original conclusion. It's indeed Realtek PHY to blame for the weird behavior. So I've added a few more words into the patch log regarding those tests. The patch will be resent tomorrow together with the rest of the STMMAC-driver-related bug-fixes detached from the original series of the fixes and cleanups (as Andrew asked to do). -Sergey > >Andrew
Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode
On Thu, Feb 11, 2021 at 10:39:41AM +, Russell King - ARM Linux admin wrote:
> On Wed, Feb 10, 2021 at 07:47:20PM +0300, Serge Semin wrote:
> > On Tue, Feb 09, 2021 at 10:56:46AM +, Russell King - ARM Linux admin
> > wrote:
> > > On Tue, Feb 09, 2021 at 11:37:29AM +0100, Heiner Kallweit wrote:
> > > > Right, adding something like a genphy_{read,write}_mmd() doesn't make
> > > > too much sense for now. What I meant is just exporting
> > > > mmd_phy_indirect().
> > > > Then you don't have to open-code the first three steps of a mmd
> > > > read/write.
> > > > And it requires no additional code in phylib.
> > >
> > > ... but at the cost that the compiler can no longer inline that code,
> > > as I mentioned in my previous reply. (However, the cost of the accesses
> > > will be higher.) On the plus side, less I-cache footprint, and smaller
> > > kernel code.
> >
> > Just to note mmd_phy_indirect() isn't defined with inline specifier,
> > but just as static and it's used twice in the
> > drivers/net/phy/phy-core.c unit. So most likely the compiler won't
> > inline the function code in there.
>
> You can't always tell whether the compiler will inline a static function
> or not.
Andrew, Heiner, Russell, what is your final decision about this? Shall
we export the mmd_phy_indirect() method, implement new
genphy_{read,write}_mmd() or just leave the patch as is manually
accessing the MMD register in the driver?
-Sergey
>
> > Anyway it's up to the PHY
> > library maintainers to decide. Please settle the issue with Heiner and
> > Andrew then. I am ok with both solutions and will do as you decide.
>
> FYI, *I* am one of the phylib maintainers.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH v2 04/24] dt-bindings: net: dwmac: Refactor snps,*-config properties
On Thu, Feb 11, 2021 at 12:58:00AM +0300, Serge Semin wrote: > On Tue, Feb 09, 2021 at 04:26:08PM -0600, Rob Herring wrote: > > On Mon, Feb 08, 2021 at 04:55:48PM +0300, Serge Semin wrote: > > > Currently the "snps,axi-config", "snps,mtl-rx-config" and > > > "snps,mtl-tx-config" properties are declared as a single phandle reference > > > to a node with corresponding parameters defined. That's not good for > > > several reasons. First of all scattering around a device tree some > > > particular device-specific configs with no visual relation to that device > > > isn't suitable from maintainability point of view. That leads to a > > > disturbed representation of the actual device tree mixing actual device > > > nodes and some vendor-specific configs. Secondly using the same configs > > > set for several device nodes doesn't represent well the devices structure, > > > since the interfaces these configs describe in hardware belong to > > > different devices and may actually differ. In the later case having the > > > configs node separated from the corresponding device nodes gets to be > > > even unjustified. > > > > > > So instead of having a separate DW *MAC configs nodes we suggest to > > > define them as sub-nodes of the device nodes, which interfaces they > > > actually describe. By doing so we'll make the DW *MAC nodes visually > > > correct describing all the aspects of the IP-core configuration. Thus > > > we'll be able to describe the configs sub-nodes bindings right in the > > > snps,dwmac.yaml file. > > > > > > Note the former "snps,axi-config", "snps,mtl-rx-config" and > > > "snps,mtl-tx-config" properties have been marked as deprecated in favor of > > > the added by this commit "axi-config", "mtl-rx-config" and "mtl-tx-config" > > > sub-nodes respectively. > > > > > > Signed-off-by: Serge Semin > > > > > > --- > > > > > > Note this change will work only if DT-schema tool is fixed like this: > > > > > > --- a/meta-schemas/nodes.yaml 2021-02-08 14:20:56.732447780 +0300 > > > +++ b/meta-schemas/nodes.yaml 2021-02-08 14:21:00.736492245 +0300 > > > @@ -22,6 +22,7 @@ > > > - unevaluatedProperties > > > - deprecated > > > - required > > > +- not > > > - allOf > > > - anyOf > > > - oneOf > > > > > Can you send me a patch or GH PR. There is another way to express. More > > below. > > Ok. I'll send a patch. To what email and mailing lists shall I send it > to? Rob, any comments on my questions above and below? -Sergey > > > > > > > > > So a property with name "not" would be allowed and the "not-required" > > > pattern would work. > > > > > > Changelog v2: > > > - Add the new sub-nodes "axi-config", "mtl-rx-config" and "mtl-tx-config" > > > describing the nodes now deprecated properties were supposed to > > > refer to. > > > - Fix invalid identation in the "snps,route-*" property settings. > > > - Use correct syntax of the JSON pointers, so the later would begin > > > with a '/' after the '#'. > > > --- > > > .../devicetree/bindings/net/snps,dwmac.yaml | 389 +- > > > 1 file changed, 297 insertions(+), 92 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > > index 03d58bf9965f..4dda9ffa822c 100644 > > > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > > @@ -150,73 +150,264 @@ properties: > > >in a different mode than the PHY in order to function. > > > > > >snps,axi-config: > > > +deprecated: true > > > $ref: /schemas/types.yaml#/definitions/phandle > > > description: > > > - AXI BUS Mode parameters. Phandle to a node that can contain the > > > - following properties > > > -* snps,lpi_en, enable Low Power Interface > > > -* snps,xit_frm, unlock on WoL > > > -* snps,wr_osr_lmt, max write outstanding req. limit > > > -* snps,rd_osr_lmt, max read outstanding req. limit > > > -* sn
Re: [PATCH 01/16] dt-bindings: net: dwmac: Add DW GMAC GPIOs properties
On Thu, Feb 11, 2021 at 01:28:06AM +0300, Serge Semin wrote: > On Tue, Feb 09, 2021 at 05:13:52PM -0600, Rob Herring wrote: > > On Mon, Feb 08, 2021 at 05:08:05PM +0300, Serge Semin wrote: > > > Synopsys DesignWare Ethernet controllers can be synthesized with > > > General-Purpose IOs support. GPIOs can work either as inputs or as outputs > > > thus belong to the gpi_i and gpo_o ports respectively. The ports width > > > (number of possible inputs/outputs) and the configuration registers layout > > > depend on the IP-core version. For instance, DW GMAC can have from 0 to 4 > > > GPIs and from 0 to 4 GPOs, while DW xGMAC have a wider ports width up to > > > 16 pins of each one. > > > > > > So the DW MAC DT-node can be equipped with "ngpios" property, which can't > > > have a value greater than 32, standard GPIO-related properties like > > > "gpio-controller" and "#gpio-cells", and, if GPIs are supposed to be > > > detected, IRQ-controller related properties. > > > > > > Signed-off-by: Serge Semin > > > --- > > > .../devicetree/bindings/net/snps,dwmac.yaml | 17 + > > > 1 file changed, 17 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > > index bdc437b14878..fcca23d3727e 100644 > > > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > > @@ -110,6 +110,23 @@ properties: > > >reset-names: > > > const: stmmaceth > > > > > > + ngpios: > > > +description: > > > + Total number of GPIOs the MAC supports. The property shall include > > > both > > > + the GPI and GPO ports width. > > > +minimum: 1 > > > +maximum: 32 > > > > > Does the driver actually need this? I'd omit it if just to validate > > consumers are in range. > > I can't say for all possible DW MAC IP-cores (I've got manuals for > GMAC and xGMAC only), but at least DW GMAC can't have more than four > GPIs and four GPOs, while XGMACs can be synthesized with up to 16 > each. That's why I've set the upper boundary here as 32. But the > driver uses the ngpios property do determine the total number GPIOs > the core has been synthesized. Th number of GPIs and GPOs will be > auto-detected then (by writing-reading to-from the GPI type field of > the GPIO control register). > > > > > Are GPI and GPO counts independent? If so, this isn't really sufficient. > > Yeap, they are independent. What do you suggest then? Define some > vendor-specific properties like snps,ngpis and snps,ngpos? If so then > they seem more generic than vendor-specific, because the separated > GPI and GPO space isn't an unique feature of the DW MAC GPIOs. Do we > need to create a generic version of such properties then? (That much > more changes then introduced here. We'd need to fix the dt-schema tool > too then.) > > -Sergey Rob, any comment on my questions above? As the kernel is in merge-window now, I just hope this part won't get pushed back in the emails log out of your sight. -Sergey > > > > > Rob
Re: [PATCH v7 1/3] usb: dwc3: qcom: Add missing DWC3 OF node refcount decrement
On Thu, Feb 18, 2021 at 04:32:29PM +0100, Greg Kroah-Hartman wrote: > On Thu, Feb 18, 2021 at 06:29:04PM +0300, Serge Semin wrote: > > Bjorn, Greg, Felippe, Andy, > > Any comments on this series? Bjorn, Greg you asked me to resend the > > patches related with the DW USB3 node name change. I did as you said, > > but no news since then. I'd be glad to have this patch accepted in > > some -next repo and forget about it. > > Sorry, but it's the merge window right now and I can't add anything new > until 5.12-rc1 is out. So can you wait until then? Well, I don't think there is another choice but to wait now.) Hopefully the patchset won't be forgotten when the merge window closes as that happened with the original series... -Sergey > > thanks, > > greg k-h
Re: [PATCH v7 1/3] usb: dwc3: qcom: Add missing DWC3 OF node refcount decrement
Bjorn, Greg, Felippe, Andy,
Any comments on this series? Bjorn, Greg you asked me to resend the
patches related with the DW USB3 node name change. I did as you said,
but no news since then. I'd be glad to have this patch accepted in
some -next repo and forget about it.
-Sergey
On Fri, Feb 12, 2021 at 11:55:19PM +0300, Serge Semin wrote:
> of_get_child_by_name() increments the reference counter of the OF node it
> managed to find. So after the code is done using the device node, the
> refcount must be decremented. Add missing of_node_put() invocation then
> to the dwc3_qcom_of_register_core() method, since DWC3 OF node is being
> used only there.
>
> Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
> Signed-off-by: Serge Semin
>
> ---
>
> Note the patch will get cleanly applied on the commit 2bc02355f8ba ("usb:
> dwc3: qcom: Add support for booting with ACPI"), while the bug has been
> there since the Qualcomm DWC3 glue driver was submitted.
>
> Changelog v7:
> - This is a new patch. Please drop it If I missed something and the OF
> node refcount decrement wasn't supposed to be there.
> ---
> drivers/usb/dwc3/dwc3-qcom.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index c703d552bbcf..3564d00cdce3 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -639,16 +639,19 @@ static int dwc3_qcom_of_register_core(struct
> platform_device *pdev)
> ret = of_platform_populate(np, NULL, NULL, dev);
> if (ret) {
> dev_err(dev, "failed to register dwc3 core - %d\n", ret);
> - return ret;
> + goto node_put;
> }
>
> qcom->dwc3 = of_find_device_by_node(dwc3_np);
> if (!qcom->dwc3) {
> + ret = -ENODEV;
> dev_err(dev, "failed to get dwc3 platform device\n");
> - return -ENODEV;
> }
>
> - return 0;
> +node_put:
> + of_node_put(dwc3_np);
> +
> + return ret;
> }
>
> static int dwc3_qcom_probe(struct platform_device *pdev)
> --
> 2.30.0
>
[PATCH v7 1/3] usb: dwc3: qcom: Add missing DWC3 OF node refcount decrement
of_get_child_by_name() increments the reference counter of the OF node it
managed to find. So after the code is done using the device node, the
refcount must be decremented. Add missing of_node_put() invocation then
to the dwc3_qcom_of_register_core() method, since DWC3 OF node is being
used only there.
Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
Signed-off-by: Serge Semin
---
Note the patch will get cleanly applied on the commit 2bc02355f8ba ("usb:
dwc3: qcom: Add support for booting with ACPI"), while the bug has been
there since the Qualcomm DWC3 glue driver was submitted.
Changelog v7:
- This is a new patch. Please drop it If I missed something and the OF
node refcount decrement wasn't supposed to be there.
---
drivers/usb/dwc3/dwc3-qcom.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index c703d552bbcf..3564d00cdce3 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -639,16 +639,19 @@ static int dwc3_qcom_of_register_core(struct
platform_device *pdev)
ret = of_platform_populate(np, NULL, NULL, dev);
if (ret) {
dev_err(dev, "failed to register dwc3 core - %d\n", ret);
- return ret;
+ goto node_put;
}
qcom->dwc3 = of_find_device_by_node(dwc3_np);
if (!qcom->dwc3) {
+ ret = -ENODEV;
dev_err(dev, "failed to get dwc3 platform device\n");
- return -ENODEV;
}
- return 0;
+node_put:
+ of_node_put(dwc3_np);
+
+ return ret;
}
static int dwc3_qcom_probe(struct platform_device *pdev)
--
2.30.0
[PATCH v7 2/3] usb: dwc3: qcom: Detect DWC3 DT-nodes using compatible string
In accordance with the USB HCD/DRD schema all the USB controllers are
supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the
existing DT-nodes will be renamed in a subsequent patch let's fix the DWC3
Qcom-specific code to detect the DWC3 sub-node just by checking its
compatible string to match the "snps,dwc3". The semantic of the code
won't change seeing all the DWC USB3 nodes are supposed to have the
compatible property with any of those strings set.
Signed-off-by: Serge Semin
---
Changelog v7:
- Replace "of_get_child_by_name(np, "usb") ?: of_get_child_by_name(np, "dwc3");"
pattern with using of_get_compatible_child() method.
- Discard Bjorn Andersson Reviewed-by tag since the patch content
has been changed.
---
drivers/usb/dwc3/dwc3-qcom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 3564d00cdce3..c8483becea5d 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -630,7 +630,7 @@ static int dwc3_qcom_of_register_core(struct
platform_device *pdev)
struct device *dev = >dev;
int ret;
- dwc3_np = of_get_child_by_name(np, "dwc3");
+ dwc3_np = of_get_compatible_child(np, "snps,dwc3");
if (!dwc3_np) {
dev_err(dev, "failed to find dwc3 core child\n");
return -ENODEV;
--
2.30.0
[PATCH v7 3/3] arm64: dts: qcom: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
Reviewed-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++--
arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++--
arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +-
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
9 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index defcbd15edf9..34e97da98270 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -1064,7 +1064,7 @@ {
status = "okay";
extcon = <_id>;
- dwc3@760 {
+ usb@760 {
extcon = <_id>;
dr_mode = "otg";
maximum-speed = "high-speed";
@@ -1075,7 +1075,7 @@ {
status = "okay";
extcon = <_id>;
- dwc3@6a0 {
+ usb@6a0 {
extcon = <_id>;
dr_mode = "otg";
};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index a32e5e79ab0b..7df4eb710aae 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -427,7 +427,7 @@ usb_0: usb@8af8800 {
resets = < GCC_USB0_BCR>;
status = "disabled";
- dwc_0: dwc3@8a0 {
+ dwc_0: usb@8a0 {
compatible = "snps,dwc3";
reg = <0x8a0 0xcd00>;
interrupts = ;
@@ -468,7 +468,7 @@ usb_1: usb@8cf8800 {
resets = < GCC_USB1_BCR>;
status = "disabled";
- dwc_1: dwc3@8c0 {
+ dwc_1: usb@8c0 {
compatible = "snps,dwc3";
reg = <0x8c0 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 7eef07e73e25..374bb7b557e4 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -1768,7 +1768,7 @@ usb3: usb@6af8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
- dwc3@6a0 {
+ usb@6a0 {
compatible = "snps,dwc3";
reg = <0x06a0 0xcc00>;
interrupts = <0 131 IRQ_TYPE_LEVEL_HIGH>;
@@ -1979,7 +1979,7 @@ usb2: usb@76f8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
- dwc3@760 {
+ usb@760 {
compatible = "snps,dwc3";
reg = <0x0760 0xcc00>;
interrupts = <0 138 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index ebdaaf1dfca4..1a7fb9d3ccab 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -1678,7 +1678,7 @@ usb3: usb@a8f8800 {
resets = < GCC_USB_30_BCR>;
- usb3_dwc3: dwc3@a80 {
+ usb3_dwc3: usb@a80 {
compatible = "snps,dwc3";
reg = <0x0a80 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index a80c578484ba..f8a55307b855 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -337,7 +337,7 @@ _phy_sec {
{
status = "okay";
- dwc3@758 {
+ usb@758 {
dr_mode = "host";
};
};
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
inde
Re: [PATCH v6 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
On Fri, Feb 12, 2021 at 11:49:15AM -0600, Bjorn Andersson wrote: > On Wed 10 Feb 13:33 CST 2021, Serge Semin wrote: > > > On Wed, Feb 10, 2021 at 12:56:59PM -0600, Bjorn Andersson wrote: > > > On Wed 10 Feb 12:40 CST 2021, Serge Semin wrote: > > > > > > > On Wed, Feb 10, 2021 at 12:17:27PM -0600, Rob Herring wrote: > > > > > On Wed, Feb 10, 2021 at 11:29 AM Serge Semin > > > > > wrote: > > > > > > > > > > > > In accordance with the USB HCD/DRD schema all the USB controllers > > > > > > are > > > > > > supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the > > > > > > existing DT-nodes will be renamed in a subsequent patch let's first > > > > > > make > > > > > > sure the DWC3 Qualcomm driver supports them and second falls back > > > > > > to the > > > > > > deprecated naming so not to fail on the legacy DTS-files passed to > > > > > > the > > > > > > newer kernels. > > > > > > > > > > > > Signed-off-by: Serge Semin > > > > > > Reviewed-by: Bjorn Andersson > > > > > > --- > > > > > > drivers/usb/dwc3/dwc3-qcom.c | 3 ++- > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c > > > > > > b/drivers/usb/dwc3/dwc3-qcom.c > > > > > > index c703d552bbcf..49ad8d507d37 100644 > > > > > > --- a/drivers/usb/dwc3/dwc3-qcom.c > > > > > > +++ b/drivers/usb/dwc3/dwc3-qcom.c > > > > > > @@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct > > > > > > platform_device *pdev) > > > > > > struct device *dev = >dev; > > > > > > int ret; > > > > > > > > > > > > - dwc3_np = of_get_child_by_name(np, "dwc3"); > > > > > > + dwc3_np = of_get_child_by_name(np, "usb") ?: > > > > > > + of_get_child_by_name(np, "dwc3"); > > > > > > > > > > > > > > Is there some reason using compatible instead wouldn't work here? > > > > > > > > I don't know for sure. The fix has been requested in the framework of > > > > this discussion: > > > > https://lore.kernel.org/linux-usb/20201020115959.2658-30-sergey.se...@baikalelectronics.ru/#t > > > > by the driver maintainer Bjorn. To get a firm answer it's better to > > > > have him asked. > > > > > > My feedback was simply that it has to catch both cases, I didn't > > > consider the fact that we have a compatible to match against. > > > > > > > As I see it having of_get_compatible_child() utilized > > > > here would also work. At least for the available in kernel dt-files. > > > > See the affected dts-es in: > > > > https://lore.kernel.org/linux-usb/20210210172850.20849-11-sergey.se...@baikalelectronics.ru/ > > > > > > > > A problem may happen if some older versions of DTS-es had another > > > > compatible string in the dwc3 sub-node... > > > > > > > > > > Afaict all Qualcomm dts files has "snps,dwc3", so you can match against > > > that instead. > > > > Ok then. I'll replace of_get_child_by_name() here with > > of_get_compatible_child() matching just against "snps,dwc3" in v7. Can you > > confirm that noone ever had a Qcom-based hardware described with dts having > > the "synopsys,dwc3" compatible used as the DWC USB3 sub-node here? That > > string has been marked as deprecated recently because the vendor-prefix > > was changed sometime ago, but the original driver still accept it. > > > > I don't see any Qualcomm users of "synopsys,dwc3", past or present. > > > Alternatively to be on a safe side we could match against both > > compatibles here as Rob suggests. What do you think? > > > > Let's go with only "snps,dwc3". Ok. Thanks. I'll resend just two patches in ten minutes. -Sergey > > Regards, > Bjorn
Re: [PATCH v6 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
On Wed, Feb 10, 2021 at 10:33:26PM +0300, Serge Semin wrote: > On Wed, Feb 10, 2021 at 12:56:59PM -0600, Bjorn Andersson wrote: > > On Wed 10 Feb 12:40 CST 2021, Serge Semin wrote: > > > > > On Wed, Feb 10, 2021 at 12:17:27PM -0600, Rob Herring wrote: > > > > On Wed, Feb 10, 2021 at 11:29 AM Serge Semin > > > > wrote: > > > > > > > > > > In accordance with the USB HCD/DRD schema all the USB controllers are > > > > > supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the > > > > > existing DT-nodes will be renamed in a subsequent patch let's first > > > > > make > > > > > sure the DWC3 Qualcomm driver supports them and second falls back to > > > > > the > > > > > deprecated naming so not to fail on the legacy DTS-files passed to the > > > > > newer kernels. > > > > > > > > > > Signed-off-by: Serge Semin > > > > > Reviewed-by: Bjorn Andersson > > > > > --- > > > > > drivers/usb/dwc3/dwc3-qcom.c | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c > > > > > b/drivers/usb/dwc3/dwc3-qcom.c > > > > > index c703d552bbcf..49ad8d507d37 100644 > > > > > --- a/drivers/usb/dwc3/dwc3-qcom.c > > > > > +++ b/drivers/usb/dwc3/dwc3-qcom.c > > > > > @@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct > > > > > platform_device *pdev) > > > > > struct device *dev = >dev; > > > > > int ret; > > > > > > > > > > - dwc3_np = of_get_child_by_name(np, "dwc3"); > > > > > + dwc3_np = of_get_child_by_name(np, "usb") ?: > > > > > + of_get_child_by_name(np, "dwc3"); > > > > > > > > > > > Is there some reason using compatible instead wouldn't work here? > > > > > > I don't know for sure. The fix has been requested in the framework of > > > this discussion: > > > https://lore.kernel.org/linux-usb/20201020115959.2658-30-sergey.se...@baikalelectronics.ru/#t > > > by the driver maintainer Bjorn. To get a firm answer it's better to > > > have him asked. > > > > My feedback was simply that it has to catch both cases, I didn't > > consider the fact that we have a compatible to match against. > > > > > As I see it having of_get_compatible_child() utilized > > > here would also work. At least for the available in kernel dt-files. > > > See the affected dts-es in: > > > https://lore.kernel.org/linux-usb/20210210172850.20849-11-sergey.se...@baikalelectronics.ru/ > > > > > > A problem may happen if some older versions of DTS-es had another > > > compatible string in the dwc3 sub-node... > > > > > > > Afaict all Qualcomm dts files has "snps,dwc3", so you can match against > > that instead. > > Ok then. I'll replace of_get_child_by_name() here with > of_get_compatible_child() matching just against "snps,dwc3" in v7. Can you > confirm that noone ever had a Qcom-based hardware described with dts having > the "synopsys,dwc3" compatible used as the DWC USB3 sub-node here? That > string has been marked as deprecated recently because the vendor-prefix > was changed sometime ago, but the original driver still accept it. > > Alternatively to be on a safe side we could match against both > compatibles here as Rob suggests. What do you think? Bjorn, any comment on the question above? So I could respin the series with this patch updated. Also note, since the patch's gonna be changed I'll have to remove your Reviewed-by tag unless u explicitly say I shouldn't. -Sergey > > -Sergey > > > > > Regards, > > Bjorn
Re: [PATCH] mtd: physmap: physmap-bt1-rom: Fix unintentional stack access
On Fri, Feb 12, 2021 at 04:40:22AM -0600, Gustavo A. R. Silva wrote:
> Cast to (char *) in order to avoid unintentionally accessing
> the stack.
>
> Notice that data is of type u32, so any increment to
> will be in the order of 4-byte chunks, and this piece of code
> is actually intended to be a byte offset.
Thanks, one more time.)
Acked-by: Serge Semin
>
> Fixes: b3e79e7682e0 ("mtd: physmap: Add Baikal-T1 physically mapped ROM
> support")
> Addresses-Coverity-ID: 1497765 ("Out-of-bounds access")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/mtd/maps/physmap-bt1-rom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/maps/physmap-bt1-rom.c
> b/drivers/mtd/maps/physmap-bt1-rom.c
> index a35450002284..58782cfaf71c 100644
> --- a/drivers/mtd/maps/physmap-bt1-rom.c
> +++ b/drivers/mtd/maps/physmap-bt1-rom.c
> @@ -79,7 +79,7 @@ static void __xipram bt1_rom_map_copy_from(struct map_info
> *map,
> if (shift) {
> chunk = min_t(ssize_t, 4 - shift, len);
> data = readl_relaxed(src - shift);
> - memcpy(to, + shift, chunk);
> + memcpy(to, (char *) + shift, chunk);
> src += chunk;
> to += chunk;
> len -= chunk;
> --
> 2.27.0
>
Re: [PATCH] spi: dw: Avoid stack content exposure
On Thu, Feb 11, 2021 at 12:37:14PM -0800, Kees Cook wrote:
> Since "data" is u32, is a "u32 *" type, which means pointer math
> will move in u32-sized steps. This was meant to be a byte offset, so
> cast to "char *" to aim the copy into the correct location.
>
> Seen with -Warray-bounds (and found by Coverity):
>
> In file included from ./include/linux/string.h:269,
> from ./arch/powerpc/include/asm/paca.h:15,
> from ./arch/powerpc/include/asm/current.h:13,
> from ./include/linux/mutex.h:14,
> from ./include/linux/notifier.h:14,
> from ./include/linux/clk.h:14,
> from drivers/spi/spi-dw-bt1.c:12:
> In function 'memcpy',
> inlined from 'dw_spi_bt1_dirmap_copy_from_map' at
> drivers/spi/spi-dw-bt1.c:87:3:
> ./include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset 4
> is out of the bounds [0, 4] of object 'data' with type 'u32' {aka 'unsigned
> int'} [-Warray-bounds]
>20 | #define __underlying_memcpy __builtin_memcpy
> | ^
> ./include/linux/fortify-string.h:191:9: note: in expansion of macro
> '__underlying_memcpy'
> 191 | return __underlying_memcpy(p, q, size);
> | ^~~
> drivers/spi/spi-dw-bt1.c: In function 'dw_spi_bt1_dirmap_copy_from_map':
> drivers/spi/spi-dw-bt1.c:77:6: note: 'data' declared here
>77 | u32 data;
> | ^~~~
Can't believe I missed that. Thanks!
Acked-by: Serge Semin
>
> Addresses-Coverity: CID 1497771 Out-of-bounds access
> Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver")
> Signed-off-by: Kees Cook
> ---
> drivers/spi/spi-dw-bt1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-dw-bt1.c b/drivers/spi/spi-dw-bt1.c
> index 4aa8596fb1f2..5be6b7b80c21 100644
> --- a/drivers/spi/spi-dw-bt1.c
> +++ b/drivers/spi/spi-dw-bt1.c
> @@ -84,7 +84,7 @@ static void dw_spi_bt1_dirmap_copy_from_map(void *to, void
> __iomem *from, size_t
> if (shift) {
> chunk = min_t(size_t, 4 - shift, len);
> data = readl_relaxed(from - shift);
> - memcpy(to, + shift, chunk);
> + memcpy(to, (char *) + shift, chunk);
> from += chunk;
> to += chunk;
> len -= chunk;
> --
> 2.25.1
>
Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode
On Thu, Feb 11, 2021 at 10:39:41AM +, Russell King - ARM Linux admin wrote:
> On Wed, Feb 10, 2021 at 07:47:20PM +0300, Serge Semin wrote:
> > On Tue, Feb 09, 2021 at 10:56:46AM +, Russell King - ARM Linux admin
> > wrote:
> > > On Tue, Feb 09, 2021 at 11:37:29AM +0100, Heiner Kallweit wrote:
> > > > Right, adding something like a genphy_{read,write}_mmd() doesn't make
> > > > too much sense for now. What I meant is just exporting
> > > > mmd_phy_indirect().
> > > > Then you don't have to open-code the first three steps of a mmd
> > > > read/write.
> > > > And it requires no additional code in phylib.
> > >
> > > ... but at the cost that the compiler can no longer inline that code,
> > > as I mentioned in my previous reply. (However, the cost of the accesses
> > > will be higher.) On the plus side, less I-cache footprint, and smaller
> > > kernel code.
> >
> > Just to note mmd_phy_indirect() isn't defined with inline specifier,
> > but just as static and it's used twice in the
> > drivers/net/phy/phy-core.c unit. So most likely the compiler won't
> > inline the function code in there.
>
> You can't always tell whether the compiler will inline a static function
> or not.
>
> > Anyway it's up to the PHY
> > library maintainers to decide. Please settle the issue with Heiner and
> > Andrew then. I am ok with both solutions and will do as you decide.
>
> FYI, *I* am one of the phylib maintainers.
Of course I saw you in the list of maintainers. My message was that
currently two maintainers claims contradicting requests. Thus in order
to go further with this patch first you need to get to some agreement
between yourself. That's why we need to have a response from Hainer
about your arguments against his suggestion.
-Sergey
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH 01/16] dt-bindings: net: dwmac: Add DW GMAC GPIOs properties
On Tue, Feb 09, 2021 at 05:13:52PM -0600, Rob Herring wrote: > On Mon, Feb 08, 2021 at 05:08:05PM +0300, Serge Semin wrote: > > Synopsys DesignWare Ethernet controllers can be synthesized with > > General-Purpose IOs support. GPIOs can work either as inputs or as outputs > > thus belong to the gpi_i and gpo_o ports respectively. The ports width > > (number of possible inputs/outputs) and the configuration registers layout > > depend on the IP-core version. For instance, DW GMAC can have from 0 to 4 > > GPIs and from 0 to 4 GPOs, while DW xGMAC have a wider ports width up to > > 16 pins of each one. > > > > So the DW MAC DT-node can be equipped with "ngpios" property, which can't > > have a value greater than 32, standard GPIO-related properties like > > "gpio-controller" and "#gpio-cells", and, if GPIs are supposed to be > > detected, IRQ-controller related properties. > > > > Signed-off-by: Serge Semin > > --- > > .../devicetree/bindings/net/snps,dwmac.yaml | 17 + > > 1 file changed, 17 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > index bdc437b14878..fcca23d3727e 100644 > > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > @@ -110,6 +110,23 @@ properties: > >reset-names: > > const: stmmaceth > > > > + ngpios: > > +description: > > + Total number of GPIOs the MAC supports. The property shall include > > both > > + the GPI and GPO ports width. > > +minimum: 1 > > +maximum: 32 > > Does the driver actually need this? I'd omit it if just to validate > consumers are in range. I can't say for all possible DW MAC IP-cores (I've got manuals for GMAC and xGMAC only), but at least DW GMAC can't have more than four GPIs and four GPOs, while XGMACs can be synthesized with up to 16 each. That's why I've set the upper boundary here as 32. But the driver uses the ngpios property do determine the total number GPIOs the core has been synthesized. Th number of GPIs and GPOs will be auto-detected then (by writing-reading to-from the GPI type field of the GPIO control register). > > Are GPI and GPO counts independent? If so, this isn't really sufficient. Yeap, they are independent. What do you suggest then? Define some vendor-specific properties like snps,ngpis and snps,ngpos? If so then they seem more generic than vendor-specific, because the separated GPI and GPO space isn't an unique feature of the DW MAC GPIOs. Do we need to create a generic version of such properties then? (That much more changes then introduced here. We'd need to fix the dt-schema tool too then.) -Sergey > > Rob
Re: [PATCH v2 16/24] net: stmmac: Use optional reset control API to work with stmmaceth
On Wed, Feb 10, 2021 at 02:49:24PM +0800, Jisheng Zhang wrote:
> Hi,
>
> On Mon, 8 Feb 2021 16:56:00 +0300 Serge Semin wrote:
>
>
> >
> > Since commit bb3222f71b57 ("net: stmmac: platform: use optional clk/reset
> > get APIs") a manual implementation of the optional device reset control
> > functionality has been replaced with using the
> > devm_reset_control_get_optional() method. But for some reason the optional
> > reset control handler usage hasn't been fixed and preserved the
> > NULL-checking statements. There is no need in that in order to perform the
> > reset control assertion/deassertion because the passed NULL will be
> > considered by the reset framework as absent optional reset control handler
> > anyway.
> >
> > Fixes: bb3222f71b57 ("net: stmmac: platform: use optional clk/reset get
> > APIs")
>
> The patch itself looks good, but the Fix tag isn't necessary since the
> patch is a clean up rather than a bug fix. Can you please drop it in next
> version?
Ok. I'll remove it.
-Sergey
>
> Thanks
>
> > Signed-off-by: Serge Semin
> > ---
> > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ---
> > 1 file changed, 8 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > index 4f1bf8f6538b..a8dec219c295 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > @@ -4935,15 +4935,13 @@ int stmmac_dvr_probe(struct device *device,
> > if ((phyaddr >= 0) && (phyaddr <= 31))
> > priv->plat->phy_addr = phyaddr;
> >
> > - if (priv->plat->stmmac_rst) {
> > - ret = reset_control_assert(priv->plat->stmmac_rst);
> > - reset_control_deassert(priv->plat->stmmac_rst);
> > - /* Some reset controllers have only reset callback instead
> > of
> > -* assert + deassert callbacks pair.
> > -*/
> > - if (ret == -ENOTSUPP)
> > - reset_control_reset(priv->plat->stmmac_rst);
> > - }
> > + ret = reset_control_assert(priv->plat->stmmac_rst);
> > + reset_control_deassert(priv->plat->stmmac_rst);
> > + /* Some reset controllers have only reset callback instead of
> > +* assert + deassert callbacks pair.
> > +*/
> > + if (ret == -ENOTSUPP)
> > + reset_control_reset(priv->plat->stmmac_rst);
> >
> > /* Init MAC and get the capabilities */
> > ret = stmmac_hw_init(priv);
> > @@ -5155,8 +5153,7 @@ int stmmac_dvr_remove(struct device *dev)
> > stmmac_exit_fs(ndev);
> > #endif
> > phylink_destroy(priv->phylink);
> > - if (priv->plat->stmmac_rst)
> > - reset_control_assert(priv->plat->stmmac_rst);
> > + reset_control_assert(priv->plat->stmmac_rst);
> > if (priv->hw->pcs != STMMAC_PCS_TBI &&
> > priv->hw->pcs != STMMAC_PCS_RTBI)
> > stmmac_mdio_unregister(ndev);
> > --
> > 2.29.2
> >
>
Re: [PATCH v2 07/24] dt-bindings: net: dwmac: Detach Generic DW MAC bindings
On Tue, Feb 09, 2021 at 04:32:58PM -0600, Rob Herring wrote: > On Mon, Feb 08, 2021 at 04:55:51PM +0300, Serge Semin wrote: > > Currently the snps,dwmac.yaml DT bindings file is used for both DT nodes > > describing generic DW MAC devices and as DT schema with common properties > > to be evaluated against a vendor-specific DW MAC IP-cores. Due to such > > dual-purpose design the "compatible" property of the common DW MAC schema > > needs to contain the vendor-specific strings to successfully pass the > > schema evaluation in case if it's referenced from the vendor-specific DT > > bindings. That's a bad design from maintainability point of view, since > > adding/removing any DW MAC-based device bindings requires the common > > schema modification. In order to fix that let's detach the schema which > > provides the generic DW MAC DT nodes evaluation into a dedicated DT > > bindings file preserving the common DW MAC properties declaration in the > > snps,dwmac.yaml file. By doing so we'll still provide a common properties > > evaluation for each vendor-specific MAC bindings which refer to the > > common bindings file, while the generic DW MAC DT nodes will be checked > > against the new snps,dwmac-generic.yaml DT schema. > > > > Signed-off-by: Serge Semin > > > > --- > > > > Changelog v2: > > - Add a note to the snps,dwmac-generic.yaml bindings file description of > > a requirement to create a new DT bindings file for the vendor-specific > > versions of the DW MAC. > > --- > > .../bindings/net/snps,dwmac-generic.yaml | 154 ++ > > .../devicetree/bindings/net/snps,dwmac.yaml | 139 +--- > > 2 files changed, 155 insertions(+), 138 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml > > > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml > > b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml > > new file mode 100644 > > index ..6c3bf5b2f890 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml > > @@ -0,0 +1,154 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/net/snps,dwmac-generic.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Synopsys DesignWare Generic MAC Device Tree Bindings > > + > > +maintainers: > > + - Alexandre Torgue > > + - Giuseppe Cavallaro > > + - Jose Abreu > > + > > +description: > > + The primary purpose of this bindings file is to validate the Generic > > + Synopsys Desginware MAC DT nodes defined in accordance with the select > > + schema. All new vendor-specific versions of the DW *MAC IP-cores must > > + be described in a dedicated DT bindings file. > > + > > +# Select the DT nodes, which have got compatible strings either as just a > > +# single string with IP-core name optionally followed by the IP version or > > +# two strings: one with IP-core name plus the IP version, another as just > > +# the IP-core name. > > +select: > > + properties: > > +compatible: > > + oneOf: > > +- items: > > +- pattern: "^snps,dw(xg)+mac(-[0-9]+\\.[0-9]+a?)?$" > > Use '' instead of "" and you can skip the double \. > > With that, > > Reviewed-by: Rob Herring Got it. Thanks. -Sergey > > > +- items: > > +- pattern: "^snps,dwmac-[0-9]+\\.[0-9]+a?$" > > +- const: snps,dwmac > > +- items: > > +- pattern: "^snps,dwxgmac-[0-9]+\\.[0-9]+a?$" > > +- const: snps,dwxgmac
Re: [PATCH v2 04/24] dt-bindings: net: dwmac: Refactor snps,*-config properties
On Tue, Feb 09, 2021 at 04:26:08PM -0600, Rob Herring wrote: > On Mon, Feb 08, 2021 at 04:55:48PM +0300, Serge Semin wrote: > > Currently the "snps,axi-config", "snps,mtl-rx-config" and > > "snps,mtl-tx-config" properties are declared as a single phandle reference > > to a node with corresponding parameters defined. That's not good for > > several reasons. First of all scattering around a device tree some > > particular device-specific configs with no visual relation to that device > > isn't suitable from maintainability point of view. That leads to a > > disturbed representation of the actual device tree mixing actual device > > nodes and some vendor-specific configs. Secondly using the same configs > > set for several device nodes doesn't represent well the devices structure, > > since the interfaces these configs describe in hardware belong to > > different devices and may actually differ. In the later case having the > > configs node separated from the corresponding device nodes gets to be > > even unjustified. > > > > So instead of having a separate DW *MAC configs nodes we suggest to > > define them as sub-nodes of the device nodes, which interfaces they > > actually describe. By doing so we'll make the DW *MAC nodes visually > > correct describing all the aspects of the IP-core configuration. Thus > > we'll be able to describe the configs sub-nodes bindings right in the > > snps,dwmac.yaml file. > > > > Note the former "snps,axi-config", "snps,mtl-rx-config" and > > "snps,mtl-tx-config" properties have been marked as deprecated in favor of > > the added by this commit "axi-config", "mtl-rx-config" and "mtl-tx-config" > > sub-nodes respectively. > > > > Signed-off-by: Serge Semin > > > > --- > > > > Note this change will work only if DT-schema tool is fixed like this: > > > > --- a/meta-schemas/nodes.yaml 2021-02-08 14:20:56.732447780 +0300 > > +++ b/meta-schemas/nodes.yaml 2021-02-08 14:21:00.736492245 +0300 > > @@ -22,6 +22,7 @@ > > - unevaluatedProperties > > - deprecated > > - required > > +- not > > - allOf > > - anyOf > > - oneOf > > Can you send me a patch or GH PR. There is another way to express. More > below. Ok. I'll send a patch. To what email and mailing lists shall I send it to? > > > > > So a property with name "not" would be allowed and the "not-required" > > pattern would work. > > > > Changelog v2: > > - Add the new sub-nodes "axi-config", "mtl-rx-config" and "mtl-tx-config" > > describing the nodes now deprecated properties were supposed to > > refer to. > > - Fix invalid identation in the "snps,route-*" property settings. > > - Use correct syntax of the JSON pointers, so the later would begin > > with a '/' after the '#'. > > --- > > .../devicetree/bindings/net/snps,dwmac.yaml | 389 +- > > 1 file changed, 297 insertions(+), 92 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > index 03d58bf9965f..4dda9ffa822c 100644 > > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > > @@ -150,73 +150,264 @@ properties: > >in a different mode than the PHY in order to function. > > > >snps,axi-config: > > +deprecated: true > > $ref: /schemas/types.yaml#/definitions/phandle > > description: > > - AXI BUS Mode parameters. Phandle to a node that can contain the > > - following properties > > -* snps,lpi_en, enable Low Power Interface > > -* snps,xit_frm, unlock on WoL > > -* snps,wr_osr_lmt, max write outstanding req. limit > > -* snps,rd_osr_lmt, max read outstanding req. limit > > -* snps,kbbe, do not cross 1KiB boundary. > > -* snps,blen, this is a vector of supported burst length. > > -* snps,fb, fixed-burst > > -* snps,mb, mixed-burst > > -* snps,rb, rebuild INCRx Burst > > + AXI BUS Mode parameters. Phandle to a node that contains the > > properties > > + described in the 'axi-config' sub-node. > > + > > + axi-config: > > +type: object > > +description: AXI BUS Mode parameters > > + > > +properties: > > +
Re: [PATCH v6 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
On Wed, Feb 10, 2021 at 12:56:59PM -0600, Bjorn Andersson wrote: > On Wed 10 Feb 12:40 CST 2021, Serge Semin wrote: > > > On Wed, Feb 10, 2021 at 12:17:27PM -0600, Rob Herring wrote: > > > On Wed, Feb 10, 2021 at 11:29 AM Serge Semin > > > wrote: > > > > > > > > In accordance with the USB HCD/DRD schema all the USB controllers are > > > > supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the > > > > existing DT-nodes will be renamed in a subsequent patch let's first make > > > > sure the DWC3 Qualcomm driver supports them and second falls back to the > > > > deprecated naming so not to fail on the legacy DTS-files passed to the > > > > newer kernels. > > > > > > > > Signed-off-by: Serge Semin > > > > Reviewed-by: Bjorn Andersson > > > > --- > > > > drivers/usb/dwc3/dwc3-qcom.c | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c > > > > index c703d552bbcf..49ad8d507d37 100644 > > > > --- a/drivers/usb/dwc3/dwc3-qcom.c > > > > +++ b/drivers/usb/dwc3/dwc3-qcom.c > > > > @@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct > > > > platform_device *pdev) > > > > struct device *dev = >dev; > > > > int ret; > > > > > > > > - dwc3_np = of_get_child_by_name(np, "dwc3"); > > > > + dwc3_np = of_get_child_by_name(np, "usb") ?: > > > > + of_get_child_by_name(np, "dwc3"); > > > > > > > > Is there some reason using compatible instead wouldn't work here? > > > > I don't know for sure. The fix has been requested in the framework of > > this discussion: > > https://lore.kernel.org/linux-usb/20201020115959.2658-30-sergey.se...@baikalelectronics.ru/#t > > by the driver maintainer Bjorn. To get a firm answer it's better to > > have him asked. > > My feedback was simply that it has to catch both cases, I didn't > consider the fact that we have a compatible to match against. > > > As I see it having of_get_compatible_child() utilized > > here would also work. At least for the available in kernel dt-files. > > See the affected dts-es in: > > https://lore.kernel.org/linux-usb/20210210172850.20849-11-sergey.se...@baikalelectronics.ru/ > > > > A problem may happen if some older versions of DTS-es had another > > compatible string in the dwc3 sub-node... > > > > Afaict all Qualcomm dts files has "snps,dwc3", so you can match against > that instead. Ok then. I'll replace of_get_child_by_name() here with of_get_compatible_child() matching just against "snps,dwc3" in v7. Can you confirm that noone ever had a Qcom-based hardware described with dts having the "synopsys,dwc3" compatible used as the DWC USB3 sub-node here? That string has been marked as deprecated recently because the vendor-prefix was changed sometime ago, but the original driver still accept it. Alternatively to be on a safe side we could match against both compatibles here as Rob suggests. What do you think? -Sergey > > Regards, > Bjorn
Re: [PATCH RESEND v6 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
On Wed, Feb 10, 2021 at 10:21:47AM -0800, Florian Fainelli wrote:
> On 2/10/21 9:28 AM, Serge Semin wrote:
> > As the subject states this series is an attempt to harmonize the xHCI,
> > EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
> > framework of the patchset [1].
> >
> > Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
> > controllers with "synopsys,"-vendor prefix compatible string in favor of
> > the ones with valid "snps,"-prefix. It's done in all the DTS files,
> > which have been unfortunate to define such nodes.
> >
> > Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
> > declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
> > been erroneously declared as boolean while having uint32 type. Neil said
> > it was ok to init that property with 0x20 value.
> >
> > Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
> > and DWC USB3 DT nodes name as in accordance with their DT schema the
> > corresponding node name is suppose to comply with the Generic USB HCD DT
> > schema, which requires the USB nodes to have the name acceptable by the
> > regexp: "^usb(@.*)?". Such requirement had been applicable even before we
> > introduced the new DT schema in [1], but as we can see it hasn't been
> > strictly implemented for a lot the DTS files. Since DT schema is now
> > available the automated DTS validation shall make sure that the rule isn't
> > violated.
> >
> > Note most of these patches have been a part of the last three patches of
> > [1]. But since there is no way to have them merged in in a combined
> > manner, I had to move them to the dedicated series and split them up so to
> > be accepted by the corresponding subsystem maintainers one-by-one.
> >
> > [1] Link:
> > https://lore.kernel.org/linux-usb/20201014101402.18271-1-sergey.se...@baikalelectronics.ru/
> > Changelog v1:
> > - As Krzysztof suggested I've created a script which checked whether the
> > node names had been also updated in all the depended dts files. As a
> > result I found two more files which should have been also modified:
> > arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
> > - Correct the USB DWC3 nodes name found in
> > arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.
> >
> > Link:
> > https://lore.kernel.org/linux-usb/20201020115959.2658-1-sergey.se...@baikalelectronics.ru
> > Changelog v2:
> > - Drop the patch:
> > [PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
> > and get back the one which marks the "synopsys,dwc3" compatible string
> > as deprecated into the DT schema related series.
> > - Drop the patches:
> > [PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
> > [PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
> > [PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
> > [PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
> > [PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
> > [PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
> > [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
> > [PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
> > [PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
> > [PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
> > [PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
> > since they have been applied to the corresponding maintainers repos.
> > - Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
> > sub-node and falling back to the "dwc3@"-prefixed one on failure.
> >
> > Link:
> > https://lore.kernel.org/linux-usb/2020091552.15593-1-sergey.se...@baikalelectronics.ru
> > Changelog v3:
> > - Drop the patches:
> > [PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
> > [PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
> > [PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
> > [PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
> > [PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes
> > name
> > [PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
> > [PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT
> > nodes name
> > [PATCH v2 16/18] arm64:
Re: [PATCH v6 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
On Wed, Feb 10, 2021 at 12:17:27PM -0600, Rob Herring wrote: > On Wed, Feb 10, 2021 at 11:29 AM Serge Semin > wrote: > > > > In accordance with the USB HCD/DRD schema all the USB controllers are > > supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the > > existing DT-nodes will be renamed in a subsequent patch let's first make > > sure the DWC3 Qualcomm driver supports them and second falls back to the > > deprecated naming so not to fail on the legacy DTS-files passed to the > > newer kernels. > > > > Signed-off-by: Serge Semin > > Reviewed-by: Bjorn Andersson > > --- > > drivers/usb/dwc3/dwc3-qcom.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c > > index c703d552bbcf..49ad8d507d37 100644 > > --- a/drivers/usb/dwc3/dwc3-qcom.c > > +++ b/drivers/usb/dwc3/dwc3-qcom.c > > @@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct > > platform_device *pdev) > > struct device *dev = >dev; > > int ret; > > > > - dwc3_np = of_get_child_by_name(np, "dwc3"); > > + dwc3_np = of_get_child_by_name(np, "usb") ?: > > + of_get_child_by_name(np, "dwc3"); > > Is there some reason using compatible instead wouldn't work here? I don't know for sure. The fix has been requested in the framework of this discussion: https://lore.kernel.org/linux-usb/20201020115959.2658-30-sergey.se...@baikalelectronics.ru/#t by the driver maintainer Bjorn. To get a firm answer it's better to have him asked. As I see it having of_get_compatible_child() utilized here would also work. At least for the available in kernel dt-files. See the affected dts-es in: https://lore.kernel.org/linux-usb/20210210172850.20849-11-sergey.se...@baikalelectronics.ru/ A problem may happen if some older versions of DTS-es had another compatible string in the dwc3 sub-node... -Sergey > > Rob
Re: [PATCH 00/16] net: stmmac: Add DW MAC GPIOs and Baikal-T1 GMAC support
On Tue, Feb 09, 2021 at 03:11:41PM +0100, Andrew Lunn wrote: > > Regarding splitting the series up. I don't see a problem in just > > sending the cover-letter patch and actual GPIO-related patches to > > the GPIO-maintainers with no need to have them added to Cc in the rest > > of the series. > > The Linux community has to handle a large number of patches. I don't > particularly want patches which are of no relevance to me landing in > my mailbox. It might take 4 or 5 rounds for the preparation patches to > be accepted. That is 4 or 5 times you are spamming the GPIO > maintainers with stuff which is not relevant to them. I don't really understand what you are arguing with. My suggestion didn't contradict to what you said. I exactly meant to omit sending the patches to GPIO maintainers, which they had no relevance to. So they wouldn't be spammed with unwanted patches. The GPIO maintainers can be Cc/To-ed only to the messages with GPIO-related patches. It's normal to have intermixed patchsets, but to post individual patches to the maintainers they might be interested in or they need to review. So splitting up isn't required in this case. Moreover doing as you suggest would extend the time of the patches review with no really much gain in the emailing activity optimization. > > One of the unfortunately things about the kernel process is, there are > a lot of developers, and not many maintainers. So the processes need > to make the life of maintainers easier, and not spamming them helps. Can't argue with that.) -Sergey > >Andrew
[PATCH v6 10/10] arm64: dts: qcom: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
Reviewed-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++--
arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++--
arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +-
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
9 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index defcbd15edf9..34e97da98270 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -1064,7 +1064,7 @@ {
status = "okay";
extcon = <_id>;
- dwc3@760 {
+ usb@760 {
extcon = <_id>;
dr_mode = "otg";
maximum-speed = "high-speed";
@@ -1075,7 +1075,7 @@ {
status = "okay";
extcon = <_id>;
- dwc3@6a0 {
+ usb@6a0 {
extcon = <_id>;
dr_mode = "otg";
};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index a32e5e79ab0b..7df4eb710aae 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -427,7 +427,7 @@ usb_0: usb@8af8800 {
resets = < GCC_USB0_BCR>;
status = "disabled";
- dwc_0: dwc3@8a0 {
+ dwc_0: usb@8a0 {
compatible = "snps,dwc3";
reg = <0x8a0 0xcd00>;
interrupts = ;
@@ -468,7 +468,7 @@ usb_1: usb@8cf8800 {
resets = < GCC_USB1_BCR>;
status = "disabled";
- dwc_1: dwc3@8c0 {
+ dwc_1: usb@8c0 {
compatible = "snps,dwc3";
reg = <0x8c0 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 7eef07e73e25..374bb7b557e4 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -1768,7 +1768,7 @@ usb3: usb@6af8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
- dwc3@6a0 {
+ usb@6a0 {
compatible = "snps,dwc3";
reg = <0x06a0 0xcc00>;
interrupts = <0 131 IRQ_TYPE_LEVEL_HIGH>;
@@ -1979,7 +1979,7 @@ usb2: usb@76f8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
- dwc3@760 {
+ usb@760 {
compatible = "snps,dwc3";
reg = <0x0760 0xcc00>;
interrupts = <0 138 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index ebdaaf1dfca4..1a7fb9d3ccab 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -1678,7 +1678,7 @@ usb3: usb@a8f8800 {
resets = < GCC_USB_30_BCR>;
- usb3_dwc3: dwc3@a80 {
+ usb3_dwc3: usb@a80 {
compatible = "snps,dwc3";
reg = <0x0a80 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index a80c578484ba..f8a55307b855 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -337,7 +337,7 @@ _phy_sec {
{
status = "okay";
- dwc3@758 {
+ usb@758 {
dr_mode = "host";
};
};
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
inde
[PATCH v6 05/10] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
---
arch/powerpc/boot/dts/akebono.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/akebono.dts
b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@301 {
interrupts = <93 2>;
};
- EHCI0: ehci@3001000 {
+ EHCI0: usb@3001000 {
compatible = "ibm,476gtr-ehci", "generic-ehci";
reg = <0x300 0x1000 0x0 0x1>;
interrupt-parent = <>;
@@ -140,14 +140,14 @@ SD0: sd@300 {
interrupt-parent = <>;
};
- OHCI0: ohci@3001001 {
+ OHCI0: usb@3001001 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1001 0x0 0x1>;
interrupt-parent = <>;
interrupts = <89 1>;
};
- OHCI1: ohci@3001002 {
+ OHCI1: usb@3001002 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1002 0x0 0x1>;
interrupt-parent = <>;
--
2.30.0
[PATCH v6 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
In accordance with the USB HCD/DRD schema all the USB controllers are
supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the
existing DT-nodes will be renamed in a subsequent patch let's first make
sure the DWC3 Qualcomm driver supports them and second falls back to the
deprecated naming so not to fail on the legacy DTS-files passed to the
newer kernels.
Signed-off-by: Serge Semin
Reviewed-by: Bjorn Andersson
---
drivers/usb/dwc3/dwc3-qcom.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index c703d552bbcf..49ad8d507d37 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct
platform_device *pdev)
struct device *dev = >dev;
int ret;
- dwc3_np = of_get_child_by_name(np, "dwc3");
+ dwc3_np = of_get_child_by_name(np, "usb") ?:
+ of_get_child_by_name(np, "dwc3");
if (!dwc3_np) {
dev_err(dev, "failed to find dwc3 core child\n");
return -ENODEV;
--
2.30.0
[PATCH v6 08/10] arm64: dts: apm: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named despite of the warning comment about possible backward
compatibility issues.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++--
arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index a83c82c50e29..832dd85b00bd 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -597,8 +597,8 @@ serial0: serial@1060 {
interrupts = <0x0 0x4c 0x4>;
};
- /* Do not change dwusb name, coded for backward compatibility */
- usb0: dwusb@1900 {
+ /* Node-name might need to be coded as dwusb for backward
compatibility */
+ usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1900 0x0 0x10>;
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 0f37e77f5459..1520a945b7f9 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -923,8 +923,8 @@ sata3: sata@1a80 {
phy-names = "sata-phy";
};
- /* Do not change dwusb name, coded for backward compatibility */
- usb0: dwusb@1900 {
+ /* Node-name might need to be coded as dwusb for backward
compatibility */
+ usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1900 0x0 0x10>;
@@ -933,7 +933,7 @@ usb0: dwusb@1900 {
dr_mode = "host";
};
- usb1: dwusb@1980 {
+ usb1: usb@1980 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1980 0x0 0x10>;
--
2.30.0
[PATCH v6 07/10] arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
Reviewed-by: Patrice Chotard
---
arch/arm/boot/dts/stih407-family.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index 23a1746f3baa..2352f76b5a69 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -681,7 +681,7 @@ st_dwc3: dwc3@8f94000 {
status = "disabled";
- dwc3: dwc3@990 {
+ dwc3: usb@990 {
compatible = "snps,dwc3";
reg = <0x0990 0x10>;
interrupts = ;
--
2.30.0
[PATCH v6 06/10] arm: dts: keystone: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/keystone-k2e.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi
b/arch/arm/boot/dts/keystone-k2e.dtsi
index fa1b8499c5a7..b8f152e7af7f 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -52,7 +52,7 @@ {
usb: usb@268 {
interrupts = ;
- dwc3@269 {
+ usb@269 {
interrupts = ;
};
};
@@ -78,7 +78,7 @@ keystone_usb1: usb@2500 {
dma-ranges;
status = "disabled";
- usb1: dwc3@2501 {
+ usb1: usb@2501 {
compatible = "snps,dwc3";
reg = <0x2501 0x7>;
interrupts = ;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 8d046a1b690c..fc9fdc857ae8 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -217,7 +217,7 @@ keystone_usb0: usb@268 {
dma-ranges;
status = "disabled";
- usb0: dwc3@269 {
+ usb0: usb@269 {
compatible = "snps,dwc3";
reg = <0x269 0x7>;
interrupts = ;
--
2.30.0
[PATCH v6 01/10] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
Cc: Shawn Guo
---
Changelog v5:
- Get back the patch to the series as it has been missing in the kernel
5.11-rc7.
---
arch/arm/boot/dts/ls1021a.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 007dd2bd0595..85462f234fc7 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -871,7 +871,7 @@ usb2: usb@860 {
phy_type = "ulpi";
};
- usb3: usb3@310 {
+ usb3: usb@310 {
compatible = "snps,dwc3";
reg = <0x0 0x310 0x0 0x1>;
interrupts = ;
--
2.30.0
[PATCH v6 02/10] arm: dts: keystone: Correct DWC USB3 compatible string
Syonpsys IP cores are supposed to be defined with "snps" vendor-prefix.
Use it instead of the deprecated "synopsys" one.
Signed-off-by: Serge Semin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/keystone-k2e.dtsi | 2 +-
arch/arm/boot/dts/keystone.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi
b/arch/arm/boot/dts/keystone-k2e.dtsi
index 2d94faf31fab..fa1b8499c5a7 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -79,7 +79,7 @@ keystone_usb1: usb@2500 {
status = "disabled";
usb1: dwc3@2501 {
- compatible = "synopsys,dwc3";
+ compatible = "snps,dwc3";
reg = <0x2501 0x7>;
interrupts = ;
usb-phy = <_phy>, <_phy>;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index c298675a29a5..8d046a1b690c 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -218,7 +218,7 @@ keystone_usb0: usb@268 {
status = "disabled";
usb0: dwc3@269 {
- compatible = "synopsys,dwc3";
+ compatible = "snps,dwc3";
reg = <0x269 0x7>;
interrupts = ;
usb-phy = <_phy>, <_phy>;
--
2.30.0
[PATCH RESEND v6 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
pients. Cc: Vineet Gupta Cc: Rafal Milecki Cc: Wei Xu Cc: Thomas Bogendoerfer Cc: Michael Ellerman Cc: Jason Cooper Cc: Santosh Shilimkar Cc: Shawn Guo Cc: Benoit Cousson Cc: Patrice Chotard Cc: Maxime Ripard Cc: Khuong Dinh Cc: Andy Gross Cc: Alexey Brodkin Cc: Hauke Mehrtens Cc: Maxime Coquelin Cc: Alexandre Torgue Cc: Amelie Delaunay Cc: Vladimir Zapolskiy Cc: Paul Cercueil Cc: Matthias Brugger Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Andrew Lunn Cc: Gregory Clement Cc: Sebastian Hesselbarth Cc: Kukjin Kim Cc: Li Yang Cc: Tony Lindgren Cc: Chen-Yu Tsai Cc: Bjorn Andersson Cc: Jun Li Cc: linux-snps-...@lists.infradead.org Cc: bcm-kernel-feedback-l...@broadcom.com Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-m...@vger.kernel.org Cc: linux-media...@lists.infradead.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-o...@vger.kernel.org Cc: linux-arm-...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Serge Semin (10): arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name arm: dts: keystone: Correct DWC USB3 compatible string arc: dts: Harmonize EHCI/OHCI DT nodes name arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name arm: dts: keystone: Harmonize DWC USB3 DT nodes name arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name arm64: dts: apm: Harmonize DWC USB3 DT nodes name usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names arm64: dts: qcom: Harmonize DWC USB3 DT nodes name arch/arc/boot/dts/axc003.dtsi| 4 ++-- arch/arc/boot/dts/axc003_idu.dtsi| 4 ++-- arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++-- arch/arc/boot/dts/hsdk.dts | 4 ++-- arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +- arch/arm/boot/dts/keystone-k2e.dtsi | 6 +++--- arch/arm/boot/dts/keystone.dtsi | 4 ++-- arch/arm/boot/dts/lpc18xx.dtsi | 4 ++-- arch/arm/boot/dts/ls1021a.dtsi | 2 +- arch/arm/boot/dts/stih407-family.dtsi| 2 +- arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++-- arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++--- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++-- arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++-- arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +- arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +- arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +- arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +- arch/powerpc/boot/dts/akebono.dts| 6 +++--- drivers/usb/dwc3/dwc3-qcom.c | 3 ++- 23 files changed, 42 insertions(+), 41 deletions(-) -- 2.30.0
[PATCH v6 03/10] arc: dts: Harmonize EHCI/OHCI DT nodes name
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin
Acked-by: Alexey Brodkin
Acked-by: Krzysztof Kozlowski
---
arch/arc/boot/dts/axc003.dtsi| 4 ++--
arch/arc/boot/dts/axc003_idu.dtsi| 4 ++--
arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++--
arch/arc/boot/dts/hsdk.dts | 4 ++--
arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +-
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index cd1edcf4f95e..3434c8131ecd 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -103,11 +103,11 @@ ethernet@18000 {
dma-coherent;
};
- ehci@4 {
+ usb@4 {
dma-coherent;
};
- ohci@6 {
+ usb@6 {
dma-coherent;
};
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi
b/arch/arc/boot/dts/axc003_idu.dtsi
index 70779386ca79..67556f4b7057 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -110,11 +110,11 @@ ethernet@18000 {
dma-coherent;
};
- ehci@4 {
+ usb@4 {
dma-coherent;
};
- ohci@6 {
+ usb@6 {
dma-coherent;
};
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 99d3e7175bf7..b64435385304 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -87,13 +87,13 @@ gmac: ethernet@18000 {
mac-address = [00 00 00 00 00 00]; /* Filled in by
U-Boot */
};
- ehci@4 {
+ usb@4 {
compatible = "generic-ehci";
reg = < 0x4 0x100 >;
interrupts = < 8 >;
};
- ohci@6 {
+ usb@6 {
compatible = "generic-ohci";
reg = < 0x6 0x100 >;
interrupts = < 8 >;
diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
index dcaa44e408ac..fdd4f7f635d3 100644
--- a/arch/arc/boot/dts/hsdk.dts
+++ b/arch/arc/boot/dts/hsdk.dts
@@ -234,7 +234,7 @@ phy0: ethernet-phy@0 { /* Micrel KSZ9031 */
};
};
- ohci@6 {
+ usb@6 {
compatible = "snps,hsdk-v1.0-ohci", "generic-ohci";
reg = <0x6 0x100>;
interrupts = <15>;
@@ -242,7 +242,7 @@ ohci@6 {
dma-coherent;
};
- ehci@4 {
+ usb@4 {
compatible = "snps,hsdk-v1.0-ehci", "generic-ehci";
reg = <0x4 0x100>;
interrupts = <15>;
diff --git a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
index cbb179770293..90a412026e64 100644
--- a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
@@ -46,7 +46,7 @@ ethernet@18000 {
clock-names = "stmmaceth";
};
- ehci@4 {
+ usb@4 {
compatible = "generic-ehci";
reg = < 0x4 0x100 >;
interrupts = < 8 >;
--
2.30.0
[PATCH v6 04/10] arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin
Acked-by: Vladimir Zapolskiy
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/lpc18xx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 10b8249b8ab6..82ffd7b0ad8a 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -121,7 +121,7 @@ mmcsd: mmcsd@40004000 {
status = "disabled";
};
- usb0: ehci@40006100 {
+ usb0: usb@40006100 {
compatible = "nxp,lpc1850-ehci", "generic-ehci";
reg = <0x40006100 0x100>;
interrupts = <8>;
@@ -133,7 +133,7 @@ usb0: ehci@40006100 {
status = "disabled";
};
- usb1: ehci@40007100 {
+ usb1: usb@40007100 {
compatible = "nxp,lpc1850-ehci", "generic-ehci";
reg = <0x40007100 0x100>;
interrupts = <9>;
--
2.30.0
Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode
On Tue, Feb 09, 2021 at 10:56:46AM +, Russell King - ARM Linux admin wrote:
> On Tue, Feb 09, 2021 at 11:37:29AM +0100, Heiner Kallweit wrote:
> > Right, adding something like a genphy_{read,write}_mmd() doesn't make
> > too much sense for now. What I meant is just exporting mmd_phy_indirect().
> > Then you don't have to open-code the first three steps of a mmd read/write.
> > And it requires no additional code in phylib.
>
> ... but at the cost that the compiler can no longer inline that code,
> as I mentioned in my previous reply. (However, the cost of the accesses
> will be higher.) On the plus side, less I-cache footprint, and smaller
> kernel code.
Just to note mmd_phy_indirect() isn't defined with inline specifier,
but just as static and it's used twice in the
drivers/net/phy/phy-core.c unit. So most likely the compiler won't
inline the function code in there. Anyway it's up to the PHY
library maintainers to decide. Please settle the issue with Heiner and
Andrew then. I am ok with both solutions and will do as you decide.
-Sergey
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH v3 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
On Wed, Feb 03, 2021 at 10:06:46AM +0100, Greg Kroah-Hartman wrote: > On Tue, Feb 02, 2021 at 05:02:08PM -0600, Bjorn Andersson wrote: > > On Sat 05 Dec 09:56 CST 2020, Serge Semin wrote: > > > > > In accordance with the USB HCD/DRD schema all the USB controllers are > > > supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the > > > existing DT-nodes will be renamed in a subsequent patch let's first make > > > sure the DWC3 Qualcomm driver supports them and second falls back to the > > > deprecated naming so not to fail on the legacy DTS-files passed to the > > > newer kernels. > > > > > > > Felipe, will you merge this, so that I can merge the dts patch depending > > on this into the Qualcomm DT tree? > > Patches this old are long-gone out of our queues. If it needs to be > applied to a linux-usb tree, please resend. Greg, Bjorn, I've revised and resent the series. Please find the recently posted patchset: Link: https://lore.kernel.org/lkml/20210208135154.6645-1-sergey.se...@baikalelectronics.ru/ Alas I've forgotten to Cc the linux-usb mailing list. Should I resend the series one more time? -Sergey > > thanks, > > greg k-h
Re: [PATCH 00/16] net: stmmac: Add DW MAC GPIOs and Baikal-T1 GMAC support
On Mon, Feb 08, 2021 at 08:36:33PM +0100, Andrew Lunn wrote: > On Mon, Feb 08, 2021 at 05:08:04PM +0300, Serge Semin wrote: > > Hi Serge > > I suggest you split this patchset up. This uses the generic GPIO > framework, which is great. But that also means you should be Cc: the > GPIO subsystem maintainers and list. But you don't want to spam them > with all the preparation work, which has little to do with the GPIO > code. > > So please split the actual GPIO driver and DT binding patches from the > rest. netdev can review the preparation work, with a comment in the > 0/X patch about what the big picture is, and then afterwards review > the GPIO patchset with a wider audience. > > And as Jakub pointed out, nobody is going to review 60 patches all at > once. Please submit one series at a time, get it merged, and then > move onto the next. Hello Andrew Right, with all that preparation work I've forgotten to Cc the GPIO-subsystem maintainers. Thanks for noticing this. Regarding the 60-patches. Please see my response to Jakub' post in the first series. To cut it short let's start working with that patchset: Link: https://lore.kernel.org/netdev/20210208135609.7685-1-sergey.se...@baikalelectronics.ru/ I'll rebase and resubmit the rest of the work when the time comes. Regarding splitting the series up. I don't see a problem in just sending the cover-letter patch and actual GPIO-related patches to the GPIO-maintainers with no need to have them added to Cc in the rest of the series. That's a normal practice. Splitting is not really required. But since I have to split the very first patchset anyway. I'll split this one up too, when it comes to have this part of changes reviewed. -Sergey > >Andrew
Re: [PATCH v2 00/24] net: stmmac: Fix clocks/reset-related procedures
On Mon, Feb 08, 2021 at 11:05:21AM -0800, Jakub Kicinski wrote: > On Mon, 8 Feb 2021 16:55:44 +0300 Serge Semin wrote: > > Baikal-T1 SoC is equipped with two Synopsys DesignWare GMAC v3.73a-based > > ethernet interfaces with no internal Ethernet PHY attached. The IP-cores > > are configured as GMAC-AXI with CSR interface clocked by a dedicated > > signal. Each of which has got Rx/Tx FIFOs of 16KB, up to 8 MAC addresses > > capability, no embedded filter hash table logic, EEE enabled, IEEE 1588 > > and 1588-2008 Advanced timestamping capabilities, power management with > > remote wake-up, IP CSUM hardware acceleration, a single PHY interface - > > RGMII with MDIO bus, 1xGPI and 1xGPO. > > > > This is a very first series of patches with fixes we've found to be > > required in order to make things working well for our setup. The series > > has turned to be rather large, but most of the patches are trivial and > > some of them are just cleanups, so it shouldn't be that hard to review. > > Hi Serge! > > You've submitted 60 patches at once, that's a lot of patches, in netdev > we limit submissions to 15 patches at a time to avoid overwhelming > reviewers. > > At a glance the patches seem to mix fixes which affect existing, > supported systems (eg. error patch reference leaks) with extensions > required to support your platform. Can the two be separated? > The fixes for existing bugs should be targeting net (Subject: > [PATCH net]) and patches to support your platform net-next (Subject: > [PATCH net-next]). > > Right now the patches are not tagged so our build bot tried applying > them to net-next and they failed to apply, so I need to toss them away. > > Andrew, others, please chime in if I'm misreading the contents of the > series or if you have additional guidance! Hi Jakub, Of course I know about the "too-big-series-to-review" rule. That's why I've split all my work up into three patchsets. Actually this one is the very first patchset, which I've submitted over two months ago but noone except Rob gave me any review comment. So I've decided to post all the work, to so called depict a scale of the work, which needs to be reviewed. Anyway I thought it would be obvious from the cover-letters which patchsets should be applied first, which next. This one states that it's a very first series. The rest of the patchsets contains a link to the previous one they were supposed to be applied to. Perhaps I should have stated that in a clearer way. Regarding having over 15 patches in this series. Normally it's not that strict rule. There are even bigger series can be found submitted, reviewed and accepted in the kernel. Of course sometimes it's hard to review even 15 patches due to complexity of the changes. But most of the alterations posted here are trivial and shouldn't be difficult to review. That's why I felt free to post it as is. Of course I agree with you. It would be too much to review over 60 patches at once. Let's review one series at a time then. This one is the very first one. Please start with it. Regarding splitting this series up. Well, normally there is no such requirement to split the fixes and feature into different series. (Though I am not surprised to get such request from net-subsystem. You always prefer to do things in your special way. ^_^) So in this series the fixes have been structured together and have been submitted first in the order, but after DT-bindings related patches. Anyway if you want it, I'll split the patchset up into two. The first one will be targeted to "net" and will have all the fixes. The second one will contain the bindings-related modifications and the clocks-related feature implementation. It will be sent to net-next. I'll do that in v2. But at the current stage could you start reviewing this series the way it is? I'll take into account your comments and add your tags in the split v2 patchsets if any. Thanks -Sergey
Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode
On Mon, Feb 08, 2021 at 09:14:02PM +0100, Heiner Kallweit wrote:
> On 08.02.2021 15:03, Serge Semin wrote:
> > It has been noticed that RTL8211E PHY stops detecting and reporting events
> > when EEE is successfully advertised and RXC stopping in LPI is enabled.
> > The freeze happens right after 3.0.10 bit (PC1R "Clock Stop Enable"
> > register) is set. At the same time LED2 stops blinking as if EEE mode has
> > been disabled. Notably the network traffic still flows through the PHY
> > with no obvious problem. Anyway if any MDIO read procedure is performed
> > after the "RXC stop in LPI" mode is enabled PHY gets to be unfrozen, LED2
> > starts blinking and PHY interrupts happens again. The problem has been
> > noticed on RTL8211E PHY working together with DW GMAC 3.73a MAC and
> > reporting its event via a dedicated IRQ signal. (Obviously the problem has
> > been unnoticed in the polling mode, since it gets naturally fixed by the
> > periodic MDIO read procedure from the PHY status register - BMSR.)
> >
> > In order to fix that problem we suggest to locally re-implement the MMD
> > write method for RTL8211E PHY and perform a dummy read right after the
> > PC1R register is accessed to enable the RXC stopping in LPI mode.
> >
> > Signed-off-by: Serge Semin
> > ---
> > drivers/net/phy/realtek.c | 37 +
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> > index 99ecd6c4c15a..cbb86c257aae 100644
> > --- a/drivers/net/phy/realtek.c
> > +++ b/drivers/net/phy/realtek.c
> > @@ -559,6 +559,42 @@ static int rtl822x_write_mmd(struct phy_device
> > *phydev, int devnum, u16 regnum,
> > return ret;
> > }
> >
> > +static int rtl8211e_write_mmd(struct phy_device *phydev, int devnum, u16
> > regnum,
> > + u16 val)
> > +{
> > + int ret;
> > +
> > + /* Write to the MMD registers by using the standard control/data pair.
> > +* The only difference is that we need to perform a dummy read after
> > +* the PC1R.CLKSTOP_EN bit is set. It's required to workaround an issue
> > +* of a partial core freeze so LED2 stops blinking in EEE mode, PHY
> > +* stops detecting the link change and raising IRQs until any read from
> > +* its registers performed. That happens only if and right after the PHY
> > +* is enabled to stop RXC in LPI mode.
> > +*/
> > + ret = __phy_write(phydev, MII_MMD_CTRL, devnum);
> > + if (ret)
> > + return ret;
> > +
> > + ret = __phy_write(phydev, MII_MMD_DATA, regnum);
> > + if (ret)
> > + return ret;
> > +
> > + ret = __phy_write(phydev, MII_MMD_CTRL, devnum | MII_MMD_CTRL_NOINCR);
> > + if (ret)
> > + return ret;
> > +
>
> Nice analysis. Alternatively to duplicating this code piece we could
> export mmd_phy_indirect(). But up to you.
I also considered creating a generic method to access the MMD
registers of a generic PHY, something like phy_read()/phy_write(), but
for MMD (alas just exporting mmd_phy_indirect() would not be enough).
But as I see it such methods need to be created only after we get to
have at least several places with duplicating direct MMD-read/write
patterns. Doing that just for a single place seems redundant. Anyway it's
up to maintainers to decide whether they want to see a generic part
of the phy_read_mmd()/phy_write_mmd() methods being detached and
exported as something like genphy_{read,write}_mmd() methods. I can do
that in v2 if you ask me to.
-Sergey
>
> > + ret = __phy_write(phydev, MII_MMD_DATA, val);
> > + if (ret)
> > + return ret;
> > +
> > + if (devnum == MDIO_MMD_PCS && regnum == MDIO_CTRL1 &&
> > + val & MDIO_PCS_CTRL1_CLKSTOP_EN)
> > + ret = __phy_read(phydev, MII_MMD_DATA);
> > +
> > + return ret < 0 ? ret : 0;
> > +}
> > +
> > static int rtl822x_get_features(struct phy_device *phydev)
> > {
> > int val;
> > @@ -725,6 +761,7 @@ static struct phy_driver realtek_drvs[] = {
> > .resume = genphy_resume,
> > .read_page = rtl821x_read_page,
> > .write_page = rtl821x_write_page,
> > + .write_mmd = rtl8211e_write_mmd,
> > }, {
> > PHY_ID_MATCH_EXACT(0x001cc916),
> > .name = "RTL8211F Gigabit Ethernet",
> >
>
Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode
On Mon, Feb 08, 2021 at 04:27:36PM +0100, Andrew Lunn wrote: > On Mon, Feb 08, 2021 at 05:03:22PM +0300, Serge Semin wrote: > > It has been noticed that RTL8211E PHY stops detecting and reporting events > > when EEE is successfully advertised and RXC stopping in LPI is enabled. > > The freeze happens right after 3.0.10 bit (PC1R "Clock Stop Enable" > > register) is set. At the same time LED2 stops blinking as if EEE mode has > > been disabled. Notably the network traffic still flows through the PHY > > with no obvious problem. Anyway if any MDIO read procedure is performed > > after the "RXC stop in LPI" mode is enabled PHY gets to be unfrozen, LED2 > > starts blinking and PHY interrupts happens again. The problem has been > > noticed on RTL8211E PHY working together with DW GMAC 3.73a MAC and > > reporting its event via a dedicated IRQ signal. (Obviously the problem has > > been unnoticed in the polling mode, since it gets naturally fixed by the > > periodic MDIO read procedure from the PHY status register - BMSR.) > > > > In order to fix that problem we suggest to locally re-implement the MMD > > write method for RTL8211E PHY and perform a dummy read right after the > > PC1R register is accessed to enable the RXC stopping in LPI mode. > > Hi Serge > > Is this listed in an Errata from Realtek? Hi Andrew, I honestly tried to find any doc with a glimpse of errata for RTL8211E PHY, but with no luck. Official datasheet didn't have any info regarding possible hw bugs too. Thus I had no choice but to find a fix of the problem myself. It took me some time to figure out why the events weren't reported after the very first link setup (turned out only a full HW reset clears the PC1R.10 bit state). I thought it could have been connected with some sleep/idle/power-safe mode. So I disabled the EEE initialization in the STMMAC driver. It worked. Then I left the EEE mode enabled, but called the phy_init_eee(phy, 0) method with "clk_stop_enable==0", so PHY wouldn't stop RXC in LPI mode. And it wonderfully worked. Then I started to dig in from another side. I left "RXC disable in LPI" mode enabled and tried to figure out what was going on with the PHY when it stopped reporting events just by reading from its CSR using phytool utility. It was curious to discover that any attempt to read from any PHY register caused the problem disappearance (LED2 started blinking, events got to be reported). Since I did nothing but a mere reading from a random even EEE-unrelated register I inferred that the problem must be in some HW/PHY bug. That's how I've got to the patch introduced here. If you have any better idea what could be a reason of that weird behavior I'd be glad to test it out on my device. -Sergey > >Andrew
[PATCH 14/16] net: stmmac: Add Generic DW MAC GPIO port driver
Synopsys DesignWare Ethernet controllers can be synthesized with
General-Purpose IOs support. GPIOs can work either as inputs or as outputs
thus belong to the gpi_i and gpo_o ports respectively. The ports width
(number of possible inputs/outputs) and the configuration registers layout
depend on the IP-core version. For instance, DW GMAC can have from 0 to 4
GPIs and from 0 to 4 GPOs, while DW xGMAC have a wider ports width up to
16 pins of each one. In the framework of this driver both implementation
can be supported as soon as the GPIO registers accessors are defined for
the particular IP-core.
Total number of GPIOs MAC supports can be passed via the platform
descriptor. If it's a OF-based platform, then the standard "ngpios"
DT-property will be parsed for it.
Before registering the GPIO-chip in the kernel, the driver will try to
auto-detect the number of GPIs and GPOs by writing 1s into the GPI type
config register. Reading the written value back and calculating the number
of actually set bits will give the GPI port width the device has been
synthesized with.
If GPIs have been detected then GPIO IRQ-chip will be also initialized and
Only in that case the GPIO IRQs handling will be activated. Since the
pending events are cleared just be reading from the GPI event status
register, only the edged IRQs type can be implemented. For the same reason
and for the reason of having the rest of GPIO configs reside in the same
CSR, we had no choice but to define the GPI type, GPI mask and GPO state
cache. So we wouldn't need to perform reading from the config register and
accidentally clear pending GPI events in order to update these fields
values.
Note In case of GPIOs being available we can't reset the core otherwise
the GPIO configs will be reset to the initial state too. Instead we
suggest to at least restore the DMA/MAC registers to the initial state,
when the software reset were supposed to happen.
Signed-off-by: Serge Semin
---
.../ethernet/stmicro/stmmac.rst | 4 +
drivers/net/ethernet/stmicro/stmmac/Kconfig | 2 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +-
drivers/net/ethernet/stmicro/stmmac/common.h | 1 +
drivers/net/ethernet/stmicro/stmmac/hwif.c| 2 +
drivers/net/ethernet/stmicro/stmmac/hwif.h| 14 +
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 19 +
.../net/ethernet/stmicro/stmmac/stmmac_gpio.c | 400 ++
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 22 +-
.../ethernet/stmicro/stmmac/stmmac_platform.c | 5 +
include/linux/stmmac.h| 1 +
11 files changed, 470 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_gpio.c
diff --git
a/Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst
b/Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst
index 5d46e5036129..c0e6f1e7538c 100644
--- a/Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst
+++ b/Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst
@@ -495,6 +495,10 @@ is used to configure the AMBA bridge to generate more
efficient STBus traffic::
int has_xgmac;
+37) Total number of supported GPIOs::
+
+u32 ngpios;
+
::
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 53f14c5a9e02..1d34672d4501 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -9,6 +9,8 @@ config STMMAC_ETH
select CRC32
imply PTP_1588_CLOCK
select RESET_CONTROLLER
+ select GPIOLIB
+ select GPIOLIB_IRQCHIP
help
This is the driver for the Ethernet IPs built around a
Synopsys IP Core.
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 24e6145d4eae..71a59b513381 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -6,7 +6,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o
ring_mode.o \
mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o dwmac4_descs.o \
dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5.o hwif.o \
stmmac_tc.o dwxgmac2_core.o dwxgmac2_dma.o dwxgmac2_descs.o \
- $(stmmac-y)
+ stmmac_gpio.o $(stmmac-y)
stmmac-$(CONFIG_STMMAC_SELFTESTS) += stmmac_selftests.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 6f271c46368d..7d18ab71edd1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -466,6 +466,7 @@ struct mac_device_info {
const struct stmmac_hwtimestamp *ptp;
const struct stmmac_tc_ops *tc;
const struct stmmac_mmc_ops *mmc;
+ const struct stmmac_gpio_ops *gpio;
const struct mdio_xpcs_ops *xpcs;
[PATCH 15/16] net: stmmac: Add DW GMAC GPIOs support
Synopsys DW GMAC can be synthesized with up to four GPIs and four GPOs
support, which in case if enabled can be configured via a MAC CSR 0xe0.
In order to have the DW GMAC GPIO interface supported in the STMMAC GPIO
driver we just need to define the GPIO configs accessors and GPI state
getter.
Signed-off-by: Serge Semin
---
Folks, I don't know whether the same GPIO CSR layout is defined for some
other DW MAC IP-core. So for now the accessors have been created for
GMACs only. But if you are sure the callbacks can be used for some other
IP, I can move them to dwmac_lib.c. Though in order to have the GPIOs
working in the driver the MAC/DMA cleanup methods need to be also defined
for that IP-core version.
---
.../net/ethernet/stmicro/stmmac/dwmac1000.h | 11 +
.../ethernet/stmicro/stmmac/dwmac1000_core.c | 40 +++
drivers/net/ethernet/stmicro/stmmac/hwif.c| 1 +
drivers/net/ethernet/stmicro/stmmac/hwif.h| 1 +
4 files changed, 53 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
index 919f5b55bc7d..7fa75e0a33bc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
@@ -30,6 +30,7 @@
#define GMAC_INT_STATUS_MMCCSUMBIT(7)
#define GMAC_INT_STATUS_TSTAMP BIT(9)
#define GMAC_INT_STATUS_LPIIS BIT(10)
+#define GMAC_INT_STATUS_GPIIS BIT(11)
/* interrupt mask register */
#defineGMAC_INT_MASK 0x003c
@@ -101,6 +102,16 @@ enum power_event {
#define GMAC_RGSMIIIS_SPEED_25 0x1
#define GMAC_RGSMIIIS_SPEED_2_50x0
+/* General Purpose IO register */
+#define GMAC_GPIO 0x00e0 /* General Purpose IO */
+#define GMAC_GPIO_GPIS GENMASK(3, 0)
+#define GMAC_GPIO_NGPIS4
+#define GMAC_GPIO_GPO GENMASK(11, 8)
+#define GMAC_GPIO_NGPOS4
+#define GMAC_GPIO_GPIE GENMASK(19, 16)
+#define GMAC_GPIO_GPIT GENMASK(27, 24)
+#define GMAC_GPIO_NGPIOS (GMAC_GPIO_NGPIS + GMAC_GPIO_NGPOS)
+
/* GMAC Configuration defines */
#define GMAC_CONTROL_2K 0x0800 /* IEEE 802.3as 2K packets */
#define GMAC_CONTROL_TC0x0100 /* Transmit Conf. in
RGMII/SGMII */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index 7dc8b254c15a..e2a4b746fde9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -12,6 +12,7 @@
Author: Giuseppe Cavallaro
***/
+#include
#include
#include
#include
@@ -577,6 +578,45 @@ const struct stmmac_ops dwmac1000_ops = {
.set_mac_loopback = dwmac1000_set_mac_loopback,
};
+static void dwmac1000_gpio_set_ctrl(struct stmmac_priv *priv, u32 gpie,
+ u32 gpit, u32 gpo)
+{
+ u32 val;
+
+ val = FIELD_PREP(GMAC_GPIO_GPO, gpo) |
+ FIELD_PREP(GMAC_GPIO_GPIE, gpie) |
+ FIELD_PREP(GMAC_GPIO_GPIT, gpit);
+
+ writel(val, priv->ioaddr + GMAC_GPIO);
+}
+
+static void dwmac1000_gpio_get_ctrl(struct stmmac_priv *priv, u32 *gpie,
+ u32 *gpit, u32 *gpo)
+{
+ u32 val;
+
+ val = readl(priv->ioaddr + GMAC_GPIO);
+
+ *gpie = FIELD_GET(GMAC_GPIO_GPIE, val);
+ *gpit = FIELD_GET(GMAC_GPIO_GPIT, val);
+ *gpo = FIELD_GET(GMAC_GPIO_GPO, val);
+}
+
+static int dwmac1000_gpio_get_gpi(struct stmmac_priv *priv)
+{
+ u32 val;
+
+ val = readl(priv->ioaddr + GMAC_GPIO);
+
+ return FIELD_GET(GMAC_GPIO_GPIS, val);
+}
+
+const struct stmmac_gpio_ops dwmac1000_gpio_ops = {
+ .set_ctrl = dwmac1000_gpio_set_ctrl,
+ .get_ctrl = dwmac1000_gpio_get_ctrl,
+ .get_gpi = dwmac1000_gpio_get_gpi,
+};
+
int dwmac1000_setup(struct stmmac_priv *priv)
{
struct mac_device_info *mac = priv->hw;
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c
b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 067420059c11..18aaa27801e4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -140,6 +140,7 @@ static const struct stmmac_hwif_entry {
.mode = NULL,
.tc = NULL,
.mmc = _mmc_ops,
+ .gpio = _gpio_ops,
.setup = dwmac1000_setup,
.quirks = stmmac_dwmac1_quirks,
}, {
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h
b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 99c5841f1060..1aabdd96ea32 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -661,6 +661,7 @@ extern const struct stmmac_ops dwmac100_ops;
extern const struct stmmac_dma_ops dwmac100_dma_ops;
extern const struct stmmac_ops dwmac1000_
[PATCH 08/16] net: stmmac: Introduce Safety Feature IRQs enable/disable methods
Safety feature IRQs is another set of IRQs, which aside with the DMA, MAC,
MTL, GPIOs, etc interrupts can be generated by the DW *MAC network
devices. They are signalled by means of the shared sbd_intr_o lane too,
so we need to be able mask/unmask these interrupts in the framework of the
generic IRQs setup procedure.
Note there is no need in preserving the Safety interrupts enable register
content in the provided callbacks as these registers are changed in these
methods only. Moreover by doing so we disable the interrupts, which are
unsupported by the Safety IRQ status handler, if any of them have been
enabled by default.
Signed-off-by: Serge Semin
---
Folks, the zero initialization of the DW xGMAC XGMAC_MTL_ECC_CONTROL
register looks suspicious. Are you sure it is supposed to be cleared out
in order to enable the safety IRQs?
---
.../net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 +
drivers/net/ethernet/stmicro/stmmac/dwmac5.c | 36 +
drivers/net/ethernet/stmicro/stmmac/dwmac5.h | 2 +
.../ethernet/stmicro/stmmac/dwxgmac2_core.c | 40 +++
drivers/net/ethernet/stmicro/stmmac/hwif.h| 6 +++
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++
6 files changed, 60 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 9ad48a0f96a6..99296ff14616 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -1320,6 +1320,8 @@ const struct stmmac_ops dwmac510_ops = {
.debug = dwmac4_debug,
.set_filter = dwmac4_set_filter,
.safety_feat_config = dwmac5_safety_feat_config,
+ .enable_safety_feat_irq = dwmac5_enable_safety_feat_irq,
+ .disable_safety_feat_irq = dwmac5_disable_safety_feat_irq,
.safety_feat_irq_status = dwmac5_safety_feat_irq_status,
.safety_feat_dump = dwmac5_safety_feat_dump,
.rxp_config = dwmac5_rxp_config,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
index 8f7ac24545ef..43682a42b4d5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
@@ -190,7 +190,7 @@ int dwmac5_safety_feat_config(void __iomem *ioaddr,
unsigned int asp)
if (!asp)
return -EINVAL;
- /* 1. Enable Safety Features */
+ /* Enable Safety Features */
value = readl(ioaddr + MTL_ECC_CONTROL);
value |= TSOEE; /* TSO ECC */
value |= MRXPEE; /* MTL RX Parser ECC */
@@ -199,30 +199,17 @@ int dwmac5_safety_feat_config(void __iomem *ioaddr,
unsigned int asp)
value |= MTXEE; /* MTL TX FIFO ECC */
writel(value, ioaddr + MTL_ECC_CONTROL);
- /* 2. Enable MTL Safety Interrupts */
- value = readl(ioaddr + MTL_ECC_INT_ENABLE);
- value |= RPCEIE; /* RX Parser Memory Correctable Error */
- value |= ECEIE; /* EST Memory Correctable Error */
- value |= RXCEIE; /* RX Memory Correctable Error */
- value |= TXCEIE; /* TX Memory Correctable Error */
- writel(value, ioaddr + MTL_ECC_INT_ENABLE);
-
- /* 3. Enable DMA Safety Interrupts */
- value = readl(ioaddr + DMA_ECC_INT_ENABLE);
- value |= TCEIE; /* TSO Memory Correctable Error */
- writel(value, ioaddr + DMA_ECC_INT_ENABLE);
-
/* Only ECC Protection for External Memory feature is selected */
if (asp <= 0x1)
return 0;
- /* 5. Enable Parity and Timeout for FSM */
+ /* Enable Parity and Timeout for FSM */
value = readl(ioaddr + MAC_FSM_CONTROL);
value |= PRTYEN; /* FSM Parity Feature */
value |= TMOUTEN; /* FSM Timeout Feature */
writel(value, ioaddr + MAC_FSM_CONTROL);
- /* 4. Enable Data Parity Protection */
+ /* Enable Data Parity Protection */
value = readl(ioaddr + MTL_DPP_CONTROL);
value |= EDPP;
writel(value, ioaddr + MTL_DPP_CONTROL);
@@ -239,6 +226,23 @@ int dwmac5_safety_feat_config(void __iomem *ioaddr,
unsigned int asp)
return 0;
}
+void dwmac5_enable_safety_feat_irq(void __iomem *ioaddr)
+{
+ /* Enable MTL Safety Interrupts: RX Parser Memory, EST, RX and Tx
+* Memory Correctable Errors.
+*/
+ writel(RPCEIE | ECEIE | RXCEIE | TXCEIE, ioaddr + MTL_ECC_INT_ENABLE);
+
+ /* Enable DMA Safety Interrupts: TSO Memory Correctable Error. */
+ writel(TCEIE, ioaddr + DMA_ECC_INT_ENABLE);
+}
+
+void dwmac5_disable_safety_feat_irq(void __iomem *ioaddr)
+{
+ writel(0, ioaddr + MTL_ECC_INT_ENABLE);
+ writel(0, ioaddr + DMA_ECC_INT_ENABLE);
+}
+
int dwmac5_safety_feat_irq_status(struct net_device *ndev,
void __iomem *ioaddr, unsigned int asp,
struct stmmac_safety_stats *stats)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac5.h
b/drivers/net/ethernet/stmicro/stmmac/dwm
[PATCH 16/16] net: stmmac: Add DW MAC IPs of 3.72a/3.73a/3.74a versions
DW MAC IPs of the denoted versions have been used on Socfpga Arria10,
Baikal-T1 SoC, Intel Socfpga Agilex and Altera Socfpga Stratix10
respectively. Update the Generic DW MAC glue-driver OF-device compatibles
to have these IPs accepted so the generic driver would be ready to work
with the devices if there were no more specific glue-driver for them.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c
index fad503820e04..09246b336499 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c
@@ -75,6 +75,9 @@ static const struct of_device_id dwmac_generic_match[] = {
{ .compatible = "snps,dwmac-3.610"},
{ .compatible = "snps,dwmac-3.70a"},
{ .compatible = "snps,dwmac-3.710"},
+ { .compatible = "snps,dwmac-3.72a"},
+ { .compatible = "snps,dwmac-3.73a"},
+ { .compatible = "snps,dwmac-3.74a"},
{ .compatible = "snps,dwmac-4.00"},
{ .compatible = "snps,dwmac-4.10a"},
{ .compatible = "snps,dwmac"},
--
2.29.2
[PATCH 12/16] net: stmmac: Introduce NIC software reset function
Since we are about to move the IRQs handler setup into the device probe
method, the DW MAC reset procedure needs to be redefined to be performed
with care. We must make sure the IRQs handler isn't executed while the
reset is proceeded and the IRQs are fully masked after that. The later is
required for some early versions of DW GMAC (in our case it's DW GMAC
v3.73a).
Signed-off-by: Serge Semin
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 32 +--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b37f49f3dc03..c4c41b554c6a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1827,6 +1827,34 @@ static void free_dma_desc_resources(struct stmmac_priv
*priv)
free_dma_tx_desc_resources(priv);
}
+/**
+ * stmmac_sw_reset - reset the MAC/DMA/etc state
+ * @priv: driver private structure
+ * Description: Cleanup/reset the DW *MAC registers to their initial state.
+ */
+static int stmmac_sw_reset(struct stmmac_priv *priv)
+{
+ int ret;
+
+ /* Disable the IRQ signal while the reset is in progress so not to
+* interfere with what the main ISR is doing.
+*/
+ disable_irq(priv->dev->irq);
+
+ ret = stmmac_reset(priv, priv->ioaddr);
+
+ /* Make sure all IRQs are disabled by default. Some DW MAC IP-cores
+* like early versions of DW GMAC have MAC and MMC interrupts enabled
+* after reset.
+*/
+ if (!ret)
+ stmmac_disable_irq(priv);
+
+ enable_irq(priv->dev->irq);
+
+ return ret;
+}
+
/**
* stmmac_mac_enable_rx_queues - Enable MAC rx queues
* @priv: driver private structure
@@ -2340,9 +2368,9 @@ static int stmmac_init_dma_engine(struct stmmac_priv
*priv)
if (priv->extend_desc && (priv->mode == STMMAC_RING_MODE))
atds = 1;
- ret = stmmac_reset(priv, priv->ioaddr);
+ ret = stmmac_sw_reset(priv);
if (ret) {
- dev_err(priv->device, "Failed to reset the dma\n");
+ dev_err(priv->device, "Failed to reset the core\n");
return ret;
}
--
2.29.2
[PATCH 10/16] net: stmmac: Convert STMMAC_DOWN flag to STMMAC_UP
The flag name and semantics are misleading. Judging by the code the flag
will be set only if the networking is requested for being reset, while
logically in order to correctly reflect the device state the flag needs to
be also set when the network device isn't opened. Let's convert the flag
to having a positive meaning instead of keeping it being set all the time
the interface is down.
This modification will be also helpful for the case of the IRQs request
being performed in the device probe method. So the driver could
enable/disable the network-related IRQs handlers by synchronous flag
switching together with the IRQs unmasking and masking. Luckily the IRQs
are normally enabled/disable in the late/early network initialization
stages respectively.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index d88bc8af8eaa..ab8b1e04ed22 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -246,7 +246,7 @@ struct stmmac_priv {
};
enum stmmac_state {
- STMMAC_DOWN,
+ STMMAC_UP,
STMMAC_RESET_REQUESTED,
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index fcd59a647b02..f458d728825c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4151,6 +4151,8 @@ static void stmmac_enable_irq(struct stmmac_priv *priv)
stmmac_enable_mac_irq(priv, priv->hw);
+ set_bit(STMMAC_UP, >state);
+
enable_irq(priv->dev->irq);
}
@@ -4165,6 +4167,8 @@ static void stmmac_disable_irq(struct stmmac_priv *priv)
disable_irq(priv->dev->irq);
+ clear_bit(STMMAC_UP, >state);
+
stmmac_disable_mac_irq(priv, priv->hw);
maxq = max(priv->plat->rx_queues_to_use, priv->plat->tx_queues_to_use);
@@ -4213,7 +4217,7 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id)
pm_wakeup_event(priv->device, 0);
/* Check if adapter is up */
- if (test_bit(STMMAC_DOWN, >state))
+ if (!test_bit(STMMAC_UP, >state))
return IRQ_HANDLED;
/* Check if a fatal error happened */
if (stmmac_safety_feat_interrupt(priv))
@@ -4739,7 +4743,7 @@ static const struct net_device_ops stmmac_netdev_ops = {
static void stmmac_reset_subtask(struct stmmac_priv *priv)
{
- if (test_bit(STMMAC_DOWN, >state))
+ if (!test_bit(STMMAC_UP, >state))
return;
netdev_err(priv->dev, "Reset adapter.\n");
@@ -4747,10 +4751,8 @@ static void stmmac_reset_subtask(struct stmmac_priv
*priv)
rtnl_lock();
netif_trans_update(priv->dev);
- set_bit(STMMAC_DOWN, >state);
dev_close(priv->dev);
dev_open(priv->dev, NULL);
- clear_bit(STMMAC_DOWN, >state);
rtnl_unlock();
}
--
2.29.2
[PATCH 06/16] net: stmmac: Extend DMA IRQs enable/disable interface
Similarly to the MAC core IRQs we need to be able to enable/disable all
the DMA-related interrupts by means of the dedicated methods so the DMA
IRQs would be enabled only when they are needed to be enabled (for
instance while the network device being opened) and disabled otherwise.
For that sake and for the sake of unification let's convert the currently
available enable_dma_irq/disable_dma_irq callbacks to fully switching the
DMA IRQs on/off and add the dedicated methods to toggle the DMA Tx/Rx IRQs
when it's required.
Note DMA channels initialization procedure won't enable the DMA IRQs
anymore. Such modification won't break the DMA-related code because the
default macro has both Tx and Rx DMA IRQs flags set anyway. So in order to
make things working as usual we just need to call the
stmmac_enable_dma_irq() method aside with the generic IRQs activating
function.
Signed-off-by: Serge Semin
---
Note folks, in the framework of this commit we've naturally fixed an
invalid default DMA IRQs enable macro usage for the DW MAC v4.10 DMA
initialization. I don't really know why it hasn't been noticed so far
especially seeing the 4.x Normal/Abnormal IRQs bit fields have been
used to enable these IRQs on 4.10a hardware. I leave this commit as is for
now. But if tests prove the bug-fix actuality, then most likely we'll need
to create a dedicated patch to correctly have it backported.
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 33
.../ethernet/stmicro/stmmac/dwmac1000_dma.c | 5 +-
.../ethernet/stmicro/stmmac/dwmac100_dma.c| 5 +-
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 10 ++--
.../net/ethernet/stmicro/stmmac/dwmac4_dma.h | 11 ++--
.../net/ethernet/stmicro/stmmac/dwmac4_lib.c | 51 ---
.../net/ethernet/stmicro/stmmac/dwmac_dma.h | 6 ++-
.../net/ethernet/stmicro/stmmac/dwmac_lib.c | 26 +++---
.../ethernet/stmicro/stmmac/dwxgmac2_dma.c| 31 +++
drivers/net/ethernet/stmicro/stmmac/hwif.h| 12 +++--
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 26 --
11 files changed, 142 insertions(+), 74 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index a5e0eff4a387..35d1aeb20fa9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -285,7 +285,6 @@ static int sun8i_dwmac_dma_reset(void __iomem *ioaddr)
static void sun8i_dwmac_dma_init(void __iomem *ioaddr,
struct stmmac_dma_cfg *dma_cfg, int atds)
{
- writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
writel(0x1FF, ioaddr + EMAC_INT_STA);
}
@@ -337,32 +336,42 @@ static void sun8i_dwmac_dump_mac_regs(struct
mac_device_info *hw,
}
}
-static void sun8i_dwmac_enable_dma_irq(void __iomem *ioaddr, u32 chan,
- bool rx, bool tx)
+static void sun8i_dwmac_enable_dma_irq(void __iomem *ioaddr, u32 chan)
+{
+ writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
+}
+
+static void sun8i_dwmac_switch_dma_rx_irq(void __iomem *ioaddr, u32 chan,
+ bool on)
{
u32 value = readl(ioaddr + EMAC_INT_EN);
- if (rx)
+ if (on)
value |= EMAC_RX_INT;
- if (tx)
- value |= EMAC_TX_INT;
+ else
+ value &= ~EMAC_RX_INT;
writel(value, ioaddr + EMAC_INT_EN);
}
-static void sun8i_dwmac_disable_dma_irq(void __iomem *ioaddr, u32 chan,
- bool rx, bool tx)
+static void sun8i_dwmac_switch_dma_tx_irq(void __iomem *ioaddr, u32 chan,
+ bool on)
{
u32 value = readl(ioaddr + EMAC_INT_EN);
- if (rx)
- value &= ~EMAC_RX_INT;
- if (tx)
+ if (on)
+ value |= EMAC_TX_INT;
+ else
value &= ~EMAC_TX_INT;
writel(value, ioaddr + EMAC_INT_EN);
}
+static void sun8i_dwmac_disable_dma_irq(void __iomem *ioaddr, u32 chan)
+{
+ writel(0, ioaddr + EMAC_INT_EN);
+}
+
static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr, u32 chan)
{
u32 v;
@@ -533,6 +542,8 @@ static const struct stmmac_dma_ops sun8i_dwmac_dma_ops = {
.dma_tx_mode = sun8i_dwmac_dma_operation_mode_tx,
.enable_dma_transmission = sun8i_dwmac_enable_dma_transmission,
.enable_dma_irq = sun8i_dwmac_enable_dma_irq,
+ .switch_dma_rx_irq = sun8i_dwmac_switch_dma_rx_irq,
+ .switch_dma_tx_irq = sun8i_dwmac_switch_dma_tx_irq,
.disable_dma_irq = sun8i_dwmac_disable_dma_irq,
.start_tx = sun8i_dwmac_dma_start_tx,
.stop_tx = sun8i_dwmac_dma_stop_tx,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index bae63e1420f2..c1b79f712323 100644
--- a/drivers/net/ethernet/st
[PATCH 13/16] net: stmmac: Request IRQs at device probe stage
Normally all DW *MAC IRQs are signalled by a single lane called
sbd_intr_o. It is used to raise MAC, DMA, MMC, PMT, GPIO, etc interrupts.
Most of those IRQs are connected with the networking activity of the
controller, so it's ok to have the IRQs setup only while the network is up
and running. But DW MAC GPIOs in general act as an independent signalling
interface, so its interrupts must be handled no matter whether the NIC is
configured or not. In that case the IRQs must be configured on the probe
stage (before DW MAC GPIO chip is registered), which has been provided in
the framework of this commit.
This modification requires a more careful work with the DW MAC network-
related interrupts. They have to be enabled only while the network
interface is opened, and disabled otherwise. Moreover since the interrupts
can be raised by some unrelated source via GPIs, which could be also
marked as system-wake capable, PMT/WoL events are allowed to be
forwarded to the PM-subsystem only when the STMMAC_UP flag is set.
Note by moving the IRQs setup procedure to the probe method we not only
make the code cleaner but also speed up the network interface
initialization/de-initialization process.
Signed-off-by: Serge Semin
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 157 +++---
1 file changed, 96 insertions(+), 61 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c4c41b554c6a..d75c851721f7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2810,9 +2810,6 @@ static int stmmac_hw_setup(struct net_device *dev, bool
init_ptp)
netif_set_real_num_rx_queues(dev, priv->plat->rx_queues_to_use);
netif_set_real_num_tx_queues(dev, priv->plat->tx_queues_to_use);
- /* Enable MAC/MTL/DMA/etc IRQs */
- stmmac_enable_irq(priv);
-
/* Start the ball rolling... */
stmmac_start_all_dma(priv);
@@ -2825,8 +2822,6 @@ static void stmmac_hw_teardown(struct net_device *dev)
stmmac_stop_all_dma(priv);
- stmmac_disable_irq(priv);
-
stmmac_release_ptp(priv);
stmmac_mac_set(priv, priv->ioaddr, false);
@@ -2929,57 +2924,13 @@ static int stmmac_open(struct net_device *dev)
/* We may have called phylink_speed_down before */
phylink_speed_up(priv->phylink);
- /* Request the IRQ lines */
- ret = request_irq(dev->irq, stmmac_interrupt,
- IRQF_SHARED, dev->name, dev);
- if (unlikely(ret < 0)) {
- netdev_err(priv->dev,
- "%s: ERROR: allocating the IRQ %d (error: %d)\n",
- __func__, dev->irq, ret);
- goto irq_error;
- }
-
- /* Request the Wake IRQ in case of another line is used for WoL */
- if (priv->wol_irq != dev->irq) {
- ret = request_irq(priv->wol_irq, stmmac_interrupt,
- IRQF_SHARED, dev->name, dev);
- if (unlikely(ret < 0)) {
- netdev_err(priv->dev,
- "%s: ERROR: allocating the WoL IRQ %d
(%d)\n",
- __func__, priv->wol_irq, ret);
- goto wolirq_error;
- }
- }
-
- /* Request the IRQ lines */
- if (priv->lpi_irq > 0) {
- ret = request_irq(priv->lpi_irq, stmmac_interrupt, IRQF_SHARED,
- dev->name, dev);
- if (unlikely(ret < 0)) {
- netdev_err(priv->dev,
- "%s: ERROR: allocating the LPI IRQ %d
(%d)\n",
- __func__, priv->lpi_irq, ret);
- goto lpiirq_error;
- }
- }
+ stmmac_enable_irq(priv);
stmmac_enable_all_queues(priv);
netif_tx_start_all_queues(priv->dev);
return 0;
-lpiirq_error:
- if (priv->wol_irq != dev->irq)
- free_irq(priv->wol_irq, dev);
-wolirq_error:
- free_irq(dev->irq, dev);
-irq_error:
- phylink_stop(priv->phylink);
-
- for (chan = 0; chan < priv->plat->tx_queues_to_use; chan++)
- hrtimer_cancel(>tx_queue[chan].txtimer);
-
- stmmac_hw_teardown(dev);
init_error:
free_dma_desc_resources(priv);
dma_desc_error:
@@ -3009,12 +2960,8 @@ static int stmmac_release(struct net_device *dev)
for (chan = 0; chan < priv->plat->tx_queues_to_use; chan++)
hrtimer_cancel(>tx_queue[chan].txtimer);
- /* Free the IRQ lines */
- free_irq(dev->irq, dev);
- if (priv->wol_irq != dev->irq)
- free_irq(priv->wol_irq, dev);
- if (priv->l
[PATCH 05/16] net: stmmac: Introduce MAC IRQs enable/disable methods
By design the DW MAC IRQ lane is shared between orthogonal IP-core
functionality like MAC, DMA/MTL, MMC, SMA/MDIO, Safety, GPIOs, etc.
These IRQs can be independently enabled/disabled by means of the
corresponding IRQ enable/mask registers.
In order to have a more flexible way of the device configuration let's
introduce dedicated MAC core IRQs enable/disable interface methods for
each IP-core the driver supports. It will be useful to have the MAC core
IRQs enabled/disabled while the network device is being opened/closed
respectively so to be able to handle the independent IRQs like GPIOs
signaled via the same lane even while the device is released.
The methods responsible for the MAC IRQs (de-)activating are added to
the generic IRQs enable/disable functions. The later ones will be filled
in the following commits with the rest of the interrupts control switchers
and will be used to mask/unmask all the device IRQs while the network
device is closed and unused.
Note the main IRQ signal needs to be masked while the IRQs enable/disable
procedure is in progress, because the IRQs handlers can also read/write
the interrupts mask/enable/status registers. This modification is required
for the case of the IRQs handler being setup at the device probe stage,
which will be introduced later in one of the following up commits.
Signed-off-by: Serge Semin
---
.../ethernet/stmicro/stmmac/dwmac1000_core.c | 28 +
.../net/ethernet/stmicro/stmmac/dwmac4_core.c | 32 +++
.../ethernet/stmicro/stmmac/dwxgmac2_core.c | 15 ++-
drivers/net/ethernet/stmicro/stmmac/hwif.h| 7
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 40 +++
5 files changed, 105 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index 2af4c8ac6fb7..7dc8b254c15a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -95,14 +95,6 @@ static void dwmac1000_core_init(struct mac_device_info *hw,
writel(value, ioaddr + GMAC_CONTROL);
- /* Mask GMAC interrupts */
- value = GMAC_INT_DEFAULT_MASK;
-
- if (hw->pcs)
- value &= ~GMAC_INT_DISABLE_PCS;
-
- writel(value, ioaddr + GMAC_INT_MASK);
-
#ifdef STMMAC_VLAN_TAG_USED
/* Tag detection without filtering */
writel(0x0, ioaddr + GMAC_VLAN_TAG);
@@ -302,6 +294,24 @@ static void dwmac1000_pmt(struct mac_device_info *hw,
unsigned long mode)
writel(pmt, ioaddr + GMAC_PMT);
}
+static void dwmac1000_enable_mac_irq(struct mac_device_info *hw)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 value = GMAC_INT_DEFAULT_MASK;
+
+ if (hw->pcs)
+ value &= ~GMAC_INT_DISABLE_PCS;
+
+ writel(value, ioaddr + GMAC_INT_MASK);
+}
+
+static void dwmac1000_disable_mac_irq(struct mac_device_info *hw)
+{
+ void __iomem *ioaddr = hw->pcsr;
+
+ writel(0x7FF, ioaddr + GMAC_INT_MASK);
+}
+
/* RGMII or SMII interface */
static void dwmac1000_rgsmii(void __iomem *ioaddr, struct stmmac_extra_stats
*x)
{
@@ -548,6 +558,8 @@ const struct stmmac_ops dwmac1000_ops = {
.set_mac = stmmac_set_mac,
.rx_ipc = dwmac1000_rx_ipc_enable,
.dump_regs = dwmac1000_dump_regs,
+ .enable_mac_irq = dwmac1000_enable_mac_irq,
+ .disable_mac_irq = dwmac1000_disable_mac_irq,
.host_irq_status = dwmac1000_irq_status,
.set_filter = dwmac1000_set_filter,
.flow_ctrl = dwmac1000_flow_ctrl,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 29f765a246a0..8fc8d3cd238d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -46,14 +46,6 @@ static void dwmac4_core_init(struct mac_device_info *hw,
}
writel(value, ioaddr + GMAC_CONFIG);
-
- /* Enable GMAC interrupts */
- value = GMAC_INT_DEFAULT_ENABLE;
-
- if (hw->pcs)
- value |= GMAC_PCS_IRQ_DEFAULT;
-
- writel(value, ioaddr + GMAC_INT_EN);
}
static void dwmac4_rx_queue_enable(struct mac_device_info *hw,
@@ -777,6 +769,24 @@ static void dwmac4_get_adv_lp(void __iomem *ioaddr, struct
rgmii_adv *adv)
dwmac_get_adv_lp(ioaddr, GMAC_PCS_BASE, adv);
}
+static void dwmac4_enable_mac_irq(struct mac_device_info *hw)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 value = GMAC_INT_DEFAULT_ENABLE;
+
+ if (hw->pcs)
+ value |= GMAC_PCS_IRQ_DEFAULT;
+
+ writel(value, ioaddr + GMAC_INT_EN);
+}
+
+static void dwmac4_disable_mac_irq(struct mac_device_info *hw)
+{
+ void __iomem *ioaddr = hw->pcsr;
+
+ writel(0, ioaddr + GMAC_INT_EN);
+}
+
/* RGMII or SMII interface */
static void dwmac4_phystatus(void __iomem *ioaddr, struct stmmac_extra_stats
*x
[PATCH 03/16] net: stmmac: Introduce MAC core cleanup method
In some DW MAC IP-core configurations and hardware setups it might be
necessary not to reset the MAC while the device is probed and added to
the system for a subsequent use. For instance having the MAC synthesized
with GPIs and GPOs requires that, so the GPIOs state would be in a
coherent state while GPIO-chip is registered in the kernel.
Since for such configurations the reset is prohibited let's provide the
MAC core cleanup method to get the basic core registers back to the
initial state so further device initialization would work with the values
it has been designed to expect.
That method will be useful for devices with GPIOs support. For now we've
got a chip with DW GMAC IP and GPIOs synthesied, so the cleanup method is
added to the corresponding driver sub-module only.
Signed-off-by: Serge Semin
---
.../ethernet/stmicro/stmmac/dwmac1000_core.c | 33 +++
drivers/net/ethernet/stmicro/stmmac/hwif.h| 4 +++
2 files changed, 37 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index 6b9a4f54b93c..2af4c8ac6fb7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -21,6 +21,38 @@
#include "stmmac_pcs.h"
#include "dwmac1000.h"
+static void dwmac1000_core_clean(void __iomem *ioaddr)
+{
+ int idx;
+
+ /* Clean the basic MAC registers up. Note the MAC interrupts are
+* enabled by default after reset. Let's mask them out so not to have
+* any spurious MAC-related IRQ generated during the cleanup
+* procedure.
+*/
+ writel(0x7FF, ioaddr + GMAC_INT_MASK);
+ writel(0, ioaddr + GMAC_CONTROL);
+ writel(0, ioaddr + GMAC_FRAME_FILTER);
+ writel(0, ioaddr + GMAC_HASH_HIGH);
+ writel(0, ioaddr + GMAC_HASH_LOW);
+ writel(0, ioaddr + GMAC_FLOW_CTRL);
+ writel(0, ioaddr + GMAC_VLAN_TAG);
+ writel(0, ioaddr + GMAC_DEBUG);
+ writel(0x8000, ioaddr + GMAC_PMT);
+ writel(0, ioaddr + LPI_CTRL_STATUS);
+ writel(0x03e8, ioaddr + LPI_TIMER_CTRL);
+ for (idx = 0; idx < 15; ++idx) {
+ writel(0x, ioaddr + GMAC_ADDR_HIGH(idx));
+ writel(0x, ioaddr + GMAC_ADDR_LOW(idx));
+ }
+ writel(0, ioaddr + GMAC_PCS_BASE);
+ writel(0, ioaddr + GMAC_RGSMIIIS);
+ writel(0x1, ioaddr + GMAC_MMC_CTRL);
+ readl(ioaddr + GMAC_INT_STATUS);
+ readl(ioaddr + GMAC_PMT);
+ readl(ioaddr + LPI_CTRL_STATUS);
+}
+
static void dwmac1000_core_init(struct mac_device_info *hw,
struct net_device *dev)
{
@@ -511,6 +543,7 @@ static void dwmac1000_set_mac_loopback(void __iomem
*ioaddr, bool enable)
}
const struct stmmac_ops dwmac1000_ops = {
+ .core_clean = dwmac1000_core_clean,
.core_init = dwmac1000_core_init,
.set_mac = stmmac_set_mac,
.rx_ipc = dwmac1000_rx_ipc_enable,
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h
b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index b40b2e0667bb..3f5eed8333a5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -287,6 +287,8 @@ struct stmmac_est;
/* Helpers to program the MAC core */
struct stmmac_ops {
+ /* MAC core cleanup */
+ void (*core_clean)(void __iomem *ioaddr);
/* MAC core initialization */
void (*core_init)(struct mac_device_info *hw, struct net_device *dev);
/* Enable the MAC RX/TX */
@@ -396,6 +398,8 @@ struct stmmac_ops {
bool enable);
};
+#define stmmac_core_clean(__priv, __args...) \
+ stmmac_do_void_callback(__priv, mac, core_clean, __args)
#define stmmac_core_init(__priv, __args...) \
stmmac_do_void_callback(__priv, mac, core_init, __args)
#define stmmac_mac_set(__priv, __args...) \
--
2.29.2
[PATCH 11/16] net: stmmac: Add STMMAC state getter
Since the STMMAC driver has internal STMMAC_UP flag declared to indicate
the STMMAC network setup state, let's define the flag getter and use it in
the driver code to get the current NIC state. We can also convert the
netif_running() method invocation to calling the stmmac_is_up()
function instead because the latter gives more accurate notion of the
network state as the flag is set only after all the NIC initializations
are finished.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 +
.../ethernet/stmicro/stmmac/stmmac_ethtool.c | 4 ++-
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 34 +--
3 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index ab8b1e04ed22..c993dcd1c7d9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -263,6 +263,7 @@ int stmmac_dvr_remove(struct device *dev);
int stmmac_dvr_probe(struct device *device,
struct plat_stmmacenet_data *plat_dat,
struct stmmac_resources *res);
+bool stmmac_is_up(struct stmmac_priv *priv);
void stmmac_disable_eee_mode(struct stmmac_priv *priv);
bool stmmac_eee_init(struct stmmac_priv *priv);
int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 0ed287edbc2d..19debbd7f981 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -402,7 +402,9 @@ static void stmmac_ethtool_setmsglevel(struct net_device
*dev, u32 level)
static int stmmac_check_if_running(struct net_device *dev)
{
- if (!netif_running(dev))
+ struct stmmac_priv *priv = netdev_priv(dev);
+
+ if (!stmmac_is_up(priv))
return -EBUSY;
return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f458d728825c..b37f49f3dc03 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2804,6 +2804,20 @@ static void stmmac_hw_teardown(struct net_device *dev)
stmmac_mac_set(priv, priv->ioaddr, false);
}
+/**
+ * stmmac_is_up - test STMMAC state
+ * @priv: driver private structure
+ * Description:
+ * Detects the current network adapter state just by testing the MAC
+ * initialization completion flag.
+ * Return value:
+ * true if the STMMAC network is setup, false otherwise.
+ */
+bool stmmac_is_up(struct stmmac_priv *priv)
+{
+ return test_bit(STMMAC_UP, >state);
+}
+
/**
* stmmac_open - open entry point of the driver
* @dev : pointer to the device structure.
@@ -4046,7 +4060,7 @@ static int stmmac_change_mtu(struct net_device *dev, int
new_mtu)
txfifosz /= priv->plat->tx_queues_to_use;
- if (netif_running(dev)) {
+ if (stmmac_is_up(priv)) {
netdev_err(priv->dev, "must be stopped to change its MTU\n");
return -EBUSY;
}
@@ -4217,7 +4231,7 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id)
pm_wakeup_event(priv->device, 0);
/* Check if adapter is up */
- if (!test_bit(STMMAC_UP, >state))
+ if (!stmmac_is_up(priv))
return IRQ_HANDLED;
/* Check if a fatal error happened */
if (stmmac_safety_feat_interrupt(priv))
@@ -4290,7 +4304,7 @@ static int stmmac_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
struct stmmac_priv *priv = netdev_priv (dev);
int ret = -EOPNOTSUPP;
- if (!netif_running(dev))
+ if (!stmmac_is_up(priv))
return -EINVAL;
switch (cmd) {
@@ -4743,7 +4757,7 @@ static const struct net_device_ops stmmac_netdev_ops = {
static void stmmac_reset_subtask(struct stmmac_priv *priv)
{
- if (!test_bit(STMMAC_UP, >state))
+ if (!stmmac_is_up(priv))
return;
netdev_err(priv->dev, "Reset adapter.\n");
@@ -4915,7 +4929,7 @@ int stmmac_reinit_queues(struct net_device *dev, u32
rx_cnt, u32 tx_cnt)
struct stmmac_priv *priv = netdev_priv(dev);
int ret = 0;
- if (netif_running(dev))
+ if (stmmac_is_up(priv))
stmmac_release(dev);
stmmac_napi_del(dev);
@@ -4925,7 +4939,7 @@ int stmmac_reinit_queues(struct net_device *dev, u32
rx_cnt, u32 tx_cnt)
stmmac_napi_add(dev);
- if (netif_running(dev))
+ if (stmmac_is_up(priv))
ret = stmmac_open(dev);
return ret;
@@ -4936,13 +4950,13 @@ int stmmac_reinit_ringparam(struct net_device *dev, u32
rx_size, u32 tx_size)
struct stmmac_priv *priv = netdev_priv(dev);
[PATCH 09/16] net: stmmac: Disable MMC IRQs in the generic IRQs disable method
MMC IRQs aren't handled by the main ISR, so for the sake of the code
coherency let's move the MMC IRQs disabling procedure to the generic IRQs
de-activating method. By doing so we've finally finished filling the
generic IRQs enable/disable functions up with the individual
MAC/MTL/DMA/etc interrupt control methods.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ddcd82d02c27..fcd59a647b02 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2274,8 +2274,6 @@ static void stmmac_mmc_setup(struct stmmac_priv *priv)
unsigned int mode = MMC_CNTRL_RESET_ON_READ | MMC_CNTRL_COUNTER_RESET |
MMC_CNTRL_PRESET | MMC_CNTRL_FULL_HALF_PRESET;
- stmmac_mmc_intr_all_mask(priv, priv->mmcaddr);
-
if (priv->dma_cap.rmon) {
stmmac_mmc_ctrl(priv, priv->mmcaddr, mode);
memset(>mmc, 0, sizeof(struct stmmac_counters));
@@ -4182,6 +4180,8 @@ static void stmmac_disable_irq(struct stmmac_priv *priv)
if (priv->dma_cap.asp)
stmmac_disable_safety_feat_irq(priv, priv->ioaddr);
+ stmmac_mmc_intr_all_mask(priv, priv->mmcaddr);
+
enable_irq(priv->dev->irq);
}
--
2.29.2
[PATCH 07/16] net: stmmac: Introduce MTL IRQs enable/disable methods
Aside with the DMA and MAC IRQs enable/disable methods the MTL IRQs state
regulation callbacks will be used to activate/de-activate the
network-related IRQs while the DW MAC network device is opened, up and
running/closed, down and stopped.
Note the MTL IRQs are enabled for the Rx Queues only in the framework of
the DMA operation mode configuration procedure as it has been done before
this commit (stmmac_dma_operation_mode() method). But in future it may
change that's why we need to have an additional "bool tx" argument.
Moreover there is no point in preserving the MTL IRQs interrupts control
register content for both DW MAC 4.x and DW xGMAC as it is related to the
MTL IRQs enable/disable configs only, which are tuned by the provided
methods and aren't touched by any other function. Thus we disable the rest
of the unsupported IRQs so not to confuse the MTL IRQs status handler.
Also note there is no need in enabling the MTL IRQs in the
stmmac_set_dma_operation_mode() method, because the later is called from
the DMA IRQ context and doesn't really intent the MTL IRQs setup change
anyway.
Signed-off-by: Serge Semin
---
.../net/ethernet/stmicro/stmmac/dwmac4_core.c | 23 +++
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 7 +-
.../ethernet/stmicro/stmmac/dwxgmac2_core.c | 21 +
.../ethernet/stmicro/stmmac/dwxgmac2_dma.c| 4
drivers/net/ethernet/stmicro/stmmac/hwif.h| 8 +++
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 14 +--
6 files changed, 65 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 8fc8d3cd238d..9ad48a0f96a6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -820,6 +820,23 @@ static void dwmac4_phystatus(void __iomem *ioaddr, struct
stmmac_extra_stats *x)
}
}
+static void dwmac4_enable_mtl_irq(void __iomem *ioaddr, u32 chan,
+ bool rx, bool tx)
+{
+ u32 value = 0;
+
+ /* Enable just MTL RX overflow IRQ for now */
+ if (rx)
+ value |= MTL_RX_OVERFLOW_INT_EN;
+
+ writel(value, ioaddr + MTL_CHAN_INT_CTRL(chan));
+}
+
+static void dwmac4_disable_mtl_irq(void __iomem *ioaddr, u32 chan)
+{
+ writel(0, ioaddr + MTL_CHAN_INT_CTRL(chan));
+}
+
static int dwmac4_irq_mtl_status(struct mac_device_info *hw, u32 chan)
{
void __iomem *ioaddr = hw->pcsr;
@@ -1190,6 +1207,8 @@ const struct stmmac_ops dwmac4_ops = {
.enable_mac_irq = dwmac4_enable_mac_irq,
.disable_mac_irq = dwmac4_disable_mac_irq,
.host_irq_status = dwmac4_irq_status,
+ .enable_mtl_irq = dwmac4_enable_mtl_irq,
+ .disable_mtl_irq = dwmac4_disable_mtl_irq,
.host_mtl_irq_status = dwmac4_irq_mtl_status,
.flow_ctrl = dwmac4_flow_ctrl,
.pmt = dwmac4_pmt,
@@ -1234,6 +1253,8 @@ const struct stmmac_ops dwmac410_ops = {
.enable_mac_irq = dwmac4_enable_mac_irq,
.disable_mac_irq = dwmac4_disable_mac_irq,
.host_irq_status = dwmac4_irq_status,
+ .enable_mtl_irq = dwmac4_enable_mtl_irq,
+ .disable_mtl_irq = dwmac4_disable_mtl_irq,
.host_mtl_irq_status = dwmac4_irq_mtl_status,
.flow_ctrl = dwmac4_flow_ctrl,
.pmt = dwmac4_pmt,
@@ -1281,6 +1302,8 @@ const struct stmmac_ops dwmac510_ops = {
.enable_mac_irq = dwmac4_enable_mac_irq,
.disable_mac_irq = dwmac4_disable_mac_irq,
.host_irq_status = dwmac4_irq_status,
+ .enable_mtl_irq = dwmac4_enable_mtl_irq,
+ .disable_mtl_irq = dwmac4_disable_mtl_irq,
.host_mtl_irq_status = dwmac4_irq_mtl_status,
.flow_ctrl = dwmac4_flow_ctrl,
.pmt = dwmac4_pmt,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 924abda6c131..11bf0167e438 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -201,7 +201,7 @@ static void dwmac4_dma_rx_chan_op_mode(void __iomem
*ioaddr, int mode,
u32 channel, int fifosz, u8 qmode)
{
unsigned int rqs = fifosz / 256 - 1;
- u32 mtl_rx_op, mtl_rx_int;
+ u32 mtl_rx_op;
mtl_rx_op = readl(ioaddr + MTL_CHAN_RX_OP_MODE(channel));
@@ -262,11 +262,6 @@ static void dwmac4_dma_rx_chan_op_mode(void __iomem
*ioaddr, int mode,
}
writel(mtl_rx_op, ioaddr + MTL_CHAN_RX_OP_MODE(channel));
-
- /* Enable MTL RX overflow */
- mtl_rx_int = readl(ioaddr + MTL_CHAN_INT_CTRL(channel));
- writel(mtl_rx_int | MTL_RX_OVERFLOW_INT_EN,
- ioaddr + MTL_CHAN_INT_CTRL(channel));
}
static void dwmac4_dma_tx_chan_op_mode(void __iomem *ioaddr, int mode,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
b/drivers/net/ethernet/s
[PATCH 04/16] net: stmmac: Introduce DMA core cleanup method
Similarly to the MAC core cleanup method let's introduce the DMA core
cleanup method, since we need have a way to get the DMA registers back
to their initial state while the whole interface reset is unavailable for
the particular DW MAC IP-core setup, like in case of GPIs and GPOs
support.
For now we've created the DMA cleanup method for the DW GMAC IP only,
since the chip we've got has been equipped with that IP and we lack the
documents to add and test the rest of the IPs support.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 12
drivers/net/ethernet/stmicro/stmmac/hwif.h | 3 +++
4 files changed, 17 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index 2a04d9d45160..bae63e1420f2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -246,6 +246,7 @@ static void dwmac1000_rx_watchdog(void __iomem *ioaddr, u32
riwt,
const struct stmmac_dma_ops dwmac1000_dma_ops = {
.reset = dwmac_dma_reset,
+ .clean = dwmac_dma_clean,
.init = dwmac1000_dma_init,
.init_rx_chan = dwmac_dma_init_rx,
.init_tx_chan = dwmac_dma_init_tx,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
b/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
index fa919bf75e19..f6e759d039d7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
@@ -145,5 +145,6 @@ void dwmac_dma_stop_rx(void __iomem *ioaddr, u32 chan);
int dwmac_dma_interrupt(void __iomem *ioaddr, struct stmmac_extra_stats *x,
u32 chan);
int dwmac_dma_reset(void __iomem *ioaddr);
+void dwmac_dma_clean(void __iomem *ioaddr);
#endif /* __DWMAC_DMA_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index 6ddfc689e77b..2186e95d5aa4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -26,6 +26,18 @@ int dwmac_dma_reset(void __iomem *ioaddr)
1, 20);
}
+void dwmac_dma_clean(void __iomem *ioaddr)
+{
+ /* Clean the basic DMA registers up */
+ writel(0, ioaddr + DMA_INTR_ENA);
+ writel(0x00020100, ioaddr + DMA_BUS_MODE);
+ writel(0, ioaddr + DMA_RCV_BASE_ADDR);
+ writel(0, ioaddr + DMA_TX_BASE_ADDR);
+ writel(0x0010, ioaddr + DMA_CONTROL);
+ writel(0x00110001, ioaddr + DMA_AXI_BUS_MODE);
+ writel(0x0001, ioaddr + DMA_STATUS);
+}
+
/* CSR1 enables the transmit DMA to check for new descriptor */
void dwmac_enable_dma_transmission(void __iomem *ioaddr)
{
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h
b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 3f5eed8333a5..dea5a4d17677 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -169,6 +169,7 @@ struct dma_features;
struct stmmac_dma_ops {
/* DMA core initialization */
int (*reset)(void __iomem *ioaddr);
+ void (*clean)(void __iomem *ioaddr);
void (*init)(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg,
int atds);
void (*init_chan)(void __iomem *ioaddr,
@@ -219,6 +220,8 @@ struct stmmac_dma_ops {
#define stmmac_reset(__priv, __args...) \
stmmac_do_callback(__priv, dma, reset, __args)
+#define stmmac_dma_clean(__priv, __args...) \
+ stmmac_do_void_callback(__priv, dma, clean, __args)
#define stmmac_dma_init(__priv, __args...) \
stmmac_do_void_callback(__priv, dma, init, __args)
#define stmmac_init_chan(__priv, __args...) \
--
2.29.2
[PATCH 02/16] dt-bindings: net: Add Baikal-T1 GMAC bindings
Baikal-T1 SoC is equipped with two DW GMAC v3.73a-based 1GBE ethernet
interfaces synthesized with: RGMII PHY interface, AXI-DMA and APB3 CSR,
16KB Tx/Rx FIFOs and PBL up to half of that, PTP, PMT, TCP/IP CoE, up to 4
outstanding AXI read/write requests, maximum AXI burst length of 16 beats,
up to eight MAC address slots, one GPI and one GPO ports. Generic DW
MAC/STMMAC driver will easily handle the DT-node describing the Baikal-T1
GMAC network devices, but the bindings still needs to be created to have a
better understanding of what the interface looks like.
Signed-off-by: Serge Semin
---
Rob, please note I couldn't declare the axi-config object properties constraints
without specifying the properties type and description. If I remove them the
dt_binding_check will curse with the error:
>> .../baikal,bt1-gmac.yaml: properties:axi-config:properties:snps,blen:
>> 'description' is a required property
>> .../baikal,bt1-gmac.yaml: properties:axi-config:properties:snps,wr_osr_lmt:
>> 'oneOf' conditional failed, one must be fixed:
'type' is a required property
Additional properties are not allowed ('maximum' was unexpected)
>> ...
I did't know what to do with these errors, so I just created normal sub-node
properties with stricter constraints than they are specified in the main
snps,dwmac.yaml schema. Any suggestion what is a better way to apply
additional constraints on sub-node properties?
---
.../bindings/net/baikal,bt1-gmac.yaml | 150 ++
1 file changed, 150 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/baikal,bt1-gmac.yaml
diff --git a/Documentation/devicetree/bindings/net/baikal,bt1-gmac.yaml
b/Documentation/devicetree/bindings/net/baikal,bt1-gmac.yaml
new file mode 100644
index ..30ab74a9023d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/baikal,bt1-gmac.yaml
@@ -0,0 +1,150 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/baikal,bt1-gmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Baikal-T1 DW GMAC Network Interface
+
+maintainers:
+ - Serge Semin
+
+description:
+ Baikal-T1 is equipped with two DW GMAC v3.73a network interfaces. Each of
+ them doesn't have any on-SoC PHY attached, but instead exports RGMII
+ interface to connect any compatible physical layer transceiver.
+
+select:
+ properties:
+compatible:
+ contains:
+const: baikal,bt1-gmac
+
+ required:
+- compatible
+
+allOf:
+ - $ref: "snps,dwmac.yaml#"
+
+properties:
+ compatible:
+items:
+ - const: baikal,bt1-gmac
+ - const: snps,dwmac-3.73a
+ - const: snps,dwmac
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ interrupt-names:
+const: macirq
+
+ clocks:
+minItems: 4
+maxItems: 4
+
+ clock-names:
+minItems: 4
+maxItems: 4
+contains:
+ enum:
+- stmmaceth
+- pclk
+- tx
+- ptp_ref
+
+ ngpios:
+description:
+ Baikal-T1 GMAC have been created with one GPI and one GPO ports
+ enabled. So there are total two GPIOs available.
+const: 2
+
+ gpio-controller: true
+
+ "#gpio-cells":
+const: 2
+
+ tx-internal-delay-ps:
+description:
+ DW MAC Tx clocks generator has been designed to always add 2ns delay
+ of TXC with respect to TXD.
+const: 2000
+
+ rx-fifo-depth:
+const: 16384
+
+ tx-fifo-depth:
+const: 16384
+
+ axi-config:
+type: object
+
+properties:
+ snps,wr_osr_lmt:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Maximum write outstanding requests is limited with 4
+maximum: 3
+
+ snps,rd_osr_lmt:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Maximum read outstanding requests is limited with 4
+maximum: 3
+
+ snps,blen:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: AXI-bus burst length width is limited with just 4 bits
+items:
+ enum: [16, 8, 4, 0]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - phy-mode
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ethernet@1f05e000 {
+ compatible = "baikal,bt1-dwmac", "snps,dwmac-3.73a", "snps,dwmac";
+ reg = <0x1f05e000 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <2>;
+
+ interrupts = <72>;
+ interrupt-names = "macirq";
+
+ clocks = <_sys 1>, <_axi 3>, <_sys 2>, <_sys 3>;
+ clock-names = "pclk", "stmmaceth", "tx", "ptp_ref";
+
+ resets = <_axi 3>;
+ reset-names = "stmmaceth";
+
+ ngpios
[PATCH 00/16] net: stmmac: Add DW MAC GPIOs and Baikal-T1 GMAC support
to be applied on top of the last revision of the next patchset: Link: https://lore.kernel.org/netdev/20210208140341.9271-1-sergey.se...@baikalelectronics.ru otherwise a few patches won't get merged in cleanly. Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Pavel Parkhomenko Cc: Vyacheslav Mitrofanov Cc: Maxime Coquelin Cc: net...@vger.kernel.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-arm-ker...@lists.infradead.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Serge Semin (16): dt-bindings: net: dwmac: Add DW GMAC GPIOs properties dt-bindings: net: Add Baikal-T1 GMAC bindings net: stmmac: Introduce MAC core cleanup method net: stmmac: Introduce DMA core cleanup method net: stmmac: Introduce MAC IRQs enable/disable methods net: stmmac: Extend DMA IRQs enable/disable interface net: stmmac: Introduce MTL IRQs enable/disable methods net: stmmac: Introduce Safety Feature IRQs enable/disable methods net: stmmac: Disable MMC IRQs in the generic IRQs disable method net: stmmac: Convert STMMAC_DOWN flag to STMMAC_UP net: stmmac: Add STMMAC state getter net: stmmac: Introduce NIC software reset function net: stmmac: Request IRQs at device probe stage net: stmmac: Add Generic DW MAC GPIO port driver net: stmmac: Add DW GMAC GPIOs support net: stmmac: Add DW MAC IPs of 3.72a/3.73a/3.74a versions .../bindings/net/baikal,bt1-gmac.yaml | 150 +++ .../devicetree/bindings/net/snps,dwmac.yaml | 17 + .../ethernet/stmicro/stmmac.rst | 4 + drivers/net/ethernet/stmicro/stmmac/Kconfig | 2 + drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +- drivers/net/ethernet/stmicro/stmmac/common.h | 1 + .../ethernet/stmicro/stmmac/dwmac-generic.c | 3 + .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 33 +- .../net/ethernet/stmicro/stmmac/dwmac1000.h | 11 + .../ethernet/stmicro/stmmac/dwmac1000_core.c | 101 - .../ethernet/stmicro/stmmac/dwmac1000_dma.c | 6 +- .../ethernet/stmicro/stmmac/dwmac100_dma.c| 5 +- .../net/ethernet/stmicro/stmmac/dwmac4_core.c | 57 ++- .../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 17 +- .../net/ethernet/stmicro/stmmac/dwmac4_dma.h | 11 +- .../net/ethernet/stmicro/stmmac/dwmac4_lib.c | 51 ++- drivers/net/ethernet/stmicro/stmmac/dwmac5.c | 36 +- drivers/net/ethernet/stmicro/stmmac/dwmac5.h | 2 + .../net/ethernet/stmicro/stmmac/dwmac_dma.h | 7 +- .../net/ethernet/stmicro/stmmac/dwmac_lib.c | 38 +- .../ethernet/stmicro/stmmac/dwxgmac2_core.c | 76 +++- .../ethernet/stmicro/stmmac/dwxgmac2_dma.c| 35 +- drivers/net/ethernet/stmicro/stmmac/hwif.c| 3 + drivers/net/ethernet/stmicro/stmmac/hwif.h| 55 ++- drivers/net/ethernet/stmicro/stmmac/stmmac.h | 22 +- .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 4 +- .../net/ethernet/stmicro/stmmac/stmmac_gpio.c | 400 ++ .../net/ethernet/stmicro/stmmac/stmmac_main.c | 323 ++ .../ethernet/stmicro/stmmac/stmmac_platform.c | 5 + include/linux/stmmac.h| 1 + 30 files changed, 1271 insertions(+), 207 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/baikal,bt1-gmac.yaml create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_gpio.c -- 2.29.2
[PATCH 01/16] dt-bindings: net: dwmac: Add DW GMAC GPIOs properties
Synopsys DesignWare Ethernet controllers can be synthesized with General-Purpose IOs support. GPIOs can work either as inputs or as outputs thus belong to the gpi_i and gpo_o ports respectively. The ports width (number of possible inputs/outputs) and the configuration registers layout depend on the IP-core version. For instance, DW GMAC can have from 0 to 4 GPIs and from 0 to 4 GPOs, while DW xGMAC have a wider ports width up to 16 pins of each one. So the DW MAC DT-node can be equipped with "ngpios" property, which can't have a value greater than 32, standard GPIO-related properties like "gpio-controller" and "#gpio-cells", and, if GPIs are supposed to be detected, IRQ-controller related properties. Signed-off-by: Serge Semin --- .../devicetree/bindings/net/snps,dwmac.yaml | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index bdc437b14878..fcca23d3727e 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -110,6 +110,23 @@ properties: reset-names: const: stmmaceth + ngpios: +description: + Total number of GPIOs the MAC supports. The property shall include both + the GPI and GPO ports width. +minimum: 1 +maximum: 32 + + gpio-controller: true + + "#gpio-cells": +const: 2 + + interrupt-controller: true + + "#interrupt-cells": +const: 2 + mac-mode: $ref: ethernet-controller.yaml#/properties/phy-connection-type description: -- 2.29.2
[PATCH 15/20] net: stmmac: Discard STMMAC_RESETING flag
That flag is totally useless. It's set inside a non-reentrant
mutex-protected section. For the same reason the test-and-set loop is also
pointless. The flag is also unused anywhere else in the driver. So just
drop it.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 -
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ---
2 files changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index e444b1b237c0..3e2bf7e2dafb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -248,7 +248,6 @@ struct stmmac_priv {
enum stmmac_state {
STMMAC_DOWN,
STMMAC_RESET_REQUESTED,
- STMMAC_RESETING,
STMMAC_SERVICE_SCHED,
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index abe8db9965f4..16e08cfaadf0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4669,14 +4669,11 @@ static void stmmac_reset_subtask(struct stmmac_priv
*priv)
rtnl_lock();
netif_trans_update(priv->dev);
- while (test_and_set_bit(STMMAC_RESETING, >state))
- usleep_range(1000, 2000);
set_bit(STMMAC_DOWN, >state);
dev_close(priv->dev);
dev_open(priv->dev, NULL);
clear_bit(STMMAC_DOWN, >state);
- clear_bit(STMMAC_RESETING, >state);
rtnl_unlock();
}
--
2.29.2
[PATCH 19/20] net: stmmac: Move DMA stop procedure to HW-setup antagonist
The DMA-channels enabling procedure is performed in the framework of the
the DW *MAC hardware setup method. For the sake of the driver code
coherency let's move the DMA-channels stop function invocation to the
HW-setup antagonist method - stmmac_hw_teardown(). The latter is called in
the stmmac_hw_setup() error path and in the network device release
callback. So by introducing this alteration we not only improve the code
readability, but also make the stmmac_hw_teardown() doing better the HW
cleanup work.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d6446aa712e1..3c03b773295a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2792,6 +2792,8 @@ static void stmmac_hw_teardown(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
+ stmmac_stop_all_dma(priv);
+
stmmac_release_ptp(priv);
}
@@ -2970,9 +2972,6 @@ static int stmmac_release(struct net_device *dev)
del_timer_sync(>eee_ctrl_timer);
}
- /* Stop TX/RX DMA and clear the descriptors */
- stmmac_stop_all_dma(priv);
-
/* Cleanup HW setup */
stmmac_hw_teardown(dev);
--
2.29.2
[PATCH 18/20] net: stmmac: Move PTP clock enabling to PTP-init method
That clock is purely dedicated for the PTP feature of DW *MAC. From the
driver readability and maintainability point of the view it's better to
have it enabled/disable in the PTP interface init/release methods. Let's
do that by moving the clock prepare/enable procedure invocation to the
stmmac_init_ptp() method and adding the clock disable/unprepare function
call to stmmac_release_ptp(). Since the clock is now handled in the
framework of the PTP-interface related initializers/de-initializers we
need to call the stmmac_release_ptp() method in the HW-setup antagonist -
stmmac_hw_teardown(). Thus call the later one when the network device is
closed to clean the PTP-interface too.
Signed-off-by: Serge Semin
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 25 +--
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f3ced94b3f4e..d6446aa712e1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -761,10 +761,18 @@ static int stmmac_hwtstamp_get(struct net_device *dev,
struct ifreq *ifr)
static int stmmac_init_ptp(struct stmmac_priv *priv)
{
bool xmac = priv->plat->has_gmac4 || priv->plat->has_xgmac;
+ int ret;
if (!(priv->dma_cap.time_stamp || priv->dma_cap.atime_stamp))
return -EOPNOTSUPP;
+ ret = clk_prepare_enable(priv->plat->clk_ptp_ref);
+ if (ret) {
+ netdev_warn(priv->dev, "failed to enable PTP ref-clock: %d\n",
+ ret);
+ return ret;
+ }
+
priv->adv_ts = 0;
/* Check if adv_ts can be enabled for dwmac 4.x / xgmac core */
if (xmac && priv->dma_cap.atime_stamp)
@@ -790,8 +798,12 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
static void stmmac_release_ptp(struct stmmac_priv *priv)
{
- clk_disable_unprepare(priv->plat->clk_ptp_ref);
+ if (!(priv->dma_cap.time_stamp || priv->dma_cap.atime_stamp))
+ return;
+
stmmac_ptp_unregister(priv);
+
+ clk_disable_unprepare(priv->plat->clk_ptp_ref);
}
/**
@@ -2716,10 +2728,6 @@ static int stmmac_hw_setup(struct net_device *dev, bool
init_ptp)
stmmac_mmc_setup(priv);
if (init_ptp) {
- ret = clk_prepare_enable(priv->plat->clk_ptp_ref);
- if (ret < 0)
- netdev_warn(priv->dev, "failed to enable PTP reference
clock: %d\n", ret);
-
ret = stmmac_init_ptp(priv);
if (ret == -EOPNOTSUPP)
netdev_warn(priv->dev, "PTP not supported by HW\n");
@@ -2784,7 +2792,7 @@ static void stmmac_hw_teardown(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
- clk_disable_unprepare(priv->plat->clk_ptp_ref);
+ stmmac_release_ptp(priv);
}
/**
@@ -2965,6 +2973,9 @@ static int stmmac_release(struct net_device *dev)
/* Stop TX/RX DMA and clear the descriptors */
stmmac_stop_all_dma(priv);
+ /* Cleanup HW setup */
+ stmmac_hw_teardown(dev);
+
/* Release and free the Rx/Tx resources */
free_dma_desc_resources(priv);
@@ -2973,8 +2984,6 @@ static int stmmac_release(struct net_device *dev)
netif_carrier_off(dev);
- stmmac_release_ptp(priv);
-
return 0;
}
--
2.29.2
[PATCH 20/20] net: stmmac: Move MAC Tx/Rx disabling to HW-setup antagonist
Since MAC Tx/Rx activity is enabled in the core hardware setup procedure it would be logically correct to it disabled in the HW-setup antagonist - stmmac_hw_teardown(). Let's do that to improve the driver code coherency and thus readability. Signed-off-by: Serge Semin --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 3c03b773295a..f70cab9f46d9 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -2795,6 +2795,8 @@ static void stmmac_hw_teardown(struct net_device *dev) stmmac_stop_all_dma(priv); stmmac_release_ptp(priv); + + stmmac_mac_set(priv, priv->ioaddr, false); } /** @@ -2978,9 +2980,6 @@ static int stmmac_release(struct net_device *dev) /* Release and free the Rx/Tx resources */ free_dma_desc_resources(priv); - /* Disable the MAC Rx/Tx */ - stmmac_mac_set(priv, priv->ioaddr, false); - netif_carrier_off(dev); return 0; -- 2.29.2
[PATCH 16/20] net: stmmac: Discard conditional service task execution
Indeed CMWQ guaranties that each particular work item is non-reenatrant,
while using the atomic bitmask operation statement may cause a requested
event being missed if for instance some event happens while the service
task is being executed (see the STMMAC_SERVICE_SCHED flag semantic).
Similarly the service task can be requested for being executed while the
STMMAC core is in the down state. (Though for now there is no such
sub-task defined in the driver).
So to speak just drop the conditional service task execution and queue the
corresponding work anytime it's requested, while the service sub-tasks
shall determine whether they really need to be performed in particular
situations.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 -
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 3e2bf7e2dafb..d88bc8af8eaa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -248,7 +248,6 @@ struct stmmac_priv {
enum stmmac_state {
STMMAC_DOWN,
STMMAC_RESET_REQUESTED,
- STMMAC_SERVICE_SCHED,
};
int stmmac_mdio_unregister(struct net_device *ndev);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 16e08cfaadf0..08112b6e7afd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -176,9 +176,7 @@ static void stmmac_enable_all_queues(struct stmmac_priv
*priv)
static void stmmac_service_event_schedule(struct stmmac_priv *priv)
{
- if (!test_bit(STMMAC_DOWN, >state) &&
- !test_and_set_bit(STMMAC_SERVICE_SCHED, >state))
- queue_work(priv->wq, >service_task);
+ queue_work(priv->wq, >service_task);
}
static void stmmac_global_err(struct stmmac_priv *priv)
@@ -4683,7 +4681,6 @@ static void stmmac_service_task(struct work_struct *work)
service_task);
stmmac_reset_subtask(priv);
- clear_bit(STMMAC_SERVICE_SCHED, >state);
}
/**
--
2.29.2
[PATCH 17/20] net: stmmac: Add 'cause' arg to the service task executioner
In order to have a more descriptive and coherent service task interface
let's add the cause argument to the stmmac_service_event_schedule()
method. It will be used to test-and-set the corresponding flag in the
private device state variable, and execute the service handler if the flag
hasn't been set. By doing so we'll be able to activate the service
sub-task just by calling the stmmac_service_event_schedule() method.
Note currently there is only a single user of the service tasks interface.
It's used to handle a case of the critical device errors to cause the
interface reset. The changes provided here will also prevent the global
error handler from being called twice if the service task has already
being executed while reset sub-task still isn't started.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 08112b6e7afd..f3ced94b3f4e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -174,16 +174,18 @@ static void stmmac_enable_all_queues(struct stmmac_priv
*priv)
}
}
-static void stmmac_service_event_schedule(struct stmmac_priv *priv)
+static void stmmac_service_event_schedule(struct stmmac_priv *priv,
+ unsigned long cause)
{
- queue_work(priv->wq, >service_task);
+ if (!test_and_set_bit(cause, >state))
+ queue_work(priv->wq, >service_task);
}
static void stmmac_global_err(struct stmmac_priv *priv)
{
netif_carrier_off(priv->dev);
- set_bit(STMMAC_RESET_REQUESTED, >state);
- stmmac_service_event_schedule(priv);
+
+ stmmac_service_event_schedule(priv, STMMAC_RESET_REQUESTED);
}
/**
@@ -4658,8 +4660,6 @@ static const struct net_device_ops stmmac_netdev_ops = {
static void stmmac_reset_subtask(struct stmmac_priv *priv)
{
- if (!test_and_clear_bit(STMMAC_RESET_REQUESTED, >state))
- return;
if (test_bit(STMMAC_DOWN, >state))
return;
@@ -4680,7 +4680,8 @@ static void stmmac_service_task(struct work_struct *work)
struct stmmac_priv *priv = container_of(work, struct stmmac_priv,
service_task);
- stmmac_reset_subtask(priv);
+ if (test_and_clear_bit(STMMAC_RESET_REQUESTED, >state))
+ stmmac_reset_subtask(priv);
}
/**
--
2.29.2
[PATCH 14/20] net: stmmac: Add DW GMAC disable LPI IRQ mask macro
Indeed the DW GMAC Interrupts mask register has got an ability to disable the LPI interrupts. Add the macro to close up the MAC IRQs mask macros set. Signed-off-by: Serge Semin --- drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h index 494e1d2f2971..919f5b55bc7d 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h @@ -38,6 +38,7 @@ #defineGMAC_INT_DISABLE_PCSAN BIT(2) #defineGMAC_INT_DISABLE_PMTBIT(3) #defineGMAC_INT_DISABLE_TIMESTAMP BIT(9) +#defineGMAC_INT_DISABLE_LPIBIT(10) #defineGMAC_INT_DISABLE_PCS(GMAC_INT_DISABLE_RGMII | \ GMAC_INT_DISABLE_PCSLINK | \ GMAC_INT_DISABLE_PCSAN) -- 2.29.2
