from:"Grygorii Strashko"

From: Vignesh Raghavendra 

Add CPSW3g DT node with two external ports, MDIO and CPTS support. For
CPSW3g DMA channels the ASEL is set to 15 (AM642x per DMA channel coherency
feature), so that CPSW DMA channel participates in Coherency and thus avoid
need to cache maintenance for SKBs. This improves bidirectional TCP
performance by up to 100Mbps (on 1G link).

Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Grygorii Strashko 
Reviewed-by: Lokesh Vutla 
---
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 74 
 arch/arm64/boot/dts/ti/k3-am64.dtsi  |  2 +
 2 files changed, 76 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 5f85950daef7..80443dbf272c 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -178,6 +178,12 @@
compatible = "ti,am654-chipid";
reg = <0x0014 0x4>;
};
+
+   phy_gmii_sel: phy@4044 {
+   compatible = "ti,am654-phy-gmii-sel";
+   reg = <0x4044 0x8>;
+   #phy-cells = <1>;
+   };
};
 
main_uart0: serial@280 {
@@ -402,4 +408,72 @@
ti,otap-del-sel-ddr50 = <0x9>;
ti,clkbuf-sel = <0x7>;
};
+
+   cpsw3g: ethernet@800 {
+   compatible = "ti,am642-cpsw-nuss";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x0 0x800 0x0 0x20>;
+   reg-names = "cpsw_nuss";
+   ranges = <0x0 0x0 0x0 0x800 0x0 0x20>;
+   clocks = <_clks 13 0>;
+   assigned-clocks = <_clks 13 1>;
+   assigned-clock-parents = <_clks 13 9>;
+   clock-names = "fck";
+   power-domains = <_pds 13 TI_SCI_PD_EXCLUSIVE>;
+
+   dmas = <_pktdma 0xC500 15>,
+  <_pktdma 0xC501 15>,
+  <_pktdma 0xC502 15>,
+  <_pktdma 0xC503 15>,
+  <_pktdma 0xC504 15>,
+  <_pktdma 0xC505 15>,
+  <_pktdma 0xC506 15>,
+  <_pktdma 0xC507 15>,
+  <_pktdma 0x4500 15>;
+   dma-names = "tx0", "tx1", "tx2", "tx3", "tx4", "tx5", "tx6",
+   "tx7", "rx";
+
+   ethernet-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpsw_port1: port@1 {
+   reg = <1>;
+   ti,mac-only;
+   label = "port1";
+   phys = <_gmii_sel 1>;
+   mac-address = [00 00 de ad be ef];
+   };
+
+   cpsw_port2: port@2 {
+   reg = <2>;
+   ti,mac-only;
+   label = "port2";
+   phys = <_gmii_sel 2>;
+   mac-address = [00 01 de ad be ef];
+   };
+   };
+
+   cpsw3g_mdio: mdio@f00 {
+   compatible = "ti,cpsw-mdio","ti,davinci_mdio";
+   reg = <0x0 0xf00 0x0 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <_clks 13 0>;
+   clock-names = "fck";
+   bus_freq = <100>;
+   };
+
+   cpts@3d000 {
+   compatible = "ti,j721e-cpts";
+   reg = <0x0 0x3d000 0x0 0x400>;
+   clocks = <_clks 13 1>;
+   clock-names = "cpts";
+   interrupts-extended = < GIC_SPI 102 
IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "cpts";
+   ti,cpts-ext-ts-inputs = <4>;
+   ti,cpts-periodic-outputs = <2>;
+   };
+   };
 };
diff --git a/arch/arm64/boot/dts/ti/k3-am64.dtsi 
b/arch/arm64/boot/dts/ti/k3-am64.dtsi
index 0ae8c844c482..de6805b0c72c 100644
--- a/arch/arm64/boot/dts/ti/k3-am64.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi
@@ -28,6 +28,8 @@
serial6 = _uart4;
serial7 = _uart5;
serial8 = _uart6;
+   ethernet0 = _port1;
+   ethernet1 = _port2;
};
 
chosen { };
-- 
2.17.1

[PATCH v2 3/4] arm64: dts: ti: k3-am642-evm: add CPSW3g DT nodes

From: Vignesh Raghavendra 

On am642-evm the CPSW3g ext. Port1 is directly connected to TI DP83867 PHY
and Port2 is connected to TI DP83869 PHY which is shared with ICSS
subsystem. The TI DP83869 PHY MII interface is configured using pinmux for
CPSW3g, while MDIO bus is connected through GPIO controllable 2:1 TMUX154E
switch (MDIO GPIO MUX) which has to be configured to route MDIO bus from
CPSW3g to TI DP83869 PHY.

Hence add networking support for am642-evm:
- add CPSW3g MDIO and RGMII pinmux entries for both ext. ports;
- add CPSW3g nodes;
- add mdio-mux-multiplexer DT nodes to represent above topology.

Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Grygorii Strashko 
Reviewed-by: Lokesh Vutla 
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 93 +
 1 file changed, 93 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts 
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 1f1787750fef..962ef807e286 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -6,6 +6,8 @@
 /dts-v1/;
 
 #include 
+#include 
+#include 
 #include "k3-am642.dtsi"
 
 / {
@@ -101,6 +103,31 @@
default-state = "off";
};
};
+
+   mdio_mux: mux-controller {
+   compatible = "gpio-mux";
+   #mux-control-cells = <0>;
+
+   mux-gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+
+   mdio-mux-1 {
+   compatible = "mdio-mux-multiplexer";
+   mux-controls = <_mux>;
+   mdio-parent-bus = <_mdio>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mdio@1 {
+   reg = <0x1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpsw3g_phy3: ethernet-phy@3 {
+   reg = <3>;
+   };
+   };
+   };
 };
 
 _pmx0 {
@@ -133,6 +160,47 @@
AM64X_IOPAD(0x026c, PIN_INPUT_PULLUP, 0) /* (B19) 
I2C1_SDA */
>;
};
+
+   mdio1_pins_default: mdio1-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x01fc, PIN_OUTPUT, 4) /* (R2) 
PRG0_PRU1_GPO19.MDIO0_MDC */
+   AM64X_IOPAD(0x01f8, PIN_INPUT, 4) /* (P5) 
PRG0_PRU1_GPO18.MDIO0_MDIO */
+   >;
+   };
+
+   rgmii1_pins_default: rgmii1-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x01cc, PIN_INPUT, 4) /* (W5) 
PRG0_PRU1_GPO7.RGMII1_RD0 */
+   AM64X_IOPAD(0x01d4, PIN_INPUT, 4) /* (Y5) 
PRG0_PRU1_GPO9.RGMII1_RD1 */
+   AM64X_IOPAD(0x01d8, PIN_INPUT, 4) /* (V6) 
PRG0_PRU1_GPO10.RGMII1_RD2 */
+   AM64X_IOPAD(0x01f4, PIN_INPUT, 4) /* (V5) 
PRG0_PRU1_GPO17.RGMII1_RD3 */
+   AM64X_IOPAD(0x0188, PIN_INPUT, 4) /* (AA5) 
PRG0_PRU0_GPO10.RGMII1_RXC */
+   AM64X_IOPAD(0x0184, PIN_INPUT, 4) /* (W6) 
PRG0_PRU0_GPO9.RGMII1_RX_CTL */
+   AM64X_IOPAD(0x0124, PIN_OUTPUT, 4) /* (V15) 
PRG1_PRU1_GPO7.RGMII1_TD0 */
+   AM64X_IOPAD(0x012c, PIN_OUTPUT, 4) /* (V14) 
PRG1_PRU1_GPO9.RGMII1_TD1 */
+   AM64X_IOPAD(0x0130, PIN_OUTPUT, 4) /* (W14) 
PRG1_PRU1_GPO10.RGMII1_TD2 */
+   AM64X_IOPAD(0x014c, PIN_OUTPUT, 4) /* (AA14) 
PRG1_PRU1_GPO17.RGMII1_TD3 */
+   AM64X_IOPAD(0x00e0, PIN_OUTPUT, 4) /* (U14) 
PRG1_PRU0_GPO10.RGMII1_TXC */
+   AM64X_IOPAD(0x00dc, PIN_OUTPUT, 4) /* (U15) 
PRG1_PRU0_GPO9.RGMII1_TX_CTL */
+   >;
+   };
+
+   rgmii2_pins_default: rgmii2-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x0108, PIN_INPUT, 4) /* (W11) 
PRG1_PRU1_GPO0.RGMII2_RD0 */
+   AM64X_IOPAD(0x010c, PIN_INPUT, 4) /* (V11) 
PRG1_PRU1_GPO1.RGMII2_RD1 */
+   AM64X_IOPAD(0x0110, PIN_INPUT, 4) /* (AA12) 
PRG1_PRU1_GPO2.RGMII2_RD2 */
+   AM64X_IOPAD(0x0114, PIN_INPUT, 4) /* (Y12) 
PRG1_PRU1_GPO3.RGMII2_RD3 */
+   AM64X_IOPAD(0x0120, PIN_INPUT, 4) /* (U11) 
PRG1_PRU1_GPO6.RGMII2_RXC */
+   AM64X_IOPAD(0x0118, PIN_INPUT, 4) /* (W12) 
PRG1_PRU1_GPO4.RGMII2_RX_CTL */
+   AM64X_IOPAD(0x0134, PIN_OUTPUT, 4) /* (AA10) 
PRG1_PRU1_GPO11.RGMII2_TD0 */
+   AM64X_IOPAD(0x0138, PIN_OUTPUT, 4) /* (V10) 
PRG1_PRU1_GPO12.RGMII2_TD1 */
+   AM64X_IOPAD(0x013c, PIN_OUTPUT, 4) /* (U10) 
PRG1_PRU1_GPO13.RGMII2_TD2 */
+   AM64X_IOPAD(0x0140, PIN_OUTPUT, 4) /* (AA11) 
PRG1_PRU1_GPO14.RGMII2_TD3 */
+   AM64X_IOPAD(0x0148, PIN_OUTPUT, 4) /* (Y1

[PATCH v2 2/4] arm64: dts: ti: k3-am64-main: add main CPTS entry

Add DT node for the Main domain CPTS.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Vignesh Raghavendra 
Reviewed-by: Lokesh Vutla 
---
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 80443dbf272c..0cf727e3d1e2 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -476,4 +476,19 @@
ti,cpts-periodic-outputs = <2>;
};
};
+
+   cpts@3900 {
+   compatible = "ti,j721e-cpts";
+   reg = <0x0 0x3900 0x0 0x400>;
+   reg-names = "cpts";
+   power-domains = <_pds 84 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 84 0>;
+   clock-names = "cpts";
+   assigned-clocks = <_clks 84 0>;
+   assigned-clock-parents = <_clks 84 8>;
+   interrupts = ;
+   interrupt-names = "cpts";
+   ti,cpts-periodic-outputs = <6>;
+   ti,cpts-ext-ts-inputs = <8>;
+   };
 };
-- 
2.17.1

[PATCH v2 4/4] arm64: dts: ti: k3-am642-sk: Add CPSW DT nodes

From: Vignesh Raghavendra 

AM642 SK board has 2 CPSW3g ports connected through TI DP83867 PHYs. Add DT
entries for the same.

Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Grygorii Strashko 
Reviewed-by: Lokesh Vutla 
---
 arch/arm64/boot/dts/ti/k3-am642-sk.dts | 73 ++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts 
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index aa6ca4c49153..397ed3b2e121 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -6,6 +6,7 @@
 /dts-v1/;
 
 #include 
+#include 
 #include "k3-am642.dtsi"
 
 / {
@@ -90,6 +91,47 @@
AM64X_IOPAD(0x026c, PIN_INPUT_PULLUP, 0) /* (B19) 
I2C1_SDA */
>;
};
+
+   mdio1_pins_default: mdio1-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x01fc, PIN_OUTPUT, 4) /* (R2) 
PRG0_PRU1_GPO19.MDIO0_MDC */
+   AM64X_IOPAD(0x01f8, PIN_INPUT, 4) /* (P5) 
PRG0_PRU1_GPO18.MDIO0_MDIO */
+   >;
+   };
+
+   rgmii1_pins_default: rgmii1-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x011c, PIN_INPUT, 4) /* (AA13) 
PRG1_PRU1_GPO5.RGMII1_RD0 */
+   AM64X_IOPAD(0x0128, PIN_INPUT, 4) /* (U12) 
PRG1_PRU1_GPO8.RGMII1_RD1 */
+   AM64X_IOPAD(0x0150, PIN_INPUT, 4) /* (Y13) 
PRG1_PRU1_GPO18.RGMII1_RD2 */
+   AM64X_IOPAD(0x0154, PIN_INPUT, 4) /* (V12) 
PRG1_PRU1_GPO19.RGMII1_RD3 */
+   AM64X_IOPAD(0x00d8, PIN_INPUT, 4) /* (W13) 
PRG1_PRU0_GPO8.RGMII1_RXC */
+   AM64X_IOPAD(0x00cc, PIN_INPUT, 4) /* (V13) 
PRG1_PRU0_GPO5.RGMII1_RX_CTL */
+   AM64X_IOPAD(0x0124, PIN_OUTPUT, 4) /* (V15) 
PRG1_PRU1_GPO7.RGMII1_TD0 */
+   AM64X_IOPAD(0x012c, PIN_OUTPUT, 4) /* (V14) 
PRG1_PRU1_GPO9.RGMII1_TD1 */
+   AM64X_IOPAD(0x0130, PIN_OUTPUT, 4) /* (W14) 
PRG1_PRU1_GPO10.RGMII1_TD2 */
+   AM64X_IOPAD(0x014c, PIN_OUTPUT, 4) /* (AA14) 
PRG1_PRU1_GPO17.RGMII1_TD3 */
+   AM64X_IOPAD(0x00e0, PIN_OUTPUT, 4) /* (U14) 
PRG1_PRU0_GPO10.RGMII1_TXC */
+   AM64X_IOPAD(0x00dc, PIN_OUTPUT, 4) /* (U15) 
PRG1_PRU0_GPO9.RGMII1_TX_CTL */
+   >;
+   };
+
+   rgmii2_pins_default: rgmii2-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x0108, PIN_INPUT, 4) /* (W11) 
PRG1_PRU1_GPO0.RGMII2_RD0 */
+   AM64X_IOPAD(0x010c, PIN_INPUT, 4) /* (V11) 
PRG1_PRU1_GPO1.RGMII2_RD1 */
+   AM64X_IOPAD(0x0110, PIN_INPUT, 4) /* (AA12) 
PRG1_PRU1_GPO2.RGMII2_RD2 */
+   AM64X_IOPAD(0x0114, PIN_INPUT, 4) /* (Y12) 
PRG1_PRU1_GPO3.RGMII2_RD3 */
+   AM64X_IOPAD(0x0120, PIN_INPUT, 4) /* (U11) 
PRG1_PRU1_GPO6.RGMII2_RXC */
+   AM64X_IOPAD(0x0118, PIN_INPUT, 4) /* (W12) 
PRG1_PRU1_GPO4.RGMII2_RX_CTL */
+   AM64X_IOPAD(0x0134, PIN_OUTPUT, 4) /* (AA10) 
PRG1_PRU1_GPO11.RGMII2_TD0 */
+   AM64X_IOPAD(0x0138, PIN_OUTPUT, 4) /* (V10) 
PRG1_PRU1_GPO12.RGMII2_TD1 */
+   AM64X_IOPAD(0x013c, PIN_OUTPUT, 4) /* (U10) 
PRG1_PRU1_GPO13.RGMII2_TD2 */
+   AM64X_IOPAD(0x0140, PIN_OUTPUT, 4) /* (AA11) 
PRG1_PRU1_GPO14.RGMII2_TD3 */
+   AM64X_IOPAD(0x0148, PIN_OUTPUT, 4) /* (Y10) 
PRG1_PRU1_GPO16.RGMII2_TXC */
+   AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11) 
PRG1_PRU1_GPO15.RGMII2_TX_CTL */
+   >;
+   };
 };
 
 _uart0 {
@@ -171,3 +213,34 @@
ti,driver-strength-ohm = <50>;
disable-wp;
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default
+_pins_default
+_pins_default>;
+};
+
+_port1 {
+   phy-mode = "rgmii-rxid";
+   phy-handle = <_phy0>;
+};
+
+_port2 {
+   phy-mode = "rgmii-rxid";
+   phy-handle = <_phy1>;
+};
+
+_mdio {
+   cpsw3g_phy0: ethernet-phy@0 {
+   reg = <0>;
+   ti,rx-internal-delay = ;
+   ti,fifo-depth = ;
+   };
+
+   cpsw3g_phy1: ethernet-phy@1 {
+   reg = <1>;
+   ti,rx-internal-delay = ;
+   ti,fifo-depth = ;
+   };
+};
-- 
2.17.1

[PATCH v2 0/4] arm64: dts: ti: am642x: add CPSW3g DT nodes

Hi

This series adds corresponding AM642x CPSW3g nodes required to enable networking
on TI am642-evm/sk platforms and adds required pinmux/PHY nodes in corresponding
board files.

Kernel Boot Log: 
EVM: https://pastebin.ubuntu.com/p/6Qkbw35Jg3/
SK: https://pastebin.ubuntu.com/p/Pd3xxP9J9K/

Changes in v2:
- minor comment fixed
- add Reviewed-by: Lokesh Vutla 

v1: https://lore.kernel.org/patchwork/cover/1389305/

Grygorii Strashko (1):
  arm64: dts: ti: k3-am64-main: add main CPTS entry

Vignesh Raghavendra (3):
  arm64: dts: ti: am64-main: Add CPSW DT node
  arm64: dts: ti: k3-am642-evm: add CPSW3g DT nodes
  arm64: dts: ti: k3-am642-sk: Add CPSW DT nodes

 arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 89 +++
 arch/arm64/boot/dts/ti/k3-am64.dtsi  |  2 +
 arch/arm64/boot/dts/ti/k3-am642-evm.dts  | 93 
 arch/arm64/boot/dts/ti/k3-am642-sk.dts   | 73 +++
 4 files changed, 257 insertions(+)

-- 
2.17.1

Re: [PATCH 1/3] clocksource/drivers/timer-ti-dm: Fix posted mode status check order





On 04/03/2021 09:21, Tony Lindgren wrote:

When the timer is configured in posted mode, we need to check the write-
posted status register (TWPS) before writing to the register.

We now check TWPS after the write starting with commit 52762fbd1c47
("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource
support").

For example, in the TRM for am571x the following is documented in chapter
"22.2.4.13.1.1 Write Posting Synchronization Mode":

"For each register, a status bit is provided in the timer write-posted
  status (TWPS) register. In this mode, it is mandatory that software check
  this status bit before any write access. If a write is attempted to a
  register with a previous access pending, the previous access is discarded
  without notice."

The regression happened when I updated the code to use standard read/write
accessors for the driver instead of using __omap_dm_timer_load_start().
We have__omap_dm_timer_load_start() check the TWPS status correctly using
__omap_dm_timer_write().

Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and 
clocksource support")
Signed-off-by: Tony Lindgren 
---
  drivers/clocksource/timer-ti-dm-systimer.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clocksource/timer-ti-dm-systimer.c 
b/drivers/clocksource/timer-ti-dm-systimer.c
--- a/drivers/clocksource/timer-ti-dm-systimer.c
+++ b/drivers/clocksource/timer-ti-dm-systimer.c
@@ -449,13 +449,13 @@ static int dmtimer_set_next_event(unsigned long cycles,
struct dmtimer_systimer *t = >t;
void __iomem *pend = t->base + t->pend;
  
-	writel_relaxed(0x - cycles, t->base + t->counter);

while (readl_relaxed(pend) & WP_TCRR)
cpu_relax();
+   writel_relaxed(0x - cycles, t->base + t->counter);
  
-	writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl);

while (readl_relaxed(pend) & WP_TCLR)
cpu_relax();
+   writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl);


It seems static [and inline] helper here could be better solution. no?

  
  	return 0;

  }
@@ -490,18 +490,18 @@ static int dmtimer_set_periodic(struct clock_event_device 
*evt)
dmtimer_clockevent_shutdown(evt);
  
  	/* Looks like we need to first set the load value separately */

-   writel_relaxed(clkevt->period, t->base + t->load);
while (readl_relaxed(pend) & WP_TLDR)
cpu_relax();
+   writel_relaxed(clkevt->period, t->base + t->load);
  
-	writel_relaxed(clkevt->period, t->base + t->counter);

while (readl_relaxed(pend) & WP_TCRR)
cpu_relax();
+   writel_relaxed(clkevt->period, t->base + t->counter);
  
-	writel_relaxed(OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,

-  t->base + t->ctrl);
while (readl_relaxed(pend) & WP_TCLR)
cpu_relax();
+   writel_relaxed(OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
+  t->base + t->ctrl);
  
  	return 0;

  }



--
Best regards,
grygorii

Re: [PATCH 2/3] clocksource/drivers/timer-ti-dm: Remove extra of_node_put()





On 04/03/2021 09:21, Tony Lindgren wrote:

We have of_translate_address() already do of_node_put() as needed.
I probably looked at __of_translate_address() earlier by accident
that of_translate_address() uses.


I do not see of_node_put() in of_translate_address() and
 __of_translate_address() is doing of_node_get(dev);
?



Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and 
clocksource support")
Signed-off-by: Tony Lindgren 
---
  drivers/clocksource/timer-ti-dm-systimer.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/clocksource/timer-ti-dm-systimer.c 
b/drivers/clocksource/timer-ti-dm-systimer.c
--- a/drivers/clocksource/timer-ti-dm-systimer.c
+++ b/drivers/clocksource/timer-ti-dm-systimer.c
@@ -265,7 +265,6 @@ static void __init dmtimer_systimer_assign_alwon(void)
pa == 0x48318000)
continue;
  
-of_node_put(np);

break;
}
}
@@ -300,7 +299,6 @@ static u32 __init 
dmtimer_systimer_find_first_available(void)
continue;
}
  
-			of_node_put(np);

break;
}
}



--
Best regards,
grygorii

[PATCH 4/4] arm64: dts: ti: k3-am642-sk: Add CPSW DT nodes

From: Vignesh Raghavendra 

AM642 SK board has 2 CPSW3g ports connected through TI DP83867 PHYs. Add DT
entries for the same.

Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Grygorii Strashko 
---
 arch/arm64/boot/dts/ti/k3-am642-sk.dts | 73 ++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts 
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index aa6ca4c49153..397ed3b2e121 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -6,6 +6,7 @@
 /dts-v1/;
 
 #include 
+#include 
 #include "k3-am642.dtsi"
 
 / {
@@ -90,6 +91,47 @@
AM64X_IOPAD(0x026c, PIN_INPUT_PULLUP, 0) /* (B19) 
I2C1_SDA */
>;
};
+
+   mdio1_pins_default: mdio1-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x01fc, PIN_OUTPUT, 4) /* (R2) 
PRG0_PRU1_GPO19.MDIO0_MDC */
+   AM64X_IOPAD(0x01f8, PIN_INPUT, 4) /* (P5) 
PRG0_PRU1_GPO18.MDIO0_MDIO */
+   >;
+   };
+
+   rgmii1_pins_default: rgmii1-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x011c, PIN_INPUT, 4) /* (AA13) 
PRG1_PRU1_GPO5.RGMII1_RD0 */
+   AM64X_IOPAD(0x0128, PIN_INPUT, 4) /* (U12) 
PRG1_PRU1_GPO8.RGMII1_RD1 */
+   AM64X_IOPAD(0x0150, PIN_INPUT, 4) /* (Y13) 
PRG1_PRU1_GPO18.RGMII1_RD2 */
+   AM64X_IOPAD(0x0154, PIN_INPUT, 4) /* (V12) 
PRG1_PRU1_GPO19.RGMII1_RD3 */
+   AM64X_IOPAD(0x00d8, PIN_INPUT, 4) /* (W13) 
PRG1_PRU0_GPO8.RGMII1_RXC */
+   AM64X_IOPAD(0x00cc, PIN_INPUT, 4) /* (V13) 
PRG1_PRU0_GPO5.RGMII1_RX_CTL */
+   AM64X_IOPAD(0x0124, PIN_OUTPUT, 4) /* (V15) 
PRG1_PRU1_GPO7.RGMII1_TD0 */
+   AM64X_IOPAD(0x012c, PIN_OUTPUT, 4) /* (V14) 
PRG1_PRU1_GPO9.RGMII1_TD1 */
+   AM64X_IOPAD(0x0130, PIN_OUTPUT, 4) /* (W14) 
PRG1_PRU1_GPO10.RGMII1_TD2 */
+   AM64X_IOPAD(0x014c, PIN_OUTPUT, 4) /* (AA14) 
PRG1_PRU1_GPO17.RGMII1_TD3 */
+   AM64X_IOPAD(0x00e0, PIN_OUTPUT, 4) /* (U14) 
PRG1_PRU0_GPO10.RGMII1_TXC */
+   AM64X_IOPAD(0x00dc, PIN_OUTPUT, 4) /* (U15) 
PRG1_PRU0_GPO9.RGMII1_TX_CTL */
+   >;
+   };
+
+   rgmii2_pins_default: rgmii2-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x0108, PIN_INPUT, 4) /* (W11) 
PRG1_PRU1_GPO0.RGMII2_RD0 */
+   AM64X_IOPAD(0x010c, PIN_INPUT, 4) /* (V11) 
PRG1_PRU1_GPO1.RGMII2_RD1 */
+   AM64X_IOPAD(0x0110, PIN_INPUT, 4) /* (AA12) 
PRG1_PRU1_GPO2.RGMII2_RD2 */
+   AM64X_IOPAD(0x0114, PIN_INPUT, 4) /* (Y12) 
PRG1_PRU1_GPO3.RGMII2_RD3 */
+   AM64X_IOPAD(0x0120, PIN_INPUT, 4) /* (U11) 
PRG1_PRU1_GPO6.RGMII2_RXC */
+   AM64X_IOPAD(0x0118, PIN_INPUT, 4) /* (W12) 
PRG1_PRU1_GPO4.RGMII2_RX_CTL */
+   AM64X_IOPAD(0x0134, PIN_OUTPUT, 4) /* (AA10) 
PRG1_PRU1_GPO11.RGMII2_TD0 */
+   AM64X_IOPAD(0x0138, PIN_OUTPUT, 4) /* (V10) 
PRG1_PRU1_GPO12.RGMII2_TD1 */
+   AM64X_IOPAD(0x013c, PIN_OUTPUT, 4) /* (U10) 
PRG1_PRU1_GPO13.RGMII2_TD2 */
+   AM64X_IOPAD(0x0140, PIN_OUTPUT, 4) /* (AA11) 
PRG1_PRU1_GPO14.RGMII2_TD3 */
+   AM64X_IOPAD(0x0148, PIN_OUTPUT, 4) /* (Y10) 
PRG1_PRU1_GPO16.RGMII2_TXC */
+   AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11) 
PRG1_PRU1_GPO15.RGMII2_TX_CTL */
+   >;
+   };
 };
 
 _uart0 {
@@ -171,3 +213,34 @@
ti,driver-strength-ohm = <50>;
disable-wp;
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default
+_pins_default
+_pins_default>;
+};
+
+_port1 {
+   phy-mode = "rgmii-rxid";
+   phy-handle = <_phy0>;
+};
+
+_port2 {
+   phy-mode = "rgmii-rxid";
+   phy-handle = <_phy1>;
+};
+
+_mdio {
+   cpsw3g_phy0: ethernet-phy@0 {
+   reg = <0>;
+   ti,rx-internal-delay = ;
+   ti,fifo-depth = ;
+   };
+
+   cpsw3g_phy1: ethernet-phy@1 {
+   reg = <1>;
+   ti,rx-internal-delay = ;
+   ti,fifo-depth = ;
+   };
+};
-- 
2.17.1

[PATCH 1/4] arm64: dts: ti: am64-main: Add CPSW DT node

From: Vignesh Raghavendra 

Add CPSW3g DT node with two external ports, MDIO and CPTS support. For
CPSW3g DMA channels the ASEL is set to 15 (AM642x per DMA channel coherency
feature), so that CPSW DMA channel participates in Coherency and thus avoid
need to cache maintenance for SKBs. This improves bidirectional TCP
performance by up to 100Mbps (on 1G link).

Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Grygorii Strashko 
---
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 74 
 arch/arm64/boot/dts/ti/k3-am64.dtsi  |  2 +
 2 files changed, 76 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 5f85950daef7..80443dbf272c 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -178,6 +178,12 @@
compatible = "ti,am654-chipid";
reg = <0x0014 0x4>;
};
+
+   phy_gmii_sel: phy@4044 {
+   compatible = "ti,am654-phy-gmii-sel";
+   reg = <0x4044 0x8>;
+   #phy-cells = <1>;
+   };
};
 
main_uart0: serial@280 {
@@ -402,4 +408,72 @@
ti,otap-del-sel-ddr50 = <0x9>;
ti,clkbuf-sel = <0x7>;
};
+
+   cpsw3g: ethernet@800 {
+   compatible = "ti,am642-cpsw-nuss";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x0 0x800 0x0 0x20>;
+   reg-names = "cpsw_nuss";
+   ranges = <0x0 0x0 0x0 0x800 0x0 0x20>;
+   clocks = <_clks 13 0>;
+   assigned-clocks = <_clks 13 1>;
+   assigned-clock-parents = <_clks 13 9>;
+   clock-names = "fck";
+   power-domains = <_pds 13 TI_SCI_PD_EXCLUSIVE>;
+
+   dmas = <_pktdma 0xC500 15>,
+  <_pktdma 0xC501 15>,
+  <_pktdma 0xC502 15>,
+  <_pktdma 0xC503 15>,
+  <_pktdma 0xC504 15>,
+  <_pktdma 0xC505 15>,
+  <_pktdma 0xC506 15>,
+  <_pktdma 0xC507 15>,
+  <_pktdma 0x4500 15>;
+   dma-names = "tx0", "tx1", "tx2", "tx3", "tx4", "tx5", "tx6",
+   "tx7", "rx";
+
+   ethernet-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpsw_port1: port@1 {
+   reg = <1>;
+   ti,mac-only;
+   label = "port1";
+   phys = <_gmii_sel 1>;
+   mac-address = [00 00 de ad be ef];
+   };
+
+   cpsw_port2: port@2 {
+   reg = <2>;
+   ti,mac-only;
+   label = "port2";
+   phys = <_gmii_sel 2>;
+   mac-address = [00 01 de ad be ef];
+   };
+   };
+
+   cpsw3g_mdio: mdio@f00 {
+   compatible = "ti,cpsw-mdio","ti,davinci_mdio";
+   reg = <0x0 0xf00 0x0 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <_clks 13 0>;
+   clock-names = "fck";
+   bus_freq = <100>;
+   };
+
+   cpts@3d000 {
+   compatible = "ti,j721e-cpts";
+   reg = <0x0 0x3d000 0x0 0x400>;
+   clocks = <_clks 13 1>;
+   clock-names = "cpts";
+   interrupts-extended = < GIC_SPI 102 
IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "cpts";
+   ti,cpts-ext-ts-inputs = <4>;
+   ti,cpts-periodic-outputs = <2>;
+   };
+   };
 };
diff --git a/arch/arm64/boot/dts/ti/k3-am64.dtsi 
b/arch/arm64/boot/dts/ti/k3-am64.dtsi
index 0ae8c844c482..de6805b0c72c 100644
--- a/arch/arm64/boot/dts/ti/k3-am64.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi
@@ -28,6 +28,8 @@
serial6 = _uart4;
serial7 = _uart5;
serial8 = _uart6;
+   ethernet0 = _port1;
+   ethernet1 = _port2;
};
 
chosen { };
-- 
2.17.1

[PATCH 0/4] arm64: dts: ti: am642x: add CPSW3g DT nodes

Hi

This series adds corresponding AM642x CPSW3g nodes required to enable networking
on TI am642-evm/sk platforms and adds required pinmux/PHY nodes in corresponding
board files.

Kernel Boot Log: 
EVM: https://pastebin.ubuntu.com/p/6Qkbw35Jg3/
SK: https://pastebin.ubuntu.com/p/Pd3xxP9J9K/


Grygorii Strashko (1):
  arm64: dts: ti: k3-am64-main: add main CPTS entry

Vignesh Raghavendra (3):
  arm64: dts: ti: am64-main: Add CPSW DT node
  arm64: dts: ti: k3-am642-evm: add CPSW3g DT nodes
  arm64: dts: ti: k3-am642-sk: Add CPSW DT nodes

 arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 89 +++
 arch/arm64/boot/dts/ti/k3-am64.dtsi  |  2 +
 arch/arm64/boot/dts/ti/k3-am642-evm.dts  | 93 
 arch/arm64/boot/dts/ti/k3-am642-sk.dts   | 73 +++
 4 files changed, 257 insertions(+)

-- 
2.17.1

[PATCH 3/4] arm64: dts: ti: k3-am642-evm: add CPSW3g DT nodes

From: Vignesh Raghavendra 

On am642-evm the CPSW3g ext. Port1 is directly connected to TI DP83867 PHY
and Port2 is connected to TI DP83869 PHY which is shared with ICSS
subsystem. The TI DP83869 PHY MII interface is configured using pinmux for
CPSW3g, while MDIO bus is connected through GPIO controllable 2:1 TMUX154E
switch (MDIO GPIO MUX) which has to be configured to route MDIO bus from
CPSW3g to TI DP83869 PHY.

Hence add networking support for am642-evm:
- add CPSW3g MDIO and RGMII pinmux entries for both ext. ports;
- add CPSW3g nodes;
- add mdio-mux-multiplexer DT nodes to represent above topology.

Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Grygorii Strashko 
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 93 +
 1 file changed, 93 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts 
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 1f1787750fef..962ef807e286 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -6,6 +6,8 @@
 /dts-v1/;
 
 #include 
+#include 
+#include 
 #include "k3-am642.dtsi"
 
 / {
@@ -101,6 +103,31 @@
default-state = "off";
};
};
+
+   mdio_mux: mux-controller {
+   compatible = "gpio-mux";
+   #mux-control-cells = <0>;
+
+   mux-gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+
+   mdio-mux-1 {
+   compatible = "mdio-mux-multiplexer";
+   mux-controls = <_mux>;
+   mdio-parent-bus = <_mdio>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mdio@1 {
+   reg = <0x1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpsw3g_phy3: ethernet-phy@3 {
+   reg = <3>;
+   };
+   };
+   };
 };
 
 _pmx0 {
@@ -133,6 +160,47 @@
AM64X_IOPAD(0x026c, PIN_INPUT_PULLUP, 0) /* (B19) 
I2C1_SDA */
>;
};
+
+   mdio1_pins_default: mdio1-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x01fc, PIN_OUTPUT, 4) /* (R2) 
PRG0_PRU1_GPO19.MDIO0_MDC */
+   AM64X_IOPAD(0x01f8, PIN_INPUT, 4) /* (P5) 
PRG0_PRU1_GPO18.MDIO0_MDIO */
+   >;
+   };
+
+   rgmii1_pins_default: rgmii1-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x01cc, PIN_INPUT, 4) /* (W5) 
PRG0_PRU1_GPO7.RGMII1_RD0 */
+   AM64X_IOPAD(0x01d4, PIN_INPUT, 4) /* (Y5) 
PRG0_PRU1_GPO9.RGMII1_RD1 */
+   AM64X_IOPAD(0x01d8, PIN_INPUT, 4) /* (V6) 
PRG0_PRU1_GPO10.RGMII1_RD2 */
+   AM64X_IOPAD(0x01f4, PIN_INPUT, 4) /* (V5) 
PRG0_PRU1_GPO17.RGMII1_RD3 */
+   AM64X_IOPAD(0x0188, PIN_INPUT, 4) /* (AA5) 
PRG0_PRU0_GPO10.RGMII1_RXC */
+   AM64X_IOPAD(0x0184, PIN_INPUT, 4) /* (W6) 
PRG0_PRU0_GPO9.RGMII1_RX_CTL */
+   AM64X_IOPAD(0x0124, PIN_OUTPUT, 4) /* (V15) 
PRG1_PRU1_GPO7.RGMII1_TD0 */
+   AM64X_IOPAD(0x012c, PIN_OUTPUT, 4) /* (V14) 
PRG1_PRU1_GPO9.RGMII1_TD1 */
+   AM64X_IOPAD(0x0130, PIN_OUTPUT, 4) /* (W14) 
PRG1_PRU1_GPO10.RGMII1_TD2 */
+   AM64X_IOPAD(0x014c, PIN_OUTPUT, 4) /* (AA14) 
PRG1_PRU1_GPO17.RGMII1_TD3 */
+   AM64X_IOPAD(0x00e0, PIN_OUTPUT, 4) /* (U14) 
PRG1_PRU0_GPO10.RGMII1_TXC */
+   AM64X_IOPAD(0x00dc, PIN_OUTPUT, 4) /* (U15) 
PRG1_PRU0_GPO9.RGMII1_TX_CTL */
+   >;
+   };
+
+   rgmii2_pins_default: rgmii2-pins-default {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x0108, PIN_INPUT, 4) /* (W11) 
PRG1_PRU1_GPO0.RGMII2_RD0 */
+   AM64X_IOPAD(0x010c, PIN_INPUT, 4) /* (V11) 
PRG1_PRU1_GPO1.RGMII2_RD1 */
+   AM64X_IOPAD(0x0110, PIN_INPUT, 4) /* (AA12) 
PRG1_PRU1_GPO2.RGMII2_RD2 */
+   AM64X_IOPAD(0x0114, PIN_INPUT, 4) /* (Y12) 
PRG1_PRU1_GPO3.RGMII2_RD3 */
+   AM64X_IOPAD(0x0120, PIN_INPUT, 4) /* (U11) 
PRG1_PRU1_GPO6.RGMII2_RXC */
+   AM64X_IOPAD(0x0118, PIN_INPUT, 4) /* (W12) 
PRG1_PRU1_GPO4.RGMII2_RX_CTL */
+   AM64X_IOPAD(0x0134, PIN_OUTPUT, 4) /* (AA10) 
PRG1_PRU1_GPO11.RGMII2_TD0 */
+   AM64X_IOPAD(0x0138, PIN_OUTPUT, 4) /* (V10) 
PRG1_PRU1_GPO12.RGMII2_TD1 */
+   AM64X_IOPAD(0x013c, PIN_OUTPUT, 4) /* (U10) 
PRG1_PRU1_GPO13.RGMII2_TD2 */
+   AM64X_IOPAD(0x0140, PIN_OUTPUT, 4) /* (AA11) 
PRG1_PRU1_GPO14.RGMII2_TD3 */
+   AM64X_IOPAD(0x0148, PIN_OUTPUT, 4) /* (Y10) 
PRG1_PRU1_

[PATCH 2/4] arm64: dts: ti: k3-am64-main: add main CPTS entry

Add DT node for the Main domain CPTS.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Vignesh Raghavendra 
---
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 80443dbf272c..0cf727e3d1e2 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -476,4 +476,19 @@
ti,cpts-periodic-outputs = <2>;
};
};
+
+   cpts@3900 {
+   compatible = "ti,j721e-cpts";
+   reg = <0x0 0x3900 0x0 0x400>;
+   reg-names = "cpts";
+   power-domains = <_pds 84 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 84 0>;
+   clock-names = "cpts";
+   assigned-clocks = <_clks 84 0>;
+   assigned-clock-parents = <_clks 84 8>;
+   interrupts = ;
+   interrupt-names = "cpts";
+   ti,cpts-periodic-outputs = <6>;
+   ti,cpts-ext-ts-inputs = <8>;
+   };
 };
-- 
2.17.1

Re: [PATCH] gpio: omap: Honor "aliases" node

2021-03-02 Thread Grygorii Strashko





On 02/03/2021 03:18, Alexander Sverdlin wrote:

Currently the naming of the GPIO chips depends on their order in the DT,
but also on the kernel version (I've noticed the change from v5.10.x to
v5.11). Honor the persistent enumeration in the "aliases" node like other
GPIO drivers do.

Signed-off-by: Alexander Sverdlin 
---
Yes, I noticed checkpatch "WARNING: DT binding docs and includes should be
a separate patch."
However, the parts below are tiny and barely make sense separately.

  Documentation/devicetree/bindings/gpio/gpio-omap.txt | 6 ++
  drivers/gpio/gpio-omap.c | 5 +
  2 files changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt 
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index e57b2cb28f6c..6050db3fd84e 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -30,9 +30,15 @@ OMAP specific properties:
  - ti,gpio-always-on:  Indicates if a GPIO bank is always powered and
so will never lose its logic state.
  
+Note: GPIO ports can have an alias correctly numbered in "aliases" node for

+persistent enumeration.
  
  Example:
  
+aliases {

+   gpio0 = 
+};
+
  gpio0: gpio@44e07000 {
  compatible = "ti,omap4-gpio";
  reg = <0x44e07000 0x1000>;
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 41952bb818ad..dd2a8f6d920f 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1014,6 +1014,11 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, 
struct irq_chip *irqc)
bank->chip.parent = _mpuio_device.dev;
bank->chip.base = OMAP_MPUIO(0);
} else {
+#ifdef CONFIG_OF_GPIO
+   ret = of_alias_get_id(bank->chip.of_node, "gpio");
+   if (ret >= 0)
+   gpio = ret * bank->width;
+#endif
label = devm_kasprintf(bank->chip.parent, GFP_KERNEL, 
"gpio-%d-%d",
   gpio, gpio + bank->width - 1);
if (!label)



You're not the first one, this was not accepted. See [1]
[1] 
https://patchwork.kernel.org/project/linux-omap/patch/1465898604-16294-1-git-send-email-u.kleine-koe...@pengutronix.de/


--
Best regards,
grygorii

Re: [PATCH] arm64: dts: ti: k3-am64-main: Add GPIO DT nodes

2021-03-01 Thread Grygorii Strashko





On 01/03/2021 08:19, Aswath Govindraju wrote:

Add device tree nodes for GPIO modules and interrupt controller in main
domain.

Signed-off-by: Aswath Govindraju 
---

This patch depends on,
https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439039


  arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 45 
  1 file changed, 45 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index a36ebddf3a4c..8b4d76d83342 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -367,6 +367,51 @@
clocks = <_clks 145 0>;
};
  
+	main_gpio_intr: interrupt-controller0 {

+   compatible = "ti,sci-intr";
+   ti,intr-trigger-type = <1>;
+   interrupt-controller;
+   interrupt-parent = <>;
+   #interrupt-cells = <1>;
+   ti,sci = <>;
+   ti,sci-dev-id = <3>;
+   ti,interrupt-ranges = <0 32 16>;
+   };
+
+   main_gpio0: gpio@60 {
+   compatible = "ti,am64-gpio", "ti,keystone-gpio";
+   reg = <0x0 0x0060 0x0 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <_gpio_intr>;
+   interrupts = <190>, <191>, <192>,
+<193>, <194>, <195>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <87>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <_pds 77 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 77 0>;
+   clock-names = "gpio";
+   };
+
+   main_gpio1: gpio@601000 {
+   compatible = "ti,am64-gpio", "ti,keystone-gpio";
+   reg = <0x0 0x00601000 0x0 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <_gpio_intr>;
+   interrupts = <180>, <181>, <182>,
+<183>, <184>, <185>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <88>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <_pds 78 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 78 0>;
+   clock-names = "gpio";
+   };
+
sdhci0: mmc@fa1 {
compatible = "ti,am64-sdhci-8bit";
reg = <0x00 0xfa1 0x00 0x260>, <0x00 0xfa18000 0x00 0x134>;



Reviewed-by: Grygorii Strashko 

--
Best regards,
grygorii

Re: linux-next: manual merge of the devicetree tree with the net-next tree

2021-02-22 Thread Grygorii Strashko





On 22/02/2021 10:23, Stephen Rothwell wrote:

Hi all,

On Mon, 15 Feb 2021 07:53:21 +1100 Stephen Rothwell  
wrote:


On Thu, 21 Jan 2021 13:26:45 +1100 Stephen Rothwell  
wrote:


Today's linux-next merge of the devicetree tree got a conflict in:

   Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml

between commit:

   19d9a846d9fc ("dt-binding: net: ti: k3-am654-cpsw-nuss: update bindings for am64x 
cpsw3g")

from the net-next tree and commit:

   0499220d6dad ("dt-bindings: Add missing array size constraints")

from the devicetree tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index 3fae9a5f0c6a,097c5cc6c853..
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@@ -72,7 -66,8 +72,8 @@@ properties
 dma-coherent: true
   
 clocks:

+ maxItems: 1
  -description: CPSW2G NUSS functional clock
  +description: CPSWxG NUSS functional clock
   
 clock-names:

   items:


With the merge window about to open, this is a reminder that this
conflict still exists.


This is now a conflict between the devicetree tree and Linus' tree.



Sorry for inconvenience, is there anything I can do to help resolve it?
(Changes went through a different trees)

--
Best regards,
grygorii

Re: [PATCH v5 net-next 05/10] net: switchdev: pass flags and mask to both {PRE_,}BRIDGE_FLAGS attributes





On 12/02/2021 17:15, Vladimir Oltean wrote:

From: Vladimir Oltean 

This switchdev attribute offers a counterproductive API for a driver
writer, because although br_switchdev_set_port_flag gets passed a
"flags" and a "mask", those are passed piecemeal to the driver, so while
the PRE_BRIDGE_FLAGS listener knows what changed because it has the
"mask", the BRIDGE_FLAGS listener doesn't, because it only has the final
value. But certain drivers can offload only certain combinations of
settings, like for example they cannot change unicast flooding
independently of multicast flooding - they must be both on or both off.
The way the information is passed to switchdev makes drivers not
expressive enough, and unable to reject this request ahead of time, in
the PRE_BRIDGE_FLAGS notifier, so they are forced to reject it during
the deferred BRIDGE_FLAGS attribute, where the rejection is currently
ignored.

This patch also changes drivers to make use of the "mask" field for edge
detection when possible.

Signed-off-by: Vladimir Oltean 
---
Changes in v5:
Rebased on top of AM65 CPSW driver.

Changes in v4:
Patch is new.

  .../marvell/prestera/prestera_switchdev.c | 23 +
  .../mellanox/mlxsw/spectrum_switchdev.c   | 50 +++
  drivers/net/ethernet/rocker/rocker_main.c | 10 ++--
  drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 24 +
  drivers/net/ethernet/ti/cpsw_switchdev.c  | 24 +
  drivers/staging/fsl-dpaa2/ethsw/ethsw.c   | 34 -
  include/net/switchdev.h   |  7 ++-
  net/bridge/br_switchdev.c |  6 +--
  net/dsa/dsa_priv.h|  6 ++-
  net/dsa/port.c| 34 +++--
  10 files changed, 129 insertions(+), 89 deletions(-)



Reviewed-by: Grygorii Strashko 

--
Best regards,
grygorii

Re: [PATCH v5 net-next 01/10] net: switchdev: propagate extack to port attributes





On 12/02/2021 17:15, Vladimir Oltean wrote:

From: Vladimir Oltean 

When a struct switchdev_attr is notified through switchdev, there is no
way to report informational messages, unlike for struct switchdev_obj.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Ido Schimmel 
Reviewed-by: Florian Fainelli 
---
Changes in v5:
Rebased on top of AM65 CPSW driver merge.

Changes in v4:
None.

Changes in v3:
None.

Changes in v2:
Patch is new.

  .../ethernet/marvell/prestera/prestera_switchdev.c|  3 ++-
  .../net/ethernet/mellanox/mlxsw/spectrum_switchdev.c  |  3 ++-
  drivers/net/ethernet/mscc/ocelot_net.c|  3 ++-
  drivers/net/ethernet/ti/am65-cpsw-switchdev.c |  3 ++-
  drivers/net/ethernet/ti/cpsw_switchdev.c  |  3 ++-
  include/net/switchdev.h   |  6 --
  net/dsa/slave.c   |  3 ++-
  net/switchdev/switchdev.c | 11 ---
  8 files changed, 24 insertions(+), 11 deletions(-)



Reviewed-by: Grygorii Strashko 

--
Best regards,
grygorii

Re: [PATCH v4 net-next 0/9] Cleanup in brport flags switchdev offload for DSA





On 12/02/2021 03:05, Vladimir Oltean wrote:

From: Vladimir Oltean 

The initial goal of this series was to have better support for
standalone ports mode on the DSA drivers like ocelot/felix and sja1105.
This turned out to require some API adjustments in both directions:
to the information presented to and by the switchdev notifier, and to
the API presented to the switch drivers by the DSA layer.

Vladimir Oltean (9):
   net: switchdev: propagate extack to port attributes
   net: bridge: offload all port flags at once in br_setport
   net: bridge: don't print in br_switchdev_set_port_flag
   net: dsa: configure better brport flags when ports leave the bridge
   net: switchdev: pass flags and mask to both {PRE_,}BRIDGE_FLAGS
 attributes
   net: dsa: act as ass passthrough for bridge port flags
   net: mscc: ocelot: use separate flooding PGID for broadcast
   net: mscc: ocelot: offload bridge port flags to device
   net: dsa: sja1105: offload bridge port flags to device

  drivers/net/dsa/b53/b53_common.c  |  91 ---
  drivers/net/dsa/b53/b53_priv.h|   2 -
  drivers/net/dsa/mv88e6xxx/chip.c  | 163 ++---
  drivers/net/dsa/mv88e6xxx/chip.h  |   6 +-
  drivers/net/dsa/mv88e6xxx/port.c  |  52 ++--
  drivers/net/dsa/mv88e6xxx/port.h  |  19 +-
  drivers/net/dsa/ocelot/felix.c|  22 ++
  drivers/net/dsa/sja1105/sja1105.h |   2 +
  drivers/net/dsa/sja1105/sja1105_main.c| 222 +-
  drivers/net/dsa/sja1105/sja1105_spi.c |   6 +
  .../marvell/prestera/prestera_switchdev.c |  26 +-
  .../mellanox/mlxsw/spectrum_switchdev.c   |  53 +++--
  drivers/net/ethernet/mscc/ocelot.c| 100 +++-
  drivers/net/ethernet/mscc/ocelot_net.c|  52 +++-
  drivers/net/ethernet/rocker/rocker_main.c |  10 +-
  drivers/net/ethernet/ti/cpsw_switchdev.c  |  27 ++-
  drivers/staging/fsl-dpaa2/ethsw/ethsw.c   |  34 ++-
  include/net/dsa.h |  10 +-
  include/net/switchdev.h   |  13 +-
  include/soc/mscc/ocelot.h |  20 +-
  net/bridge/br_netlink.c   | 116 +++--
  net/bridge/br_private.h   |   6 +-
  net/bridge/br_switchdev.c |  23 +-
  net/bridge/br_sysfs_if.c  |   7 +-
  net/dsa/dsa_priv.h|  11 +-
  net/dsa/port.c|  76 --
  net/dsa/slave.c   |  10 +-
  net/switchdev/switchdev.c |  11 +-
  28 files changed, 870 insertions(+), 320 deletions(-)



Sorry, but we seems just added more work for you.
https://lore.kernel.org/patchwork/cover/1379380/

--
Best regards,
grygorii

Re: [Linuxarm] Re: [PATCH for next v1 1/2] gpio: omap: Replace raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()





On 12/02/2021 15:12, Song Bao Hua (Barry Song) wrote:




-Original Message-
From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
Sent: Saturday, February 13, 2021 12:53 AM
To: Song Bao Hua (Barry Song) ; Andy Shevchenko

Cc: Arnd Bergmann ; luojiaxing ; Linus
Walleij ; Santosh Shilimkar ;
Kevin Hilman ; open list:GPIO SUBSYSTEM
; linux-kernel@vger.kernel.org;
linux...@openeuler.org
Subject: Re: [Linuxarm] Re: [PATCH for next v1 1/2] gpio: omap: Replace
raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()



On 12/02/2021 13:29, Song Bao Hua (Barry Song) wrote:




-Original Message-
From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
Sent: Friday, February 12, 2021 11:57 PM
To: Song Bao Hua (Barry Song) 
Cc: Grygorii Strashko ; Arnd Bergmann
; luojiaxing ; Linus Walleij
; Santosh Shilimkar ; Kevin
Hilman ; open list:GPIO SUBSYSTEM
; linux-kernel@vger.kernel.org;
linux...@openeuler.org
Subject: Re: [Linuxarm] Re: [PATCH for next v1 1/2] gpio: omap: Replace
raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()

On Fri, Feb 12, 2021 at 10:42:19AM +, Song Bao Hua (Barry Song) wrote:

From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
Sent: Friday, February 12, 2021 11:28 PM
On 12/02/2021 11:45, Arnd Bergmann wrote:

On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
 wrote:



Note. there is also generic_handle_irq() call inside.


So generic_handle_irq() is not safe to run in thread thus requires
an interrupt-disabled environment to run? If so, I'd rather this
irqsave moved into generic_handle_irq() rather than asking everyone
calling it to do irqsave.


In a preempt-rt kernel, interrupts are run in task context, so they clearly
should not be called with interrupts disabled, that would defeat the
purpose of making them preemptible.

generic_handle_irq() does need to run with in_irq()==true though,
but this should be set by the caller of the gpiochip's handler, and
it is not set by raw_spin_lock_irqsave().


It will produce warning from __handle_irq_event_percpu(), as this is IRQ
dispatcher
and generic_handle_irq() will call one of handle_level_irq or

handle_edge_irq.


The history behind this is commit 450fa54cfd66 ("gpio: omap: convert to

use

generic irq handler").

The resent related discussion:
https://lkml.org/lkml/2020/12/5/208


Ok, second thought. irqsave before generic_handle_irq() won't defeat
the purpose of preemption too much as the dispatched irq handlers by
gpiochip will run in their own threads but not in the thread of
gpiochip's handler.

so looks like this patch can improve by:
* move other raw_spin_lock_irqsave to raw_spin_lock;
* keep the raw_spin_lock_irqsave before generic_handle_irq() to mute
the warning in genirq.


Isn't the idea of irqsave is to prevent dead lock from the process context

when

we get interrupt on the *same* CPU?


Anyway, gpiochip is more tricky as it is also a irq dispatcher. Moving
spin_lock_irq to spin_lock in the irq handler of non-irq dispatcher
driver is almost always correct.

But for gpiochip, would the below be true though it is almost alway true
for non-irq dispatcher?

1. While gpiochip's handler runs in hardIRQ, interrupts are disabled, so no

more

interrupt on the same cpu -> No deadleak.

2. While gpiochip's handler runs in threads
* other non-threaded interrupts such as timer tick might come on same cpu,
but they are an irrelevant driver and thus they are not going to get the
lock gpiochip's handler has held. -> no deadlock.
* other devices attached to this gpiochip might get interrupts, since
gpiochip's handler is running in threads, raw_spin_lock can help avoid
messing up the critical data by two threads -> still no deadlock.


The worst RT case I can imagine is when gpio API is still called from hard IRQ
context by some
other device driver - some toggling for example.
Note. RT or "threadirqs" does not mean gpiochip become sleepable.

In this case:
   threaded handler
 raw_spin_lock
IRQ from other device
hard_irq handler
  gpiod_x()
raw_spin_lock_irqsave() -- oops


Actually no oops here. other drivers don't hold the same
spinlock of this driver.


huh.
driver/module A requests gpio and uses it in its hard_irq handler by calling 
GPIO API
(Like gpiod_set_value()), those will go to this driver and end up in 
omap_gpio_set().





But in general, what are the benefit of such changes at all, except better 
marking
call context annotation,
so we are spending so much time on it?


TBH, the benefit is really tiny except code cleanup. just curious how things 
could
be different while it happens in an irq dispatcher's handler.



--
Best regards,
grygorii

Re: [Linuxarm] Re: [PATCH for next v1 1/2] gpio: omap: Replace raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()





On 12/02/2021 13:29, Song Bao Hua (Barry Song) wrote:




-Original Message-
From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
Sent: Friday, February 12, 2021 11:57 PM
To: Song Bao Hua (Barry Song) 
Cc: Grygorii Strashko ; Arnd Bergmann
; luojiaxing ; Linus Walleij
; Santosh Shilimkar ; Kevin
Hilman ; open list:GPIO SUBSYSTEM
; linux-kernel@vger.kernel.org;
linux...@openeuler.org
Subject: Re: [Linuxarm] Re: [PATCH for next v1 1/2] gpio: omap: Replace
raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()

On Fri, Feb 12, 2021 at 10:42:19AM +, Song Bao Hua (Barry Song) wrote:

From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
Sent: Friday, February 12, 2021 11:28 PM
On 12/02/2021 11:45, Arnd Bergmann wrote:

On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
 wrote:



Note. there is also generic_handle_irq() call inside.


So generic_handle_irq() is not safe to run in thread thus requires
an interrupt-disabled environment to run? If so, I'd rather this
irqsave moved into generic_handle_irq() rather than asking everyone
calling it to do irqsave.


In a preempt-rt kernel, interrupts are run in task context, so they clearly
should not be called with interrupts disabled, that would defeat the
purpose of making them preemptible.

generic_handle_irq() does need to run with in_irq()==true though,
but this should be set by the caller of the gpiochip's handler, and
it is not set by raw_spin_lock_irqsave().


It will produce warning from __handle_irq_event_percpu(), as this is IRQ
dispatcher
and generic_handle_irq() will call one of handle_level_irq or

handle_edge_irq.


The history behind this is commit 450fa54cfd66 ("gpio: omap: convert to

use

generic irq handler").

The resent related discussion:
https://lkml.org/lkml/2020/12/5/208


Ok, second thought. irqsave before generic_handle_irq() won't defeat
the purpose of preemption too much as the dispatched irq handlers by
gpiochip will run in their own threads but not in the thread of
gpiochip's handler.

so looks like this patch can improve by:
* move other raw_spin_lock_irqsave to raw_spin_lock;
* keep the raw_spin_lock_irqsave before generic_handle_irq() to mute
the warning in genirq.


Isn't the idea of irqsave is to prevent dead lock from the process context when
we get interrupt on the *same* CPU?


Anyway, gpiochip is more tricky as it is also a irq dispatcher. Moving
spin_lock_irq to spin_lock in the irq handler of non-irq dispatcher
driver is almost always correct.

But for gpiochip, would the below be true though it is almost alway true
for non-irq dispatcher?

1. While gpiochip's handler runs in hardIRQ, interrupts are disabled, so no more
interrupt on the same cpu -> No deadleak.

2. While gpiochip's handler runs in threads
* other non-threaded interrupts such as timer tick might come on same cpu,
but they are an irrelevant driver and thus they are not going to get the
lock gpiochip's handler has held. -> no deadlock.
* other devices attached to this gpiochip might get interrupts, since
gpiochip's handler is running in threads, raw_spin_lock can help avoid
messing up the critical data by two threads -> still no deadlock.


The worst RT case I can imagine is when gpio API is still called from hard IRQ 
context by some
other device driver - some toggling for example.
Note. RT or "threadirqs" does not mean gpiochip become sleepable.

In this case:
 threaded handler
   raw_spin_lock
IRQ from other device
  hard_irq handler
gpiod_x()
raw_spin_lock_irqsave() -- oops

But in general, what are the benefit of such changes at all, except better 
marking call context annotation,
so we are spending so much time on it?


--
Best regards,
grygorii

Re: [Linuxarm] Re: [PATCH for next v1 1/2] gpio: omap: Replace raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()


Hi Arnd,

On 12/02/2021 11:45, Arnd Bergmann wrote:

On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
 wrote:

-Original Message-




Note. there is also generic_handle_irq() call inside.


So generic_handle_irq() is not safe to run in thread thus requires
an interrupt-disabled environment to run? If so, I'd rather this
irqsave moved into generic_handle_irq() rather than asking everyone
calling it to do irqsave.


In a preempt-rt kernel, interrupts are run in task context, so they clearly
should not be called with interrupts disabled, that would defeat the
purpose of making them preemptible.

generic_handle_irq() does need to run with in_irq()==true though,
but this should be set by the caller of the gpiochip's handler, and
it is not set by raw_spin_lock_irqsave().


It will produce warning from __handle_irq_event_percpu(), as this is IRQ 
dispatcher
and generic_handle_irq() will call one of handle_level_irq or handle_edge_irq.

The history behind this is commit 450fa54cfd66 ("gpio: omap: convert to use generic 
irq handler").

The resent related discussion:
https://lkml.org/lkml/2020/12/5/208



--
Best regards,
grygorii

Re: [PATCH for next v1 1/2] gpio: omap: Replace raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()

2021-02-11 Thread Grygorii Strashko





On 11/02/2021 21:39, Arnd Bergmann wrote:

On Thu, Feb 11, 2021 at 7:25 PM Grygorii Strashko
 wrote:

On 08/02/2021 10:56, Luo Jiaxing wrote:

There is no need to use API with _irqsave in omap_gpio_irq_handler(),
because it already be in a irq-disabled context.


NACK.
Who said that this is always hard IRQ handler?
What about RT-kernel or boot with "threadirqs"?


In those cases, the interrupt handler is just a normal thread, so the
preempt_disable() that is implied by raw_spin_lock() is sufficient.

Disabling interrupts inside of an interrupt handler is always incorrect,
the patch looks like a useful cleanup to me, if only for readability.


Note. there is also generic_handle_irq() call inside.

--
Best regards,
grygorii

Re: [PATCH for next v1 1/2] gpio: omap: Replace raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()

2021-02-11 Thread Grygorii Strashko





On 08/02/2021 10:56, Luo Jiaxing wrote:

There is no need to use API with _irqsave in omap_gpio_irq_handler(),
because it already be in a irq-disabled context.

Signed-off-by: Luo Jiaxing 
---
  drivers/gpio/gpio-omap.c | 15 ++-
  1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 41952bb..dc8bbf4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -560,8 +560,6 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
u32 enabled, isr, edge;
unsigned int bit;
struct gpio_bank *bank = gpiobank;
-   unsigned long wa_lock_flags;
-   unsigned long lock_flags;
  
  	isr_reg = bank->base + bank->regs->irqstatus;

if (WARN_ON(!isr_reg))
@@ -572,7 +570,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
return IRQ_NONE;
  
  	while (1) {

-   raw_spin_lock_irqsave(>lock, lock_flags);
+   raw_spin_lock(>lock);
  
  		enabled = omap_get_gpio_irqbank_mask(bank);

isr = readl_relaxed(isr_reg) & enabled;
@@ -586,7 +584,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
if (edge)
omap_clear_gpio_irqbank(bank, edge);
  
-		raw_spin_unlock_irqrestore(>lock, lock_flags);

+   raw_spin_unlock(>lock);
  
  		if (!isr)

break;
@@ -595,7 +593,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
bit = __ffs(isr);
isr &= ~(BIT(bit));
  
-			raw_spin_lock_irqsave(>lock, lock_flags);

+   raw_spin_lock(>lock);
/*
 * Some chips can't respond to both rising and falling
 * at the same time.  If this irq was requested with
@@ -606,15 +604,14 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
if (bank->toggle_mask & (BIT(bit)))
omap_toggle_gpio_edge_triggering(bank, bit);
  
-			raw_spin_unlock_irqrestore(>lock, lock_flags);

+   raw_spin_unlock(>lock);
  
-			raw_spin_lock_irqsave(>wa_lock, wa_lock_flags);

+   raw_spin_lock(>wa_lock);
  
  			generic_handle_irq(irq_find_mapping(bank->chip.irq.domain,

bit));
  
-			raw_spin_unlock_irqrestore(>wa_lock,

-  wa_lock_flags);
+   raw_spin_unlock(>wa_lock);
}
}
  exit:



NACK.
Who said that this is always hard IRQ handler?
What about RT-kernel or boot with "threadirqs"?

--
Best regards,
grygorii

Re: [PATCH] soc: ti: k3-ringacc: Use of_device_get_match_data()

2021-02-05 Thread Grygorii Strashko





On 30/01/2021 07:04, Suman Anna wrote:

Simplify the retrieval of getting the match data in the probe
function by directly using of_device_get_match_data() instead
of using of_match_node() and getting data.

Signed-off-by: Suman Anna 
---
  drivers/soc/ti/k3-ringacc.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
index b495b0d5d0fa..312ba0f98ad7 100644
--- a/drivers/soc/ti/k3-ringacc.c
+++ b/drivers/soc/ti/k3-ringacc.c
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -1517,15 +1518,13 @@ EXPORT_SYMBOL_GPL(k3_ringacc_dmarings_init);
  static int k3_ringacc_probe(struct platform_device *pdev)
  {
const struct ringacc_match_data *match_data;
-   const struct of_device_id *match;
struct device *dev = >dev;
struct k3_ringacc *ringacc;
int ret;
  
-	match = of_match_node(k3_ringacc_of_match, dev->of_node);

-   if (!match)
+   match_data = of_device_get_match_data(>dev);
+   if (!match_data)
return -ENODEV;
-   match_data = match->data;
  
  	ringacc = devm_kzalloc(dev, sizeof(*ringacc), GFP_KERNEL);

if (!ringacc)



Thank you
Reviewed-by: Grygorii Strashko 
--
Best regards,
grygorii

[PATCH] dmaengine: ti: k3-psil: optimize struct psil_endpoint_config for size

2021-01-29 Thread Grygorii Strashko

Optimize struct psil_endpoint_config for size by
- reordering fields
- grouping bitfields
- change mapped_channel_id type to s16 (32K channel is enough)
- default_flow_id type to s16 as it's assigned to -1

before:
textdata bssdec hex filename
126541005211472  666904 1853247611ac87c vmlinux

after:
126541005208528  666904 1852953211abcfc vmlinux

diff: 2944 bytes

Signed-off-by: Grygorii Strashko 
---
 include/linux/dma/k3-psil.h | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/include/linux/dma/k3-psil.h b/include/linux/dma/k3-psil.h
index 36e22c5a0f29..5f106d852f1c 100644
--- a/include/linux/dma/k3-psil.h
+++ b/include/linux/dma/k3-psil.h
@@ -42,14 +42,14 @@ enum psil_endpoint_type {
 /**
  * struct psil_endpoint_config - PSI-L Endpoint configuration
  * @ep_type:   PSI-L endpoint type
+ * @channel_tpl:   Desired throughput level for the channel
  * @pkt_mode:  If set, the channel must be in Packet mode, otherwise in
  * TR mode
  * @notdpkt:   TDCM must be suppressed on the TX channel
  * @needs_epib:Endpoint needs EPIB
- * @psd_size:  If set, PSdata is used by the endpoint
- * @channel_tpl:   Desired throughput level for the channel
  * @pdma_acc32:ACC32 must be enabled on the PDMA side
  * @pdma_burst:BURST must be enabled on the PDMA side
+ * @psd_size:  If set, PSdata is used by the endpoint
  * @mapped_channel_id: PKTDMA thread to channel mapping for mapped channels.
  * The thread must be serviced by the specified channel if
  * mapped_channel_id is >= 0 in case of PKTDMA
@@ -62,23 +62,22 @@ enum psil_endpoint_type {
  */
 struct psil_endpoint_config {
enum psil_endpoint_type ep_type;
+   enum udma_tp_level channel_tpl;
 
unsigned pkt_mode:1;
unsigned notdpkt:1;
unsigned needs_epib:1;
-   u32 psd_size;
-   enum udma_tp_level channel_tpl;
-
/* PDMA properties, valid for PSIL_EP_PDMA_* */
unsigned pdma_acc32:1;
unsigned pdma_burst:1;
 
+   u32 psd_size;
/* PKDMA mapped channel */
-   int mapped_channel_id;
+   s16 mapped_channel_id;
/* PKTDMA tflow and rflow ranges for mapped channel */
u16 flow_start;
u16 flow_num;
-   u16 default_flow_id;
+   s16 default_flow_id;
 };
 
 int psil_set_new_ep_config(struct device *dev, const char *name,
-- 
2.17.1

Re: [PATCH v2 2/6] drivers: net: davinci_mdio: Use of_device_get_match_data()

2021-01-26 Thread Grygorii Strashko





On 23/01/2021 05:44, Stephen Boyd wrote:

Use the more modern API to get the match data out of the of match table.
This saves some code, lines, and nicely avoids referencing the match
table when it is undefined with configurations where CONFIG_OF=n.

Signed-off-by: Stephen Boyd 
Cc: Arnd Bergmann 
Cc: Geert Uytterhoeven 
Cc: Grygorii Strashko 
Cc: "David S. Miller" 
Cc: Rob Herring 
Cc: Frank Rowand 
Cc: 
---

Please ack so Rob can apply.

  drivers/net/ethernet/ti/davinci_mdio.c | 12 
  1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_mdio.c 
b/drivers/net/ethernet/ti/davinci_mdio.c
index cfff3d48807a..a4efd5e35158 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -358,20 +358,16 @@ static int davinci_mdio_probe(struct platform_device 
*pdev)
}
  
  	if (IS_ENABLED(CONFIG_OF) && dev->of_node) {

-   const struct of_device_id   *of_id;
+   const struct davinci_mdio_of_param *of_mdio_data;
  
  		ret = davinci_mdio_probe_dt(>pdata, pdev);

if (ret)
return ret;
snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s", pdev->name);
  
-		of_id = of_match_device(davinci_mdio_of_mtable, >dev);

-   if (of_id) {
-   const struct davinci_mdio_of_param *of_mdio_data;
-
-   of_mdio_data = of_id->data;
-   if (of_mdio_data)
-   autosuspend_delay_ms =
+   of_mdio_data = of_device_get_match_data(>dev);
+   if (of_mdio_data) {
+   autosuspend_delay_ms =
of_mdio_data->autosuspend_delay_ms;
    }
    } else {



Thank you.
Reviewed-by: Grygorii Strashko 

--
Best regards,
grygorii

[PATCH] dt-bindings: mmc: sdhci-am654: fix compatible for j7200

On TI J7200 SoC the SDHCI controller compatible defined as
 "ti,j7200-sdhci-8bit", "ti,j721e-sdhci-8bit"
 or
 "ti,j7200-sdhci-4bit", "ti,j721e-sdhci-4bit"
which causes dtbs_check warnings:
mmc@4f8: compatible: ['ti,j7200-sdhci-8bit', 'ti,j721e-sdhci-8bit'] is too 
long
mmc@4f8: compatible: Additional items are not allowed 
('ti,j721e-sdhci-8bit' was unexpected)
mmc@4fb: compatible:0: 'ti,j7200-sdhci-4bit' is not one of 
['ti,am654-sdhci-5.1', 'ti,j721e-sdhci-8bit',
 'ti,j721e-sdhci-4bit', 'ti,j7200-sdhci-8bit', 'ti,j721e-sdhci-4bit', 
'ti,am64-sdhci-8bit', 'ti,am64-sdhci-4bit']
mmc@4fb: compatible: ['ti,j7200-sdhci-4bit', 'ti,j721e-sdhci-4bit'] is too 
long
mmc@4fb: compatible: Additional items are not allowed 
('ti,j721e-sdhci-4bit' was unexpected)

Fix it by adding missing compatible strings and their combinations.

Fixes: 407d0c2cdd12 ("dt-bindings: mmc: sdhci-am654: Convert sdhci-am654 
controller documentation to json schema")
Signed-off-by: Grygorii Strashko 
---
 .../devicetree/bindings/mmc/sdhci-am654.yaml  | 21 ---
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml 
b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml
index 34e53db29428..3a79e39253d2 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml
+++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml
@@ -15,14 +15,19 @@ allOf:
 
 properties:
   compatible:
-enum:
-  - ti,am654-sdhci-5.1
-  - ti,j721e-sdhci-8bit
-  - ti,j721e-sdhci-4bit
-  - ti,j7200-sdhci-8bit
-  - ti,j721e-sdhci-4bit
-  - ti,am64-sdhci-8bit
-  - ti,am64-sdhci-4bit
+oneOf:
+  - const: ti,am654-sdhci-5.1
+  - const: ti,j721e-sdhci-8bit
+  - const: ti,j721e-sdhci-4bit
+  - const: ti,j721e-sdhci-4bit
+  - const: ti,am64-sdhci-8bit
+  - const: ti,am64-sdhci-4bit
+  - items:
+  - const: ti,j7200-sdhci-8bit
+  - const: ti,j721e-sdhci-8bit
+  - items:
+  - const: ti,j7200-sdhci-4bit
+  - const: ti,j721e-sdhci-4bit
 
   reg:
 maxItems: 2
-- 
2.17.1

[PATCH] dt-bindings: usb: j721e: add ranges and dma-coherent props

Add missed 'ranges' and 'dma-coherent' properties as cdns-usb DT nodes has
child node and DMA IO is coherent on TI K3 J721E/J7200 SoCs.

This also fixes dtbs_check warning:
 cdns-usb@4104000: 'dma-coherent', 'ranges' do not match any of the regexes: 
'^usb@', 'pinctrl-[0-9]+'

Signed-off-by: Grygorii Strashko 
---
 Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml 
b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
index 4423f0a29f54..7ec87a783c5c 100644
--- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
@@ -21,6 +21,8 @@ properties:
   reg:
 maxItems: 1
 
+  ranges: true
+
   power-domains:
 description:
   PM domain provider node and an args specifier containing
@@ -63,6 +65,8 @@ properties:
   '#size-cells':
 const: 2
 
+  dma-coherent: true
+
 patternProperties:
   "^usb@":
 type: object
-- 
2.17.1

[PATCH] arm64: dts: ti: k3: mmc: fix dtbs_check warnings

Now the dtbs_check produces below warnings
 sdhci@4f8: clock-names:0: 'clk_ahb' was expected
 sdhci@4f8: clock-names:1: 'clk_xin' was expected
 $nodename:0: 'sdhci@4f8' does not match '^mmc(@.*)?$'

Fix above warnings by updating mmc DT definitions to follow
sdhci-am654.yaml bindings:
 - rename sdhci dt nodes to 'mmc@'
 - swap clk_xin/clk_ahb clocks, the clk_ahb clock expected to be defined
first

Signed-off-by: Grygorii Strashko 
---
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi  |  4 ++--
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi |  8 
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 18 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 12591a854020..ceb579fb427d 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -256,7 +256,7 @@
#size-cells = <0>;
};
 
-   sdhci0: sdhci@4f8 {
+   sdhci0: mmc@4f8 {
compatible = "ti,am654-sdhci-5.1";
reg = <0x0 0x4f8 0x0 0x260>, <0x0 0x4f9 0x0 0x134>;
power-domains = <_pds 47 TI_SCI_PD_EXCLUSIVE>;
@@ -280,7 +280,7 @@
dma-coherent;
};
 
-   sdhci1: sdhci@4fa {
+   sdhci1: mmc@4fa {
compatible = "ti,am654-sdhci-5.1";
reg = <0x0 0x4fa 0x0 0x260>, <0x0 0x4fb 0x0 0x134>;
power-domains = <_pds 48 TI_SCI_PD_EXCLUSIVE>;
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index 4e39f0325c03..3f23b913b498 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -506,8 +506,8 @@
reg = <0x00 0x04f8 0x00 0x260>, <0x00 0x4f88000 0x00 0x134>;
interrupts = ;
power-domains = <_pds 91 TI_SCI_PD_EXCLUSIVE>;
-   clock-names = "clk_xin", "clk_ahb";
-   clocks = <_clks 91 3>, <_clks 91 0>;
+   clock-names = "clk_ahb", "clk_xin";
+   clocks = <_clks 91 0>, <_clks 91 3>;
ti,otap-del-sel-legacy = <0x0>;
ti,otap-del-sel-mmc-hs = <0x0>;
ti,otap-del-sel-ddr52 = <0x6>;
@@ -525,8 +525,8 @@
reg = <0x00 0x04fb 0x00 0x260>, <0x00 0x4fb8000 0x00 0x134>;
interrupts = ;
power-domains = <_pds 92 TI_SCI_PD_EXCLUSIVE>;
-   clock-names = "clk_xin", "clk_ahb";
-   clocks = <_clks 92 2>, <_clks 92 1>;
+   clock-names = "clk_ahb", "clk_xin";
+   clocks = <_clks 92 1>, <_clks 92 2>;
ti,otap-del-sel-legacy = <0x0>;
ti,otap-del-sel-sd-hs = <0x0>;
ti,otap-del-sel-sdr12 = <0xf>;
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 2d526ea44a85..8c84dafb7125 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -1032,13 +1032,13 @@
clock-names = "gpio";
};
 
-   main_sdhci0: sdhci@4f8 {
+   main_sdhci0: mmc@4f8 {
compatible = "ti,j721e-sdhci-8bit";
reg = <0x0 0x4f8 0x0 0x1000>, <0x0 0x4f88000 0x0 0x400>;
interrupts = ;
power-domains = <_pds 91 TI_SCI_PD_EXCLUSIVE>;
-   clock-names = "clk_xin", "clk_ahb";
-   clocks = <_clks 91 1>, <_clks 91 0>;
+   clock-names = "clk_ahb", "clk_xin";
+   clocks = <_clks 91 0>, <_clks 91 1>;
assigned-clocks = <_clks 91 1>;
assigned-clock-parents = <_clks 91 2>;
bus-width = <8>;
@@ -1054,13 +1054,13 @@
dma-coherent;
};
 
-   main_sdhci1: sdhci@4fb {
+   main_sdhci1: mmc@4fb {
compatible = "ti,j721e-sdhci-4bit";
reg = <0x0 0x04fb 0x0 0x1000>, <0x0 0x4fb8000 0x0 0x400>;
interrupts = ;
power-domains = <_pds 92 TI_SCI_PD_EXCLUSIVE>;
-   clock-names = "clk_xin", "clk_ahb";
-   clocks = <_clks 92 0>, <_clks 92 5>;
+   clock-names = "clk_ahb", "clk_xin";
+   clocks = <_clks 92 5>, <_clks 92 0>;
assigned-clocks = <_clks 92 0>;
assigned-clock-parents = <_clks 92 1>

[net-next 1/6] dt-binding: ti: am65x-cpts: add assigned-clock and power-domains props

The CPTS clock is usually a clk-mux which allows to select CPTS reference
clock by using 'assigned-clock-parents', 'assigned-clocks' DT properties.
Also depending on integration the power-domains has to be specified to
enable CPTS IP.

Hence add 'assigned-clock-parents', 'assigned-clocks' and 'power-domains'
properties to the CPTS DT bindings to avoid dtbs_check warnings:
 cpts@310d: 'assigned-clock-parents', 'assigned-clocks' do not match any of 
the regexes: 'pinctrl-[0-9]+'
 cpts@310d: 'power-domains' does not match any of the regexes: 
'pinctrl-[0-9]+'

Signed-off-by: Grygorii Strashko 
---
 .../devicetree/bindings/net/ti,k3-am654-cpts.yaml  | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml 
b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml
index 9b7117920d90..ce43a1c58a57 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml
@@ -73,6 +73,13 @@ properties:
 items:
   - const: cpts
 
+  assigned-clock-parents: true
+
+  assigned-clocks: true
+
+  power-domains:
+maxItems: 1
+
   ti,cpts-ext-ts-inputs:
 $ref: /schemas/types.yaml#/definitions/uint32
 maximum: 8
-- 
2.17.1

[net-next 2/6] dt-binding: net: ti: k3-am654-cpsw-nuss: update bindings for am64x cpsw3g

Update DT binding for recently introduced TI K3 AM642x SoC [1] which
contains 3 port (2 external ports) CPSW3g module. The CPSW3g integrated
in MAIN domain and can be configured in multi port or switch modes.

The overall functionality and DT bindings are similar to other K3 CPSWxg
versions, so DT binding changes are minimal:
 - reword description
 - add new compatible 'ti,am642-cpsw-nuss'
 - allow 2 external ports child nodes
 - add missed 'assigned-clock' props

[1] https://www.ti.com/lit/pdf/spruim2
Signed-off-by: Grygorii Strashko 
---
 .../bindings/net/ti,k3-am654-cpsw-nuss.yaml   | 50 +++
 1 file changed, 30 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml 
b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index c47b58f3e3f6..3fae9a5f0c6a 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -4,7 +4,7 @@
 $id: http://devicetree.org/schemas/net/ti,k3-am654-cpsw-nuss.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: The TI AM654x/J721E SoC Gigabit Ethernet MAC (Media Access Controller) 
Device Tree Bindings
+title: The TI AM654x/J721E/AM642x SoC Gigabit Ethernet MAC (Media Access 
Controller) Device Tree Bindings
 
 maintainers:
   - Grygorii Strashko 
@@ -13,19 +13,16 @@ maintainers:
 description:
   The TI AM654x/J721E SoC Gigabit Ethernet MAC (CPSW2G NUSS) has two ports
   (one external) and provides Ethernet packet communication for the device.
-  CPSW2G NUSS features - the Reduced Gigabit Media Independent Interface 
(RGMII),
-  Reduced Media Independent Interface (RMII), the Management Data
-  Input/Output (MDIO) interface for physical layer device (PHY) management,
-  new version of Common Platform Time Sync (CPTS), updated Address Lookup
-  Engine (ALE).
-  One external Ethernet port (port 1) with selectable RGMII/RMII interfaces and
-  an internal Communications Port Programming Interface (CPPI5) (Host port 0).
+  The TI AM642x SoC Gigabit Ethernet MAC (CPSW3G NUSS) has three ports
+  (two external) and provides Ethernet packet communication and switching.
+
+  The internal Communications Port Programming Interface (CPPI5) (Host port 0).
   Host Port 0 CPPI Packet Streaming Interface interface supports 8 TX channels
-  and one RX channels and operating by TI AM654x/J721E NAVSS Unified DMA
-  Peripheral Root Complex (UDMA-P) controller.
-  The CPSW2G NUSS is integrated into device MCU domain named MCU_CPSW0.
+  and one RX channels and operating by NAVSS Unified DMA  Peripheral Root
+  Complex (UDMA-P) controller.
 
-  Additional features
+  CPSWxG features
+  updated Address Lookup Engine (ALE).
   priority level Quality Of Service (QOS) support (802.1p)
   Support for Audio/Video Bridging (P802.1Qav/D6.0)
   Support for IEEE 1588 Clock Synchronization (2008 Annex D, Annex E and Annex 
F)
@@ -38,10 +35,18 @@ description:
   VLAN support, 802.1Q compliant, Auto add port VLAN for untagged frames on
   ingress, Auto VLAN removal on egress and auto pad to minimum frame size.
   RX/TX csum offload
+  Management Data Input/Output (MDIO) interface for PHYs management
+  RMII/RGMII Interfaces support
+  new version of Common Platform Time Sync (CPTS)
+
+  The CPSWxG NUSS is integrated into
+device MCU domain named MCU_CPSW0 on AM654x/J721E SoC.
+device MAIN domain named CPSW0 on AM642x SoC.
 
   Specifications can be found at
-http://www.ti.com/lit/ug/spruid7e/spruid7e.pdf
-http://www.ti.com/lit/ug/spruil1a/spruil1a.pdf
+https://www.ti.com/lit/pdf/spruid7
+https://www.ti.com/lit/zip/spruil1
+https://www.ti.com/lit/pdf/spruim2
 
 properties:
   "#address-cells": true
@@ -51,11 +56,12 @@ properties:
 oneOf:
   - const: ti,am654-cpsw-nuss
   - const: ti,j721e-cpsw-nuss
+  - const: ti,am642-cpsw-nuss
 
   reg:
 maxItems: 1
 description:
-  The physical base address and size of full the CPSW2G NUSS IO range
+  The physical base address and size of full the CPSWxG NUSS IO range
 
   reg-names:
 items:
@@ -66,12 +72,16 @@ properties:
   dma-coherent: true
 
   clocks:
-description: CPSW2G NUSS functional clock
+description: CPSWxG NUSS functional clock
 
   clock-names:
 items:
   - const: fck
 
+  assigned-clock-parents: true
+
+  assigned-clocks: true
+
   power-domains:
 maxItems: 1
 
@@ -99,16 +109,16 @@ properties:
 const: 0
 
 patternProperties:
-  port@1:
+  port@[1-2]:
 type: object
-description: CPSW2G NUSS external ports
+description: CPSWxG NUSS external ports
 
 $ref: ethernet-controller.yaml#
 
 properties:
   reg:
-items:
-  - const: 1
+minimum: 1
+maximum: 2
 description: CPSW port number
 
   phys:
-- 
2.17.1

[net-next 5/6] net: ti: cpsw_ale: add driver data for AM64 CPSW3g

From: Vignesh Raghavendra 

The AM642x CPSW3g is similar to j721e-cpswxg except its ALE table size is
512 entries. Add entry for the same.

Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/cpsw_ale.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw_ale.c 
b/drivers/net/ethernet/ti/cpsw_ale.c
index cdc308a2aa3e..d828f856237a 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -1256,6 +1256,13 @@ static const struct cpsw_ale_dev_id cpsw_ale_id_match[] 
= {
.major_ver_mask = 0x7,
.vlan_entry_tbl = vlan_entry_k3_cpswxg,
},
+   {
+   .dev_id = "am64-cpswxg",
+   .features = CPSW_ALE_F_STATUS_REG | CPSW_ALE_F_HW_AUTOAGING,
+   .major_ver_mask = 0x7,
+   .vlan_entry_tbl = vlan_entry_k3_cpswxg,
+   .tbl_entries = 512,
+   },
{ },
 };
 
-- 
2.17.1

[net-next 0/6] net: ethernet: ti: am65-cpsw-nuss: introduce support for am64x cpsw3g

Hi

This series introduces basic support for recently introduced TI K3 AM642x SoC 
[1]
which contains 3 port (2 external ports) CPSW3g module. The CPSW3g integrated
in MAIN domain and can be configured in multi port or switch modes.
In this series only multi port mode is enabled. The initial version of switchdev
support was introduced by Vignesh Raghavendra [2] and work is in progress.

The overall functionality and DT bindings are similar to other K3 CPSWxg
versions, so DT binding changes are minimal and driver is mostly re-used for
TI K3 AM642x CPSW3g.

The main difference is that TI K3 AM642x SoC is not fully DMA coherent and
instead DMA coherency is supported per DMA channel.

Patches 1-2 - DT bindings update 
Patches 3-4 - Update driver to support changed DMA coherency model
Patches 5-6 - adds TI K3 AM642x SoC platform data and so enable CPSW3g 

[1] https://www.ti.com/lit/pdf/spruim2
[2] 
https://patchwork.ozlabs.org/project/netdev/cover/20201130082046.16292-1-vigne...@ti.com/

Grygorii Strashko (2):
  dt-binding: ti: am65x-cpts: add assigned-clock and power-domains props
  dt-binding: net: ti: k3-am654-cpsw-nuss: update bindings for am64x cpsw3g

Peter Ujfalusi (2):
  net: ethernet: ti: am65-cpsw-nuss: Use DMA device for DMA API
  net: ethernet: ti: am65-cpsw-nuss: Support for transparent ASEL
handling

Vignesh Raghavendra (2):
  net: ti: cpsw_ale: add driver data for AM64 CPSW3g
  net: ethernet: ti: am65-cpsw: add support for am64x cpsw3g

 .../bindings/net/ti,k3-am654-cpsw-nuss.yaml   | 50 ++
 .../bindings/net/ti,k3-am654-cpts.yaml|  7 ++
 drivers/net/ethernet/ti/am65-cpsw-nuss.c  | 96 +++
 drivers/net/ethernet/ti/am65-cpsw-nuss.h  |  2 +
 drivers/net/ethernet/ti/cpsw_ale.c|  7 ++
 5 files changed, 101 insertions(+), 61 deletions(-)

-- 
2.17.1

[net-next 6/6] net: ethernet: ti: am65-cpsw: add support for am64x cpsw3g

From: Vignesh Raghavendra 

The TI AM64x SoCs Gigabit Ethernet Switch subsystem (CPSW3g NUSS) has three
ports (2 ext. ports) and provides Ethernet packet communication for the
device and can be configured in multi port mode or as an Ethernet switch.

This patch adds support for the corresponding CPSW3g version.

Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c 
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index d060744dd0b2..1850743c04da 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -2115,9 +2115,16 @@ static const struct am65_cpsw_pdata j721e_pdata = {
.fdqring_mode = K3_RINGACC_RING_MODE_MESSAGE,
 };
 
+static const struct am65_cpsw_pdata am64x_cpswxg_pdata = {
+   .quirks = 0,
+   .ale_dev_id = "am64-cpswxg",
+   .fdqring_mode = K3_RINGACC_RING_MODE_RING,
+};
+
 static const struct of_device_id am65_cpsw_nuss_of_mtable[] = {
{ .compatible = "ti,am654-cpsw-nuss", .data = _sr1_0},
{ .compatible = "ti,j721e-cpsw-nuss", .data = _pdata},
+   { .compatible = "ti,am642-cpsw-nuss", .data = _cpswxg_pdata},
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, am65_cpsw_nuss_of_mtable);
-- 
2.17.1

[net-next 4/6] net: ethernet: ti: am65-cpsw-nuss: Support for transparent ASEL handling

From: Peter Ujfalusi 

Use the glue layer's functions to convert the dma_addr_t to and from CPPI5
address (with the ASEL bits), which should be used within the descriptors
and data buffers.

- Per channel coherency support
The DMAs use the 'ASEL' bits to select data and configuration fetch path.
The ASEL bits are placed at the unused parts of any address field used by
the DMAs (pointers to descriptors, addresses in descriptors, ring base
addresses). The ASEL is not part of the address (the DMAs can address
48bits). Individual channels can be configured to be coherent (via ACP
port) or non coherent individually by configuring the ASEL to appropriate
value.

[1] https://lore.kernel.org/patchwork/cover/1350756/
Signed-off-by: Peter Ujfalusi 
Co-developed-by: Vignesh Raghavendra 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c 
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 8bf48cf3be9b..d060744dd0b2 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -376,6 +376,7 @@ static int am65_cpsw_nuss_rx_push(struct am65_cpsw_common 
*common,
 
cppi5_hdesc_init(desc_rx, CPPI5_INFO0_HDESC_EPIB_PRESENT,
 AM65_CPSW_NAV_PS_DATA_SIZE);
+   k3_udma_glue_rx_dma_to_cppi5_addr(rx_chn->rx_chn, _dma);
cppi5_hdesc_attach_buf(desc_rx, buf_dma, skb_tailroom(skb), buf_dma, 
skb_tailroom(skb));
swdata = cppi5_hdesc_get_swdata(desc_rx);
*((void **)swdata) = skb;
@@ -692,6 +693,7 @@ static void am65_cpsw_nuss_rx_cleanup(void *data, 
dma_addr_t desc_dma)
swdata = cppi5_hdesc_get_swdata(desc_rx);
skb = *swdata;
cppi5_hdesc_get_obuf(desc_rx, _dma, _dma_len);
+   k3_udma_glue_rx_cppi5_to_dma_addr(rx_chn->rx_chn, _dma);
 
dma_unmap_single(rx_chn->dma_dev, buf_dma, buf_dma_len, 
DMA_FROM_DEVICE);
k3_cppi_desc_pool_free(rx_chn->desc_pool, desc_rx);
@@ -780,6 +782,7 @@ static int am65_cpsw_nuss_rx_packets(struct 
am65_cpsw_common *common,
swdata = cppi5_hdesc_get_swdata(desc_rx);
skb = *swdata;
cppi5_hdesc_get_obuf(desc_rx, _dma, _dma_len);
+   k3_udma_glue_rx_cppi5_to_dma_addr(rx_chn->rx_chn, _dma);
pkt_len = cppi5_hdesc_get_pktlen(desc_rx);
cppi5_desc_get_tags_ids(_rx->hdr, _id, NULL);
dev_dbg(dev, "%s rx port_id:%d\n", __func__, port_id);
@@ -875,19 +878,23 @@ static void am65_cpsw_nuss_xmit_free(struct 
am65_cpsw_tx_chn *tx_chn,
next_desc = first_desc;
 
cppi5_hdesc_get_obuf(first_desc, _dma, _dma_len);
+   k3_udma_glue_tx_cppi5_to_dma_addr(tx_chn->tx_chn, _dma);
 
dma_unmap_single(tx_chn->dma_dev, buf_dma, buf_dma_len, DMA_TO_DEVICE);
 
next_desc_dma = cppi5_hdesc_get_next_hbdesc(first_desc);
+   k3_udma_glue_tx_cppi5_to_dma_addr(tx_chn->tx_chn, _desc_dma);
while (next_desc_dma) {
next_desc = k3_cppi_desc_pool_dma2virt(tx_chn->desc_pool,
   next_desc_dma);
cppi5_hdesc_get_obuf(next_desc, _dma, _dma_len);
+   k3_udma_glue_tx_cppi5_to_dma_addr(tx_chn->tx_chn, _dma);
 
dma_unmap_page(tx_chn->dma_dev, buf_dma, buf_dma_len,
   DMA_TO_DEVICE);
 
next_desc_dma = cppi5_hdesc_get_next_hbdesc(next_desc);
+   k3_udma_glue_tx_cppi5_to_dma_addr(tx_chn->tx_chn, 
_desc_dma);
 
k3_cppi_desc_pool_free(tx_chn->desc_pool, next_desc);
}
@@ -1140,6 +1147,7 @@ static netdev_tx_t am65_cpsw_nuss_ndo_slave_xmit(struct 
sk_buff *skb,
cppi5_hdesc_set_pkttype(first_desc, 0x7);
cppi5_desc_set_tags_ids(_desc->hdr, 0, port->port_id);
 
+   k3_udma_glue_tx_dma_to_cppi5_addr(tx_chn->tx_chn, _dma);
cppi5_hdesc_attach_buf(first_desc, buf_dma, pkt_len, buf_dma, pkt_len);
swdata = cppi5_hdesc_get_swdata(first_desc);
*(swdata) = skb;
@@ -1185,11 +1193,13 @@ static netdev_tx_t am65_cpsw_nuss_ndo_slave_xmit(struct 
sk_buff *skb,
}
 
cppi5_hdesc_reset_hbdesc(next_desc);
+   k3_udma_glue_tx_dma_to_cppi5_addr(tx_chn->tx_chn, _dma);
cppi5_hdesc_attach_buf(next_desc,
   buf_dma, frag_size, buf_dma, frag_size);
 
desc_dma = k3_cppi_desc_pool_virt2dma(tx_chn->desc_pool,
  next_desc);
+   k3_udma_glue_tx_dma_to_cppi5_addr(tx_chn->tx_chn, _dma);
cppi5_hdesc_link_hbdesc(cur_desc, desc_dma);
 
pkt_len += frag_size;
-- 
2.17.1

[net-next 3/6] net: ethernet: ti: am65-cpsw-nuss: Use DMA device for DMA API

From: Peter Ujfalusi 

For DMA API the DMA device should be used as cpsw does not accesses to
descriptors or data buffers in any ways. The DMA does.

Also, drop dma_coerce_mask_and_coherent() setting on CPSW device, as it
should be done by DMA driver which does data movement.

This is required for adding AM64x CPSW3g support where DMA coherency
supported per DMA channel.

Signed-off-by: Peter Ujfalusi 
Co-developed-by: Vignesh Raghavendra 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 79 
 drivers/net/ethernet/ti/am65-cpsw-nuss.h |  2 +
 2 files changed, 40 insertions(+), 41 deletions(-)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c 
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 766e8866bbef..8bf48cf3be9b 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -366,8 +366,9 @@ static int am65_cpsw_nuss_rx_push(struct am65_cpsw_common 
*common,
}
desc_dma = k3_cppi_desc_pool_virt2dma(rx_chn->desc_pool, desc_rx);
 
-   buf_dma = dma_map_single(dev, skb->data, pkt_len, DMA_FROM_DEVICE);
-   if (unlikely(dma_mapping_error(dev, buf_dma))) {
+   buf_dma = dma_map_single(rx_chn->dma_dev, skb->data, pkt_len,
+DMA_FROM_DEVICE);
+   if (unlikely(dma_mapping_error(rx_chn->dma_dev, buf_dma))) {
k3_cppi_desc_pool_free(rx_chn->desc_pool, desc_rx);
dev_err(dev, "Failed to map rx skb buffer\n");
return -EINVAL;
@@ -692,7 +693,7 @@ static void am65_cpsw_nuss_rx_cleanup(void *data, 
dma_addr_t desc_dma)
skb = *swdata;
cppi5_hdesc_get_obuf(desc_rx, _dma, _dma_len);
 
-   dma_unmap_single(rx_chn->dev, buf_dma, buf_dma_len, DMA_FROM_DEVICE);
+   dma_unmap_single(rx_chn->dma_dev, buf_dma, buf_dma_len, 
DMA_FROM_DEVICE);
k3_cppi_desc_pool_free(rx_chn->desc_pool, desc_rx);
 
dev_kfree_skb_any(skb);
@@ -793,7 +794,7 @@ static int am65_cpsw_nuss_rx_packets(struct 
am65_cpsw_common *common,
csum_info = psdata[2];
dev_dbg(dev, "%s rx csum_info:%#x\n", __func__, csum_info);
 
-   dma_unmap_single(dev, buf_dma, buf_dma_len, DMA_FROM_DEVICE);
+   dma_unmap_single(rx_chn->dma_dev, buf_dma, buf_dma_len, 
DMA_FROM_DEVICE);
 
k3_cppi_desc_pool_free(rx_chn->desc_pool, desc_rx);
 
@@ -864,7 +865,6 @@ static int am65_cpsw_nuss_rx_poll(struct napi_struct 
*napi_rx, int budget)
 }
 
 static void am65_cpsw_nuss_xmit_free(struct am65_cpsw_tx_chn *tx_chn,
-struct device *dev,
 struct cppi5_host_desc_t *desc)
 {
struct cppi5_host_desc_t *first_desc, *next_desc;
@@ -876,8 +876,7 @@ static void am65_cpsw_nuss_xmit_free(struct 
am65_cpsw_tx_chn *tx_chn,
 
cppi5_hdesc_get_obuf(first_desc, _dma, _dma_len);
 
-   dma_unmap_single(dev, buf_dma, buf_dma_len,
-DMA_TO_DEVICE);
+   dma_unmap_single(tx_chn->dma_dev, buf_dma, buf_dma_len, DMA_TO_DEVICE);
 
next_desc_dma = cppi5_hdesc_get_next_hbdesc(first_desc);
while (next_desc_dma) {
@@ -885,7 +884,7 @@ static void am65_cpsw_nuss_xmit_free(struct 
am65_cpsw_tx_chn *tx_chn,
   next_desc_dma);
cppi5_hdesc_get_obuf(next_desc, _dma, _dma_len);
 
-   dma_unmap_page(dev, buf_dma, buf_dma_len,
+   dma_unmap_page(tx_chn->dma_dev, buf_dma, buf_dma_len,
   DMA_TO_DEVICE);
 
next_desc_dma = cppi5_hdesc_get_next_hbdesc(next_desc);
@@ -906,7 +905,7 @@ static void am65_cpsw_nuss_tx_cleanup(void *data, 
dma_addr_t desc_dma)
desc_tx = k3_cppi_desc_pool_dma2virt(tx_chn->desc_pool, desc_dma);
swdata = cppi5_hdesc_get_swdata(desc_tx);
skb = *(swdata);
-   am65_cpsw_nuss_xmit_free(tx_chn, tx_chn->common->dev, desc_tx);
+   am65_cpsw_nuss_xmit_free(tx_chn, desc_tx);
 
dev_kfree_skb_any(skb);
 }
@@ -926,7 +925,7 @@ am65_cpsw_nuss_tx_compl_packet(struct am65_cpsw_tx_chn 
*tx_chn,
 desc_dma);
swdata = cppi5_hdesc_get_swdata(desc_tx);
skb = *(swdata);
-   am65_cpsw_nuss_xmit_free(tx_chn, tx_chn->common->dev, desc_tx);
+   am65_cpsw_nuss_xmit_free(tx_chn, desc_tx);
 
ndev = skb->dev;
 
@@ -1119,9 +1118,9 @@ static netdev_tx_t am65_cpsw_nuss_ndo_slave_xmit(struct 
sk_buff *skb,
netif_txq = netdev_get_tx_queue(ndev, q_idx);
 
/* Map the linear buffer */
-   buf_dma = dma_map_single(dev, skb->data, pkt_len,
+   buf_dma = dma_map_single(tx_chn->dma_dev, skb->data, pkt_len,
 DMA_TO_DEVICE);
-   if (unlikely(dma_mapping_error(dev, buf_dma))) {
+   if (unlikely(dma_mapping_error(t

[PATCH net] net: ethernet: ti: cpts: fix ethtool output when no ptp_clock registered

2020-12-24 Thread Grygorii Strashko

The CPTS driver registers PTP PHC clock when first netif is going up and
unregister it when all netif are down. Now ethtool will show:
 - PTP PHC clock index 0 after boot until first netif is up;
 - the last assigned PTP PHC clock index even if PTP PHC clock is not
registered any more after all netifs are down.

This patch ensures that -1 is returned by ethtool when PTP PHC clock is not
registered any more.

Fixes: 8a2c9a5ab4b9 ("net: ethernet: ti: cpts: rework 
initialization/deinitialization")
Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/cpts.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index d1fc7955d422..43222a34cba0 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -599,6 +599,7 @@ void cpts_unregister(struct cpts *cpts)
 
ptp_clock_unregister(cpts->clock);
cpts->clock = NULL;
+   cpts->phc_index = -1;
 
cpts_write32(cpts, 0, int_enable);
cpts_write32(cpts, 0, control);
@@ -784,6 +785,7 @@ struct cpts *cpts_create(struct device *dev, void __iomem 
*regs,
cpts->cc.read = cpts_systim_read;
cpts->cc.mask = CLOCKSOURCE_MASK(32);
cpts->info = cpts_info;
+   cpts->phc_index = -1;
 
if (n_ext_ts)
cpts->info.n_ext_ts = n_ext_ts;
-- 
2.17.1

Re: [v2] i2c: mediatek: Move suspend and resume handling to NOIRQ phase

2020-12-14 Thread Grygorii Strashko





On 14/12/2020 10:48, Qii Wang wrote:

On Thu, 2020-12-10 at 15:03 +0200, Grygorii Strashko wrote:


On 10/12/2020 03:56, Qii Wang wrote:

On Mon, 2020-12-07 at 18:35 +0200, Grygorii Strashko wrote:




On Thu, 2020-12-03 at 10:01 +0200, Grygorii Strashko wrote:


On 03/12/2020 03:25, Qii Wang wrote:

On Wed, 2020-12-02 at 16:35 +0100, Wolfram Sang wrote:

Hi,


Some i2c device driver indirectly uses I2C driver when it is now
being suspended. The i2c devices driver is suspended during the
NOIRQ phase and this cannot be changed due to other dependencies.
Therefore, we also need to move the suspend handling for the I2C
controller driver to the NOIRQ phase as well.

Signed-off-by: Qii Wang 


Is this a bugfix and should go into 5.10? Or can it wait for 5.11?



Yes, Can you help to apply it into 5.10? Thanks


To be honest if you still do have any i2c device which accessing i2c buss after 
_noirq
stage and your driver does not implement .master_xfer_atomic() - you definitely 
have a bigger problem.
So adding IRQF_NO_SUSPEND sound like a hack and probably works just by luck.



At present, it is only a problem caused by missing interrupts,
and .master_xfer_atomic() just a implement in polling mode. Why not set
the interrupt to a state that can always be triggered?




Because you must not use any IRQ driven operations after _noirq suspend state 
as it might (and most probably will)
cause unpredictable behavior later  in suspend_enter():

arch_suspend_disable_irqs();
BUG_ON(!irqs_disabled());
^after this point any IRQ driven I2C transfer will cause IRQ to be re-enabled

if you need  turn off device from platform callbacks -  .master_xfer_atomic() 
has to be implemented and used.


Maybe my comment is a bit disturbing.Our purpose is not to call i2c and
use interrupts after _noirq pauses.So We use
i2c_mark_adapter_suspended_mark_adapter_resumed to block these i2c
transfers， There will not have any IRQ driven I2C transfer after this
point:
  arch_suspend_disable_irqs();
  BUG_ON(!irqs_disabled());
But some device driver will do i2c transfer after
dpm_noirq_resume_devices in dpm_resume_noirq(PMSG_RESUME) when our
driver irq hasn't resume.
void dpm_resume_noirq(pm_message_t state)
{
dpm_noirq_resume_devices(state);


Just to clarify. You have resume sequence in dpm_noirq_resume_devices
   dpm_noirq_resume_devices -> resume I2C -> resume some device -> do i2c 
transfer after?



Yes.


huh. First consider IRQF_EARLY_RESUME - it's better, but still will be a hack




Is "some device" in Kernel mainline?



The problematic device driver is drivers/regulator/da9211-regulator.c in
Kernel mainline.


regulator is passive device, somebody should call it !?

And da9211-regulator IRQ handler should remain disabled till 
resume_device_irqs() call.

note. regulator_class implements only

static const struct dev_pm_ops __maybe_unused regulator_pm_ops = {
.suspend= regulator_suspend,
.resume = regulator_resume,
};





resume_device_irqs();
device_wakeup_disarm_wake_irqs();
cpuidle_resume();
}
.master_xfer_atomic() seems to be invalid for this question at this
time?







--
Best regards,
grygorii

Re: [RFC PATCH] RFC: drivers: gpio: helper for generic pin IRQ handling

2020-12-10 Thread Grygorii Strashko





On 09/12/2020 12:23, Enrico Weigelt, metux IT consult wrote:

On 08.12.20 17:18, Grygorii Strashko wrote:


Having all GPIO drivers doing their IRQ management entirely through the
GPIO subsystem (eg. never calling generic_handle_irq() and using the
builtin
IRQ handling) would also allow a more direct (eg. callback-based)
pin change
notification for GPIO consumers, that doesn't involve registering
them as
generic IRQ handlers.


Above part makes me worry - why?


Why so ?

Little clarification, in case i've been a bit confusion - there're two
separate topics:

a) consolidating repeated patterns (eg. calling the actual irq handling)
into gpiolib, (and later possibly use more fields already existing in
struct gpio_chip for irq handling)


Even if there is some pattern It doesn't mean consolidation is always 
reasonable.
one of the things to think about is compiler optimization and will/will not 
this change
add additional



b) a direct consumer callback for change, where the consumer doesn't
have to care about IRQs at all (some drivers could even do polling,
when hw doesn't have IRQs). This is for consumers that don't use
GPIOs as interrupt source, but more more like a very raw serial port,
eg. bitbanging of other interfaces (maybe an gpio bus type ? ;-))


in his case they do polling, so what's the issue with this?

or you want gpio-controller to do polling for you?

Actually there are few types of consumers:
- gpio users, no irq
- irq users, no gpio
- gpio users and irq users
- and finally (only few) use the same gpio as gpio and as an irq,
  including dynamic direction change.



The above paragraph just outlines that b) might be much easier to
implement, once the suggested refactoring is done and no driver would
call irq handlers directly anymore. But this hasn't much to do with
the proposal itself, just an idea for future use.

--mtx



--
Best regards,
grygorii

Re: Howto listen to/handle gpio state changes ? Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver

2020-12-10 Thread Grygorii Strashko





On 09/12/2020 22:38, Arnd Bergmann wrote:

On Wed, Dec 9, 2020 at 9:22 PM Grygorii Strashko
 wrote:

On 09/12/2020 14:53, Linus Walleij wrote:

On Wed, Dec 9, 2020 at 12:19 PM Arnd Bergmann  wrote:

On Wed, Dec 9, 2020 at 9:51 AM Linus Walleij  wrote:

On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult 
 wrote:



What we need to understand is if your new usecase is an outlier
so it is simplest modeled by a "mock" irq_chip or we have to design
something new altogether like notifications on changes. I suspect
irq_chip would be best because all drivers using GPIOs for interrupts
are expecting interrupts, and it would be an enormous task to
change them all and really annoying to create a new mechanism
on the side.


I would expect the platform abstraction to actually be close enough
to a chained irqchip that it actually works: the notification should
come in via vring_interrupt(), which is a normal interrupt handler
that calls vq->vq.callback(), calling generic_handle_irq() (and
possibly chained_irq_enter()/chained_irq_exit() around it) like the
other gpio drivers do should just work here I think, and if it did
not, then I would expect this to be just a bug in the driver rather
than something missing in the gpio framework.


Performance/latency-wise that would also be strongly encouraged.

Tglx isn't super-happy about the chained interrupts at times, as they
can create really nasty bugs, but a pure IRQ in fastpath of some
kinde is preferable and intuitive either way.


In my opinion the problem here is that proposed patch somehow describes Front 
end, but
says nothing about Backend and overall design.

What is expected to be virtualized? whole GPIO chip? or set of GPIOs from 
different GPIO chips?
Most often nobody want to give Guest access to the whole GPIO chip, so, most 
probably, smth. similar to
GPIO Aggregator will be needed.


I would argue that it does not matter, the virtual GPIO chip could really
be anything. Certain functions such as a gpio based keyboard require
interrupts, so it sounds useful to make them work.


Agree, and my point was not to discard IRQ support, but solve problem step by 
step.
And existing Back end, in any form, may just help to understand virtio-gpio 
protocol spec and
identify missed pieces.

For example, should 'Configuration space' specify if IRQs are supported on not?

--
Best regards,
grygorii

Re: [v2] i2c: mediatek: Move suspend and resume handling to NOIRQ phase

2020-12-10 Thread Grygorii Strashko





On 10/12/2020 03:56, Qii Wang wrote:

On Mon, 2020-12-07 at 18:35 +0200, Grygorii Strashko wrote:




On Thu, 2020-12-03 at 10:01 +0200, Grygorii Strashko wrote:


On 03/12/2020 03:25, Qii Wang wrote:

On Wed, 2020-12-02 at 16:35 +0100, Wolfram Sang wrote:

Hi,


Some i2c device driver indirectly uses I2C driver when it is now
being suspended. The i2c devices driver is suspended during the
NOIRQ phase and this cannot be changed due to other dependencies.
Therefore, we also need to move the suspend handling for the I2C
controller driver to the NOIRQ phase as well.

Signed-off-by: Qii Wang 


Is this a bugfix and should go into 5.10? Or can it wait for 5.11?



Yes, Can you help to apply it into 5.10? Thanks


To be honest if you still do have any i2c device which accessing i2c buss after 
_noirq
stage and your driver does not implement .master_xfer_atomic() - you definitely 
have a bigger problem.
So adding IRQF_NO_SUSPEND sound like a hack and probably works just by luck.



At present, it is only a problem caused by missing interrupts,
and .master_xfer_atomic() just a implement in polling mode. Why not set
the interrupt to a state that can always be triggered?




Because you must not use any IRQ driven operations after _noirq suspend state 
as it might (and most probably will)
cause unpredictable behavior later  in suspend_enter():

arch_suspend_disable_irqs();
BUG_ON(!irqs_disabled());
^after this point any IRQ driven I2C transfer will cause IRQ to be re-enabled

if you need  turn off device from platform callbacks -  .master_xfer_atomic() 
has to be implemented and used.
   

Maybe my comment is a bit disturbing.Our purpose is not to call i2c and
use interrupts after _noirq pauses.So We use
i2c_mark_adapter_suspended_mark_adapter_resumed to block these i2c
transfers， There will not have any IRQ driven I2C transfer after this
point:
 arch_suspend_disable_irqs();
 BUG_ON(!irqs_disabled());
But some device driver will do i2c transfer after
dpm_noirq_resume_devices in dpm_resume_noirq(PMSG_RESUME) when our
driver irq hasn't resume.
void dpm_resume_noirq(pm_message_t state)
{
dpm_noirq_resume_devices(state);


Just to clarify. You have resume sequence in dpm_noirq_resume_devices
 dpm_noirq_resume_devices -> resume I2C -> resume some device -> do i2c 
transfer after?

Is "some device" in Kernel mainline?


resume_device_irqs();
device_wakeup_disarm_wake_irqs();
cpuidle_resume();
}
.master_xfer_atomic() seems to be invalid for this question at this
time?



--
Best regards,
grygorii

Re: Howto listen to/handle gpio state changes ? Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver

2020-12-09 Thread Grygorii Strashko





On 09/12/2020 14:53, Linus Walleij wrote:

On Wed, Dec 9, 2020 at 12:19 PM Arnd Bergmann  wrote:

On Wed, Dec 9, 2020 at 9:51 AM Linus Walleij  wrote:

On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult 
 wrote:



What we need to understand is if your new usecase is an outlier
so it is simplest modeled by a "mock" irq_chip or we have to design
something new altogether like notifications on changes. I suspect
irq_chip would be best because all drivers using GPIOs for interrupts
are expecting interrupts, and it would be an enormous task to
change them all and really annoying to create a new mechanism
on the side.


I would expect the platform abstraction to actually be close enough
to a chained irqchip that it actually works: the notification should
come in via vring_interrupt(), which is a normal interrupt handler
that calls vq->vq.callback(), calling generic_handle_irq() (and
possibly chained_irq_enter()/chained_irq_exit() around it) like the
other gpio drivers do should just work here I think, and if it did
not, then I would expect this to be just a bug in the driver rather
than something missing in the gpio framework.


Performance/latency-wise that would also be strongly encouraged.

Tglx isn't super-happy about the chained interrupts at times, as they
can create really nasty bugs, but a pure IRQ in fastpath of some
kinde is preferable and intuitive either way.


In my opinion the problem here is that proposed patch somehow describes Front 
end, but
says nothing about Backend and overall design.

What is expected to be virtualized? whole GPIO chip? or set of GPIOs from 
different GPIO chips?
Most often nobody want to give Guest access to the whole GPIO chip, so, most 
probably, smth. similar to
GPIO Aggregator will be needed.

How is situation going to be resolved that GPIO framework and IRQ framework are 
independent, but intersect, and
GPIO controller drivers have no idea who and how requesting GPIO IRQ - threaded 
vs non-threaded vs oneshot.
So, some information need to be transferred to Back end  - at minimum IRQ 
triggering type.

Overall, it might be better to start from pure gpio and leave GPIO IRQ aside.
--
Best regards,
grygorii

Re: [RFC PATCH] RFC: drivers: gpio: helper for generic pin IRQ handling





On 08/12/2020 16:38, Andy Shevchenko wrote:

On Tue, Dec 8, 2020 at 4:19 PM Andy Shevchenko
 wrote:

On Tue, Dec 8, 2020 at 4:14 PM Enrico Weigelt, metux IT consult
 wrote:


Many gpio drivers already use gpiolib's builtin irqchip handling
(CONFIG_GPIOLIB_IRQCHIP), but still has some boilerplate for retrieving
the actual Linux IRQ number and calling into the generic handler.
That boilerplate can be reduced by moving that into a helper function.

This is an RFC patch to outline how that could be done. Note: it's
completely untested yet.

Several drivers still have their completely IRQ own implementation and
thus can't be converted yet. Some of them perhaps could be changed to
store their irq domain in the struct gpio, so the new helper could
also be used for those.

Having all GPIO drivers doing their IRQ management entirely through the
GPIO subsystem (eg. never calling generic_handle_irq() and using the builtin
IRQ handling) would also allow a more direct (eg. callback-based) pin change
notification for GPIO consumers, that doesn't involve registering them as
generic IRQ handlers.


Above part makes me worry - why?



Further reduction of boilerplate could be achieved by additional helpers
for common patterns like for_each_set_bit() loops on irq masks.


Have you able to test them all?
As the PCA953x case showed us this is not so simple, besides the name
which sucks — we don't *raise* and IRQ we *handle* it.

NAK.


To be on constructive side what I think can help here:
- split patch on per driver basis (and first patch is a simple
introduction of new API)
- rename function
- in each new per-driver patch explain what is the difference in behaviour
- test as many as you can and explain in a cover letter what has been
done and what are the expectations on the ones that you weren't able
to test.



agree.

--
Best regards,
grygorii

Re: Howto listen to/handle gpio state changes ? Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver





On 08/12/2020 16:04, Enrico Weigelt, metux IT consult wrote:

On 08.12.20 10:38, Linus Walleij wrote:

Hi,


This is Bartosz territory, but the gpio-mockup.c driver will insert
IRQs into the system, he went and added really core stuff
into kernel/irq to make this happen. Notice that in Kconfig
it does:

select IRQ_SIM

Then this is used:
include/linux/irq_sim.h

This is intended for simulating IRQs and both GPIO and IIO use it.
I think this inserts IRQs from debugfs and I have no idea how
flexible that is.


Oh, thx.

It seems to implement a pseudo-irqchip driver. I've already though about
doing that, but didn't think its worth it, just for my driver alone.
I've implemented a few irq handling cb's directly the driver. But since
we already have it, I'll reconsider :)

BUT: this wasn't exactly my question :p

I've been looking for some more direct notification callback for gpio
consumers: here the consumer would register itself as a listener on
some gpio_desc and called back when something changes (with data what
exactly changed, eg. "gpio #3 input switched to high").


But this is exactly why there is GPIO IRQs in the first place,
which are used to notify consumers.

More over most consumers doesn't know where the IRQ came from - on one HW it 
can be gpio,
while on another HW - direct interrupt controller line.

--
Best regards,
grygorii

Re: [PATCH v3 13/20] dmaengine: ti: k3-psil: Extend psil_endpoint_config for K3 PKTDMA





On 08/12/2020 11:04, Peter Ujfalusi wrote:

Additional fields needed for K3 PKTDMA to be able to handle the mapped
channels (channels are locked to handle specific threads) and flow ranges
for these mapped threads.
PKTDMA also introduces tflow for tx channels which can not be found in
K3 UDMA architecture.

Signed-off-by: Peter Ujfalusi 
---
  include/linux/dma/k3-psil.h | 16 
  1 file changed, 16 insertions(+)



Reviewed-by: Grygorii Strashko 

--
Best regards,
grygorii

Re: [PATCH v3 06/20] dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings





On 08/12/2020 11:04, Peter Ujfalusi wrote:

Rings in RING mode should be using the DMA device for DMA API as in this
mode the ringacc will not access the ring memory in any ways, but the DMA
is.

Fix up the ring configuration and set the dma_dev unconditionally and let
the ringacc driver to select the correct device to use for DMA API.

Signed-off-by: Peter Ujfalusi 
---
  drivers/dma/ti/k3-udma-glue.c | 8 
  1 file changed, 8 insertions(+)



Reviewed-by: Grygorii Strashko 

--
Best regards,
grygorii

Re: [PATCH v3 05/20] dmaengine: ti: k3-udma-glue: Get the ringacc from udma_dev





On 08/12/2020 11:04, Peter Ujfalusi wrote:

If of_xudma_dev_get() returns with the valid udma_dev then the driver
already got the ringacc, there is no need to execute
of_k3_ringacc_get_by_phandle() for each channel via the glue layer.

Signed-off-by: Peter Ujfalusi 
---
  drivers/dma/ti/k3-udma-glue.c| 6 +-
  drivers/dma/ti/k3-udma-private.c | 6 ++
  drivers/dma/ti/k3-udma.h | 1 +
  3 files changed, 8 insertions(+), 5 deletions(-)

Reviewed-by: Grygorii Strashko 

--
Best regards,
grygorii

Re: [PATCH v3 04/20] dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA API





On 08/12/2020 11:04, Peter Ujfalusi wrote:

Glue layer users should use the device of the DMA for DMA mapping and
allocations as it is the DMA which accesses to descriptors and buffers,
not the clients

Signed-off-by: Peter Ujfalusi 


Reviewed-by: Grygorii Strashko 

--
Best regards,
grygorii

Re: [v2] i2c: mediatek: Move suspend and resume handling to NOIRQ phase

2020-12-07 Thread Grygorii Strashko

On 07/12/2020 09:33, Qii Wang wrote:

Hi:
Thank you very much for your patience review.
There are two main purposes of this patch:
1.i2c_mark_adapter_suspended_mark_adapter_resumed
Avoid accessing the adapter while it is suspended by marking it
suspended during suspend. This allows the I2C core to catch this, and
print a warning.
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20181219164827.20985-2-wsa+rene...@sang-engineering.com/

2. IRQF_NO_SUSPEND.
Having interrupts disabled means not only that an interrupt will not
occur at an awkward time, but also that using any functionality that
requires interrupts will not work. So if the driver uses an I2C bus or
similar to tell the device to turn off, and if the I2C bus uses
interrupts to indicate completion (which is normal), then either the
device must be powered-off in suspend_late, so the I2C interrupt must be
marked IRQF_NO_SUSPEND.
https://patchwork.kernel.org/project/linux-acpi/patch/20180923135812.29574-8-hdego...@redhat.com/

Pls, do not top post.

On Thu, 2020-12-03 at 10:01 +0200, Grygorii Strashko wrote:

On 03/12/2020 03:25, Qii Wang wrote:

On Wed, 2020-12-02 at 16:35 +0100, Wolfram Sang wrote:

Hi,

Some i2c device driver indirectly uses I2C driver when it is now
being suspended. The i2c devices driver is suspended during the
NOIRQ phase and this cannot be changed due to other dependencies.
Therefore, we also need to move the suspend handling for the I2C
controller driver to the NOIRQ phase as well.

Signed-off-by: Qii Wang

Is this a bugfix and should go into 5.10? Or can it wait for 5.11?

Yes, Can you help to apply it into 5.10? Thanks

To be honest if you still do have any i2c device which accessing i2c buss after
_noirq
stage and your driver does not implement .master_xfer_atomic() - you definitely
have a bigger problem.
So adding IRQF_NO_SUSPEND sound like a hack and probably works just by luck.

At present, it is only a problem caused by missing interrupts,
and .master_xfer_atomic() just a implement in polling mode. Why not set
the interrupt to a state that can always be triggered?

Because you must not use any IRQ driven operations after _noirq suspend state
as it might (and most probably will)
cause unpredictable behavior later in suspend_enter():

arch_suspend_disable_irqs();
BUG_ON(!irqs_disabled());
^after this point any IRQ driven I2C transfer will cause IRQ to be re-enabled

if you need turn off device from platform callbacks - .master_xfer_atomic()
has to be implemented and used.

--
Best regards,
grygorii

Re: [PATCH 1/4] net: ti: am65-cpsw-nuss: Add devlink support

2020-12-03 Thread Grygorii Strashko





On 03/12/2020 16:18, Andrew Lunn wrote:

We don't want to enable HW based switch support unless explicitly
asked by user.


This is the key point. Why? Does individual ports when passed through
the switch not work properly? Does it add extra latency/jitter?


When switch mode is enabled the forwarding is enabled by default and can't be 
completely
disabled, while in multi port mode every port and switch tables (ALE) 
configured so no packet
leaking between ports is happen.
The multi port is the requirement for us to have as default mode no mater to 
what upper interface
ports are attached to LAG, LRE (HSR/PRP) or bridge.

Switching between modes required significant Port and ALE reconfiguration there 
for
technical decision made and implemented to use parameter for mode change (by 
using devlink).

It also allows to keep user interface similar to what was implements for 
previous generation
of TI CPSW (am3/4/5).

--
Best regards,
grygorii

Re: [v2] i2c: mediatek: Move suspend and resume handling to NOIRQ phase

2020-12-03 Thread Grygorii Strashko





On 03/12/2020 03:25, Qii Wang wrote:

On Wed, 2020-12-02 at 16:35 +0100, Wolfram Sang wrote:

Hi,


Some i2c device driver indirectly uses I2C driver when it is now
being suspended. The i2c devices driver is suspended during the
NOIRQ phase and this cannot be changed due to other dependencies.
Therefore, we also need to move the suspend handling for the I2C
controller driver to the NOIRQ phase as well.

Signed-off-by: Qii Wang 


Is this a bugfix and should go into 5.10? Or can it wait for 5.11?



Yes, Can you help to apply it into 5.10? Thanks


To be honest if you still do have any i2c device which accessing i2c buss after 
_noirq
stage and your driver does not implement .master_xfer_atomic() - you definitely 
have a bigger problem.
So adding IRQF_NO_SUSPEND sound like a hack and probably works just by luck.


--
Best regards,
grygorii

Re: [PATCH] gpiolib: do not print err message for EPROBE_DEFER

2020-12-01 Thread Grygorii Strashko


hi Bartosz, All,

On 18/11/2020 16:29, Grygorii Strashko wrote:

The gpiochip may have dependencies from pinmux and so got deferred. Now it
will print error message every time -EPROBE_DEFER is returned which is
unnecessary:

"gpiochip_add_data_with_key: GPIOs 0..31 (gpio-0-31) failed to register, -517"

Hence, do suppress error message for -EPROBE_DEFER case.

Signed-off-by: Grygorii Strashko 
---
  drivers/gpio/gpiolib.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 089ddcaa9bc6..fd2c503a6aab 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -771,9 +771,11 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void 
*data,
ida_free(_ida, gdev->id);
  err_free_gdev:
/* failures here can mean systems won't boot... */
-   pr_err("%s: GPIOs %d..%d (%s) failed to register, %d\n", __func__,
-  gdev->base, gdev->base + gdev->ngpio - 1,
-  gc->label ? : "generic", ret);
+   if (ret != -EPROBE_DEFER) {
+   pr_err("%s: GPIOs %d..%d (%s) failed to register, %d\n", 
__func__,
+  gdev->base, gdev->base + gdev->ngpio - 1,
+  gc->label ? : "generic", ret);
+   }
kfree(gdev);
return ret;
  }



Any comments for this patch?

Note. Modern dev_err_probe() seems can't be used as gpio_chip->parent is not 
guaranteed to be set and
it's not clear if chip_err() still can be used at this stage.

--
Best regards,
grygorii

Re: [PATCH 5/8] i2c: omap: fix reference leak when pm_runtime_get_sync fails

2020-12-01 Thread Grygorii Strashko





On 01/12/2020 11:31, Qinglang Miao wrote:

The PM reference count is not expected to be incremented on
return in omap_i2c_probe() and omap_i2c_remove().

However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here. I Replace it with pm_runtime_resume_and_get
to keep usage counter balanced.

What's more, error path 'err_free_mem' seems not like a proper
name any more. So I change the name to err_disable_pm and move
pm_runtime_disable below, for pm_runtime of 'pdev->dev' should
be disabled when pm_runtime_resume_and_get fails.

Fixes: 3b0fb97c8dc4 ("I2C: OMAP: Handle error check for pm runtime")
Reported-by: Hulk Robot 
Signed-off-by: Qinglang Miao 
---
  drivers/i2c/busses/i2c-omap.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 12ac4212a..d4f6c6d60 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1404,9 +1404,9 @@ omap_i2c_probe(struct platform_device *pdev)
pm_runtime_set_autosuspend_delay(omap->dev, OMAP_I2C_PM_TIMEOUT);
pm_runtime_use_autosuspend(omap->dev);
  
-	r = pm_runtime_get_sync(omap->dev);

+   r = pm_runtime_resume_and_get(omap->dev);
if (r < 0)
-   goto err_free_mem;
+   goto err_disable_pm;
  
  	/*

 * Read the Rev hi bit-[15:14] ie scheme this is 1 indicates ver2.
@@ -1513,8 +1513,8 @@ omap_i2c_probe(struct platform_device *pdev)
omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
pm_runtime_dont_use_autosuspend(omap->dev);
pm_runtime_put_sync(omap->dev);
+err_disable_pm:
pm_runtime_disable(>dev);
-err_free_mem:
  
  	return r;

  }
@@ -1525,7 +1525,7 @@ static int omap_i2c_remove(struct platform_device *pdev)
int ret;
  
  	i2c_del_adapter(>adapter);

-   ret = pm_runtime_get_sync(>dev);
+   ret = pm_runtime_resume_and_get(>dev);
if (ret < 0)
    return ret;
  



Reviewed-by: Grygorii Strashko 

--
Best regards,
grygorii

Re: [PATCH] gpio: omap: handle deferred probe with dev_err_probe() for gpiochip_add_data()

2020-11-30 Thread Grygorii Strashko


Hi All,

On 19/11/2020 11:19, Tony Lindgren wrote:

* Grygorii Strashko  [201118 14:33]:

The gpiochip_add_data() may return -EPROBE_DEFER which is not handled
properly by TI GPIO driver and causes unnecessary boot log messages.

Hence, add proper deferred probe handling with new dev_err_probe() API.

Signed-off-by: Grygorii Strashko 


Acked-by: Tony Lindgren 



Are there any comments? Could it be merged?
On am335 we no do see ~10 annoying error  messages during boot as there now is
dependency from pinctrl on this platform.

--
Best regards,
grygorii

Re: [PATCH v2 0/2] arm64: dts: ti: k3-j7200-som/cpb: Correct i2c bus representations

2020-11-26 Thread Grygorii Strashko





On 20/11/2020 09:35, Peter Ujfalusi wrote:

Hi,

Changes since v1:
- Added REviewed-by from Vignesh
- Comment block to explain main_i2c1 connection to CPB

The main_i2c0 missed the ioexpander present on the SOM itself to control muxes
to route signals to CPB connectors.

The main_i2c1 of J7200 is _not_ connected to the i2c1 of CPB, it is connected to
i2c3, so the devices on the CPB's i2c1 bus are not avalible, but the ones on the
CPB i2c3 are available under the main_i2c1.

Add nice line names at the same time to these.

Regards,
Peter
---
Peter Ujfalusi (2):
   arm64: dts: ti: k3-j7200-som-p0: main_i2c0 have an ioexpander on the
 SOM
   arm64: dts: ti: k3-j7200-common-proc-board: Correct the name of io
 expander on main_i2c1

  .../dts/ti/k3-j7200-common-proc-board.dts | 23 
  arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi   | 26 +++
  2 files changed, 37 insertions(+), 12 deletions(-)



Thank you.
Reviewed-by: Grygorii Strashko 

--
Best regards,
grygorii

Re: [PATCH v2] mdio_bus: suppress err message for reset gpio EPROBE_DEFER





On 19/11/2020 23:11, Heiner Kallweit wrote:

Am 19.11.2020 um 21:34 schrieb Grygorii Strashko:

The mdio_bus may have dependencies from GPIO controller and so got
deferred. Now it will print error message every time -EPROBE_DEFER is
returned which from:
__mdiobus_register()
  |-devm_gpiod_get_optional()
without actually identifying error code.

"mdio_bus 4a101000.mdio: mii_bus 4a101000.mdio couldn't get reset GPIO"

Hence, suppress error message for devm_gpiod_get_optional() returning
-EPROBE_DEFER case by using dev_err_probe().

Signed-off-by: Grygorii Strashko 
---
  drivers/net/phy/mdio_bus.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 757e950fb745..83cd61c3dd01 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -546,10 +546,10 @@ int __mdiobus_register(struct mii_bus *bus, struct module 
*owner)
/* de-assert bus level PHY GPIO reset */
gpiod = devm_gpiod_get_optional(>dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(gpiod)) {
-   dev_err(>dev, "mii_bus %s couldn't get reset GPIO\n",
-   bus->id);
+   err = dev_err_probe(>dev, PTR_ERR(gpiod),
+   "mii_bus %s couldn't get reset GPIO\n", 
bus->id);


Doesn't checkpatch complain about line length > 80 here?


:)

commit bdc48fa11e46f867ea4d75fa59ee87a7f48be144
Author: Joe Perches 
Date:   Fri May 29 16:12:21 2020 -0700

checkpatch/coding-style: deprecate 80-column warning




device_del(>dev);
-   return PTR_ERR(gpiod);
+   return err;
} else  if (gpiod) {
bus->reset_gpiod = gpiod;
  



Last but not least the net or net-next patch annotation is missing.
I'd be fine with treating the change as an improvement (net-next).

Apart from that change looks good to me.



--
Best regards,
grygorii

[PATCH v2] mdio_bus: suppress err message for reset gpio EPROBE_DEFER

The mdio_bus may have dependencies from GPIO controller and so got
deferred. Now it will print error message every time -EPROBE_DEFER is
returned which from:
__mdiobus_register()
 |-devm_gpiod_get_optional()
without actually identifying error code.

"mdio_bus 4a101000.mdio: mii_bus 4a101000.mdio couldn't get reset GPIO"

Hence, suppress error message for devm_gpiod_get_optional() returning
-EPROBE_DEFER case by using dev_err_probe().

Signed-off-by: Grygorii Strashko 
---
 drivers/net/phy/mdio_bus.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 757e950fb745..83cd61c3dd01 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -546,10 +546,10 @@ int __mdiobus_register(struct mii_bus *bus, struct module 
*owner)
/* de-assert bus level PHY GPIO reset */
gpiod = devm_gpiod_get_optional(>dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(gpiod)) {
-   dev_err(>dev, "mii_bus %s couldn't get reset GPIO\n",
-   bus->id);
+   err = dev_err_probe(>dev, PTR_ERR(gpiod),
+   "mii_bus %s couldn't get reset GPIO\n", 
bus->id);
device_del(>dev);
-   return PTR_ERR(gpiod);
+   return err;
} else  if (gpiod) {
bus->reset_gpiod = gpiod;
 
-- 
2.17.1

[PATCH 2/2] ARM: dts: am335x-evm/evmsk/icev2: switch to new cpsw switch drv

The dual_mac mode has been preserved the same way between legacy and new
driver, and one port devices works the same as 1 dual_mac port - it's safe
to switch drivers.

So, Switch amam335x-evm, am335x-evmsk and am335x-icev2 boards to use new
cpsw switch driver. Those boards have or 2 Ext. port wired and configured
in dual_mac mode by default, or only 1 Ext. port.

Signed-off-by: Grygorii Strashko 
---
 arch/arm/boot/dts/am335x-evm.dts   | 13 -
 arch/arm/boot/dts/am335x-evmsk.dts | 14 ++
 arch/arm/boot/dts/am335x-icev2.dts | 14 ++
 3 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 12dffccd1ffd..1753ce2b1773 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -684,28 +684,31 @@
};
 };
 
- {
+_sw {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_default>;
pinctrl-1 = <_sleep>;
status = "okay";
-   slaves = <1>;
 };
 
-_mdio {
+_mdio_sw {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_mdio_default>;
pinctrl-1 = <_mdio_sleep>;
-   status = "okay";
 
ethphy0: ethernet-phy@0 {
reg = <0>;
};
 };
 
-_emac0 {
+_port1 {
phy-handle = <>;
phy-mode = "rgmii-id";
+   ti,dual-emac-pvid = <1>;
+};
+
+_port2 {
+status = "disabled";
 };
 
  {
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index b43b94122d3c..d5f8d5e2eb5d 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -596,19 +596,17 @@
};
 };
 
- {
+_sw {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_default>;
pinctrl-1 = <_sleep>;
-   dual_emac = <1>;
status = "okay";
 };
 
-_mdio {
+_mdio_sw {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_mdio_default>;
pinctrl-1 = <_mdio_sleep>;
-   status = "okay";
 
ethphy0: ethernet-phy@0 {
reg = <0>;
@@ -619,16 +617,16 @@
};
 };
 
-_emac0 {
+_port1 {
phy-handle = <>;
phy-mode = "rgmii-id";
-   dual_emac_res_vlan = <1>;
+   ti,dual-emac-pvid = <1>;
 };
 
-_emac1 {
+_port2 {
phy-handle = <>;
phy-mode = "rgmii-id";
-   dual_emac_res_vlan = <2>;
+   ti,dual-emac-pvid = <2>;
 };
 
  {
diff --git a/arch/arm/boot/dts/am335x-icev2.dts 
b/arch/arm/boot/dts/am335x-icev2.dts
index b958ab56a412..e923d065304d 100644
--- a/arch/arm/boot/dts/am335x-icev2.dts
+++ b/arch/arm/boot/dts/am335x-icev2.dts
@@ -474,31 +474,29 @@
};
 };
 
-_emac0 {
+_port1 {
phy-handle = <>;
phy-mode = "rmii";
-   dual_emac_res_vlan = <1>;
+   ti,dual-emac-pvid = <1>;
 };
 
-_emac1 {
+_port2 {
phy-handle = <>;
phy-mode = "rmii";
-   dual_emac_res_vlan = <2>;
+   ti,dual-emac-pvid = <2>;
 };
 
- {
+_sw {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_default>;
pinctrl-1 = <_sleep>;
status = "okay";
-   dual_emac;
 };
 
-_mdio {
+_mdio_sw {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_mdio_default>;
pinctrl-1 = <_mdio_sleep>;
-   status = "okay";
reset-gpios = < 5 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>;   /* PHY datasheet states 1uS min */
 
-- 
2.17.1

[PATCH 1/2] ARM: dts: am33xx-l4: add dt node for new cpsw switchdev driver

Add DT node for the new cpsw switchdev based driver.

Signed-off-by: Grygorii Strashko 
---
 arch/arm/boot/dts/am33xx-l4.dtsi | 49 
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
index ea20e4bdf040..2dbf7cdc9882 100644
--- a/arch/arm/boot/dts/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/am33xx-l4.dtsi
@@ -751,6 +751,55 @@
phys = <_gmii_sel 2 1>;
};
};
+
+   mac_sw: switch@0 {
+   compatible = "ti,am335x-cpsw-switch", 
"ti,cpsw-switch";
+   reg = <0x0 0x4000>;
+   ranges = <0 0 0x4000>;
+   clocks = <_125mhz_gclk>;
+   clock-names = "fck";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   syscon = <_conf>;
+   status = "disabled";
+
+   interrupts = <40 41 42 43>;
+   interrupt-names = "rx_thresh", "rx", "tx", 
"misc";
+
+   ethernet-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpsw_port1: port@1 {
+   reg = <1>;
+   label = "port1";
+   mac-address = [ 00 00 00 00 00 
00 ];
+   phys = <_gmii_sel 1 1>;
+   };
+
+   cpsw_port2: port@2 {
+   reg = <2>;
+   label = "port2";
+   mac-address = [ 00 00 00 00 00 
00 ];
+   phys = <_gmii_sel 2 1>;
+   };
+   };
+
+   davinci_mdio_sw: mdio@1000 {
+   compatible = 
"ti,cpsw-mdio","ti,davinci_mdio";
+   clocks = <_125mhz_gclk>;
+   clock-names = "fck";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   bus_freq = <100>;
+   reg = <0x1000 0x100>;
+   };
+
+   cpts {
+   clocks = <_cpts_rft_clk>;
+   clock-names = "cpts";
+   };
+   };
};
 
target-module@18 {  /* 0x4a18, ap 5 
10.0 */
-- 
2.17.1

[PATCH 0/2] ARM: dts: am335x-evm/evmsk/icev2: switch to new cpsw switch drv

Hi Tony,

This is the initial conversation of am335x boards to use new cpsw switch driver.
This series adds the cpsw switch driver DT definition and am335x-evm/evmsk/icev2
boards are converted to use it.

Grygorii Strashko (2):
  ARM: dts: am33xx-l4: add dt node for new cpsw switchdev driver
  ARM: dts: am335x-evm/evmsk/icev2: switch to new cpsw switch drv

 arch/arm/boot/dts/am335x-evm.dts   | 13 +---
 arch/arm/boot/dts/am335x-evmsk.dts | 14 -
 arch/arm/boot/dts/am335x-icev2.dts | 14 -
 arch/arm/boot/dts/am33xx-l4.dtsi   | 49 ++
 4 files changed, 69 insertions(+), 21 deletions(-)

-- 
2.17.1

Re: [PATCH] mdio_bus: suppress err message for reset gpio EPROBE_DEFER





On 19/11/2020 14:30, Heiner Kallweit wrote:

Am 18.11.2020 um 15:24 schrieb Grygorii Strashko:

The mdio_bus may have dependencies from GPIO controller and so got
deferred. Now it will print error message every time -EPROBE_DEFER is
returned from:
__mdiobus_register()
  |-devm_gpiod_get_optional()
without actually identifying error code.

"mdio_bus 4a101000.mdio: mii_bus 4a101000.mdio couldn't get reset GPIO"

Hence, suppress error message when devm_gpiod_get_optional() returning
-EPROBE_DEFER case.

Signed-off-by: Grygorii Strashko 
---
  drivers/net/phy/mdio_bus.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 757e950fb745..54fc13043656 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -546,10 +546,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module 
*owner)
/* de-assert bus level PHY GPIO reset */
gpiod = devm_gpiod_get_optional(>dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(gpiod)) {
-   dev_err(>dev, "mii_bus %s couldn't get reset GPIO\n",
-   bus->id);
+   err = PTR_ERR(gpiod);
+   if (err != -EPROBE_DEFER)
+   dev_err(>dev, "mii_bus %s couldn't get reset GPIO 
%d\n", bus->id, err);
device_del(>dev);
-   return PTR_ERR(gpiod);
+   return err;
} else  if (gpiod) {
bus->reset_gpiod = gpiod;
  



Using dev_err_probe() here would simplify the code.



this was my first though, but was not sure if it's correct as dev_err_probe() 
will use dev
to store defer reason, but the same 'dev' is deleted on the next line.

I also thought about using bus->parent, but it's not always provided.

So, if you think dev_err_probe(0) can be used - I can change and re-send.

--
Best regards,
grygorii

Re: [PATCH v2 0/4] arm64: dts: ti: J7200 GPIO support and warning fixes





On 17/11/2020 18:19, Sekhar Nori wrote:

These patches add gpio support for TI's J7200 platform. The first
two patches fix existing warnings in preparation for adding GPIO
support.

Changes in v2:
- Add patches fixing existing warnings so GPIO support does not
   end up adding more warnings
- Addressed Nishanth's comments on GPIO patches
   - merge patches adding main and wakeup domain GPIOs into single patch
   - fix commit description going over 75 chars
   - fix W=2 warnings about lack of #address-cells in GPIO nodes





Faiz Abbas (2):
   arm64: dts: ti: k3-j7200: Add gpio nodes
   arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio
 modules

Sekhar Nori (2):
   arm64: dts: ti: k3: squelch warning about lack of #interrupt-cells
   arm64: dts: ti: k3: squelch warnings regarding no #address-cells for
 interrupt-controller

  arch/arm64/boot/dts/ti/k3-am65-main.dtsi  |  6 ++
  arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi|  2 +
  .../arm64/boot/dts/ti/k3-am654-base-board.dts |  1 +
  .../dts/ti/k3-j7200-common-proc-board.dts | 16 
  arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 75 +++
  .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi  | 35 +
  .../dts/ti/k3-j721e-common-proc-board.dts |  1 +
  arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 12 +++
  .../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi  |  3 +
  9 files changed, 151 insertions(+)



For patches 1,3,4
Reviewed-by: Grygorii Strashko 
--
Best regards,
grygorii

Re: [PATCH v2 2/4] arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller





On 18/11/2020 17:12, Nishanth Menon wrote:

On 13:38-20201118, Grygorii Strashko wrote:

Hi Rob,

On 17/11/2020 18:19, Sekhar Nori wrote:

With dtc 1.6.0, building TI device-tree files with W=2 results in warnings
like below for all interrupt controllers.

/bus@10/bus@3000/interrupt-controller1: Missing #address-cells in 
interrupt provider

Fix these by adding #address-cells = <0>; for all interrupt controllers in
TI device-tree files. Any other #address-cells value is really only needed
if interrupt-map property is being used (which is not the case for existing
TI device-tree files)

Signed-off-by: Sekhar Nori 
---
   arch/arm64/boot/dts/ti/k3-am65-main.dtsi  |  5 +
   arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi|  2 ++
   arch/arm64/boot/dts/ti/k3-am654-base-board.dts|  1 +
   arch/arm64/boot/dts/ti/k3-j7200-main.dtsi |  3 +++
   arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi   |  1 +
   arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts |  1 +
   arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 11 +++
   arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi   |  3 +++
   8 files changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index aa8725db0187..55aaa1404d7d 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -440,6 +440,7 @@
interrupt-controller;
interrupt-parent = <>;
#interrupt-cells = <1>;
+   #address-cells = <0>;

Does it really required or mandatory to have #address-cells = <0>; defined for 
interrupt-controller DT nodes which
do not have child nodes and no "interrupt-map"?


Just to help clarify (I could be mistaken as well): is'nt the
interrupt map for user interrupt map nodes that refer to this
interrupt controller node to state they dont need a parent address
specifier - so are we claiming none of the users will have an
interrupt-map (now and never in the future as well) - we we might want
to explain why we think that is the case, and if we are expecting dtc
to deduce that (if so how?)?



The main reason I commented - is hope to get some clarification from DT 
maintainers.
90% of interrupt-controller nodes do not have #address-cells and I never seen 
in in GPIO nodes
(most often is present in PCI and GIC nodes).
and nobody seems fixing it. So, if we are going to move this direction it's 
reasonable to get clarification to be sure.

And there is no "never" here - #address-cells always can be added if really 
required.

--
Best regards,
grygorii

[PATCH] gpio: omap: handle deferred probe with dev_err_probe() for gpiochip_add_data()

The gpiochip_add_data() may return -EPROBE_DEFER which is not handled
properly by TI GPIO driver and causes unnecessary boot log messages.

Hence, add proper deferred probe handling with new dev_err_probe() API.

Signed-off-by: Grygorii Strashko 
---
 drivers/gpio/gpio-omap.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f7ceb2b11afc..41952bb818ad 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1049,11 +1049,8 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, 
struct irq_chip *irqc)
irq->first = irq_base;
 
ret = gpiochip_add_data(>chip, bank);
-   if (ret) {
-   dev_err(bank->chip.parent,
-   "Could not register gpio chip %d\n", ret);
-   return ret;
-   }
+   if (ret)
+   return dev_err_probe(bank->chip.parent, ret, "Could not 
register gpio chip\n");
 
ret = devm_request_irq(bank->chip.parent, bank->irq,
   omap_gpio_irq_handler,
-- 
2.17.1

[PATCH] gpiolib: do not print err message for EPROBE_DEFER

The gpiochip may have dependencies from pinmux and so got deferred. Now it
will print error message every time -EPROBE_DEFER is returned which is
unnecessary:

"gpiochip_add_data_with_key: GPIOs 0..31 (gpio-0-31) failed to register, -517"

Hence, do suppress error message for -EPROBE_DEFER case.

Signed-off-by: Grygorii Strashko 
---
 drivers/gpio/gpiolib.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 089ddcaa9bc6..fd2c503a6aab 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -771,9 +771,11 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void 
*data,
ida_free(_ida, gdev->id);
 err_free_gdev:
/* failures here can mean systems won't boot... */
-   pr_err("%s: GPIOs %d..%d (%s) failed to register, %d\n", __func__,
-  gdev->base, gdev->base + gdev->ngpio - 1,
-  gc->label ? : "generic", ret);
+   if (ret != -EPROBE_DEFER) {
+   pr_err("%s: GPIOs %d..%d (%s) failed to register, %d\n", 
__func__,
+  gdev->base, gdev->base + gdev->ngpio - 1,
+  gc->label ? : "generic", ret);
+   }
kfree(gdev);
return ret;
 }
-- 
2.17.1

[PATCH] mdio_bus: suppress err message for reset gpio EPROBE_DEFER

The mdio_bus may have dependencies from GPIO controller and so got
deferred. Now it will print error message every time -EPROBE_DEFER is
returned from:
__mdiobus_register()
 |-devm_gpiod_get_optional()
without actually identifying error code.

"mdio_bus 4a101000.mdio: mii_bus 4a101000.mdio couldn't get reset GPIO"

Hence, suppress error message when devm_gpiod_get_optional() returning
-EPROBE_DEFER case.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/phy/mdio_bus.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 757e950fb745..54fc13043656 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -546,10 +546,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module 
*owner)
/* de-assert bus level PHY GPIO reset */
gpiod = devm_gpiod_get_optional(>dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(gpiod)) {
-   dev_err(>dev, "mii_bus %s couldn't get reset GPIO\n",
-   bus->id);
+   err = PTR_ERR(gpiod);
+   if (err != -EPROBE_DEFER)
+   dev_err(>dev, "mii_bus %s couldn't get reset GPIO 
%d\n", bus->id, err);
device_del(>dev);
-   return PTR_ERR(gpiod);
+   return err;
} else  if (gpiod) {
bus->reset_gpiod = gpiod;
 
-- 
2.17.1

[PATCH] bus: ti-sysc: suppress err msg for timers used as clockevent/source

GP Timers used as clockevent/source are not available for ti-sysc bus and
handled by Kernel timekeeping core. Now ti-sysc produces error message
every time such timer is detected:

 "ti-sysc: probe of 4804.target-module failed with error -16"

Such messages are not necessary, so suppress them by returning -ENXIO
instead of -EBUSY.

Signed-off-by: Grygorii Strashko 
---
 drivers/bus/ti-sysc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index 792a2878cb16..02186bac1b0b 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -2883,7 +2883,7 @@ static int sysc_check_active_timer(struct sysc *ddata)
 
if ((ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT) &&
(ddata->cfg.quirks & SYSC_QUIRK_NO_IDLE))
-   return -EBUSY;
+   return -ENXIO;
 
return 0;
 }
-- 
2.17.1

Re: [PATCH v2 2/4] arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller


Hi Rob,

On 17/11/2020 18:19, Sekhar Nori wrote:

With dtc 1.6.0, building TI device-tree files with W=2 results in warnings
like below for all interrupt controllers.

/bus@10/bus@3000/interrupt-controller1: Missing #address-cells in 
interrupt provider

Fix these by adding #address-cells = <0>; for all interrupt controllers in
TI device-tree files. Any other #address-cells value is really only needed
if interrupt-map property is being used (which is not the case for existing
TI device-tree files)

Signed-off-by: Sekhar Nori 
---
  arch/arm64/boot/dts/ti/k3-am65-main.dtsi  |  5 +
  arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi|  2 ++
  arch/arm64/boot/dts/ti/k3-am654-base-board.dts|  1 +
  arch/arm64/boot/dts/ti/k3-j7200-main.dtsi |  3 +++
  arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi   |  1 +
  arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts |  1 +
  arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 11 +++
  arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi   |  3 +++
  8 files changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index aa8725db0187..55aaa1404d7d 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -440,6 +440,7 @@
interrupt-controller;
interrupt-parent = <>;
#interrupt-cells = <1>;
+   #address-cells = <0>;

Does it really required or mandatory to have #address-cells = <0>; defined for 
interrupt-controller DT nodes which
do not have child nodes and no "interrupt-map"?

--
Best regards,
grygorii

Re: [PATCH net-next 3/3] net: ethernet: ti: am65-cpsw: enable broadcast/multicast rate limit support

2020-11-16 Thread Grygorii Strashko





On 14/11/2020 21:17, Vladimir Oltean wrote:

On Sat, Nov 14, 2020 at 05:56:54AM +0200, Grygorii Strashko wrote:

This patch enables support for ingress broadcast(BC)/multicast(MC) rate limiting
in TI AM65x CPSW driver (the corresponding ALE support was added in previous
patch) by implementing HW offload for simple tc-flower policer with matches
on dst_mac:
  - ff:ff:ff:ff:ff:ff has to be used for BC rate limiting
  - 01:00:00:00:00:00 fixed value has to be used for MC rate limiting

Hence tc policer defines rate limit in terms of bits per second, but the
ALE supports limiting in terms of packets per second - the rate limit
bits/sec is converted to number of packets per second assuming minimum
Ethernet packet size ETH_ZLEN=60 bytes.

Examples:
- BC rate limit to 1000pps:
   tc qdisc add dev eth0 clsact
   tc filter add dev eth0 ingress flower skip_sw dst_mac ff:ff:ff:ff:ff:ff \
   action police rate 480kbit burst 64k

   rate 480kbit - 1000pps * 60 bytes * 8, burst - not used.

- MC rate limit to 2pps:
   tc qdisc add dev eth0 clsact
   tc filter add dev eth0 ingress flower skip_sw dst_mac 01:00:00:00:00:00 \
   action police rate 9600kbit burst 64k

   rate 9600kbit - 2pps * 60 bytes * 8, burst - not used.

Signed-off-by: Grygorii Strashko 
---


I understand this is unpleasant feedback, but don't you want to extend
tc-police to have an option to rate-limit based on packet count and not
based on byte count?


Huh.
I'd be appreciated if you could provide more detailed opinion of how it can 
look like?
Sry, it's my first experience with tc.


The assumption you make in the driver that the
packets are all going to be minimum-sized is not a great one.
I can
imagine that the user's policer budget is vastly exceeded if they enable
jumbo frames and they put a policer at 9.6 Mbps, and this is not at all
according to their expectation. 20Kpps assuming 60 bytes per packet
might be 9.6 Mbps, and the user will assume this bandwidth profile is
not exceeded, that's the whole point. But 20Kpps assuming 9KB per packet
is 1.44Gbps. Weird.


Sry, not sure I completely understood above. This is specific HW feature, which 
can
imit packet rate only. And it is expected to be applied by admin who know what 
he is doing.
The main purpose is to preserve CPU resource, which first of all affected by 
packet rate.
So, I see it as not "assumption", but requirement/agreement which will be 
reflected
in docs and works for a specific use case which is determined by presence of:
 - skip_sw flag
 - specific dst_mac/dst_mac_mask pair
in which case rate determines pps and not K/Mbps.


Also some ref on previous discussion [1] [2]
[1] https://www.spinics.net/lists/netdev/msg494630.html
[2] https://lore.kernel.org/patchwork/patch/481285/

--
Best regards,
grygorii

Re: [PATCH net-next 2/3] net: ethernet: ti: cpsw_new: enable broadcast/multicast rate limit support

2020-11-16 Thread Grygorii Strashko





On 14/11/2020 21:09, Vladimir Oltean wrote:

On Sat, Nov 14, 2020 at 05:56:53AM +0200, Grygorii Strashko wrote:

This patch enables support for ingress broadcast(BC)/multicast(MC) rate limiting
in TI CPSW switchdev driver (the corresponding ALE support was added in previous
patch) by implementing HW offload for simple tc-flower policer with matches
on dst_mac:
  - ff:ff:ff:ff:ff:ff has to be used for BC rate limiting
  - 01:00:00:00:00:00 fixed value has to be used for MC rate limiting

Hence tc policer defines rate limit in terms of bits per second, but the
ALE supports limiting in terms of packets per second - the rate limit
bits/sec is converted to number of packets per second assuming minimum
Ethernet packet size ETH_ZLEN=60 bytes.

Examples:
- BC rate limit to 1000pps:
   tc qdisc add dev eth0 clsact
   tc filter add dev eth0 ingress flower skip_sw dst_mac ff:ff:ff:ff:ff:ff \
   action police rate 480kbit burst 64k

   rate 480kbit - 1000pps * 60 bytes * 8, burst - not used.

- MC rate limit to 2pps:
   tc qdisc add dev eth0 clsact
   tc filter add dev eth0 ingress flower skip_sw dst_mac 01:00:00:00:00:00 \
   action police rate 9600kbit burst 64k

   rate 9600kbit - 2pps * 60 bytes * 8, burst - not used.

Signed-off-by: Grygorii Strashko 
---


Your example for multicast would actually be correct if you specified
the mask as well. Like this:

tc filter add dev eth0 ingress flower skip_sw \
dst_mac 01:00:00:00:00:00/01:00:00:00:00:00 \
action police rate 9600kbit burst 64k

But as things stand, the flow rule would have a certain meaning in
software (rate-limit only that particular multicast MAC address) and a
different meaning in hardware. Please modify the driver code to also
match on the mask.



ok.

--
Best regards,
grygorii

Re: [PATCH 1/3] arm64: dts: ti: k3-j7200-main: Add gpio nodes in main domain


Hi

On 13/11/2020 22:55, Nishanth Menon wrote:

On 00:39-20201114, Sekhar Nori wrote:


I was using the latest schema from master. But I changed to 2020.08.1
also, and still don't see the warning.

$ dt-doc-validate --version
2020.12.dev1+gab5a73fcef26

I dont have a system-wide dtc installed. One in kernel tree is updated.

$ scripts/dtc/dtc --version
Version: DTC 1.6.0-gcbca977e

Looking at your logs, it looks like you have more patches than just this
applied. I wonder if thats making a difference. Can you check with just
these patches applied to linux-next or share your tree which includes
other patches?

In your logs, you have such error for other interrupt controller nodes
as well. For example:

  arch/arm64/boot/dts/ti/k3-j7200-main.dtsi:
/bus@10/bus@3000/interrupt-controller1: Missing #address-cells
in interrupt provider

Which I don't see in my logs. My guess is some other patch(es) in your
patch stack either uncovers this warning or causes it.


Oh boy! I sent you and myself on wild goose chase! Really sorry about
messing up in the report of bug.

It is not dtbs_check, it is building dtbs with W=2 that generates this
warning. dtc 1.6.0 is sufficient to reproduce this behavior.

Using v5.10-rc1 as baseline (happens the same with next-20201113 as
well.

v5.10-rc1: https://pastebin.ubuntu.com/p/Pn9HDqRjQ4/ (recording:
 https://asciinema.org/a/55YVpql9Bq8rh8fePTxI2xObO)

v5.10-rc1 + 1st patch in the series(since we are testing):
https://pastebin.ubuntu.com/p/QWQRMSv565/ (recording:
https://asciinema.org/a/ZSKZkOY13l4lmZ2xWH34jMlM1)

Diff: https://pastebin.ubuntu.com/p/239sYYT2QY/



This warning come from scripts/dtc/checks.c
and was introduced by commit 3eb619b2f7d8 ("scripts/dtc: Update to upstream version 
v1.6.0-11-g9d7888cbf19c").

In my opinion it's false warning as there is no requirement to have  
#address-cells in interrupt provider node.
by the way, above commit description says: "The interrupt_provider check is noisy, 
so turn it off for now."

--
Best regards,
grygorii

[PATCH net-next 2/3] net: ethernet: ti: cpsw_new: enable broadcast/multicast rate limit support

This patch enables support for ingress broadcast(BC)/multicast(MC) rate limiting
in TI CPSW switchdev driver (the corresponding ALE support was added in previous
patch) by implementing HW offload for simple tc-flower policer with matches
on dst_mac:
 - ff:ff:ff:ff:ff:ff has to be used for BC rate limiting
 - 01:00:00:00:00:00 fixed value has to be used for MC rate limiting

Hence tc policer defines rate limit in terms of bits per second, but the
ALE supports limiting in terms of packets per second - the rate limit
bits/sec is converted to number of packets per second assuming minimum
Ethernet packet size ETH_ZLEN=60 bytes.

Examples:
- BC rate limit to 1000pps:
  tc qdisc add dev eth0 clsact
  tc filter add dev eth0 ingress flower skip_sw dst_mac ff:ff:ff:ff:ff:ff \
  action police rate 480kbit burst 64k

  rate 480kbit - 1000pps * 60 bytes * 8, burst - not used.

- MC rate limit to 2pps:
  tc qdisc add dev eth0 clsact
  tc filter add dev eth0 ingress flower skip_sw dst_mac 01:00:00:00:00:00 \
  action police rate 9600kbit burst 64k

  rate 9600kbit - 2pps * 60 bytes * 8, burst - not used.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/cpsw_new.c  |   4 +-
 drivers/net/ethernet/ti/cpsw_priv.c | 171 
 drivers/net/ethernet/ti/cpsw_priv.h |   8 ++
 3 files changed, 182 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/cpsw_new.c 
b/drivers/net/ethernet/ti/cpsw_new.c
index 2f5e0ad23ad7..6fad5a5461f6 100644
--- a/drivers/net/ethernet/ti/cpsw_new.c
+++ b/drivers/net/ethernet/ti/cpsw_new.c
@@ -505,6 +505,8 @@ static void cpsw_restore(struct cpsw_priv *priv)
 
/* restore CBS offload */
cpsw_cbs_resume(>slaves[priv->emac_port - 1], priv);
+
+   cpsw_qos_clsflower_resume(priv);
 }
 
 static void cpsw_init_stp_ale_entry(struct cpsw_common *cpsw)
@@ -1418,7 +1420,7 @@ static int cpsw_create_ports(struct cpsw_common *cpsw)
cpsw->slaves[i].ndev = ndev;
 
ndev->features |= NETIF_F_HW_VLAN_CTAG_FILTER |
- NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_NETNS_LOCAL;
+ NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_NETNS_LOCAL 
| NETIF_F_HW_TC;
 
ndev->netdev_ops = _netdev_ops;
ndev->ethtool_ops = _ethtool_ops;
diff --git a/drivers/net/ethernet/ti/cpsw_priv.c 
b/drivers/net/ethernet/ti/cpsw_priv.c
index 31c5e36ff706..0908d476b854 100644
--- a/drivers/net/ethernet/ti/cpsw_priv.c
+++ b/drivers/net/ethernet/ti/cpsw_priv.c
@@ -502,6 +502,7 @@ int cpsw_init_common(struct cpsw_common *cpsw, void __iomem 
*ss_regs,
ale_params.ale_ageout   = ale_ageout;
ale_params.ale_ports= CPSW_ALE_PORTS_NUM;
ale_params.dev_id   = "cpsw";
+   ale_params.bus_freq = cpsw->bus_freq_mhz * 100;
 
cpsw->ale = cpsw_ale_create(_params);
if (IS_ERR(cpsw->ale)) {
@@ -1046,6 +1047,8 @@ static int cpsw_set_mqprio(struct net_device *ndev, void 
*type_data)
return 0;
 }
 
+static int cpsw_qos_setup_tc_block(struct net_device *ndev, struct 
flow_block_offload *f);
+
 int cpsw_ndo_setup_tc(struct net_device *ndev, enum tc_setup_type type,
  void *type_data)
 {
@@ -1056,6 +1059,9 @@ int cpsw_ndo_setup_tc(struct net_device *ndev, enum 
tc_setup_type type,
case TC_SETUP_QDISC_MQPRIO:
return cpsw_set_mqprio(ndev, type_data);
 
+   case TC_SETUP_BLOCK:
+   return cpsw_qos_setup_tc_block(ndev, type_data);
+
default:
return -EOPNOTSUPP;
}
@@ -1383,3 +1389,168 @@ int cpsw_run_xdp(struct cpsw_priv *priv, int ch, struct 
xdp_buff *xdp,
page_pool_recycle_direct(cpsw->page_pool[ch], page);
return ret;
 }
+
+static int cpsw_qos_clsflower_add_policer(struct cpsw_priv *priv,
+ struct netlink_ext_ack *extack,
+ struct flow_cls_offload *cls,
+ u64 rate_bytes_ps)
+{
+   struct flow_rule *rule = flow_cls_offload_flow_rule(cls);
+   struct flow_dissector *dissector = rule->match.dissector;
+   u8 null_mac[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+   u8 bc_mac[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
+   u8 mc_mac[] = {0x01, 0x00, 0x00, 0x00, 0x00, 0x00};
+   struct flow_match_eth_addrs match;
+   u32 pps, port_id;
+   int ret;
+
+   if (dissector->used_keys &
+   ~(BIT(FLOW_DISSECTOR_KEY_BASIC) |
+ BIT(FLOW_DISSECTOR_KEY_CONTROL) |
+ BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS))) {
+   NL_SET_ERR_MSG_MOD(extack,
+  "Unsupported keys used");
+   return -EOPNOTSUPP;
+   }
+
+   if (!flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ETH_ADDRS)) {
+   NL_SET_ERR_MSG_MOD(extack, "

[PATCH net-next 0/3] net: ethernet: ti: cpsw: enable broadcast/multicast rate limit support

Hi

This series first adds supports for the ALE feature to rate limit number ingress
broadcast(BC)/multicast(MC) packets per/sec which main purpose is BC/MC storm
prevention.

And then enables corresponding support for ingress broadcast(BC)/multicast(MC)
rate limiting for TI CPSW switchdev and AM65x/J221E CPSW_NUSS drivers by
implementing HW offload for simple tc-flower policer with matches on dst_mac:
 - ff:ff:ff:ff:ff:ff has to be used for BC rate limiting
 - 01:00:00:00:00:00 fixed value has to be used for MC rate limiting

Hence tc policer defines rate limit in terms of bits per second, but the
ALE supports limiting in terms of packets per second - the rate limit
bits/sec is converted to number of packets per second assuming minimum
Ethernet packet size ETH_ZLEN=60 bytes.

The solution inspired patch from Vladimir Oltean [1].

Examples:
- BC rate limit to 1000pps:
  tc qdisc add dev eth0 clsact
  tc filter add dev eth0 ingress flower skip_sw dst_mac ff:ff:ff:ff:ff:ff \
  action police rate 480kbit burst 64k

  rate 480kbit - 1000pps * 60 bytes * 8, burst - not used.

- MC rate limit to 2pps:
  tc qdisc add dev eth0 clsact
  tc filter add dev eth0 ingress flower skip_sw dst_mac 01:00:00:00:00:00 \
  action police rate 9600kbit burst 64k

  rate 9600kbit - 2pps * 60 bytes * 8, burst - not used.

- show: tc filter show dev eth0 ingress
filter protocol all pref 49151 flower chain 0
filter protocol all pref 49151 flower chain 0 handle 0x1
  dst_mac ff:ff:ff:ff:ff:ff
  skip_sw
  in_hw in_hw_count 1
action order 1:  police 0x2 rate 480Kbit burst 64Kb mtu 2Kb action 
reclassify overhead 0b
ref 1 bind 1

filter protocol all pref 49152 flower chain 0
filter protocol all pref 49152 flower chain 0 handle 0x1
  dst_mac 01:00:00:00:00:00
  skip_sw
  in_hw in_hw_count 1
action order 1:  police 0x1 rate 9600Kbit burst 64Kb mtu 2Kb action 
reclassify overhead 0b
ref 1 bind

Testing MC with iperf:
- client
  -- setup tc-flower as per above
  route add -host 239.255.1.3 eth0
  iperf -s -B 239.255.1.3 -u -f m &
  cat /sys/class/net/eth0/statistics/rx_packets

- server
  route add -host 239.255.1.3 eth0
  iperf -c 239.255.1.3 -u -f m -i 5 -t 30 -l1472  -b12176 -t1 //~1pps

[1] https://lore.kernel.org/patchwork/patch/1217254/

Grygorii Strashko (3):
  drivers: net: cpsw: ale: add broadcast/multicast rate limit support
  net: ethernet: ti: cpsw_new: enable broadcast/multicast rate limit
support
  net: ethernet: ti: am65-cpsw: enable broadcast/multicast rate limit
support

 drivers/net/ethernet/ti/am65-cpsw-qos.c | 148 
 drivers/net/ethernet/ti/am65-cpsw-qos.h |   8 ++
 drivers/net/ethernet/ti/cpsw_ale.c  |  66 +
 drivers/net/ethernet/ti/cpsw_ale.h  |   2 +
 drivers/net/ethernet/ti/cpsw_new.c  |   4 +-
 drivers/net/ethernet/ti/cpsw_priv.c | 171 
 drivers/net/ethernet/ti/cpsw_priv.h |   8 ++
 7 files changed, 406 insertions(+), 1 deletion(-)

-- 
2.17.1

[PATCH net-next 3/3] net: ethernet: ti: am65-cpsw: enable broadcast/multicast rate limit support

This patch enables support for ingress broadcast(BC)/multicast(MC) rate limiting
in TI AM65x CPSW driver (the corresponding ALE support was added in previous
patch) by implementing HW offload for simple tc-flower policer with matches
on dst_mac:
 - ff:ff:ff:ff:ff:ff has to be used for BC rate limiting
 - 01:00:00:00:00:00 fixed value has to be used for MC rate limiting

Hence tc policer defines rate limit in terms of bits per second, but the
ALE supports limiting in terms of packets per second - the rate limit
bits/sec is converted to number of packets per second assuming minimum
Ethernet packet size ETH_ZLEN=60 bytes.

Examples:
- BC rate limit to 1000pps:
  tc qdisc add dev eth0 clsact
  tc filter add dev eth0 ingress flower skip_sw dst_mac ff:ff:ff:ff:ff:ff \
  action police rate 480kbit burst 64k

  rate 480kbit - 1000pps * 60 bytes * 8, burst - not used.

- MC rate limit to 2pps:
  tc qdisc add dev eth0 clsact
  tc filter add dev eth0 ingress flower skip_sw dst_mac 01:00:00:00:00:00 \
  action police rate 9600kbit burst 64k

  rate 9600kbit - 2pps * 60 bytes * 8, burst - not used.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/am65-cpsw-qos.c | 148 
 drivers/net/ethernet/ti/am65-cpsw-qos.h |   8 ++
 2 files changed, 156 insertions(+)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-qos.c 
b/drivers/net/ethernet/ti/am65-cpsw-qos.c
index 3bdd4dbcd2ff..a06207233cd5 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-qos.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-qos.c
@@ -8,10 +8,12 @@
 
 #include 
 #include 
+#include 
 
 #include "am65-cpsw-nuss.h"
 #include "am65-cpsw-qos.h"
 #include "am65-cpts.h"
+#include "cpsw_ale.h"
 
 #define AM65_CPSW_REG_CTL  0x004
 #define AM65_CPSW_PN_REG_CTL   0x004
@@ -588,12 +590,158 @@ static int am65_cpsw_setup_taprio(struct net_device 
*ndev, void *type_data)
return am65_cpsw_set_taprio(ndev, type_data);
 }
 
+static int am65_cpsw_qos_clsflower_add_policer(struct am65_cpsw_port *port,
+  struct netlink_ext_ack *extack,
+  struct flow_cls_offload *cls,
+  u64 rate_bytes_ps)
+{
+   struct flow_rule *rule = flow_cls_offload_flow_rule(cls);
+   struct flow_dissector *dissector = rule->match.dissector;
+   u8 null_mac[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+   u8 bc_mac[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
+   u8 mc_mac[] = {0x01, 0x00, 0x00, 0x00, 0x00, 0x00};
+   struct am65_cpsw_qos *qos = >qos;
+   struct flow_match_eth_addrs match;
+   u32 pps;
+   int ret;
+
+   if (dissector->used_keys &
+   ~(BIT(FLOW_DISSECTOR_KEY_BASIC) |
+ BIT(FLOW_DISSECTOR_KEY_CONTROL) |
+ BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS))) {
+   NL_SET_ERR_MSG_MOD(extack,
+  "Unsupported keys used");
+   return -EOPNOTSUPP;
+   }
+
+   if (!flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ETH_ADDRS)) {
+   NL_SET_ERR_MSG_MOD(extack, "Not matching on eth address");
+   return -EOPNOTSUPP;
+   }
+
+   flow_rule_match_eth_addrs(rule, );
+
+   if (!ether_addr_equal_masked(match.key->src, null_mac,
+match.mask->src)) {
+   NL_SET_ERR_MSG_MOD(extack,
+  "Matching on source MAC not supported");
+   return -EOPNOTSUPP;
+   }
+
+   /* Calculate number of packets per second for given bps
+* assuming min ethernet packet size
+*/
+   pps = div_u64(rate_bytes_ps, ETH_ZLEN);
+
+   if (ether_addr_equal(match.key->dst, bc_mac)) {
+   ret = cpsw_ale_rx_ratelimit_bc(port->common->ale, 
port->port_id, pps);
+   if (ret)
+   return ret;
+
+   qos->ale_bc_ratelimit.cookie = cls->cookie;
+   qos->ale_bc_ratelimit.rate_packet_ps = pps;
+   }
+
+   if (ether_addr_equal(match.key->dst, mc_mac)) {
+   ret = cpsw_ale_rx_ratelimit_mc(port->common->ale, 
port->port_id, pps);
+   if (ret)
+   return ret;
+
+   qos->ale_mc_ratelimit.cookie = cls->cookie;
+   qos->ale_mc_ratelimit.rate_packet_ps = pps;
+   }
+
+   return 0;
+}
+
+static int am65_cpsw_qos_configure_clsflower(struct am65_cpsw_port *port,
+struct flow_cls_offload *cls)
+{
+   struct flow_rule *rule = flow_cls_offload_flow_rule(cls);
+   struct netlink_ext_ack *extack = cls->common.extack;
+   const struct flow_action_entry *act;
+   int i;
+
+   flow_action_for_each(i, act, >action) {
+   switch (

[PATCH net-next 1/3] drivers: net: cpsw: ale: add broadcast/multicast rate limit support

The CPSW ALE supports feature to rate limit number ingress
broadcast(BC)/multicast(MC) packets per/sec which main purpose is BC/MC
storm prevention.

The ALE BC/MC packet rate limit configuration consist of two parts:
- global
  ALE_CONTROL.ENABLE_RATE_LIMIT bit 0 which enables rate limiting globally
  ALE_PRESCALE.PRESCALE specifies rate limiting interval
- per-port
  ALE_PORTCTLx.BCASTMCAST/_LIMIT specifies number of BC/MC packets allowed
  per rate limiting interval.
  When port.BCASTMCAST/_LIMIT is 0 rate limiting is disabled for Port.

When BC/MC packet rate limiting is enabled the number of allowed packets
per/sec is defined as:
  number_of_packets/sec = (Fclk / ALE_PRESCALE) * port.BCASTMCAST/_LIMIT

Hence, the ALE_PRESCALE configuration is common for all ports the 1ms
interval is selected and configured during ALE initialization while
port.BCAST/MCAST_LIMIT are configured per-port.
This allows to achieve:
 - min number_of_packets = 1000 when port.BCAST/MCAST_LIMIT = 1
 - max number_of_packets = 1000 * 255 = 255000
   when port.BCAST/MCAST_LIMIT = 0xFF

The ALE_CONTROL.ENABLE_RATE_LIMIT can also be enabled once during ALE
initialization as rate limiting enabled by non zero port.BCASTMCAST/_LIMIT
values.

This patch implements above logic in ALE and adds new ALE APIs
 cpsw_ale_rx_ratelimit_bc();
 cpsw_ale_rx_ratelimit_mc();

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/cpsw_ale.c | 66 ++
 drivers/net/ethernet/ti/cpsw_ale.h |  2 +
 2 files changed, 68 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw_ale.c 
b/drivers/net/ethernet/ti/cpsw_ale.c
index cdc308a2aa3e..771e4d9f98ab 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -50,6 +50,8 @@
 /* ALE_AGING_TIMER */
 #define ALE_AGING_TIMER_MASK   GENMASK(23, 0)
 
+#define ALE_RATE_LIMIT_MIN_PPS 1000
+
 /**
  * struct ale_entry_fld - The ALE tbl entry field description
  * @start_bit: field start bit
@@ -1136,6 +1138,50 @@ int cpsw_ale_control_get(struct cpsw_ale *ale, int port, 
int control)
return tmp & BITMASK(info->bits);
 }
 
+int cpsw_ale_rx_ratelimit_mc(struct cpsw_ale *ale, int port, unsigned int 
ratelimit_pps)
+
+{
+   int val = ratelimit_pps / ALE_RATE_LIMIT_MIN_PPS;
+   u32 remainder = ratelimit_pps % ALE_RATE_LIMIT_MIN_PPS;
+
+   if (ratelimit_pps && !val) {
+   dev_err(ale->params.dev, "ALE MC port:%d ratelimit min value 
1000pps\n", port);
+   return -EINVAL;
+   }
+
+   if (remainder)
+   dev_info(ale->params.dev, "ALE port:%d MC ratelimit set to 
%dpps (requested %d)\n",
+port, ratelimit_pps - remainder, ratelimit_pps);
+
+   cpsw_ale_control_set(ale, port, ALE_PORT_MCAST_LIMIT, val);
+
+   dev_dbg(ale->params.dev, "ALE port:%d MC ratelimit set %d\n",
+   port, val * ALE_RATE_LIMIT_MIN_PPS);
+   return 0;
+}
+
+int cpsw_ale_rx_ratelimit_bc(struct cpsw_ale *ale, int port, unsigned int 
ratelimit_pps)
+
+{
+   int val = ratelimit_pps / ALE_RATE_LIMIT_MIN_PPS;
+   u32 remainder = ratelimit_pps % ALE_RATE_LIMIT_MIN_PPS;
+
+   if (ratelimit_pps && !val) {
+   dev_err(ale->params.dev, "ALE port:%d BC ratelimit min value 
1000pps\n", port);
+   return -EINVAL;
+   }
+
+   if (remainder)
+   dev_info(ale->params.dev, "ALE port:%d BC ratelimit set to 
%dpps (requested %d)\n",
+port, ratelimit_pps - remainder, ratelimit_pps);
+
+   cpsw_ale_control_set(ale, port, ALE_PORT_BCAST_LIMIT, val);
+
+   dev_dbg(ale->params.dev, "ALE port:%d BC ratelimit set %d\n",
+   port, val * ALE_RATE_LIMIT_MIN_PPS);
+   return 0;
+}
+
 static void cpsw_ale_timer(struct timer_list *t)
 {
struct cpsw_ale *ale = from_timer(ale, t, timer);
@@ -1199,6 +1245,26 @@ static void cpsw_ale_aging_stop(struct cpsw_ale *ale)
 
 void cpsw_ale_start(struct cpsw_ale *ale)
 {
+   unsigned long ale_prescale;
+
+   /* configure Broadcast and Multicast Rate Limit
+* number_of_packets = (Fclk / ALE_PRESCALE) * port.BCAST/MCAST_LIMIT
+* ALE_PRESCALE width is 19bit and min value 0x10
+* port.BCAST/MCAST_LIMIT is 8bit
+*
+* For multi port configuration support the ALE_PRESCALE is configured 
to 1ms interval,
+* which allows to configure port.BCAST/MCAST_LIMIT per port and 
achieve:
+* min number_of_packets = 1000 when port.BCAST/MCAST_LIMIT = 1
+* max number_of_packets = 1000 * 255 = 255000 when 
port.BCAST/MCAST_LIMIT = 0xFF
+*/
+   ale_prescale = ale->params.bus_freq / ALE_RATE_LIMIT_MIN_PPS;
+   writel((u32)ale_prescale, ale->params.ale_regs + ALE_PRESCALE);
+
+   /* Allow MC/BC rate limiting globally.
+* The actual Rate Limit cfg enabled per-port by port.BCAST/MCAST_LI

[PATCH v5] net: ethernet: ti: am65-cpts: update ret when ptp_clock is ERROR

2020-11-12 Thread Grygorii Strashko

From: Wang Qing 

We always have to update the value of ret, otherwise the
 error value may be the previous one.

Fixes: f6bd59526ca5 ("net: ethernet: ti: introduce am654 common platform time 
sync driver")
Signed-off-by: Wang Qing 
[grygorii.stras...@ti.com: fix build warn, subj add fixes tag]
Signed-off-by: Grygorii Strashko 
Acked-by: Richard Cochran 
---
Hi

I've update patch as requested and added Acked-by from Richard from v1.

v4: https://lore.kernel.org/patchwork/patch/1336771/
v3: https://lore.kernel.org/patchwork/patch/1334871/
v2: https://lore.kernel.org/patchwork/patch/1334549/
v1: https://lore.kernel.org/patchwork/patch/1334067/

 drivers/net/ethernet/ti/am65-cpts.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/am65-cpts.c 
b/drivers/net/ethernet/ti/am65-cpts.c
index 75056c14b161..5dc60ecabe56 100644
--- a/drivers/net/ethernet/ti/am65-cpts.c
+++ b/drivers/net/ethernet/ti/am65-cpts.c
@@ -1001,8 +1001,7 @@ struct am65_cpts *am65_cpts_create(struct device *dev, 
void __iomem *regs,
if (IS_ERR_OR_NULL(cpts->ptp_clock)) {
dev_err(dev, "Failed to register ptp clk %ld\n",
PTR_ERR(cpts->ptp_clock));
-   if (!cpts->ptp_clock)
-   ret = -ENODEV;
+   ret = cpts->ptp_clock ? PTR_ERR(cpts->ptp_clock) : -ENODEV;
goto refclk_disable;
}
cpts->phc_index = ptp_clock_index(cpts->ptp_clock);
-- 
2.17.1

[PATCH] net: ethernet: ti: cpsw: fix cpts irq after suspend

2020-11-12 Thread Grygorii Strashko

Depending on the SoC/platform the CPSW can completely lose context after a
suspend/resume cycle, including CPSW wrapper (WR) which will cause reset of
WR_C0_MISC_EN register, so CPTS IRQ will became disabled.

Fix it by moving CPTS IRQ enabling in cpsw_ndo_open() where CPTS is
actually started.

Fixes: 84ea9c0a95d7 ("net: ethernet: ti: cpsw: enable cpts irq")
Reported-by: Tony Lindgren 
Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/cpsw.c | 10 ++
 drivers/net/ethernet/ti/cpsw_new.c |  9 ++---
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 9fd1f77190ad..fa2d1025cbb2 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -838,9 +838,12 @@ static int cpsw_ndo_open(struct net_device *ndev)
if (ret < 0)
goto err_cleanup;
 
-   if (cpts_register(cpsw->cpts))
-   dev_err(priv->dev, "error registering cpts device\n");
-
+   if (cpsw->cpts) {
+   if (cpts_register(cpsw->cpts))
+   dev_err(priv->dev, "error registering cpts 
device\n");
+   else
+   writel(0x10, >wr_regs->misc_en);
+   }
}
 
cpsw_restore(priv);
@@ -1716,7 +1719,6 @@ static int cpsw_probe(struct platform_device *pdev)
 
/* Enable misc CPTS evnt_pend IRQ */
cpts_set_irqpoll(cpsw->cpts, false);
-   writel(0x10, >wr_regs->misc_en);
 
 skip_cpts:
cpsw_notice(priv, probe,
diff --git a/drivers/net/ethernet/ti/cpsw_new.c 
b/drivers/net/ethernet/ti/cpsw_new.c
index f779d2e1b5c5..2f5e0ad23ad7 100644
--- a/drivers/net/ethernet/ti/cpsw_new.c
+++ b/drivers/net/ethernet/ti/cpsw_new.c
@@ -873,8 +873,12 @@ static int cpsw_ndo_open(struct net_device *ndev)
if (ret < 0)
goto err_cleanup;
 
-   if (cpts_register(cpsw->cpts))
-   dev_err(priv->dev, "error registering cpts device\n");
+   if (cpsw->cpts) {
+   if (cpts_register(cpsw->cpts))
+   dev_err(priv->dev, "error registering cpts 
device\n");
+   else
+   writel(0x10, >wr_regs->misc_en);
+   }
 
napi_enable(>napi_rx);
napi_enable(>napi_tx);
@@ -2006,7 +2010,6 @@ static int cpsw_probe(struct platform_device *pdev)
 
/* Enable misc CPTS evnt_pend IRQ */
cpts_set_irqpoll(cpsw->cpts, false);
-   writel(0x10, >wr_regs->misc_en);
 
 skip_cpts:
ret = cpsw_register_notifiers(cpsw);
-- 
2.17.1

Re: [PATCH V4 net-bugfixs] net/ethernet: Update ret when ptp_clock is ERROR

2020-11-12 Thread Grygorii Strashko





On 12/11/2020 10:25, Arnd Bergmann wrote:

On Thu, Nov 12, 2020 at 2:48 AM 王擎  wrote:

On Wed, Nov 11, 2020 at 03:24:33PM +0200, Grygorii Strashko wrote:


I don't think v1 builds cleanly folks (not 100% sure, cpts is not
compiled on x86):

   ret = cpts->ptp_clock ? cpts->ptp_clock : (-ENODEV);

ptp_clock is a pointer, ret is an integer, right?


yeah, I will modify like: ret = cpts->ptp_clock ? PTR_ERR(cpts->ptp_clock) : 
-ENODEV;


This is not really getting any better. If Richard is worried about
Kconfig getting changed here, I would suggest handling the
case of PTP being disabled by returning an error early on in the
function, like

struct am65_cpts *am65_cpts_create(struct device *dev, void __iomem *regs,
struct device_node *node)
{
 struct am65_cpts *cpts;
 int ret, i;

 if (!IS_ENABLED(CONFIG_PTP_1588_CLOCK))
  return -ENODEV;

Then you can replace the broken IS_ERR_OR_NULL() path with
a simpler IS_ERR() case and keep the rest of the function readable.


There is proper blocker in am65-cpts.h #if IS_ENABLED(CONFIG_TI_K3_AM65_CPTS)
and in Makefile and proper dependency in Kconfig.

config TI_K3_AM65_CPTS
tristate "TI K3 AM65x CPTS"
depends on ARCH_K3 && OF
depends on PTP_1588_CLOCK

But, as Richard mentioned [1], ptp_clock_register() may return NULL even if 
PTP_1588_CLOCK=y
(which I can't confirm neither deny - from the fast look at ptp_clock_register()
 code it seems should not return NULL)




Grygorii, would you mind sending a correct patch in so Wang Qing can
see how it's done? I've been asking for a fixes tag multiple times
already :(


I still don't quite understand what a fixes tag means，
can you tell me how to do this, thanks.


This identifies which patch introduced the problem you are fixing
originally. If you add an alias in your ~/.gitconfig such as

[alias]
 fixes = show --format='Fixes: %h (\"%s\")' -s

then running

$ git fixes f6bd59526c
produces this line:

Fixes: f6bd59526ca5 ("net: ethernet: ti: introduce am654 common
platform time sync driver")


correct



which you can add to the changelog, just above the Signed-off-by
lines.




[1] https://lore.kernel.org/patchwork/patch/1334067/#1529232
--
Best regards,
grygorii

Re: [PATCHv2] bus: ti-sysc: Fix bogus resetdone warning on enable for cpsw

2020-11-11 Thread Grygorii Strashko





On 10/11/2020 11:21, Tony Lindgren wrote:

Bail out early from sysc_wait_softreset() just like we do in sysc_reset()
if there's no sysstatus srst_shift to fix a bogus resetdone warning on
enable as suggested by Grygorii Strashko .

We do not currently handle resets for modules that need writing to the
sysstatus register. If we at some point add that, we also need to add
SYSS_QUIRK_RESETDONE_INVERTED flag for cpsw as the sysstatus bit is low
when reset is done as described in the am335x TRM "Table 14-202
SOFT_RESET Register Field Descriptions"

Fixes: d46f9fbec719 ("bus: ti-sysc: Use optional clocks on for enable and wait for 
softreset bit")
Suggested-by: Grygorii Strashko 
Signed-off-by: Tony Lindgren 
---


Acked-by: Grygorii Strashko 



Changes since v1:
- Drop quirk handling and use fix suggested by Grygorii

---
  drivers/bus/ti-sysc.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -227,6 +227,9 @@ static int sysc_wait_softreset(struct sysc *ddata)
u32 sysc_mask, syss_done, rstval;
int syss_offset, error = 0;
  
+	if (ddata->cap->regbits->srst_shift < 0)

+   return 0;
+
syss_offset = ddata->offsets[SYSC_SYSSTATUS];
sysc_mask = BIT(ddata->cap->regbits->srst_shift);
  



--
Best regards,
grygorii

Re: [PATCH V4 net-bugfixs] net/ethernet: Update ret when ptp_clock is ERROR

2020-11-11 Thread Grygorii Strashko


hi Jakub,

On 11/11/2020 14:32, Richard Cochran wrote:

On Wed, Nov 11, 2020 at 05:24:41PM +0800, Wang Qing wrote:

We always have to update the value of ret, otherwise the error value
  may be the previous one. And ptp_clock_register() never return NULL
  when PTP_1588_CLOCK enable.


NAK.

Your code must handle the possibility that ptp_clock_register() can
return NULL.  Why?

1. Because that follows the documented API.

2. Because people will copy/paste this driver.

3. Because the Kconfig for your driver can change without warning.


Following Richard's comments v1 of the patch has to be applied [1].
I've also added my Reviewed-by there.

[1] https://lore.kernel.org/patchwork/patch/1334067/
--
Best regards,
grygorii

Re: [PATCH] net/ethernet: update ret when ptp_clock is ERROR

2020-11-11 Thread Grygorii Strashko





On 07/11/2020 17:08, Richard Cochran wrote:

On Fri, Nov 06, 2020 at 03:56:45PM +0800, Wang Qing wrote:

We always have to update the value of ret, otherwise the
  error value may be the previous one.

Signed-off-by: Wang Qing 


Acked-by: Richard Cochran 



Following Richard's comments:

Reviewed-by: Grygorii Strashko 




---
  drivers/net/ethernet/ti/am65-cpts.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/am65-cpts.c 
b/drivers/net/ethernet/ti/am65-cpts.c
index 75056c1..b77ff61
--- a/drivers/net/ethernet/ti/am65-cpts.c
+++ b/drivers/net/ethernet/ti/am65-cpts.c
@@ -1001,8 +1001,7 @@ struct am65_cpts *am65_cpts_create(struct device *dev, 
void __iomem *regs,
if (IS_ERR_OR_NULL(cpts->ptp_clock)) {
dev_err(dev, "Failed to register ptp clk %ld\n",
PTR_ERR(cpts->ptp_clock));
-   if (!cpts->ptp_clock)
-   ret = -ENODEV;
+   ret = cpts->ptp_clock ? cpts->ptp_clock : (-ENODEV);
goto refclk_disable;
}
cpts->phc_index = ptp_clock_index(cpts->ptp_clock);
--
2.7.4



--
Best regards,
grygorii

Re: [PATCH] net/ethernet: update ret when ptp_clock is ERROR

2020-11-06 Thread Grygorii Strashko





On 06/11/2020 14:58, Kurt Kanzenbach wrote:

On Fri Nov 06 2020, Arnd Bergmann wrote:

On Fri, Nov 6, 2020 at 12:35 PM Grygorii Strashko
 wrote:

On 06/11/2020 09:56, Wang Qing wrote:



+++ b/drivers/net/ethernet/ti/am65-cpts.c
@@ -1001,8 +1001,7 @@ struct am65_cpts *am65_cpts_create(struct device *dev, 
void __iomem *regs,


there is
 cpts->ptp_clock = ptp_clock_register(>ptp_info, cpts->dev);



   if (IS_ERR_OR_NULL(cpts->ptp_clock)) {


And ptp_clock_register() can return NULL only if PTP support is disabled.
In which case, we should not even get here.

So, I'd propose to s/IS_ERR_OR_NULL/IS_ERR above,
and just assign ret = PTR_ERR(cpts->ptp_clock) here.


Right, using IS_ERR_OR_NULL() is almost ever a mistake, either
from misunderstanding the interface, or from a badly designed
interface that needs to be changed.


The NULL case should be handled differently and it is documented:

/**
  * ptp_clock_register() - register a PTP hardware clock driver
[...]
  * Returns a valid pointer on success or PTR_ERR on failure.  If PHC
  * support is missing at the configuration level, this function
  * returns NULL, and drivers are expected to gracefully handle that
  * case separately.
  */


I think, it's not the first time such question triggered, I've found [1]

I've managed to find 6 drivers which uses IS_ERR_OR_NULL check with 
ptp_clock_register() and, kinda,
assume to be able to work with !CONFIG_PTP_1588_CLOCK. List below with some 
comments:

hv
hv_util.c
hv_timesync_init, line 697:  hv_ptp_clock = 
ptp_clock_register(_hyperv_info, NULL);

net/ethernet
sja1105 (depends on PTP_1588_CLOCK, use IS_ERR())
sja1105_ptp.c
sja1105_ptp_clock_register, line 867:  ptp_data->clock = 
ptp_clock_register(_data->caps, ds->dev);

net/ethernet
chelsio (can be fixed by adding !IS_ENABLED(CONFIG_PTP_1588_CLOCK))
cxgb4
cxgb4_ptp.c
cxgb4_ptp_init, line 431:  adapter->ptp_clock = 
ptp_clock_register(>ptp_clock_info,

net/ethernet
octeontx2 (can be fixed by adding !IS_ENABLED(CONFIG_PTP_1588_CLOCK))
nic
otx2_ptp.c
otx2_ptp_init, line 170:  ptp_ptr->ptp_clock = 
ptp_clock_register(_ptr->ptp_info, pfvf->dev);

net/ethernet
renesas (no checks - will crash if init failed or !PTP), uses imply 
PTP_1588_CLOCK
ravb_ptp.c
ravb_ptp_init, line 345:  priv->ptp.clock = ptp_clock_register(>ptp.info, 
>dev);

net/phy
mscc  (no checks - will crash if init failed or !PTP, depends on 
NETWORK_PHY_TIMESTAMPING)
mscc_ptp.c
__vsc8584_init_ptp, line 1495:  vsc8531->ptp->ptp_clock = 
ptp_clock_register(>ptp->caps,

In general, if above updated, the return value for ptp_clock_register() can be 
changed to ERR_PTR(-EOPNOTSUPP)
for the !CONFIG_PTP_1588_CLOCK and so question resolved.

For hv/sja1105/cxgb4/octeontx2 below diff should solve the case, but I'm not 
sure about
renesas/ravb_ptp and net/phy/mscc.

For renesas/ravb_ptp - seems strict "depends on PTP_1588_CLOCK" can be the 
choice
For net/phy/mscc - seems code dependencies need to be changed from 
CONFIG_NETWORK_PHY_TIMESTAMPING to
CONFIG_PTP_1588_CLOCK.

[1] https://lore.kernel.org/lkml/c04458ed-29ee-1797-3a11-7f3f56055...@ti.com/
--
Best regards,
grygorii

-
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 05566ecdbe4b..0fa8f6cb2394 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -681,6 +681,11 @@ static struct ptp_clock *hv_ptp_clock;
 
 static int hv_timesync_init(struct hv_util_service *srv)

 {
+   int ret = 0;
+
+   if (!IS_ENABLED(CONFIG_PTP_1588_CLOCK))
+   return -EOPNOTSUPP;
+
/* TimeSync requires Hyper-V clocksource. */
if (!hv_read_reference_counter)
return -ENODEV;
@@ -695,13 +700,13 @@ static int hv_timesync_init(struct hv_util_service *srv)
 * as it still handles the ICTIMESYNCFLAG_SYNC case.
 */
hv_ptp_clock = ptp_clock_register(_hyperv_info, NULL);
-   if (IS_ERR_OR_NULL(hv_ptp_clock)) {
-   pr_err("cannot register PTP clock: %ld\n",
-  PTR_ERR(hv_ptp_clock));
+   if (IS_ERR(hv_ptp_clock)) {
+   ret = PTR_ERR(hv_ptp_clock);
+   pr_err("cannot register PTP clock: %ld\n", ret);
hv_ptp_clock = NULL;
}
 
-   return 0;

+   return ret;
 }
 
 static void hv_timesync_cancel_work(void)

diff --git a/drivers/net/dsa/sja1105/sja1105_ptp.c 
b/drivers/net/dsa/sja1105/sja1105_ptp.c
index 1b90570b257b..1e41d491c854 100644
--- a/drivers/net/dsa/sja1105/sja1105_ptp.c
+++ b/drivers/net/dsa/sja1105/sja1105_ptp.c
@@ -865,7 +865,7 @@ int sja1105_ptp_clock_register(struct dsa_switch *ds)
spin_lock_init(_data->meta_lock);
 
ptp_data->clock = ptp_clock_register(_data->caps, ds->dev);

-   if (IS_ERR_OR_NULL(ptp_data->clock))
+   if (IS_ERR(ptp_data->clock))
return PTR_ERR(ptp_data->clock);
 
ptp_data->cmd.cor

Re: [PATCH v1 00/18] Refactor fw_devlink to significantly improve boot time

2020-11-06 Thread Grygorii Strashko





On 06/11/2020 10:36, Saravana Kannan wrote:

On Thu, Nov 5, 2020 at 9:09 PM Laurent Pinchart
 wrote:


Hi Saravana,

Thank you for working on this !

On Wed, Nov 04, 2020 at 03:23:37PM -0800, Saravana Kannan wrote:

The current implementation of fw_devlink is very inefficient because it
tries to get away without creating fwnode links in the name of saving
memory usage. Past attempts to optimize runtime at the cost of memory
usage were blocked with request for data showing that the optimization
made significant improvement for real world scenarios.

We have those scenarios now. There have been several reports of boot
time increase in the order of seconds in this thread [1]. Several OEMs
and SoC manufacturers have also privately reported significant
(350-400ms) increase in boot time due to all the parsing done by
fw_devlink.

So this patch series refactors fw_devlink to be more efficient. The key
difference now is the addition of support for fwnode links -- just a few
simple APIs. This also allows most of the code to be moved out of
firmware specific (DT mostly) code into driver core.

This brings the following benefits:
- Instead of parsing the device tree multiple times (complexity was
   close to O(N^3) where N in the number of properties) during bootup,
   fw_devlink parses each fwnode node/property only once and creates
   fwnode links. The rest of the fw_devlink code then just looks at these
   fwnode links to do rest of the work.

- Makes it much easier to debug probe issue due to fw_devlink in the
   future. fw_devlink=on blocks the probing of devices if they depend on
   a device that hasn't been added yet. With this refactor, it'll be very
   easy to tell what that device is because we now have a reference to
   the fwnode of the device.

- Much easier to add fw_devlink support to ACPI and other firmware
   types. A refactor to move the common bits from DT specific code to
   driver core was in my TODO list as a prerequisite to adding ACPI
   support to fw_devlink. This series gets that done.

Tomi/Laurent/Grygorii,

If you can test this series, that'd be great!


I gave it a try, rebasing my branch from v5.9 to v5.10-rc2 first. On
v5.10-rc2 the kernel dies when booting due to a deadlock (reported by
lockdep, so hopefully not too hard to debug). *sigh*. Fortunately, it
dies after the fw_devlink initialization, so I can still report results.


Phew! For a sec I thought you said fw_devlink was causing a deadlock.



Before your series:

[0.743065] cpuidle: using governor menu
[   13.350259] No ATAGs?

With your series applied:

[0.722670] cpuidle: using governor menu
[1.135859] No ATAGs?

That's a very clear improvement :-)


Thanks for testing. Great to hear it's helping!


Tested-by: Laurent Pinchart 


I'll add it to my v2 series.


I've tried your series on top of
521b619acdc8 Merge tag 'linux-kselftest-kunit-fixes-5.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
on am571x-idk

Before:
[0.049395] cpuidle: using governor menu
[1.654766] audit: type=2000 audit(0.040:1): state=initialized 
audit_enabled=0 res=1
[2.315266] No ATAGs?
[2.315317] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint 
registers.
[2.315327] hw-breakpoint: maximum watchpoint size is 8 bytes.
...
[6.549595] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. 
Opts: (null)
[6.557794] VFS: Mounted root (ext4 filesystem) on device 179:26.
[6.574103] devtmpfs: mounted
[6.577749] Freeing unused kernel memory: 1024K
[6.582433] Run /sbin/init as init process


after:
[0.049223] cpuidle: using governor menu
[0.095893] audit: type=2000 audit(0.040:1): state=initialized 
audit_enabled=0 res=1
[0.102958] No ATAGs?
[0.103010] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint 
registers.
[0.103020] hw-breakpoint: maximum watchpoint size is 8 bytes.
...
[3.518623] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. 
Opts: (null)
[3.526822] VFS: Mounted root (ext4 filesystem) on device 179:26.
[3.543128] devtmpfs: mounted
[3.546781] Freeing unused kernel memory: 1024K
[3.551463] Run /sbin/init as init process

So, it's much better. Thank you.
Tested-by: Grygorii Strashko 

--
Best regards,
grygorii

Re: [PATCH] net/ethernet: update ret when ptp_clock is ERROR

2020-11-06 Thread Grygorii Strashko





On 06/11/2020 09:56, Wang Qing wrote:

We always have to update the value of ret, otherwise the
  error value may be the previous one.

Signed-off-by: Wang Qing 
---
  drivers/net/ethernet/ti/am65-cpts.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/am65-cpts.c 
b/drivers/net/ethernet/ti/am65-cpts.c
index 75056c1..b77ff61
--- a/drivers/net/ethernet/ti/am65-cpts.c
+++ b/drivers/net/ethernet/ti/am65-cpts.c
@@ -1001,8 +1001,7 @@ struct am65_cpts *am65_cpts_create(struct device *dev, 
void __iomem *regs,


there is
cpts->ptp_clock = ptp_clock_register(>ptp_info, cpts->dev);



if (IS_ERR_OR_NULL(cpts->ptp_clock)) {


And ptp_clock_register() can return NULL only if PTP support is disabled.
In which case, we should not even get here.

So, I'd propose to s/IS_ERR_OR_NULL/IS_ERR above,
and just assign ret = PTR_ERR(cpts->ptp_clock) here.


dev_err(dev, "Failed to register ptp clk %ld\n",
PTR_ERR(cpts->ptp_clock));
-   if (!cpts->ptp_clock)
-   ret = -ENODEV;
+   ret = cpts->ptp_clock ? cpts->ptp_clock : (-ENODEV);
goto refclk_disable;
}
cpts->phc_index = ptp_clock_index(cpts->ptp_clock);



--
Best regards,
grygorii

Re: [PATCH 07/12] net: ethernet: ti: am65-cpts: Document am65_cpts_rx_enable()'s 'en' parameter

2020-11-04 Thread Grygorii Strashko





On 04/11/2020 11:06, Lee Jones wrote:

Fixes the following W=1 kernel build warning(s):

  drivers/net/ethernet/ti/am65-cpts.c:736: warning: Function parameter or 
member 'en' not described in 'am65_cpts_rx_enable'
  drivers/net/ethernet/ti/am65-cpts.c:736: warning: Excess function parameter 
'skb' description in 'am65_cpts_rx_enable'

Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Grygorii Strashko 
Cc: Kurt Kanzenbach 
Cc: net...@vger.kernel.org
Signed-off-by: Lee Jones 
---
  drivers/net/ethernet/ti/am65-cpts.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/am65-cpts.c 
b/drivers/net/ethernet/ti/am65-cpts.c
index 75056c14b161b..bb2b8e4919feb 100644
--- a/drivers/net/ethernet/ti/am65-cpts.c
+++ b/drivers/net/ethernet/ti/am65-cpts.c
@@ -727,7 +727,7 @@ static long am65_cpts_ts_work(struct ptp_clock_info *ptp)
  /**
   * am65_cpts_rx_enable - enable rx timestamping
   * @cpts: cpts handle
- * @skb: packet
+ * @en: enable
   *
   * This functions enables rx packets timestamping. The CPTS can timestamp all
   * rx packets.



Thank you.
Reviewed-by: Grygorii Strashko 

--
Best regards,
grygorii

Re: [PATCH] dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions

2020-11-04 Thread Grygorii Strashko





On 02/11/2020 09:46, Peter Ujfalusi wrote:



On 30/10/2020 22.30, Grygorii Strashko wrote:

The NAVSS UDMA will stuck if target IP module is disabled by PM while PSI-L
threads are paired UDMA<->IP and no further transfers is possible. This
could be the case for IPs J721E Main CPSW (cpsw9g).

Hence, to avoid such situation do PSI-L threads pairing only when UDMA
channel is going to be enabled as at this time DMA consumer module expected
to be active already.


Is this patch on top of the AM64 (BCDMA/PKTDMA) series or not?
Will it cause any conflict?


No. It was not based on top of AM64 series and I've not checked for conflicts.



Acked-by: Peter Ujfalusi 



Signed-off-by: Grygorii Strashko 
---
  drivers/dma/ti/k3-udma-glue.c | 64 +--
  1 file changed, 38 insertions(+), 26 deletions(-)


...

--
Best regards,
grygorii

[PATCH] dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions

The NAVSS UDMA will stuck if target IP module is disabled by PM while PSI-L
threads are paired UDMA<->IP and no further transfers is possible. This
could be the case for IPs J721E Main CPSW (cpsw9g).

Hence, to avoid such situation do PSI-L threads pairing only when UDMA
channel is going to be enabled as at this time DMA consumer module expected
to be active already.

Signed-off-by: Grygorii Strashko 
---
 drivers/dma/ti/k3-udma-glue.c | 64 +--
 1 file changed, 38 insertions(+), 26 deletions(-)

diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index a367584f0d7b..dfb65e382ab9 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -303,19 +303,6 @@ struct k3_udma_glue_tx_channel 
*k3_udma_glue_request_tx_chn(struct device *dev,
goto err;
}
 
-   ret = xudma_navss_psil_pair(tx_chn->common.udmax,
-   tx_chn->common.src_thread,
-   tx_chn->common.dst_thread);
-   if (ret) {
-   dev_err(dev, "PSI-L request err %d\n", ret);
-   goto err;
-   }
-
-   tx_chn->psil_paired = true;
-
-   /* reset TX RT registers */
-   k3_udma_glue_disable_tx_chn(tx_chn);
-
k3_udma_glue_dump_tx_chn(tx_chn);
 
return tx_chn;
@@ -378,6 +365,18 @@ EXPORT_SYMBOL_GPL(k3_udma_glue_pop_tx_chn);
 
 int k3_udma_glue_enable_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
 {
+   int ret;
+
+   ret = xudma_navss_psil_pair(tx_chn->common.udmax,
+   tx_chn->common.src_thread,
+   tx_chn->common.dst_thread);
+   if (ret) {
+   dev_err(tx_chn->common.dev, "PSI-L request err %d\n", ret);
+   return ret;
+   }
+
+   tx_chn->psil_paired = true;
+
xudma_tchanrt_write(tx_chn->udma_tchanx, UDMA_CHAN_RT_PEER_RT_EN_REG,
UDMA_PEER_RT_EN_ENABLE);
 
@@ -398,6 +397,13 @@ void k3_udma_glue_disable_tx_chn(struct 
k3_udma_glue_tx_channel *tx_chn)
xudma_tchanrt_write(tx_chn->udma_tchanx,
UDMA_CHAN_RT_PEER_RT_EN_REG, 0);
k3_udma_glue_dump_tx_rt_chn(tx_chn, "txchn dis2");
+
+   if (tx_chn->psil_paired) {
+   xudma_navss_psil_unpair(tx_chn->common.udmax,
+   tx_chn->common.src_thread,
+   tx_chn->common.dst_thread);
+   tx_chn->psil_paired = false;
+   }
 }
 EXPORT_SYMBOL_GPL(k3_udma_glue_disable_tx_chn);
 
@@ -815,19 +821,6 @@ k3_udma_glue_request_rx_chn_priv(struct device *dev, const 
char *name,
goto err;
}
 
-   ret = xudma_navss_psil_pair(rx_chn->common.udmax,
-   rx_chn->common.src_thread,
-   rx_chn->common.dst_thread);
-   if (ret) {
-   dev_err(dev, "PSI-L request err %d\n", ret);
-   goto err;
-   }
-
-   rx_chn->psil_paired = true;
-
-   /* reset RX RT registers */
-   k3_udma_glue_disable_rx_chn(rx_chn);
-
k3_udma_glue_dump_rx_chn(rx_chn);
 
return rx_chn;
@@ -1052,12 +1045,24 @@ EXPORT_SYMBOL_GPL(k3_udma_glue_rx_flow_disable);
 
 int k3_udma_glue_enable_rx_chn(struct k3_udma_glue_rx_channel *rx_chn)
 {
+   int ret;
+
if (rx_chn->remote)
return -EINVAL;
 
if (rx_chn->flows_ready < rx_chn->flow_num)
return -EINVAL;
 
+   ret = xudma_navss_psil_pair(rx_chn->common.udmax,
+   rx_chn->common.src_thread,
+   rx_chn->common.dst_thread);
+   if (ret) {
+   dev_err(rx_chn->common.dev, "PSI-L request err %d\n", ret);
+   return ret;
+   }
+
+   rx_chn->psil_paired = true;
+
xudma_rchanrt_write(rx_chn->udma_rchanx, UDMA_CHAN_RT_CTL_REG,
UDMA_CHAN_RT_CTL_EN);
 
@@ -1078,6 +1083,13 @@ void k3_udma_glue_disable_rx_chn(struct 
k3_udma_glue_rx_channel *rx_chn)
xudma_rchanrt_write(rx_chn->udma_rchanx, UDMA_CHAN_RT_CTL_REG, 0);
 
k3_udma_glue_dump_rx_rt_chn(rx_chn, "rxrt dis2");
+
+   if (rx_chn->psil_paired) {
+   xudma_navss_psil_unpair(rx_chn->common.udmax,
+   rx_chn->common.src_thread,
+   rx_chn->common.dst_thread);
+   rx_chn->psil_paired = false;
+   }
 }
 EXPORT_SYMBOL_GPL(k3_udma_glue_disable_rx_chn);
 
-- 
2.17.1

[PATCH net-next v3 07/10] net: ethernet: ti: am65-cpsw: fix tx csum offload for multi mac mode

The current implementation uses .ndo_set_features() callback to track
NETIF_F_HW_CSUM feature changes and update generic
CPSW_P0_CONTROL_REG.RX_CHECKSUM_EN option accordingly. It's not going to
work in case of multi-port devices as TX csum offload can be changed per
netdev.

On K3 CPSWxG devices TX csum offload enabled in the following way:

 - the CPSW_P0_CONTROL_REG.RX_CHECKSUM_EN option enables TX csum offload in
generic and affects all TX DMA channels and packets;

 - corresponding fields in TX DMA descriptor have to be filed properly when
upper layer wants to offload TX csum (skb->ip_summed == CHECKSUM_PARTIAL)
and it's per-packet option.

The Linux Network core is expected to never request TX csum offload if
netdev NETIF_F_HW_CSUM feature is disabled, and, as result, TX DMA
descriptors should not be modified, and per-packet TX csum offload will be
disabled (or enabled) on per-netdev basis. Which, in turn, makes it safe to
enable the CPSW_P0_CONTROL_REG.RX_CHECKSUM_EN option unconditionally.

Hence, fix TX csum offload for multi-port devices by:
 - enabling the CPSW_P0_CONTROL_REG.RX_CHECKSUM_EN option in
am65_cpsw_nuss_common_open() unconditionally
 - and removing .ndo_set_features() callback implementation, which was used
only NETIF_F_HW_CSUM feature update purposes

Signed-off-by: Grygorii Strashko 
Reviewed-by: Jesse Brandeburg 
---
 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 30 +---
 1 file changed, 1 insertion(+), 29 deletions(-)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c 
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 0bc0eec46709..2aa0c2acd059 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -428,9 +428,7 @@ static int am65_cpsw_nuss_common_open(struct 
am65_cpsw_common *common,
writel(common->rx_flow_id_base,
   host_p->port_base + AM65_CPSW_PORT0_REG_FLOW_ID_OFFSET);
/* en tx crc offload */
-   if (features & NETIF_F_HW_CSUM)
-   writel(AM65_CPSW_P0_REG_CTL_RX_CHECKSUM_EN,
-  host_p->port_base + AM65_CPSW_P0_REG_CTL);
+   writel(AM65_CPSW_P0_REG_CTL_RX_CHECKSUM_EN, host_p->port_base + 
AM65_CPSW_P0_REG_CTL);
 
am65_cpsw_nuss_set_p0_ptype(common);
 
@@ -1371,31 +1369,6 @@ static void am65_cpsw_nuss_ndo_get_stats(struct 
net_device *dev,
stats->tx_dropped   = dev->stats.tx_dropped;
 }
 
-static int am65_cpsw_nuss_ndo_slave_set_features(struct net_device *ndev,
-netdev_features_t features)
-{
-   struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
-   netdev_features_t changes = features ^ ndev->features;
-   struct am65_cpsw_host *host_p;
-
-   host_p = am65_common_get_host(common);
-
-   if (changes & NETIF_F_HW_CSUM) {
-   bool enable = !!(features & NETIF_F_HW_CSUM);
-
-   dev_info(common->dev, "Turn %s tx-checksum-ip-generic\n",
-enable ? "ON" : "OFF");
-   if (enable)
-   writel(AM65_CPSW_P0_REG_CTL_RX_CHECKSUM_EN,
-  host_p->port_base + AM65_CPSW_P0_REG_CTL);
-   else
-   writel(0,
-  host_p->port_base + AM65_CPSW_P0_REG_CTL);
-   }
-
-   return 0;
-}
-
 static const struct net_device_ops am65_cpsw_nuss_netdev_ops_2g = {
.ndo_open   = am65_cpsw_nuss_ndo_slave_open,
.ndo_stop   = am65_cpsw_nuss_ndo_slave_stop,
@@ -1408,7 +1381,6 @@ static const struct net_device_ops 
am65_cpsw_nuss_netdev_ops_2g = {
.ndo_vlan_rx_add_vid= am65_cpsw_nuss_ndo_slave_add_vid,
.ndo_vlan_rx_kill_vid   = am65_cpsw_nuss_ndo_slave_kill_vid,
.ndo_do_ioctl   = am65_cpsw_nuss_ndo_slave_ioctl,
-   .ndo_set_features   = am65_cpsw_nuss_ndo_slave_set_features,
.ndo_setup_tc   = am65_cpsw_qos_ndo_setup_tc,
 };
 
-- 
2.17.1

[PATCH net-next v3 06/10] net: ethernet: ti: am65-cpsw: keep active if cpts enabled

Some K3 CPSW NUSS instances can lose context after PM runtime ON->OFF->ON
transition depending on integration (including all submodules: CPTS, MDIO,
etc), like J721E Main CPSW (CPSW9G).

In case CPTS is enabled it's initialized during probe and does not expect
to be reset. Hence, keep K3 CPSW active by forbidding PM runtime if CPTS is
enabled.

Signed-off-by: Grygorii Strashko 
Reviewed-by: Jesse Brandeburg 
---
 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c 
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index fecaf6b8270f..0bc0eec46709 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -1727,6 +1727,13 @@ static int am65_cpsw_init_cpts(struct am65_cpsw_common 
*common)
return ret;
}
common->cpts = cpts;
+   /* Forbid PM runtime if CPTS is running.
+* K3 CPSWxG modules may completely lose context during ON->OFF
+* transitions depending on integration.
+* AM65x/J721E MCU CPSW2G: false
+* J721E MAIN_CPSW9G: true
+*/
+   pm_runtime_forbid(dev);
 
return 0;
 }
-- 
2.17.1

[PATCH] pwm: tiehrpwm: handle deferred probe with dev_err_probe()

The devm_clk_get() may return -EPROBE_DEFER which is not handled properly
by TI EHRPWM driver and causes unnecessary boot log messages.

Hence, add proper deferred probe handling with new dev_err_probe() API.

Signed-off-by: Grygorii Strashko 
---
 drivers/pwm/pwm-tiehrpwm.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index 0846917ff2d2..14c8fdcfd607 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -437,10 +437,8 @@ static int ehrpwm_pwm_probe(struct platform_device *pdev)
}
}
 
-   if (IS_ERR(clk)) {
-   dev_err(>dev, "failed to get clock\n");
-   return PTR_ERR(clk);
-   }
+   if (IS_ERR(clk))
+   return dev_err_probe(>dev, PTR_ERR(clk), "Failed to get 
fck\n");
 
pc->clk_rate = clk_get_rate(clk);
if (!pc->clk_rate) {
@@ -462,10 +460,8 @@ static int ehrpwm_pwm_probe(struct platform_device *pdev)
 
/* Acquire tbclk for Time Base EHRPWM submodule */
pc->tbclk = devm_clk_get(>dev, "tbclk");
-   if (IS_ERR(pc->tbclk)) {
-   dev_err(>dev, "Failed to get tbclk\n");
-   return PTR_ERR(pc->tbclk);
-   }
+   if (IS_ERR(pc->tbclk))
+   return dev_err_probe(>dev, PTR_ERR(pc->tbclk), "Failed to 
get tbclk\n");
 
ret = clk_prepare(pc->tbclk);
if (ret < 0) {
-- 
2.17.1

[PATCH net-next v3 10/10] net: ethernet: ti: am65-cpsw: handle deferred probe with dev_err_probe()

Use new dev_err_probe() API to handle deferred probe properly and simplify
the code.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 28 +---
 1 file changed, 10 insertions(+), 18 deletions(-)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c 
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index feb94b813ffc..766e8866bbef 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -1561,9 +1561,8 @@ static int am65_cpsw_nuss_init_tx_chns(struct 
am65_cpsw_common *common)
tx_chn->tx_chn_name,
_cfg);
if (IS_ERR(tx_chn->tx_chn)) {
-   ret = PTR_ERR(tx_chn->tx_chn);
-   dev_err(dev, "Failed to request tx dma channel %d\n",
-   ret);
+   ret = dev_err_probe(dev, PTR_ERR(tx_chn->tx_chn),
+   "Failed to request tx dma 
channel\n");
goto err;
}
 
@@ -1634,8 +1633,8 @@ static int am65_cpsw_nuss_init_rx_chns(struct 
am65_cpsw_common *common)
 
rx_chn->rx_chn = k3_udma_glue_request_rx_chn(dev, "rx", _cfg);
if (IS_ERR(rx_chn->rx_chn)) {
-   ret = PTR_ERR(rx_chn->rx_chn);
-   dev_err(dev, "Failed to request rx dma channel %d\n", ret);
+   ret = dev_err_probe(dev, PTR_ERR(rx_chn->rx_chn),
+   "Failed to request rx dma channel\n");
goto err;
}
 
@@ -1850,12 +1849,10 @@ static int am65_cpsw_nuss_init_slave_ports(struct 
am65_cpsw_common *common)
/* get phy/link info */
if (of_phy_is_fixed_link(port_np)) {
ret = of_phy_register_fixed_link(port_np);
-   if (ret) {
-   if (ret != -EPROBE_DEFER)
-   dev_err(dev, "%pOF failed to register 
fixed-link phy: %d\n",
-   port_np, ret);
-   return ret;
-   }
+   if (ret)
+   return dev_err_probe(dev, ret,
+"failed to register 
fixed-link phy %pOF\n",
+port_np);
port->slave.phy_node = of_node_get(port_np);
} else {
port->slave.phy_node =
@@ -2180,13 +2177,8 @@ static int am65_cpsw_nuss_probe(struct platform_device 
*pdev)
return -ENOMEM;
 
clk = devm_clk_get(dev, "fck");
-   if (IS_ERR(clk)) {
-   ret = PTR_ERR(clk);
-
-   if (ret != -EPROBE_DEFER)
-   dev_err(dev, "error getting fck clock %d\n", ret);
-   return ret;
-   }
+   if (IS_ERR(clk))
+   return dev_err_probe(dev, PTR_ERR(clk), "getting fck clock\n");
common->bus_freq = clk_get_rate(clk);
 
pm_runtime_enable(dev);
-- 
2.17.1

[PATCH net-next v3 08/10] net: ethernet: ti: am65-cpsw: prepare xmit/rx path for multi-port devices in mac-only mode

This patch adds multi-port support to TI AM65x CPSW driver xmit/rx path in
preparation for adding support for multi-port devices, like Main CPSW0 on
K3 J721E SoC or future CPSW3g on K3 AM64x SoC.
Hence DMA channels are common/shared for all ext Ports and the RX/TX NAPI
and DMA processing going to be assigned to first available netdev this patch:
 - ensures all RX descriptors fields are initialized;
 - adds synchronization for TX DMA push/pop operation (locking) as
Networking core locks are not enough any more;
 - updates TX bql processing for every packet in
am65_cpsw_nuss_tx_compl_packets() as every completed TX skb can have
different ndev assigned (come from different netdevs).

To avoid performance issues for existing one-port CPSW2g devices the above
changes are done only for multi-port devices by splitting xmit path for
one-port and multi-port devices.

Signed-off-by: Grygorii Strashko 
Reviewed-by: Jesse Brandeburg 
---
 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 141 +--
 drivers/net/ethernet/ti/am65-cpsw-nuss.h |   1 +
 2 files changed, 108 insertions(+), 34 deletions(-)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c 
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 2aa0c2acd059..86bfd253e295 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -375,7 +375,7 @@ static int am65_cpsw_nuss_rx_push(struct am65_cpsw_common 
*common,
 
cppi5_hdesc_init(desc_rx, CPPI5_INFO0_HDESC_EPIB_PRESENT,
 AM65_CPSW_NAV_PS_DATA_SIZE);
-   cppi5_hdesc_attach_buf(desc_rx, 0, 0, buf_dma, skb_tailroom(skb));
+   cppi5_hdesc_attach_buf(desc_rx, buf_dma, skb_tailroom(skb), buf_dma, 
skb_tailroom(skb));
swdata = cppi5_hdesc_get_swdata(desc_rx);
*((void **)swdata) = skb;
 
@@ -911,10 +911,57 @@ static void am65_cpsw_nuss_tx_cleanup(void *data, 
dma_addr_t desc_dma)
dev_kfree_skb_any(skb);
 }
 
+static struct sk_buff *
+am65_cpsw_nuss_tx_compl_packet(struct am65_cpsw_tx_chn *tx_chn,
+  dma_addr_t desc_dma)
+{
+   struct am65_cpsw_ndev_priv *ndev_priv;
+   struct am65_cpsw_ndev_stats *stats;
+   struct cppi5_host_desc_t *desc_tx;
+   struct net_device *ndev;
+   struct sk_buff *skb;
+   void **swdata;
+
+   desc_tx = k3_cppi_desc_pool_dma2virt(tx_chn->desc_pool,
+desc_dma);
+   swdata = cppi5_hdesc_get_swdata(desc_tx);
+   skb = *(swdata);
+   am65_cpsw_nuss_xmit_free(tx_chn, tx_chn->common->dev, desc_tx);
+
+   ndev = skb->dev;
+
+   am65_cpts_tx_timestamp(tx_chn->common->cpts, skb);
+
+   ndev_priv = netdev_priv(ndev);
+   stats = this_cpu_ptr(ndev_priv->stats);
+   u64_stats_update_begin(>syncp);
+   stats->tx_packets++;
+   stats->tx_bytes += skb->len;
+   u64_stats_update_end(>syncp);
+
+   return skb;
+}
+
+static void am65_cpsw_nuss_tx_wake(struct am65_cpsw_tx_chn *tx_chn, struct 
net_device *ndev,
+  struct netdev_queue *netif_txq)
+{
+   if (netif_tx_queue_stopped(netif_txq)) {
+   /* Check whether the queue is stopped due to stalled
+* tx dma, if the queue is stopped then wake the queue
+* as we have free desc for tx
+*/
+   __netif_tx_lock(netif_txq, smp_processor_id());
+   if (netif_running(ndev) &&
+   (k3_cppi_desc_pool_avail(tx_chn->desc_pool) >= 
MAX_SKB_FRAGS))
+   netif_tx_wake_queue(netif_txq);
+
+   __netif_tx_unlock(netif_txq);
+   }
+}
+
 static int am65_cpsw_nuss_tx_compl_packets(struct am65_cpsw_common *common,
   int chn, unsigned int budget)
 {
-   struct cppi5_host_desc_t *desc_tx;
struct device *dev = common->dev;
struct am65_cpsw_tx_chn *tx_chn;
struct netdev_queue *netif_txq;
@@ -923,15 +970,13 @@ static int am65_cpsw_nuss_tx_compl_packets(struct 
am65_cpsw_common *common,
struct sk_buff *skb;
dma_addr_t desc_dma;
int res, num_tx = 0;
-   void **swdata;
 
tx_chn = >tx_chns[chn];
 
while (true) {
-   struct am65_cpsw_ndev_priv *ndev_priv;
-   struct am65_cpsw_ndev_stats *stats;
-
+   spin_lock(_chn->lock);
res = k3_udma_glue_pop_tx_chn(tx_chn->tx_chn, _dma);
+   spin_unlock(_chn->lock);
if (res == -ENODATA)
break;
 
@@ -941,23 +986,52 @@ static int am65_cpsw_nuss_tx_compl_packets(struct 
am65_cpsw_common *common,
break;
}
 
-   desc_tx = k3_cppi_desc_pool_dma2virt(tx_chn->desc_pool,
-desc_dma);
-   swdata = cppi5_hdesc_get_swdata(desc_tx);
-

[PATCH net-next v3 05/10] net: ethernet: ti: am65-cpsw: fix vlan offload for multi mac mode

The VLAN offload for AM65x CPSW2G is implemented using existing ALE APIs,
which are also used by legacy CPSW drivers.
So, now it always adds current Ext. Port and Host as VLAN members when VLAN
is added by 8021Q core (.ndo_vlan_rx_add_vid) and forcibly removes VLAN
from ALE table in .ndo_vlan_rx_kill_vid(). This works as for AM65x CPSW2G
(which has only one Ext. Port) as for legacy CPSW devices (which can't
support same VLAN on more then one Port in multi mac (dual-mac) mode). But
it doesn't work for the new J721E and AM64x multi port CPSWxG versions
doesn't have such restrictions and allow to offload the same VLAN on any
number of ports.

Now the attempt to add same VLAN on two (or more) K3 CPSWxG Ports will
cause:
 - VLAN members mask overwrite when VLAN is added
 - VLAN removal from ALE table when any Port removes VLAN

This patch fixes an issue by:
 - switching to use cpsw_ale_vlan_add_modify() instead of
   cpsw_ale_add_vlan() when VLAN is added to ALE table, so VLAN members
   mask will not be overwritten;
 - Updates cpsw_ale_del_vlan() as:
 if more than one ext. Port is in VLAN member mask
 then remove only current port from VLAN member mask
 else remove VLAN ALE entry

 Example:
  add: P1 | P0 (Host) -> members mask: P1 | P0
  add: P2 | P0-> members mask: P2 | P1 | P0
  rem: P1 | P0-> members mask: P2 | P0
  rem: P2 | P0-> members mask: -

The VLAN is forcibly removed if port_mask=0 passed to cpsw_ale_del_vlan()
to preserve existing legacy CPSW drivers functionality.

Signed-off-by: Grygorii Strashko 
Reviewed-by: Jesse Brandeburg 
---
 drivers/net/ethernet/ti/am65-cpsw-nuss.c |  8 +---
 drivers/net/ethernet/ti/cpsw_ale.c   | 19 +++
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c 
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 65c5446e324e..fecaf6b8270f 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -241,8 +241,8 @@ static int am65_cpsw_nuss_ndo_slave_add_vid(struct 
net_device *ndev,
if (!vid)
unreg_mcast = port_mask;
dev_info(common->dev, "Adding vlan %d to vlan filter\n", vid);
-   ret = cpsw_ale_add_vlan(common->ale, vid, port_mask,
-   unreg_mcast, port_mask, 0);
+   ret = cpsw_ale_vlan_add_modify(common->ale, vid, port_mask,
+  unreg_mcast, port_mask, 0);
 
pm_runtime_put(common->dev);
return ret;
@@ -252,6 +252,7 @@ static int am65_cpsw_nuss_ndo_slave_kill_vid(struct 
net_device *ndev,
 __be16 proto, u16 vid)
 {
struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
+   struct am65_cpsw_port *port = am65_ndev_to_port(ndev);
int ret;
 
if (!netif_running(ndev) || !vid)
@@ -264,7 +265,8 @@ static int am65_cpsw_nuss_ndo_slave_kill_vid(struct 
net_device *ndev,
}
 
dev_info(common->dev, "Removing vlan %d from vlan filter\n", vid);
-   ret = cpsw_ale_del_vlan(common->ale, vid, 0);
+   ret = cpsw_ale_del_vlan(common->ale, vid,
+   BIT(port->port_id) | ALE_PORT_HOST);
 
pm_runtime_put(common->dev);
return ret;
diff --git a/drivers/net/ethernet/ti/cpsw_ale.c 
b/drivers/net/ethernet/ti/cpsw_ale.c
index b1cce39eda17..cdc308a2aa3e 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -694,7 +694,7 @@ int cpsw_ale_vlan_del_modify(struct cpsw_ale *ale, u16 vid, 
int port_mask)
 int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port_mask)
 {
u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
-   int idx;
+   int members, idx;
 
idx = cpsw_ale_match_vlan(ale, vid);
if (idx < 0)
@@ -702,11 +702,22 @@ int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int 
port_mask)
 
cpsw_ale_read(ale, idx, ale_entry);
 
-   if (port_mask) {
-   cpsw_ale_vlan_del_modify_int(ale, ale_entry, vid, port_mask);
-   } else {
+   /* if !port_mask - force remove VLAN (legacy).
+* Check if there are other VLAN members ports
+* if no - remove VLAN.
+* if yes it means same VLAN was added to >1 port in multi port mode, so
+* remove port_mask ports from VLAN ALE entry excluding Host port.
+*/
+   members = cpsw_ale_vlan_get_fld(ale, ale_entry, 
ALE_ENT_VID_MEMBER_LIST);
+   members &= ~port_mask;
+
+   if (!port_mask || !members) {
+   /* last port or force remove - remove VLAN */
cpsw_ale_set_vlan_untag(ale, ale_entry, vid, 0);
cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_FREE);
+   } else {
+   port_mask &= ~ALE_PORT_HOST;
+   cpsw_ale_vlan_del_modify_int(ale, ale_entry, vid, port_mask);
}
 
cpsw_ale_write(ale, idx, ale_entry);
-- 
2.17.1

[PATCH net-next v3 09/10] net: ethernet: ti: am65-cpsw: add multi port support in mac-only mode