[PATCH 13/20] net: stmmac: Move DMA Tx/Rx init methods to DW MAC lib

2021-02-08 Thread Serge Semin
These methods are identical for both DW MAC100 and DW MAC1000 cores, so
their implementation can be moved to the common for the core library.

Signed-off-by: Serge Semin 
---
 .../ethernet/stmicro/stmmac/dwmac1000_dma.c   | 20 ++-
 .../ethernet/stmicro/stmmac/dwmac100_dma.c| 20 ++-
 .../net/ethernet/stmicro/stmmac/dwmac_dma.h   |  4 
 .../net/ethernet/stmicro/stmmac/dwmac_lib.c   | 14 +
 4 files changed, 22 insertions(+), 36 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index 2bac49b49f73..2a04d9d45160 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -110,22 +110,6 @@ static void dwmac1000_dma_init(void __iomem *ioaddr,
writel(DMA_INTR_DEFAULT_MASK, ioaddr + DMA_INTR_ENA);
 }
 
-static void dwmac1000_dma_init_rx(void __iomem *ioaddr,
- struct stmmac_dma_cfg *dma_cfg,
- dma_addr_t dma_rx_phy, u32 chan)
-{
-   /* RX descriptor base address list must be written into DMA CSR3 */
-   writel(lower_32_bits(dma_rx_phy), ioaddr + DMA_RCV_BASE_ADDR);
-}
-
-static void dwmac1000_dma_init_tx(void __iomem *ioaddr,
- struct stmmac_dma_cfg *dma_cfg,
- dma_addr_t dma_tx_phy, u32 chan)
-{
-   /* TX descriptor base address list must be written into DMA CSR4 */
-   writel(lower_32_bits(dma_tx_phy), ioaddr + DMA_TX_BASE_ADDR);
-}
-
 static u32 dwmac1000_configure_fc(u32 csr6, int rxfifosz)
 {
csr6 &= ~DMA_CONTROL_RFA_MASK;
@@ -263,8 +247,8 @@ static void dwmac1000_rx_watchdog(void __iomem *ioaddr, u32 
riwt,
 const struct stmmac_dma_ops dwmac1000_dma_ops = {
.reset = dwmac_dma_reset,
.init = dwmac1000_dma_init,
-   .init_rx_chan = dwmac1000_dma_init_rx,
-   .init_tx_chan = dwmac1000_dma_init_tx,
+   .init_rx_chan = dwmac_dma_init_rx,
+   .init_tx_chan = dwmac_dma_init_tx,
.axi = dwmac1000_dma_axi,
.dump_regs = dwmac1000_dump_dma_regs,
.dma_rx_mode = dwmac1000_dma_operation_mode_rx,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
index 8f0d9bc7cab5..ad51a7949a42 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
@@ -29,22 +29,6 @@ static void dwmac100_dma_init(void __iomem *ioaddr,
writel(DMA_INTR_DEFAULT_MASK, ioaddr + DMA_INTR_ENA);
 }
 
-static void dwmac100_dma_init_rx(void __iomem *ioaddr,
-struct stmmac_dma_cfg *dma_cfg,
-dma_addr_t dma_rx_phy, u32 chan)
-{
-   /* RX descriptor base addr lists must be written into DMA CSR3 */
-   writel(lower_32_bits(dma_rx_phy), ioaddr + DMA_RCV_BASE_ADDR);
-}
-
-static void dwmac100_dma_init_tx(void __iomem *ioaddr,
-struct stmmac_dma_cfg *dma_cfg,
-dma_addr_t dma_tx_phy, u32 chan)
-{
-   /* TX descriptor base addr lists must be written into DMA CSR4 */
-   writel(lower_32_bits(dma_tx_phy), ioaddr + DMA_TX_BASE_ADDR);
-}
-
 /* Store and Forward capability is not used at all.
  *
  * The transmit threshold can be programmed by setting the TTC bits in the DMA
@@ -111,8 +95,8 @@ static void dwmac100_dma_diagnostic_fr(void *data, struct 
stmmac_extra_stats *x,
 const struct stmmac_dma_ops dwmac100_dma_ops = {
.reset = dwmac_dma_reset,
.init = dwmac100_dma_init,
-   .init_rx_chan = dwmac100_dma_init_rx,
-   .init_tx_chan = dwmac100_dma_init_tx,
+   .init_rx_chan = dwmac_dma_init_rx,
+   .init_tx_chan = dwmac_dma_init_tx,
.dump_regs = dwmac100_dump_dma_regs,
.dma_tx_mode = dwmac100_dma_operation_mode_tx,
.dma_diagnostic_fr = dwmac100_dma_diagnostic_fr,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h 
b/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
index e5dbd0bc257e..fa919bf75e19 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
@@ -134,8 +134,12 @@
 void dwmac_enable_dma_transmission(void __iomem *ioaddr);
 void dwmac_enable_dma_irq(void __iomem *ioaddr, u32 chan, bool rx, bool tx);
 void dwmac_disable_dma_irq(void __iomem *ioaddr, u32 chan, bool rx, bool tx);
+void dwmac_dma_init_tx(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg,
+  dma_addr_t dma_tx_phy, u32 chan);
 void dwmac_dma_start_tx(void __iomem *ioaddr, u32 chan);
 void dwmac_dma_stop_tx(void __iomem *ioaddr, u32 chan);
+void dwmac_dma_init_rx(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg,
+  dma_addr_t dma_rx_phy, u32 chan);
 void dwmac_dma_start_rx(void __iomem *ioaddr, u32 chan);
 void dwmac_dma_stop_rx(void __iomem *ioaddr,

[PATCH 11/20] net: stmmac: Discard index usage in the dirty_rx init

2021-02-08 Thread Serge Semin
Indeed in accordance with the initialization loop logics the statement
"(i - priv->dma_rx_size)" will always equal to zero. Just initialize the
dirty_rx pointer with zero then.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8599ef6df52f..abe8db9965f4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1412,7 +1412,7 @@ static int init_dma_rx_desc_rings(struct net_device *dev, 
gfp_t flags)
}
 
rx_q->cur_rx = 0;
-   rx_q->dirty_rx = (unsigned int)(i - priv->dma_rx_size);
+   rx_q->dirty_rx = 0;
 
/* Setup the chained descriptor addresses */
if (priv->mode == STMMAC_CHAIN_MODE) {
-- 
2.29.2



[PATCH 12/20] net: stmmac: Discard dwmac1000_dma_ops declaration from dwmac100.h

2021-02-08 Thread Serge Semin
Indeed it's redundant to have that variable declaration in the dwmac1000.h
header file since it's used in the hwif.c module only and declared in its
header together with the rest of the ops descriptors.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
index b70d44ac0990..494e1d2f2971 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
@@ -329,5 +329,4 @@ enum rtc_control {
 #define GMAC_MMC_RX_CSUM_OFFLOAD   0x208
 #define GMAC_EXTHASH_BASE  0x500
 
-extern const struct stmmac_dma_ops dwmac1000_dma_ops;
 #endif /* __DWMAC1000_H__ */
-- 
2.29.2



[PATCH 10/20] net: stmmac: Discard Rx copybreak ethtool setting

2021-02-08 Thread Serge Semin
Since commit 2af6106ae949 ("net: stmmac: Introducing support for Page
Pool") the mapping and unmapping has been replaced with Pages Pool usage.
The ethtool-tunable config like Rx copy-break is no longer used for
SK-buffers setup. So the ethtool tunable callback since setting/getting the
ETHTOOL_RX_COPYBREAK id doesn't really change anything. Just discard
the ethtool tunable callback then together with the rx_copybreak private
data field.

The same concerns the "rx_zeroc_thresh" member of the device private data,
but the main user has already been removed in commit 2af6106ae949
("net: stmmac: Introducing support for Page Pool") and in
commit d66e67bd4cc7 ("net: stmmac: Remove unused inline function
stmmac_rx_threshold_count").

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  2 -
 .../ethernet/stmicro/stmmac/stmmac_ethtool.c  | 39 ---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  4 --
 3 files changed, 45 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h 
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index af02d369e641..e444b1b237c0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -79,7 +79,6 @@ struct stmmac_rx_queue {
struct dma_desc *dma_rx cacheline_aligned_in_smp;
unsigned int cur_rx;
unsigned int dirty_rx;
-   u32 rx_zeroc_thresh;
dma_addr_t dma_rx_phy;
u32 rx_tail_addr;
unsigned int state_saved;
@@ -159,7 +158,6 @@ struct stmmac_priv {
u32 sarc_type;
 
unsigned int dma_buf_sz;
-   unsigned int rx_copybreak;
u32 rx_riwt;
int hwts_rx_en;
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 9e54f953634b..0ed287edbc2d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -929,43 +929,6 @@ static int stmmac_get_ts_info(struct net_device *dev,
return ethtool_op_get_ts_info(dev, info);
 }
 
-static int stmmac_get_tunable(struct net_device *dev,
- const struct ethtool_tunable *tuna, void *data)
-{
-   struct stmmac_priv *priv = netdev_priv(dev);
-   int ret = 0;
-
-   switch (tuna->id) {
-   case ETHTOOL_RX_COPYBREAK:
-   *(u32 *)data = priv->rx_copybreak;
-   break;
-   default:
-   ret = -EINVAL;
-   break;
-   }
-
-   return ret;
-}
-
-static int stmmac_set_tunable(struct net_device *dev,
- const struct ethtool_tunable *tuna,
- const void *data)
-{
-   struct stmmac_priv *priv = netdev_priv(dev);
-   int ret = 0;
-
-   switch (tuna->id) {
-   case ETHTOOL_RX_COPYBREAK:
-   priv->rx_copybreak = *(u32 *)data;
-   break;
-   default:
-   ret = -EINVAL;
-   break;
-   }
-
-   return ret;
-}
-
 static const struct ethtool_ops stmmac_ethtool_ops = {
.supported_coalesce_params = ETHTOOL_COALESCE_USECS |
 ETHTOOL_COALESCE_MAX_FRAMES,
@@ -999,8 +962,6 @@ static const struct ethtool_ops stmmac_ethtool_ops = {
.set_coalesce = stmmac_set_coalesce,
.get_channels = stmmac_get_channels,
.set_channels = stmmac_set_channels,
-   .get_tunable = stmmac_get_tunable,
-   .set_tunable = stmmac_set_tunable,
.get_link_ksettings = stmmac_ethtool_get_link_ksettings,
.set_link_ksettings = stmmac_ethtool_set_link_ksettings,
 };
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3bc07f5b64e1..8599ef6df52f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -84,8 +84,6 @@ static int buf_sz = DEFAULT_BUFSIZE;
 module_param(buf_sz, int, 0644);
 MODULE_PARM_DESC(buf_sz, "DMA buffer size");
 
-#defineSTMMAC_RX_COPYBREAK 256
-
 static const u32 default_msg_level = (NETIF_MSG_DRV | NETIF_MSG_PROBE |
  NETIF_MSG_LINK | NETIF_MSG_IFUP |
  NETIF_MSG_IFDOWN | NETIF_MSG_TIMER);
@@ -2831,8 +2829,6 @@ static int stmmac_open(struct net_device *dev)
priv->dma_buf_sz = bfsize;
buf_sz = bfsize;
 
-   priv->rx_copybreak = STMMAC_RX_COPYBREAK;
-
if (!priv->dma_tx_size)
priv->dma_tx_size = DMA_DEFAULT_TX_SIZE;
if (!priv->dma_rx_size)
-- 
2.29.2



[PATCH 09/20] net: stmmac: Discard mii_irq array from private data

2021-02-08 Thread Serge Semin
There has been no user of the denoted array of the device private data
since commit e7f4dc3536a4 ("mdio: Move allocation of interrupts into
core"). Discard it then.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h 
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index e553b9a1f785..af02d369e641 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -185,7 +185,6 @@ struct stmmac_priv {
unsigned int flow_ctrl;
unsigned int pause;
struct mii_bus *mii;
-   int mii_irq[PHY_MAX_ADDR];
 
struct phylink_config phylink_config;
struct phylink *phylink;
-- 
2.29.2



[PATCH 08/20] net: stmmac: Fix typo in the XGMAC_L3_ADDR3 macro name

2021-02-08 Thread Serge Semin
The macro has been declared as XMGAC_L3_ADDR3 with obvious second and
third chars confused. Revert them then.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h 
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index 6c3b8a950f58..2e6f60633128 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -191,7 +191,7 @@
 #define XGMAC_L3_ADDR0 0x4
 #define XGMAC_L3_ADDR1 0x5
 #define XGMAC_L3_ADDR2 0x6
-#define XMGAC_L3_ADDR3 0x7
+#define XGMAC_L3_ADDR3 0x7
 #define XGMAC_ARP_ADDR 0x0c10
 #define XGMAC_RSS_CTRL 0x0c80
 #define XGMAC_UDP4TE   BIT(3)
-- 
2.29.2



[PATCH 05/20] net: stmmac: Use dwmac410_disable_dma_irq for DW MAC v4.10 DMA

2021-02-08 Thread Serge Semin
>From the very beginning of the DW GMAC v4.10 IP support the driver has used
an invalid DMA IRQ disable method to switch the DMA IRQs off. Since
commit 021bd5e36970 ("net: stmmac: Let TX and RX interrupts be
independently enabled/disabled") a valid method has been added to the
dwmac4_lib.c module, but the commit author forgot to initialize the
corresponding field of the DW MAC DMA operations descriptor with it. That
mistake hasn't caused any problem so far just because the RIE/TIE fields
match in both 4.x and 4.10 IPs. Anyway fix the inconsistency in order to
at least have a coherent driver code.

Fixes: 021bd5e36970 ("net: stmmac: Let TX and RX interrupts be independently 
enabled/disabled")
Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index bb29bfcd62c3..59da9ff36a43 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -531,7 +531,7 @@ const struct stmmac_dma_ops dwmac410_dma_ops = {
.dma_rx_mode = dwmac4_dma_rx_chan_op_mode,
.dma_tx_mode = dwmac4_dma_tx_chan_op_mode,
.enable_dma_irq = dwmac410_enable_dma_irq,
-   .disable_dma_irq = dwmac4_disable_dma_irq,
+   .disable_dma_irq = dwmac410_disable_dma_irq,
.start_tx = dwmac4_dma_start_tx,
.stop_tx = dwmac4_dma_stop_tx,
.start_rx = dwmac4_dma_start_rx,
-- 
2.29.2



[PATCH 07/20] net: stmmac: Clear descriptors before initializing them

2021-02-08 Thread Serge Semin
According to the methods naming and partly based on their semantics the
descriptors need to be cleared first, then they can be properly
initialized. That specifically concerns the Tx descriptors and the chain
mode. Moreover doing the Rx-descriptors clearance twice is redundant. Fix
all of that by discarding the Rx descriptor clearance from the
init_dma_rx_desc_rings() method and move the generic method of all
descriptors clearance to the head of the init_dma_desc_rings() function.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1c40dc26fbf7..3bc07f5b64e1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1399,8 +1399,6 @@ static int init_dma_rx_desc_rings(struct net_device *dev, 
gfp_t flags)
  "(%s) dma_rx_phy=0x%08x\n", __func__,
  (u32)rx_q->dma_rx_phy);
 
-   stmmac_clear_rx_descriptors(priv, queue);
-
for (i = 0; i < priv->dma_rx_size; i++) {
struct dma_desc *p;
 
@@ -1522,14 +1520,14 @@ static int init_dma_desc_rings(struct net_device *dev, 
gfp_t flags)
struct stmmac_priv *priv = netdev_priv(dev);
int ret;
 
+   stmmac_clear_descriptors(priv);
+
ret = init_dma_rx_desc_rings(dev, flags);
if (ret)
return ret;
 
ret = init_dma_tx_desc_rings(dev);
 
-   stmmac_clear_descriptors(priv);
-
if (netif_msg_hw(priv))
stmmac_display_rings(priv);
 
-- 
2.29.2



[PATCH 06/20] net: stmmac: Use LPI IRQ status-related macro in DW MAC1000 isr

2021-02-08 Thread Serge Semin
For some reason the DW MAC1000-specific IRQ status handler has been using
the GMAC_INT_DISABLE_PMT macro to test whether the PMT IRQ is pending in
the MAC status register while there is a dedicated macro
GMAC_INT_STATUS_PMT exists for the corresponding field to test. It didn't
cause any error because the bits position match in both DW MAC IRQ mask
and status registers, but semantically the code still doesn't look
correct. Let's fix that by using the correct macro there.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index fc8759f146c7..6b9a4f54b93c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -321,7 +321,7 @@ static int dwmac1000_irq_status(struct mac_device_info *hw,
x->mmc_rx_irq_n++;
if (unlikely(intr_status & GMAC_INT_STATUS_MMCCSUM))
x->mmc_rx_csum_offload_irq_n++;
-   if (unlikely(intr_status & GMAC_INT_DISABLE_PMT)) {
+   if (unlikely(intr_status & GMAC_INT_STATUS_PMT)) {
/* clear the PMT bits 5 and 6 by reading the PMT status reg */
readl(ioaddr + GMAC_PMT);
x->irq_receive_pmt_irq_n++;
-- 
2.29.2



[PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode

2021-02-08 Thread Serge Semin
It has been noticed that RTL8211E PHY stops detecting and reporting events
when EEE is successfully advertised and RXC stopping in LPI is enabled.
The freeze happens right after 3.0.10 bit (PC1R "Clock Stop Enable"
register) is set. At the same time LED2 stops blinking as if EEE mode has
been disabled. Notably the network traffic still flows through the PHY
with no obvious problem. Anyway if any MDIO read procedure is performed
after the "RXC stop in LPI" mode is enabled PHY gets to be unfrozen, LED2
starts blinking and PHY interrupts happens again. The problem has been
noticed on RTL8211E PHY working together with DW GMAC 3.73a MAC and
reporting its event via a dedicated IRQ signal. (Obviously the problem has
been unnoticed in the polling mode, since it gets naturally fixed by the
periodic MDIO read procedure from the PHY status register - BMSR.)

In order to fix that problem we suggest to locally re-implement the MMD
write method for RTL8211E PHY and perform a dummy read right after the
PC1R register is accessed to enable the RXC stopping in LPI mode.

Signed-off-by: Serge Semin 
---
 drivers/net/phy/realtek.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 99ecd6c4c15a..cbb86c257aae 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -559,6 +559,42 @@ static int rtl822x_write_mmd(struct phy_device *phydev, 
int devnum, u16 regnum,
return ret;
 }
 
+static int rtl8211e_write_mmd(struct phy_device *phydev, int devnum, u16 
regnum,
+ u16 val)
+{
+   int ret;
+
+   /* Write to the MMD registers by using the standard control/data pair.
+* The only difference is that we need to perform a dummy read after
+* the PC1R.CLKSTOP_EN bit is set. It's required to workaround an issue
+* of a partial core freeze so LED2 stops blinking in EEE mode, PHY
+* stops detecting the link change and raising IRQs until any read from
+* its registers performed. That happens only if and right after the PHY
+* is enabled to stop RXC in LPI mode.
+*/
+   ret = __phy_write(phydev, MII_MMD_CTRL, devnum);
+   if (ret)
+   return ret;
+
+   ret = __phy_write(phydev, MII_MMD_DATA, regnum);
+   if (ret)
+   return ret;
+
+   ret = __phy_write(phydev, MII_MMD_CTRL, devnum | MII_MMD_CTRL_NOINCR);
+   if (ret)
+   return ret;
+
+   ret = __phy_write(phydev, MII_MMD_DATA, val);
+   if (ret)
+   return ret;
+
+   if (devnum == MDIO_MMD_PCS && regnum == MDIO_CTRL1 &&
+   val & MDIO_PCS_CTRL1_CLKSTOP_EN)
+   ret =  __phy_read(phydev, MII_MMD_DATA);
+
+   return ret < 0 ? ret : 0;
+}
+
 static int rtl822x_get_features(struct phy_device *phydev)
 {
int val;
@@ -725,6 +761,7 @@ static struct phy_driver realtek_drvs[] = {
.resume = genphy_resume,
.read_page  = rtl821x_read_page,
.write_page = rtl821x_write_page,
+   .write_mmd  = rtl8211e_write_mmd,
}, {
PHY_ID_MATCH_EXACT(0x001cc916),
.name   = "RTL8211F Gigabit Ethernet",
-- 
2.29.2



[PATCH 03/20] net: stmmac: Fix false MTL RX overflow handling for higher queues

2021-02-08 Thread Serge Semin
Judging by the MAC/MTL-related part of the ISR implementation if MTL IRQs
status handler returns MTL Rx overflow bit set, the
stmmac_set_rx_tail_ptr() method will be called for all subsequent queues.
That most likely isn't what we want. Fix it by just overriding the status
variable on each loop iteration. Note we can freely break the loop at the
very beginning if the stmmac_host_mtl_irq_status() method returns -EINVAL,
because that error means the MTL IRQ status handler isn't available for
the detected hardware.

Fixes: 7bac4e1ec3ca ("net: stmmac: stmmac interrupt treatment prepared for 
multiple queues")
Signed-off-by: Serge Semin 

---

Folks, I haven't seen an effect of that bug. The patch has been created
purely based on the code visual perception. If you think the handler is
supposed to work like that and I am missing something (though I have much
doubt about that), just drop this patch.
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 5ee840525824..d45af1ea2565 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4149,7 +4149,6 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id)
/* To handle GMAC own interrupts */
if ((priv->plat->has_gmac) || xmac) {
int status = stmmac_host_irq_status(priv, priv->hw, 
>xstats);
-   int mtl_status;
 
if (unlikely(status)) {
/* For LPI we need to save the tx status */
@@ -4162,10 +4161,10 @@ static irqreturn_t stmmac_interrupt(int irq, void 
*dev_id)
for (queue = 0; queue < queues_count; queue++) {
struct stmmac_rx_queue *rx_q = >rx_queue[queue];
 
-   mtl_status = stmmac_host_mtl_irq_status(priv, priv->hw,
-   queue);
-   if (mtl_status != -EINVAL)
-   status |= mtl_status;
+   status = stmmac_host_mtl_irq_status(priv, priv->hw,
+   queue);
+   if (status == -EINVAL)
+   break;
 
if (status & CORE_IRQ_MTL_RX_OVERFLOW)
stmmac_set_rx_tail_ptr(priv, priv->ioaddr,
-- 
2.29.2



[PATCH 04/20] net: stmmac: Assert reset control after MDIO de-registration

2021-02-08 Thread Serge Semin
Indeed it's unlikely but MDIO de-registration may still require an access
to the core registers, which obviously won't be possible in case if the
interface has been put into the reset state. So move the reset control
assertion to be executed after the MDIO bus is de-registered.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d45af1ea2565..1c40dc26fbf7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5159,10 +5159,10 @@ int stmmac_dvr_remove(struct device *dev)
stmmac_exit_fs(ndev);
 #endif
phylink_destroy(priv->phylink);
-   reset_control_assert(priv->plat->stmmac_rst);
if (priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
+   reset_control_assert(priv->plat->stmmac_rst);
destroy_workqueue(priv->wq);
mutex_destroy(>lock);
 
-- 
2.29.2



[PATCH 02/20] net: stmmac: Free Rx descs on Tx allocation failure

2021-02-08 Thread Serge Semin
Indeed in accordance with the alloc_dma_desc_resources() method logic the
Rx descriptors will be left allocated if Tx descriptors allocation fails.
Fix it by calling the free_dma_rx_desc_resources() in case if the
alloc_dma_tx_desc_resources() method returns non-zero value.

While at it refactor the method a bit. Just move the Rx descriptors
allocation method invocation out of the local variables declaration block
and discard a pointless comment from there.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 03acf14d76de..5ee840525824 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1791,13 +1791,15 @@ static int alloc_dma_tx_desc_resources(struct 
stmmac_priv *priv)
  */
 static int alloc_dma_desc_resources(struct stmmac_priv *priv)
 {
-   /* RX Allocation */
-   int ret = alloc_dma_rx_desc_resources(priv);
+   int ret;
 
+   ret = alloc_dma_rx_desc_resources(priv);
if (ret)
return ret;
 
ret = alloc_dma_tx_desc_resources(priv);
+   if (ret)
+   free_dma_rx_desc_resources(priv);
 
return ret;
 }
-- 
2.29.2



[PATCH 00/20] net: stmmac: Obvious cleanups and several fixes

2021-02-08 Thread Serge Semin
This series consists of a preparation patches before adding DW MAC GPIOs
and final Baikal-T1 GMAC support. (The later will be done in the framework
of the Generic DW MAC glue-driver though.) It's mainly about cleaning the
code up here and there by removing unused data and macro names, but also
includes several bugs and design fixes.

The patchset starts from fixing the Realtek PHYs driver. In particular it
has been discovered that disabling RXC in LPI (EEE) causes RTL8211E PHY
partial freeze until the next MDIO read operation from the PHY CSRs. We
suggest to fix that problem by dummy reading from the MMD Data register
each time the PC1R.10 bit is intended to be set.

Then the series evolves in a set of bug fixes discovered in the main
STMMAC driver code. First of all the cleanup-on-error path has been
incorrectly implemented in the DMA descriptor allocation procedure due to
which in case Tx DMA resources allocation failures the Rx DMA descriptors
will be left unfreed. Secondly it has been discovered that the MTL IRQs
handling procedure didn't do that quite well, so any MTL RX overflow
errors will be handled for queues with higher order too, which most likely
isn't what the code author originally intended. Thirdly the DW MAC reset
control de-assetion should be performed after the MDIO-bus
de-registration, because the later may need to access PHY registers, which
is supposed to be done via the MAC SMA interface. Fourthly we've found out
that DW MAC v4.x code was using a generic dwmac4_disable_dma_irq() method
to disable DMA IRQs instead of having the dedicated
dwmac410_disable_dma_irq() method utilized. That didn't cause any problem
because the modified bits matches in both IP-core revisions, but for
consistency we suggest to fix that. Fifthly for the same reason of the
naming consistency the GMAC_INT_STATUS_PMT macro constant should be used
instead of GMAC_INT_DISABLE_PMT to check the PMT IRQs status. Finally it's
strange that the problem hasn't been discovered before, but it is most
likely wrong to initialized Tx/Rx DMA descriptors, and then clean them up.
That specifically concerns the Tx DMA descriptors initialization procedure
in the Chain-mode. Please the patch for details.

The patchset then proceed with multiple optimizations and cleanups
performed here and there in the code: fix typo in the XGMAC_L3_ADDR3 macro
name, discard unused mii_irq array from the private data, discard nothing
changing Rx copybreak ethtool setting, discard redundant index variable
usage in the dirty_rx initialization method, discard dwmac1000_dma_ops
declaration from dwmac100.h, move DMA Tx/Rx init methods to the DW MAC lib
since they match for DW MAC and DW GMA IP-cores, discard pointless
STMMAC_RESETING flag, discard conditional service task execution since
it's called from CMWQ anyway (it's also errors prone, since any event
happening during the service task execution will be lost), add 'cause' arg
to the service task executioner to generalize the deferred events handling
interface. Finally in the framework of the code cleanup procedure we
suggest to extend the stmmac_hw_teardown() functionality with all the
necessary hardware cleanups, which for some reason were directly performed
in the network device release callback. That concerns PTP clocks
disabling, DMA channels and MAC Tx/Rx de-activation.

Note the STMMAC driver is having much more weak design patterns and style
problems (like calculating the total number of queues every time it's
needed, or antagonist/cleanup methods absence while having the reversal
code added in the remove/cleanup paths), than what is fixed in the
framework of this series, which make the code hard to read, comprehend,
maintain and extend with new features. Most likely the situation turned to
be like that due to a long history of the driver evolving to support many
different IP-core versions and vendor-specific MAC extensions. Anyway it
would have taken not a single patches series to fix all of the problems.
Since it hasn't been my primary target, here in this series I've
introduced the cleanups and fixes, which prepared the corresponding parts
of the code for easier alterations in the framework of adding the DW MAC
GPIOs and Baikal-T1 GMAC support into the driver.

The series is supposed to be applied on top of the last revision of the
next patchset:
Link: 
https://lore.kernel.org/netdev/20201214091616.13545-1-sergey.se...@baikalelectronics.ru/
otherwise a few patches won't get merged in cleanly.

Fixes: 7bac4e1ec3ca ("net: stmmac: stmmac interrupt treatment prepared for 
multiple queues")
Fixes: 021bd5e36970 ("net: stmmac: Let TX and RX interrupts be independently 
enabled/disabled")
Signed-off-by: Serge Semin 
Cc: Alexey Malahov 
Cc: Pavel Parkhomenko 
Cc: Vyacheslav Mitrofanov 
Cc: Maxime Coquelin 
Cc: Russell King 
Cc: Andrew Lunn 
Cc: Heiner Kallweit 
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.

[PATCH v2 23/24] net: stmmac: Use pclk to set MDC clock frequency

2021-02-08 Thread Serge Semin
In accordance with [1] the MDC clock frequency is supposed to be selected
with respect to the CSR clock frequency. CSR clock can be either tied to
the DW MAC system clock (GMAC main clock) or supplied via a dedicated
clk_csr_i signal. Current MDC clock selection procedure handles the former
case while having no support of the later one. That's wrong for the
devices which have separate system and CSR clocks. Let's fix it by first
trying to get the synchro-signal rate from the "pclk" clock, if it hasn't
been specified then fall-back to the "stmmaceth" clock.

[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 424.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a8dec219c295..03acf14d76de 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -206,7 +206,12 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
 {
u32 clk_rate;
 
-   clk_rate = clk_get_rate(priv->plat->stmmac_clk);
+   /* If APB clock has been specified then it is supposed to be used
+* to select the CSR mode. Otherwise the application clock is the
+* source of the periodic signal for the CSR interface.
+*/
+   clk_rate = clk_get_rate(priv->plat->pclk) ?:
+  clk_get_rate(priv->plat->stmmac_clk);
 
/* Platform provided default clk_csr would be assumed valid
 * for all other cases except for the below mentioned ones.
-- 
2.29.2



[PATCH v2 20/24] net: stmmac: dwc-qos: Discard Tx/Rx clocks request

2021-02-08 Thread Serge Semin
Since the Tx/Rx clocks with the same names are now requested and
enabled/disabled in the STMMAC DT-based platform config method, there is
no need in duplicating the same procedures in the DWC QoS Eth sub-driver.
Discard it then, but make sure the denoted clocks have been specified
for the platform.

Note also the deprecated clock "phy_ref_clk" have been defined as the Tx
clock in the DWC QoS Eth bindings. Let's use a pointer to the Tx clock
defined in the platform data then instead of the unrelated pclk pointer.

Signed-off-by: Serge Semin 
---
 .../stmicro/stmmac/dwmac-dwc-qos-eth.c| 44 +--
 1 file changed, 11 insertions(+), 33 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index b71f0c3faebe..f315ca395e12 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -31,8 +31,6 @@ struct tegra_eqos {
struct reset_control *rst;
struct clk *clk_master;
struct clk *clk_slave;
-   struct clk *clk_tx;
-   struct clk *clk_rx;
 
struct gpio_desc *reset;
 };
@@ -155,7 +153,7 @@ static int dwc_qos_probe(struct platform_device *pdev,
goto disable;
}
 
-   plat_dat->pclk = clk;
+   plat_dat->tx_clk = clk;
 
return 0;
 
@@ -175,8 +173,8 @@ static int dwc_qos_remove(struct platform_device *pdev)
 * data so the stmmac_remove_config_dt() method wouldn't have disabled
 * the clocks too.
 */
-   clk_disable_unprepare(priv->plat->pclk);
-   priv->plat->pclk = NULL;
+   clk_disable_unprepare(priv->plat->tx_clk);
+   priv->plat->tx_clk = NULL;
 
clk_disable_unprepare(priv->plat->stmmac_clk);
priv->plat->stmmac_clk = NULL;
@@ -197,6 +195,7 @@ static int dwc_qos_remove(struct platform_device *pdev)
 static void tegra_eqos_fix_speed(void *priv, unsigned int speed)
 {
struct tegra_eqos *eqos = priv;
+   struct stmmac_priv *sp = netdev_priv(dev_get_drvdata(eqos->dev));
unsigned long rate = 12500;
bool needs_calibration = false;
u32 value;
@@ -262,7 +261,7 @@ static void tegra_eqos_fix_speed(void *priv, unsigned int 
speed)
writel(value, eqos->regs + AUTO_CAL_CONFIG);
}
 
-   err = clk_set_rate(eqos->clk_tx, rate);
+   err = clk_set_rate(sp->plat->tx_clk, rate);
if (err < 0)
dev_err(eqos->dev, "failed to set TX rate: %d\n", err);
 }
@@ -299,6 +298,11 @@ static int tegra_eqos_probe(struct platform_device *pdev,
if (!is_of_node(dev->fwnode))
goto bypass_clk_reset_gpio;
 
+   if (!data->tx_clk || !data->rx_clk) {
+   err = -EINVAL;
+   goto error;
+   }
+
eqos->clk_master = devm_clk_get(>dev, "master_bus");
if (IS_ERR(eqos->clk_master)) {
err = PTR_ERR(eqos->clk_master);
@@ -321,30 +325,10 @@ static int tegra_eqos_probe(struct platform_device *pdev,
 
data->stmmac_clk = eqos->clk_slave;
 
-   eqos->clk_rx = devm_clk_get(>dev, "rx");
-   if (IS_ERR(eqos->clk_rx)) {
-   err = PTR_ERR(eqos->clk_rx);
-   goto disable_slave;
-   }
-
-   err = clk_prepare_enable(eqos->clk_rx);
-   if (err < 0)
-   goto disable_slave;
-
-   eqos->clk_tx = devm_clk_get(>dev, "tx");
-   if (IS_ERR(eqos->clk_tx)) {
-   err = PTR_ERR(eqos->clk_tx);
-   goto disable_rx;
-   }
-
-   err = clk_prepare_enable(eqos->clk_tx);
-   if (err < 0)
-   goto disable_rx;
-
eqos->reset = devm_gpiod_get(>dev, "phy-reset", GPIOD_OUT_HIGH);
if (IS_ERR(eqos->reset)) {
err = PTR_ERR(eqos->reset);
-   goto disable_tx;
+   goto disable_slave;
}
 
usleep_range(2000, 4000);
@@ -385,10 +369,6 @@ static int tegra_eqos_probe(struct platform_device *pdev,
reset_control_assert(eqos->rst);
 reset_phy:
gpiod_set_value(eqos->reset, 1);
-disable_tx:
-   clk_disable_unprepare(eqos->clk_tx);
-disable_rx:
-   clk_disable_unprepare(eqos->clk_rx);
 disable_slave:
clk_disable_unprepare(eqos->clk_slave);
data->stmmac_clk = NULL;
@@ -405,8 +385,6 @@ static int tegra_eqos_remove(struct platform_device *pdev)
 
reset_control_assert(eqos->rst);
gpiod_set_value(eqos->reset, 1);
-   clk_disable_unprepare(eqos->clk_tx);
-   clk_disable_unprepare(eqos->clk_rx);
clk_disable_unprepare(eqos->clk_slave);
clk_disable_unprepare(eqos->clk_master);
 
-- 
2.29.2



[PATCH v2 22/24] net: stmmac: Call stmmaceth clock as system clock in warn-message

2021-02-08 Thread Serge Semin
By all means of the stmmac_clk clock usage it isn't CSR clock, but the
system or application clock, which in particular cases can be used as a
clock source for the CSR interface. Make sure the warning message
correctly identify the clock. While at it add error message printout if
actual CSR clock failed to be requested.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index a6e35c84e135..7cbde9d99133 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -573,7 +573,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
 STMMAC_RESOURCE_NAME);
if (IS_ERR(plat->stmmac_clk)) {
rc = PTR_ERR(plat->stmmac_clk);
-   dev_err_probe(>dev, rc, "Cannot get CSR clock\n");
+   dev_err_probe(>dev, rc, "Cannot get system clock\n");
goto error_dma_cfg_alloc;
}
clk_prepare_enable(plat->stmmac_clk);
@@ -581,6 +581,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
plat->pclk = devm_clk_get_optional(>dev, "pclk");
if (IS_ERR(plat->pclk)) {
rc = PTR_ERR(plat->pclk);
+   dev_err_probe(>dev, rc, "Cannot get CSR clock\n");
goto error_pclk_get;
}
clk_prepare_enable(plat->pclk);
-- 
2.29.2



[PATCH v2 17/24] net: stmmac: dwc-qos: Cleanup STMMAC platform data clock pointers

2021-02-08 Thread Serge Semin
The pointers need to be nullified otherwise the stmmac_remove_config_dt()
method called after them being initialized will disable the clocks. That
then will cause a WARN() backtrace being printed since the clocks would be
also disabled in the locally defined remove method.

Signed-off-by: Serge Semin 
---
 .../stmicro/stmmac/dwmac-dwc-qos-eth.c| 42 ++-
 1 file changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index 27254b27d7ed..20b3696fb776 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -123,39 +123,46 @@ static int dwc_qos_probe(struct platform_device *pdev,
 struct plat_stmmacenet_data *plat_dat,
 struct stmmac_resources *stmmac_res)
 {
+   struct clk *clk;
int err;
 
-   plat_dat->stmmac_clk = devm_clk_get(>dev, "apb_pclk");
-   if (IS_ERR(plat_dat->stmmac_clk)) {
+   clk = devm_clk_get(>dev, "apb_pclk");
+   if (IS_ERR(clk)) {
dev_err(>dev, "apb_pclk clock not found.\n");
-   return PTR_ERR(plat_dat->stmmac_clk);
+   return PTR_ERR(clk);
}
 
-   err = clk_prepare_enable(plat_dat->stmmac_clk);
+   err = clk_prepare_enable(clk);
if (err < 0) {
dev_err(>dev, "failed to enable apb_pclk clock: %d\n",
err);
return err;
}
 
-   plat_dat->pclk = devm_clk_get(>dev, "phy_ref_clk");
-   if (IS_ERR(plat_dat->pclk)) {
+   plat_dat->stmmac_clk = clk;
+
+   clk = devm_clk_get(>dev, "phy_ref_clk");
+   if (IS_ERR(clk)) {
dev_err(>dev, "phy_ref_clk clock not found.\n");
-   err = PTR_ERR(plat_dat->pclk);
+   err = PTR_ERR(clk);
goto disable;
}
 
-   err = clk_prepare_enable(plat_dat->pclk);
+   err = clk_prepare_enable(clk);
if (err < 0) {
dev_err(>dev, "failed to enable phy_ref clock: %d\n",
err);
goto disable;
}
 
+   plat_dat->pclk = clk;
+
return 0;
 
 disable:
clk_disable_unprepare(plat_dat->stmmac_clk);
+   plat_dat->stmmac_clk = NULL;
+
return err;
 }
 
@@ -164,8 +171,15 @@ static int dwc_qos_remove(struct platform_device *pdev)
struct net_device *ndev = platform_get_drvdata(pdev);
struct stmmac_priv *priv = netdev_priv(ndev);
 
+   /* Cleanup the pointers to the clock handlers hidden in the platform
+* data so the stmmac_remove_config_dt() method wouldn't have disabled
+* the clocks too.
+*/
clk_disable_unprepare(priv->plat->pclk);
+   priv->plat->pclk = NULL;
+
clk_disable_unprepare(priv->plat->stmmac_clk);
+   priv->plat->stmmac_clk = NULL;
 
return 0;
 }
@@ -301,12 +315,12 @@ static int tegra_eqos_probe(struct platform_device *pdev,
goto disable_master;
}
 
-   data->stmmac_clk = eqos->clk_slave;
-
err = clk_prepare_enable(eqos->clk_slave);
if (err < 0)
goto disable_master;
 
+   data->stmmac_clk = eqos->clk_slave;
+
eqos->clk_rx = devm_clk_get(>dev, "rx");
if (IS_ERR(eqos->clk_rx)) {
err = PTR_ERR(eqos->clk_rx);
@@ -377,6 +391,7 @@ static int tegra_eqos_probe(struct platform_device *pdev,
clk_disable_unprepare(eqos->clk_rx);
 disable_slave:
clk_disable_unprepare(eqos->clk_slave);
+   data->stmmac_clk = NULL;
 disable_master:
clk_disable_unprepare(eqos->clk_master);
 error:
@@ -385,6 +400,7 @@ static int tegra_eqos_probe(struct platform_device *pdev,
 
 static int tegra_eqos_remove(struct platform_device *pdev)
 {
+   struct stmmac_priv *priv = netdev_priv(platform_get_drvdata(pdev));
struct tegra_eqos *eqos = get_stmmac_bsp_priv(>dev);
 
reset_control_assert(eqos->rst);
@@ -394,6 +410,12 @@ static int tegra_eqos_remove(struct platform_device *pdev)
clk_disable_unprepare(eqos->clk_slave);
clk_disable_unprepare(eqos->clk_master);
 
+   /* Cleanup the pointers to the clock handlers hidden in the platform
+* data so the stmmac_remove_config_dt() method wouldn't have disabled
+* the clocks too.
+*/
+   priv->plat->stmmac_clk = NULL;
+
return 0;
 }
 
-- 
2.29.2



[PATCH v2 18/24] net: stmmac: dwc-qos: Use dev_err_probe() for probe errors handling

2021-02-08 Thread Serge Semin
There is a very handy dev_err_probe() method to handle the deferred probe
error number. It reduces the code size and identations, uniforms error
handling, records the defer probe reason, etc. Use it to print the probe
callback error message.

Signed-off-by: Serge Semin 
Cc: Anson Huang 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index 20b3696fb776..b71f0c3faebe 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -466,10 +466,8 @@ static int dwc_eth_dwmac_probe(struct platform_device 
*pdev)
 
ret = data->probe(pdev, plat_dat, _res);
if (ret < 0) {
-   if (ret != -EPROBE_DEFER)
-   dev_err(>dev, "failed to probe subdriver: %d\n",
-   ret);
-
+   dev_err_probe(>dev, ret, "failed to probe subdriver: 
%d\n",
+ ret);
goto remove_config;
}
 
-- 
2.29.2



[PATCH v2 24/24] net: stmmac: dwc-qos: Save master/slave clocks in the plat-data

2021-02-08 Thread Serge Semin
Currently the "master_bus" clock of the DW QoS Eth controller isn't
preserved in the STMMAC platform data, while the "slave_bus" clock is
assigned to the stmmaceth clock pointer. It isn't correct from the
platform clock bindings point of view. The "stmmaceth" clock is supposed
to be the system clock, which is responsible for clocking the DMA
transfers from/to the controller FIFOs to/from the system memory and the
CSR interface if the later isn't separately clocked. If it's clocked
separately then the STMMAC platform code expects to also have "pclk"
specified. So in order to have the STMMAC platform data properly
initialized we need to set the "master_bus" clock handler to the
"stmmaceth" clock pointer, and the "slave_bus" clock handler to the "pclk"
clock pointer.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index f315ca395e12..bb2297638805 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -313,6 +313,8 @@ static int tegra_eqos_probe(struct platform_device *pdev,
if (err < 0)
goto error;
 
+   data->stmmac_clk = eqos->clk_master;
+
eqos->clk_slave = devm_clk_get(>dev, "slave_bus");
if (IS_ERR(eqos->clk_slave)) {
err = PTR_ERR(eqos->clk_slave);
@@ -323,7 +325,7 @@ static int tegra_eqos_probe(struct platform_device *pdev,
if (err < 0)
goto disable_master;
 
-   data->stmmac_clk = eqos->clk_slave;
+   data->pclk = eqos->clk_slave;
 
eqos->reset = devm_gpiod_get(>dev, "phy-reset", GPIOD_OUT_HIGH);
if (IS_ERR(eqos->reset)) {
@@ -371,9 +373,10 @@ static int tegra_eqos_probe(struct platform_device *pdev,
gpiod_set_value(eqos->reset, 1);
 disable_slave:
clk_disable_unprepare(eqos->clk_slave);
-   data->stmmac_clk = NULL;
+   data->pclk = NULL;
 disable_master:
clk_disable_unprepare(eqos->clk_master);
+   data->stmmac_clk = NULL;
 error:
return err;
 }
@@ -392,6 +395,7 @@ static int tegra_eqos_remove(struct platform_device *pdev)
 * data so the stmmac_remove_config_dt() method wouldn't have disabled
 * the clocks too.
 */
+   priv->plat->pclk = NULL;
priv->plat->stmmac_clk = NULL;
 
return 0;
-- 
2.29.2



[PATCH v2 21/24] net: stmmac: dwmac-imx: Discard Tx clock request

2021-02-08 Thread Serge Semin
Since the Tx clock is now requested and enabled/disabled in the STMMAC
DT-based platform config method, there is no need in duplicating the same
procedures in the DW MAC iMX sub-driver.

Signed-off-by: Serge Semin 
---
 .../net/ethernet/stmicro/stmmac/dwmac-imx.c   | 21 +--
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
index 223f69da7e95..8b2c7f1ba745 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
@@ -40,7 +40,6 @@ struct imx_dwmac_ops {
 
 struct imx_priv_data {
struct device *dev;
-   struct clk *clk_tx;
struct clk *clk_mem;
struct regmap *intf_regmap;
u32 intf_reg_off;
@@ -104,12 +103,6 @@ static int imx_dwmac_init(struct platform_device *pdev, 
void *priv)
return ret;
}
 
-   ret = clk_prepare_enable(dwmac->clk_tx);
-   if (ret) {
-   dev_err(>dev, "tx clock enable failed\n");
-   goto clk_tx_en_failed;
-   }
-
if (dwmac->ops->set_intf_mode) {
ret = dwmac->ops->set_intf_mode(plat_dat);
if (ret)
@@ -119,8 +112,6 @@ static int imx_dwmac_init(struct platform_device *pdev, 
void *priv)
return 0;
 
 intf_mode_failed:
-   clk_disable_unprepare(dwmac->clk_tx);
-clk_tx_en_failed:
clk_disable_unprepare(dwmac->clk_mem);
return ret;
 }
@@ -129,7 +120,6 @@ static void imx_dwmac_exit(struct platform_device *pdev, 
void *priv)
 {
struct imx_priv_data *dwmac = priv;
 
-   clk_disable_unprepare(dwmac->clk_tx);
clk_disable_unprepare(dwmac->clk_mem);
 }
 
@@ -162,7 +152,7 @@ static void imx_dwmac_fix_speed(void *priv, unsigned int 
speed)
return;
}
 
-   err = clk_set_rate(dwmac->clk_tx, rate);
+   err = clk_set_rate(plat_dat->tx_clk, rate);
if (err < 0)
dev_err(dwmac->dev, "failed to set tx rate %lu\n", rate);
 }
@@ -176,10 +166,9 @@ imx_dwmac_parse_dt(struct imx_priv_data *dwmac, struct 
device *dev)
if (of_get_property(np, "snps,rmii_refclk_ext", NULL))
dwmac->rmii_refclk_ext = true;
 
-   dwmac->clk_tx = devm_clk_get(dev, "tx");
-   if (IS_ERR(dwmac->clk_tx)) {
-   dev_err(dev, "failed to get tx clock\n");
-   return PTR_ERR(dwmac->clk_tx);
+   if (!dwmac->plat_dat->tx_clk) {
+   dev_err(dev, "no tx clock found\n");
+   return -EINVAL;
}
 
dwmac->clk_mem = NULL;
@@ -239,6 +228,7 @@ static int imx_dwmac_probe(struct platform_device *pdev)
 
dwmac->ops = data;
dwmac->dev = >dev;
+   dwmac->plat_dat = plat_dat;
 
ret = imx_dwmac_parse_dt(dwmac, >dev);
if (ret) {
@@ -251,7 +241,6 @@ static int imx_dwmac_probe(struct platform_device *pdev)
plat_dat->exit = imx_dwmac_exit;
plat_dat->fix_mac_speed = imx_dwmac_fix_speed;
plat_dat->bsp_priv = dwmac;
-   dwmac->plat_dat = plat_dat;
 
ret = imx_dwmac_init(pdev, dwmac);
if (ret)
-- 
2.29.2



[PATCH v2 19/24] net: stmmac: Add Tx/Rx platform clocks support

2021-02-08 Thread Serge Semin
Depending on the DW *MAC configuration it can be at least connected to an
external Transmit clock, but in some cases to an external Receive clock
generator. In order to simplify/unify the sub-drivers code and to prevent
having the same clocks named differently add the Tx/Rx clocks support to
the generic STMMAC DT-based platform data initialization method under the
names "tx" and "rx" respectively. The bindings schema has already been
altered in accordance with that.

Signed-off-by: Serge Semin 
---
 .../ethernet/stmicro/stmmac/stmmac_platform.c | 22 +++
 include/linux/stmmac.h|  2 ++
 2 files changed, 24 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 9a7c94622c36..a6e35c84e135 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -585,6 +585,22 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
}
clk_prepare_enable(plat->pclk);
 
+   plat->tx_clk = devm_clk_get_optional(>dev, "tx");
+   if (IS_ERR(plat->tx_clk)) {
+   rc = PTR_ERR(plat->tx_clk);
+   dev_err_probe(>dev, rc, "Cannot get Tx clock\n");
+   goto error_tx_clk_get;
+   }
+   clk_prepare_enable(plat->tx_clk);
+
+   plat->rx_clk = devm_clk_get_optional(>dev, "rx");
+   if (IS_ERR(plat->rx_clk)) {
+   rc = PTR_ERR(plat->rx_clk);
+   dev_err_probe(>dev, rc, "Cannot get Rx clock\n");
+   goto error_rx_clk_get;
+   }
+   clk_prepare_enable(plat->rx_clk);
+
/* Fall-back to main clock in case of no PTP ref is passed */
plat->clk_ptp_ref = devm_clk_get_optional(>dev, "ptp_ref");
if (IS_ERR(plat->clk_ptp_ref)) {
@@ -609,6 +625,10 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
return plat;
 
 error_hw_init:
+   clk_disable_unprepare(plat->rx_clk);
+error_rx_clk_get:
+   clk_disable_unprepare(plat->tx_clk);
+error_tx_clk_get:
clk_disable_unprepare(plat->pclk);
 error_pclk_get:
clk_disable_unprepare(plat->stmmac_clk);
@@ -630,6 +650,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
 void stmmac_remove_config_dt(struct platform_device *pdev,
 struct plat_stmmacenet_data *plat)
 {
+   clk_disable_unprepare(plat->rx_clk);
+   clk_disable_unprepare(plat->tx_clk);
clk_disable_unprepare(plat->pclk);
clk_disable_unprepare(plat->stmmac_clk);
of_node_put(plat->phy_node);
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 15ca6b4167cc..cec970adaf2e 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -186,6 +186,8 @@ struct plat_stmmacenet_data {
void *bsp_priv;
struct clk *stmmac_clk;
struct clk *pclk;
+   struct clk *tx_clk;
+   struct clk *rx_clk;
struct clk *clk_ptp_ref;
unsigned int clk_ptp_rate;
unsigned int clk_ref_rate;
-- 
2.29.2



[PATCH v2 15/24] net: stmmac: Use optional clock request method to get ptp_clk

2021-02-08 Thread Serge Semin
Let's replace the manual implementation of the optional ptp_clk
functionality with method devm_clk_get_optional() provided by the common
clock kernel framework. First of all it will be better from
maintainability point of view. Secondly by doing so we'll also fix a
potential problem, which will come out if the PTP clock has been actually
specified, but the clock framework failed to request it.

Note since we are switching the code to using the optional common clock
API, then there is no need in checking the clk_ptp_ref pointer for being
not NULL before calling the clk_prepare_enable() method. The later will
correctly handle it. So just discard the conditional statement of
priv->plat->clk_ptp_ref pointer value testing in the stmmac_resume()
method.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +--
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b371842d9337..4f1bf8f6538b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5289,8 +5289,7 @@ int stmmac_resume(struct device *dev)
/* enable the clk previously disabled */
clk_prepare_enable(priv->plat->stmmac_clk);
clk_prepare_enable(priv->plat->pclk);
-   if (priv->plat->clk_ptp_ref)
-   clk_prepare_enable(priv->plat->clk_ptp_ref);
+   clk_prepare_enable(priv->plat->clk_ptp_ref);
/* reset the phy so that it's ready */
if (priv->mii)
stmmac_mdio_reset(priv->mii);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index a66467baf30a..9a7c94622c36 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -586,10 +586,13 @@ stmmac_probe_config_dt(struct platform_device *pdev, 
const char **mac)
clk_prepare_enable(plat->pclk);
 
/* Fall-back to main clock in case of no PTP ref is passed */
-   plat->clk_ptp_ref = devm_clk_get(>dev, "ptp_ref");
+   plat->clk_ptp_ref = devm_clk_get_optional(>dev, "ptp_ref");
if (IS_ERR(plat->clk_ptp_ref)) {
+   rc = PTR_ERR(plat->clk_ptp_ref);
+   dev_err_probe(>dev, rc, "Cannot get PTP clock\n");
+   goto error_hw_init;
+   } else if (!plat->clk_ptp_ref) {
plat->clk_ptp_rate = clk_get_rate(plat->stmmac_clk);
-   plat->clk_ptp_ref = NULL;
dev_info(>dev, "PTP uses main clock\n");
} else {
plat->clk_ptp_rate = clk_get_rate(plat->clk_ptp_ref);
-- 
2.29.2



[PATCH v2 16/24] net: stmmac: Use optional reset control API to work with stmmaceth

2021-02-08 Thread Serge Semin
Since commit bb3222f71b57 ("net: stmmac: platform: use optional clk/reset
get APIs") a manual implementation of the optional device reset control
functionality has been replaced with using the
devm_reset_control_get_optional() method. But for some reason the optional
reset control handler usage hasn't been fixed and preserved the
NULL-checking statements. There is no need in that in order to perform the
reset control assertion/deassertion because the passed NULL will be
considered by the reset framework as absent optional reset control handler
anyway.

Fixes: bb3222f71b57 ("net: stmmac: platform: use optional clk/reset get APIs")
Signed-off-by: Serge Semin 
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4f1bf8f6538b..a8dec219c295 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4935,15 +4935,13 @@ int stmmac_dvr_probe(struct device *device,
if ((phyaddr >= 0) && (phyaddr <= 31))
priv->plat->phy_addr = phyaddr;
 
-   if (priv->plat->stmmac_rst) {
-   ret = reset_control_assert(priv->plat->stmmac_rst);
-   reset_control_deassert(priv->plat->stmmac_rst);
-   /* Some reset controllers have only reset callback instead of
-* assert + deassert callbacks pair.
-*/
-   if (ret == -ENOTSUPP)
-   reset_control_reset(priv->plat->stmmac_rst);
-   }
+   ret = reset_control_assert(priv->plat->stmmac_rst);
+   reset_control_deassert(priv->plat->stmmac_rst);
+   /* Some reset controllers have only reset callback instead of
+* assert + deassert callbacks pair.
+*/
+   if (ret == -ENOTSUPP)
+   reset_control_reset(priv->plat->stmmac_rst);
 
/* Init MAC and get the capabilities */
ret = stmmac_hw_init(priv);
@@ -5155,8 +5153,7 @@ int stmmac_dvr_remove(struct device *dev)
stmmac_exit_fs(ndev);
 #endif
phylink_destroy(priv->phylink);
-   if (priv->plat->stmmac_rst)
-   reset_control_assert(priv->plat->stmmac_rst);
+   reset_control_assert(priv->plat->stmmac_rst);
if (priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
-- 
2.29.2



[PATCH v2 11/24] net: stmmac: dwmac-stm32: Cleanup STMMAC DT-config in remove cb

2021-02-08 Thread Serge Semin
The stmmac_remove_config_dt() method needs to be called on the device
remove procedure otherwise for at least some of device-nodes will be left
requested.

Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev 
leaks")
Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
index 5d4df4c5254e..b45aab38c7b0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -426,6 +426,8 @@ static int stm32_dwmac_remove(struct platform_device *pdev)
 
stm32_dwmac_clk_disable(priv->plat->bsp_priv);
 
+   stmmac_remove_config_dt(pdev, priv->plat);
+
if (dwmac->irq_pwr_wakeup >= 0) {
dev_pm_clear_wake_irq(>dev);
device_init_wakeup(>dev, false);
-- 
2.29.2



[PATCH v2 06/24] dt-bindings: net: dwmac: Add Tx/Rx clock sources

2021-02-08 Thread Serge Semin
Generic DW *MAC can be connected to an external Transmit and Receive clock
generators. Add the corresponding clocks description and clock-names to
the generic bindings schema so new DW *MAC-based bindings wouldn't declare
its own names of the same clocks.

Signed-off-by: Serge Semin 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/net/snps,dwmac.yaml| 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 21e53427551c..56baf8e6bf17 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -126,6 +126,18 @@ properties:
   MCI, CSR and SMA interfaces run on this clock. If it's omitted,
   the CSR interfaces are considered as synchronous to the system
   clock domain.
+  - description:
+  GMAC Tx clock or so called Transmit clock. The clock is supplied
+  by an external with respect to the DW MAC clock generator.
+  The clock source and its frequency depends on the DW MAC xMII mode.
+  In case if it's supplied by PHY/SerDes this property can be
+  omitted.
+  - description:
+  GMAC Rx clock or so called Receive clock. The clock is supplied
+  by an external with respect to the DW MAC clock generator.
+  The clock source and its frequency depends on the DW MAC xMII mode.
+  In case if it's supplied by PHY/SerDes or it's synchronous to
+  the Tx clock this property can be omitted.
   - description:
   PTP reference clock. This clock is used for programming the
   Timestamp Addend Register. If not passed then the system
@@ -139,6 +151,8 @@ properties:
   enum:
 - stmmaceth
 - pclk
+- tx
+- rx
 - ptp_ref
 
   resets:
-- 
2.29.2



[PATCH v2 07/24] dt-bindings: net: dwmac: Detach Generic DW MAC bindings

2021-02-08 Thread Serge Semin
Currently the snps,dwmac.yaml DT bindings file is used for both DT nodes
describing generic DW MAC devices and as DT schema with common properties
to be evaluated against a vendor-specific DW MAC IP-cores. Due to such
dual-purpose design the "compatible" property of the common DW MAC schema
needs to contain the vendor-specific strings to successfully pass the
schema evaluation in case if it's referenced from the vendor-specific DT
bindings. That's a bad design from maintainability point of view, since
adding/removing any DW MAC-based device bindings requires the common
schema modification. In order to fix that let's detach the schema which
provides the generic DW MAC DT nodes evaluation into a dedicated DT
bindings file preserving the common DW MAC properties declaration in the
snps,dwmac.yaml file. By doing so we'll still provide a common properties
evaluation for each vendor-specific MAC bindings which refer to the
common bindings file, while the generic DW MAC DT nodes will be checked
against the new snps,dwmac-generic.yaml DT schema.

Signed-off-by: Serge Semin 

---

Changelog v2:
- Add a note to the snps,dwmac-generic.yaml bindings file description of
  a requirement to create a new DT bindings file for the vendor-specific
  versions of the DW MAC.
---
 .../bindings/net/snps,dwmac-generic.yaml  | 154 ++
 .../devicetree/bindings/net/snps,dwmac.yaml   | 139 +---
 2 files changed, 155 insertions(+), 138 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
new file mode 100644
index ..6c3bf5b2f890
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/snps,dwmac-generic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare Generic MAC Device Tree Bindings
+
+maintainers:
+  - Alexandre Torgue 
+  - Giuseppe Cavallaro 
+  - Jose Abreu 
+
+description:
+  The primary purpose of this bindings file is to validate the Generic
+  Synopsys Desginware MAC DT nodes defined in accordance with the select
+  schema. All new vendor-specific versions of the DW *MAC IP-cores must
+  be described in a dedicated DT bindings file.
+
+# Select the DT nodes, which have got compatible strings either as just a
+# single string with IP-core name optionally followed by the IP version or
+# two strings: one with IP-core name plus the IP version, another as just
+# the IP-core name.
+select:
+  properties:
+compatible:
+  oneOf:
+- items:
+- pattern: "^snps,dw(xg)+mac(-[0-9]+\\.[0-9]+a?)?$"
+- items:
+- pattern: "^snps,dwmac-[0-9]+\\.[0-9]+a?$"
+- const: snps,dwmac
+- items:
+- pattern: "^snps,dwxgmac-[0-9]+\\.[0-9]+a?$"
+- const: snps,dwxgmac
+
+  required:
+- compatible
+
+allOf:
+  - $ref: snps,dwmac.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - description: Generic Synopsys DW MAC
+oneOf:
+  - items:
+  - enum:
+  - snps,dwmac-3.50a
+  - snps,dwmac-3.610
+  - snps,dwmac-3.70a
+  - snps,dwmac-3.710
+  - snps,dwmac-4.00
+  - snps,dwmac-4.10a
+  - snps,dwmac-4.20a
+  - const: snps,dwmac
+  - const: snps,dwmac
+  - description: Generic Synopsys DW xGMAC
+oneOf:
+  - items:
+  - enum:
+  - snps,dwxgmac-2.10
+  - const: snps,dwxgmac
+  - const: snps,dwxgmac
+  - description: ST SPEAr SoC Family GMAC
+deprecated: true
+const: st,spear600-gmac
+
+  reg:
+maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+  - |
+gmac0: ethernet@e080 {
+  compatible = "snps,dwxgmac-2.10", "snps,dwxgmac";
+  reg = <0xe080 0x8000>;
+  interrupt-parent = <>;
+  interrupts = <24 23 22>;
+  interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+  mac-address = []; /* Filled in by U-Boot */
+  max-frame-size = <3800>;
+  phy-mode = "gmii";
+  snps,multicast-filter-bins = <256>;
+  snps,perfect-filter-entries = <128>;
+  rx-fifo-depth = <16384>;
+  tx-fifo-depth = <16384>;
+  clocks = <>;
+  clock-names = "stmmaceth";
+  snps,axi-config = <_axi_setup>;
+  snps,mtl-rx-config = <_rx_setup>;
+  snps,mtl-tx-config = <_tx_setup>;
+  mdio0 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible =

[PATCH v2 08/24] net: stmmac: Add {axi,mtl-rx,mtl-tx}-config sub-nodes support

2021-02-08 Thread Serge Semin
Currently the "snps,axi-config", "snps,mtl-rx-config" and
"snps,mtl-tx-config" DT node properties are marked as deprecated when
being defined as a phandle reference to a node with parameters. The new
way of defining the DW MAC interfaces config is to add sub-nodes to the DW
MAC device DT node with vendor-prefixless names. Make sure the STMMAC
driver supports them.

Signed-off-by: Serge Semin 

---

Changelog v2:
- Discard "snps" vendor-prefix from the new AXI/MTL Tx/Rx config
  sub-nodes.
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 6dc9f10414e4..1815fe36b62f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -95,7 +95,8 @@ static struct stmmac_axi *stmmac_axi_setup(struct 
platform_device *pdev)
struct device_node *np;
struct stmmac_axi *axi;
 
-   np = of_parse_phandle(pdev->dev.of_node, "snps,axi-config", 0);
+   np = of_parse_phandle(pdev->dev.of_node, "snps,axi-config", 0) ?:
+of_get_child_by_name(pdev->dev.of_node, "axi-config");
if (!np)
return NULL;
 
@@ -150,11 +151,13 @@ static int stmmac_mtl_setup(struct platform_device *pdev,
plat->rx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB;
plat->tx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB;
 
-   rx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-rx-config", 0);
+   rx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-rx-config", 0) 
?:
+ of_get_child_by_name(pdev->dev.of_node, "mtl-rx-config");
if (!rx_node)
return ret;
 
-   tx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-tx-config", 0);
+   tx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-tx-config", 0) 
?:
+ of_get_child_by_name(pdev->dev.of_node, "mtl-tx-config");
if (!tx_node) {
of_node_put(rx_node);
return ret;
-- 
2.29.2



[PATCH v2 14/24] net: stmmac: Use optional clock request method to get stmmaceth

2021-02-08 Thread Serge Semin
The "stmmaceth" clock is expected to be optional by the current driver
design, but there are several problems in the implementation. First if the
clock is specified, but failed to be requested due to an internal error or
due to not being ready yet for configuration, then the DT-probe procedure
will just proceed with further initializations. It is erroneous in both
cases. Secondly if we'd use the clock API, which expect the clock being
optional we wouldn't have needed to avoid the clock request procedure for
the "snps,dwc-qos-ethernet-4.10"-compatible devices to prevent the error
message from being printed. All of that can be fixed by using the
devm_clk_get_optional() method here provided by the common clock
framework.

Signed-off-by: Serge Semin 
---
 .../ethernet/stmicro/stmmac/stmmac_platform.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index ff66c470f07f..a66467baf30a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -566,16 +566,17 @@ stmmac_probe_config_dt(struct platform_device *pdev, 
const char **mac)
if (rc)
goto error_dma_cfg_alloc;
 
-   /* clock setup */
-   if (!of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
-   plat->stmmac_clk = devm_clk_get(>dev,
-   STMMAC_RESOURCE_NAME);
-   if (IS_ERR(plat->stmmac_clk)) {
-   dev_warn(>dev, "Cannot get CSR clock\n");
-   plat->stmmac_clk = NULL;
-   }
-   clk_prepare_enable(plat->stmmac_clk);
+   /* All clocks are optional since the sub-drivers may use the platform
+* clocks pointers to preserve their own clock-descriptors.
+*/
+   plat->stmmac_clk = devm_clk_get_optional(>dev,
+STMMAC_RESOURCE_NAME);
+   if (IS_ERR(plat->stmmac_clk)) {
+   rc = PTR_ERR(plat->stmmac_clk);
+   dev_err_probe(>dev, rc, "Cannot get CSR clock\n");
+   goto error_dma_cfg_alloc;
}
+   clk_prepare_enable(plat->stmmac_clk);
 
plat->pclk = devm_clk_get_optional(>dev, "pclk");
if (IS_ERR(plat->pclk)) {
-- 
2.29.2



[PATCH v2 12/24] net: stmmac: Directly call reverse methods in stmmac_probe_config_dt()

2021-02-08 Thread Serge Semin
Calling an antagonistic method from the corresponding protagonist isn't
good from maintainability point of view, since prevents us from directly
adding a functionality in the later, which needs to be reverted in the
former. Since that's what we are about to do in order to fix the commit
573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to
platform structure"), let's replace the stmmac_remove_config_dt() method
invocation in stmmac_probe_config_dt() with direct reversal procedures.

Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst 
to platform structure")
Signed-off-by: Serge Semin 
---
 .../ethernet/stmicro/stmmac/stmmac_platform.c | 23 ++-
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1815fe36b62f..c9feac70ca77 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -402,7 +402,6 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
struct device_node *np = pdev->dev.of_node;
struct plat_stmmacenet_data *plat;
struct stmmac_dma_cfg *dma_cfg;
-   void *ret;
int rc;
 
plat = devm_kzalloc(>dev, sizeof(*plat), GFP_KERNEL);
@@ -458,7 +457,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
/* To Configure PHY by using all device-tree supported properties */
rc = stmmac_dt_phy(plat, np, >dev);
if (rc)
-   return ERR_PTR(rc);
+   goto error_dt_phy_parse;
 
of_property_read_u32(np, "tx-fifo-depth", >tx_fifo_size);
 
@@ -536,8 +535,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
dma_cfg = devm_kzalloc(>dev, sizeof(*dma_cfg),
   GFP_KERNEL);
if (!dma_cfg) {
-   stmmac_remove_config_dt(pdev, plat);
-   return ERR_PTR(-ENOMEM);
+   rc = -ENOMEM;
+   goto error_dma_cfg_alloc;
}
plat->dma_cfg = dma_cfg;
 
@@ -564,10 +563,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
plat->axi = stmmac_axi_setup(pdev);
 
rc = stmmac_mtl_setup(pdev, plat);
-   if (rc) {
-   stmmac_remove_config_dt(pdev, plat);
-   return ERR_PTR(rc);
-   }
+   if (rc)
+   goto error_dma_cfg_alloc;
 
/* clock setup */
if (!of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
@@ -582,7 +579,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
 
plat->pclk = devm_clk_get_optional(>dev, "pclk");
if (IS_ERR(plat->pclk)) {
-   ret = plat->pclk;
+   rc = PTR_ERR(plat->pclk);
goto error_pclk_get;
}
clk_prepare_enable(plat->pclk);
@@ -601,7 +598,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
plat->stmmac_rst = devm_reset_control_get_optional(>dev,
   
STMMAC_RESOURCE_NAME);
if (IS_ERR(plat->stmmac_rst)) {
-   ret = plat->stmmac_rst;
+   rc = PTR_ERR(plat->stmmac_rst);
goto error_hw_init;
}
 
@@ -611,8 +608,12 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
clk_disable_unprepare(plat->pclk);
 error_pclk_get:
clk_disable_unprepare(plat->stmmac_clk);
+error_dma_cfg_alloc:
+   of_node_put(plat->mdio_node);
+error_dt_phy_parse:
+   of_node_put(plat->phy_node);
 
-   return ret;
+   return ERR_PTR(rc);
 }
 
 /**
-- 
2.29.2



[PATCH v2 13/24] net: stmmac: Fix clocks left enabled on glue-probes failure

2021-02-08 Thread Serge Semin
The generic clocks request and preparation have been moved from
stmmac_dvr_probe()/stmmac_init_ptp() to the stmmac_probe_config_dt()
method in the framework of commit f573c0b9c4e0 ("stmmac: move stmmac_clk,
pclk, clk_ptp_ref and stmmac_rst to platform structure"). At the same time
the clocks disabling and reset assertion have been left in
stmmac_dvr_remove() instead of also being moved to the symmetric
antagonistic method - stmmac_remove_config_dt(). Due to that all the glue
drivers probe cleanup-on-failure paths don't perform the generic clocks
disable/unprepare procedure, which of course is wrong. Fix it by moving
the clocks disable/unprepare methods invocation to the
stmmac_remove_config_dt() function.

Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst 
to platform structure")
Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 2 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 --
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 4 +++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 103d2448e9e0..56b914b5527a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -665,6 +665,8 @@ static void intel_eth_pci_remove(struct pci_dev *pdev)
 
pci_free_irq_vectors(pdev);
 
+   clk_disable_unprepare(priv->plat->stmmac_clk);
+
clk_unregister_fixed_rate(priv->plat->stmmac_clk);
 
pcim_iounmap_regions(pdev, BIT(0));
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 26b971cd4da5..b371842d9337 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5157,8 +5157,6 @@ int stmmac_dvr_remove(struct device *dev)
phylink_destroy(priv->phylink);
if (priv->plat->stmmac_rst)
reset_control_assert(priv->plat->stmmac_rst);
-   clk_disable_unprepare(priv->plat->pclk);
-   clk_disable_unprepare(priv->plat->stmmac_clk);
if (priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index c9feac70ca77..ff66c470f07f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -621,11 +621,13 @@ stmmac_probe_config_dt(struct platform_device *pdev, 
const char **mac)
  * @pdev: platform_device structure
  * @plat: driver data platform structure
  *
- * Release resources claimed by stmmac_probe_config_dt().
+ * Disable and release resources claimed by stmmac_probe_config_dt().
  */
 void stmmac_remove_config_dt(struct platform_device *pdev,
 struct plat_stmmacenet_data *plat)
 {
+   clk_disable_unprepare(plat->pclk);
+   clk_disable_unprepare(plat->stmmac_clk);
of_node_put(plat->phy_node);
of_node_put(plat->mdio_node);
 }
-- 
2.29.2



[PATCH v2 10/24] net: stmmac: dwmac-sti: Cleanup STMMAC DT-config in remove cb

2021-02-08 Thread Serge Semin
The stmmac_remove_config_dt() method needs to be called on the device
remove procedure otherwise for at least some of device-nodes will be left
requested.

Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev 
leaks")
Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
index e1b63df6f96f..3454c5eff822 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
@@ -370,11 +370,14 @@ static int sti_dwmac_probe(struct platform_device *pdev)
 
 static int sti_dwmac_remove(struct platform_device *pdev)
 {
+   struct stmmac_priv *priv = netdev_priv(platform_get_drvdata(pdev));
struct sti_dwmac *dwmac = get_stmmac_bsp_priv(>dev);
int ret = stmmac_dvr_remove(>dev);
 
clk_disable_unprepare(dwmac->clk);
 
+   stmmac_remove_config_dt(pdev, priv->plat);
+
return ret;
 }
 
-- 
2.29.2



[PATCH v2 09/24] net: stmmac: dwmac-rk: Cleanup STMMAC DT-config in remove cb

2021-02-08 Thread Serge Semin
The stmmac_remove_config_dt() method needs to be called on the device
remove procedure otherwise for at least some of device-nodes will be left
requested.

Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev 
leaks")
Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 6ef30252bfe0..01c10ca80f1a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1433,11 +1433,14 @@ static int rk_gmac_probe(struct platform_device *pdev)
 
 static int rk_gmac_remove(struct platform_device *pdev)
 {
+   struct stmmac_priv *priv = netdev_priv(platform_get_drvdata(pdev));
struct rk_priv_data *bsp_priv = get_stmmac_bsp_priv(>dev);
int ret = stmmac_dvr_remove(>dev);
 
rk_gmac_powerdown(bsp_priv);
 
+   stmmac_remove_config_dt(pdev, priv->plat);
+
return ret;
 }
 
-- 
2.29.2



[PATCH v2 05/24] dt-bindings: net: dwmac: Elaborate stmmaceth/pclk description

2021-02-08 Thread Serge Semin
Current clocks description doesn't provide a comprehensive notion about
what "stmmaceth" and "pclk" actually represent from the IP-core manual
point of view. The bindings file states:
stmmaceth - "GMAC main clock",
apb - "Peripheral registers interface clock".
It isn't that easy to understand what they actually mean especially seeing
the DW *MAC manual operates with clock definitions like Application,
System, Host, CSR, Transmit, Receive, etc clocks. Moreover the clocks
usage in the driver doesn't shade a full light on their essence. What
inferred from there is that the "stmmaceth" name has been assigned to the
common clock, which feeds both system and CSR interfaces. But what about
"apb"? The bindings defines it as the clock for "peripheral registers
interface". So it's close to the CSR clock in the IP-core manual notation.
If so then when "apb" clock is specified aside with the "stmmaceth", it
represents a case when the DW *MAC is synthesized with CSR_SLV_CLK=y
(separate system and CSR clocks). But even though the "apb" clock is
requested in the MAC driver, the driver doesn't actually use it as a
separate CSR clock where the IP-core manual requires. All of that makes me
thinking that the case of separate system and CSR clocks isn't correctly
implemented in the driver.

Let's start with elaborating the clocks description so anyone reading
the DW *MAC bindings file would understand that "stmmaceth" is the
system clock and "pclk" is actually the CSR clock. Indeed in accordance
with sheets depicted in [1]:
system/application clock can be either of: hclk_i, aclk_i, clk_app_i;
CSR clock can be either of: hclk_i, aclk_i, clk_app_i, clk_csr_i.
(Most likely the similar definitions present in the others IP-core
manuals.) So the CSR clock can be tied to the application clock
considering the later as the main clock, but not the other way around. In
case if there is only "stmmaceth" clock specified in a DT node, then it
will be considered as a source of clocks for both application and CSR. But
if "pclk" is also specified in the list of the device clocks, then it will
be perceived as the separate CSR clock.

[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 564.

Signed-off-by: Serge Semin 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/net/snps,dwmac.yaml  | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 4dda9ffa822c..21e53427551c 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -116,8 +116,16 @@ properties:
 maxItems: 5
 additionalItems: true
 items:
-  - description: GMAC main clock
-  - description: Peripheral registers interface clock
+  - description:
+  GMAC main clock, also called as system/application clock.
+  This clock is used to provide a periodic signal for the DMA/MTL
+  interface and optionally for CSR, if the later isn't separately
+  clocked.
+  - description:
+  Peripheral registers interface clock, also called as CSR clock.
+  MCI, CSR and SMA interfaces run on this clock. If it's omitted,
+  the CSR interfaces are considered as synchronous to the system
+  clock domain.
   - description:
   PTP reference clock. This clock is used for programming the
   Timestamp Addend Register. If not passed then the system
-- 
2.29.2



[PATCH v2 00/24] net: stmmac: Fix clocks/reset-related procedures

2021-02-08 Thread Serge Semin
"snps" vendor-prefix from the new AXI/MTL-Tx/Rx config
  sub-nodes.
- Add the new sub-nodes "axi-config", "mtl-rx-config" and "mtl-tx-config"
  to the DW *MAC bindings describing the nodes the now deprecated
  config-properties were supposed to refer to.
- Fix invalid identation in the "snps,route-*" property settings.
- Discard the patch
  [PATCH 15/25] net: stmmac: Use optional clock request method to get pclk
  since the corresponding functionality has already been integrated into
  the driver.
- Rebase on top of the kernel 5.11-rc7.

Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev 
leaks")
Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst 
to platform structure")
Signed-off-by: Serge Semin 
Cc: Alexey Malahov 
Cc: Pavel Parkhomenko 
Cc: Vyacheslav Mitrofanov 
Cc: Maxime Coquelin 
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Serge Semin (24):
  dt-bindings: net: dwmac: Validate PBL for all IP-cores
  dt-bindings: net: dwmac: Extend number of PBL values
  dt-bindings: net: dwmac: Fix the TSO property declaration
  dt-bindings: net: dwmac: Refactor snps,*-config properties
  dt-bindings: net: dwmac: Elaborate stmmaceth/pclk description
  dt-bindings: net: dwmac: Add Tx/Rx clock sources
  dt-bindings: net: dwmac: Detach Generic DW MAC bindings
  net: stmmac: Add {axi,mtl-rx,mtl-tx}-config sub-nodes support
  net: stmmac: dwmac-rk: Cleanup STMMAC DT-config in remove cb
  net: stmmac: dwmac-sti: Cleanup STMMAC DT-config in remove cb
  net: stmmac: dwmac-stm32: Cleanup STMMAC DT-config in remove cb
  net: stmmac: Directly call reverse methods in stmmac_probe_config_dt()
  net: stmmac: Fix clocks left enabled on glue-probes failure
  net: stmmac: Use optional clock request method to get stmmaceth
  net: stmmac: Use optional clock request method to get ptp_clk
  net: stmmac: Use optional reset control API to work with stmmaceth
  net: stmmac: dwc-qos: Cleanup STMMAC platform data clock pointers
  net: stmmac: dwc-qos: Use dev_err_probe() for probe errors handling
  net: stmmac: Add Tx/Rx platform clocks support
  net: stmmac: dwc-qos: Discard Tx/Rx clocks request
  net: stmmac: dwmac-imx: Discard Tx clock request
  net: stmmac: Call stmmaceth clock as system clock in warn-message
  net: stmmac: Use pclk to set MDC clock frequency
  net: stmmac: dwc-qos: Save master/slave clocks in the plat-data

 .../bindings/net/snps,dwmac-generic.yaml  | 154 +
 .../devicetree/bindings/net/snps,dwmac.yaml   | 578 ++
 .../stmicro/stmmac/dwmac-dwc-qos-eth.c|  90 +--
 .../net/ethernet/stmicro/stmmac/dwmac-imx.c   |  21 +-
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c |   2 +
 .../net/ethernet/stmicro/stmmac/dwmac-rk.c|   3 +
 .../net/ethernet/stmicro/stmmac/dwmac-sti.c   |   3 +
 .../net/ethernet/stmicro/stmmac/dwmac-stm32.c |   2 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  31 +-
 .../ethernet/stmicro/stmmac/stmmac_platform.c |  85 ++-
 include/linux/stmmac.h|   2 +
 11 files changed, 616 insertions(+), 355 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml

-- 
2.29.2



[PATCH v2 03/24] dt-bindings: net: dwmac: Fix the TSO property declaration

2021-02-08 Thread Serge Semin
Indeed the STMMAC driver doesn't take the vendor-specific compatible
string into account to parse the "snps,tso" boolean property. It just
makes sure the node is compatible with DW MAC 4.x, 5.x and DW xGMAC
IP-cores. The original allwinner sunXi bindings file also didn't have the
TSO-related property declared. Taking all of that into account fix the
conditional statement so the TSO-property would be evaluated for the
compatibles having the corresponding IP-core version.

While at it move the whole allOf-block from the tail of the binding file
to the head of it, as it's normally done in the most of the DT schemas.

Signed-off-by: Serge Semin 

---

Note this won't break the bindings description, since the "snps,tso"
property isn't parsed by the Allwinner SunX GMAC glue driver, but only
by the generic platform DT-parser.

Changelog v2:
- Use correct syntax of the JSON pointers, so the later would begin
  with a '/' after the '#'.
---
 .../devicetree/bindings/net/snps,dwmac.yaml   | 52 +--
 1 file changed, 24 insertions(+), 28 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index cb68a8dcafd7..03d58bf9965f 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -37,6 +37,30 @@ select:
   required:
 - compatible
 
+allOf:
+  - $ref: "ethernet-controller.yaml#"
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - snps,dwmac-4.00
+  - snps,dwmac-4.10a
+  - snps,dwmac-4.20a
+  - snps,dwmac-5.10a
+  - snps,dwxgmac
+  - snps,dwxgmac-2.10
+
+  required:
+- compatible
+then:
+  properties:
+snps,tso:
+  $ref: /schemas/types.yaml#/definitions/flag
+  description:
+Enables the TSO feature otherwise it will be managed by
+MAC HW capability register.
+
 properties:
 
   # We need to include all the compatibles from schemas that will
@@ -317,34 +341,6 @@ dependencies:
   snps,reset-active-low: ["snps,reset-gpio"]
   snps,reset-delay-us: ["snps,reset-gpio"]
 
-allOf:
-  - $ref: "ethernet-controller.yaml#"
-  - if:
-  properties:
-compatible:
-  contains:
-enum:
-  - allwinner,sun7i-a20-gmac
-  - allwinner,sun8i-a83t-emac
-  - allwinner,sun8i-h3-emac
-  - allwinner,sun8i-r40-emac
-  - allwinner,sun8i-v3s-emac
-  - allwinner,sun50i-a64-emac
-  - snps,dwmac-4.00
-  - snps,dwmac-4.10a
-  - snps,dwmac-4.20a
-  - snps,dwxgmac
-  - snps,dwxgmac-2.10
-  - st,spear600-gmac
-
-then:
-  properties:
-snps,tso:
-  $ref: /schemas/types.yaml#/definitions/flag
-  description:
-Enables the TSO feature otherwise it will be managed by
-MAC HW capability register.
-
 additionalProperties: true
 
 examples:
-- 
2.29.2



[PATCH v2 04/24] dt-bindings: net: dwmac: Refactor snps,*-config properties

2021-02-08 Thread Serge Semin
Currently the "snps,axi-config", "snps,mtl-rx-config" and
"snps,mtl-tx-config" properties are declared as a single phandle reference
to a node with corresponding parameters defined. That's not good for
several reasons. First of all scattering around a device tree some
particular device-specific configs with no visual relation to that device
isn't suitable from maintainability point of view. That leads to a
disturbed representation of the actual device tree mixing actual device
nodes and some vendor-specific configs. Secondly using the same configs
set for several device nodes doesn't represent well the devices structure,
since the interfaces these configs describe in hardware belong to
different devices and may actually differ. In the later case having the
configs node separated from the corresponding device nodes gets to be
even unjustified.

So instead of having a separate DW *MAC configs nodes we suggest to
define them as sub-nodes of the device nodes, which interfaces they
actually describe. By doing so we'll make the DW *MAC nodes visually
correct describing all the aspects of the IP-core configuration. Thus
we'll be able to describe the configs sub-nodes bindings right in the
snps,dwmac.yaml file.

Note the former "snps,axi-config", "snps,mtl-rx-config" and
"snps,mtl-tx-config" properties have been marked as deprecated in favor of
the added by this commit "axi-config", "mtl-rx-config" and "mtl-tx-config"
sub-nodes respectively.

Signed-off-by: Serge Semin 

---

Note this change will work only if DT-schema tool is fixed like this:

--- a/meta-schemas/nodes.yaml   2021-02-08 14:20:56.732447780 +0300
+++ b/meta-schemas/nodes.yaml   2021-02-08 14:21:00.736492245 +0300
@@ -22,6 +22,7 @@
 - unevaluatedProperties
 - deprecated
 - required
+- not
 - allOf
 - anyOf
 - oneOf

So a property with name "not" would be allowed and the "not-required"
pattern would work.

Changelog v2:
- Add the new sub-nodes "axi-config", "mtl-rx-config" and "mtl-tx-config"
  describing the nodes now deprecated properties were supposed to
  refer to.
- Fix invalid identation in the "snps,route-*" property settings.
- Use correct syntax of the JSON pointers, so the later would begin
  with a '/' after the '#'.
---
 .../devicetree/bindings/net/snps,dwmac.yaml   | 389 +-
 1 file changed, 297 insertions(+), 92 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 03d58bf9965f..4dda9ffa822c 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -150,73 +150,264 @@ properties:
   in a different mode than the PHY in order to function.
 
   snps,axi-config:
+deprecated: true
 $ref: /schemas/types.yaml#/definitions/phandle
 description:
-  AXI BUS Mode parameters. Phandle to a node that can contain the
-  following properties
-* snps,lpi_en, enable Low Power Interface
-* snps,xit_frm, unlock on WoL
-* snps,wr_osr_lmt, max write outstanding req. limit
-* snps,rd_osr_lmt, max read outstanding req. limit
-* snps,kbbe, do not cross 1KiB boundary.
-* snps,blen, this is a vector of supported burst length.
-* snps,fb, fixed-burst
-* snps,mb, mixed-burst
-* snps,rb, rebuild INCRx Burst
+  AXI BUS Mode parameters. Phandle to a node that contains the properties
+  described in the 'axi-config' sub-node.
+
+  axi-config:
+type: object
+description: AXI BUS Mode parameters
+
+properties:
+  snps,lpi_en:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Enable Low Power Interface
+
+  snps,xit_frm:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Unlock on WoL
+
+  snps,wr_osr_lmt:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Max write outstanding req. limit
+default: 1
+minimum: 0
+maximum: 15
+
+  snps,rd_osr_lmt:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Max read outstanding req. limit
+default: 1
+minimum: 0
+maximum: 15
+
+  snps,kbbe:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Do not cross 1KiB boundary
+
+  snps,blen:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: A vector of supported burst lengths
+minItems: 7
+maxItems: 7
+items:
+  enum: [256, 128, 64, 32, 16, 8, 4, 0]
+
+  snps,fb:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Fixed-burst
+
+  snps,mb:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Mixed-burst
+
+  snps,

[PATCH v2 01/24] dt-bindings: net: dwmac: Validate PBL for all IP-cores

2021-02-08 Thread Serge Semin
Indeed the maximum DMA burst length can be programmed not only for DW
xGMACs, Allwinner EMACs and Spear SoC GMAC, but in accordance with [1]
for Generic DW *MAC IP-cores. Moreover the STMMAC set of drivers parse
the property and then apply the configuration for all supported DW MAC
devices. All of that makes the property being available for all IP-cores
the bindings supports. Let's make sure the PBL-related properties are
validated for all of them by the common DW MAC DT schema.

[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 380.

Signed-off-by: Serge Semin 
Reviewed-by: Rob Herring 

---

Changelog v2:
- Use correct syntax of the JSON pointers, so the later would begin
  with a '/' after the '#'.
---
 .../devicetree/bindings/net/snps,dwmac.yaml   | 69 +++
 1 file changed, 26 insertions(+), 43 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 0642b0f59491..40a002770441 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -265,6 +265,32 @@ properties:
   is supported. For example, this is used in case of SGMII and
   MAC2MAC connection.
 
+  snps,pbl:
+description:
+  Programmable Burst Length (tx and rx)
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [2, 4, 8]
+
+  snps,txpbl:
+description:
+  Tx Programmable Burst Length. If set, DMA tx will use this
+  value rather than snps,pbl.
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [2, 4, 8]
+
+  snps,rxpbl:
+description:
+  Rx Programmable Burst Length. If set, DMA rx will use this
+  value rather than snps,pbl.
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [2, 4, 8]
+
+  snps,no-pbl-x8:
+$ref: /schemas/types.yaml#/definitions/flag
+description:
+  Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core
+  rev < 3.50, don\'t multiply the values by 4.
+
   mdio:
 type: object
 description:
@@ -290,49 +316,6 @@ dependencies:
 
 allOf:
   - $ref: "ethernet-controller.yaml#"
-  - if:
-  properties:
-compatible:
-  contains:
-enum:
-  - allwinner,sun7i-a20-gmac
-  - allwinner,sun8i-a83t-emac
-  - allwinner,sun8i-h3-emac
-  - allwinner,sun8i-r40-emac
-  - allwinner,sun8i-v3s-emac
-  - allwinner,sun50i-a64-emac
-  - snps,dwxgmac
-  - snps,dwxgmac-2.10
-  - st,spear600-gmac
-
-then:
-  properties:
-snps,pbl:
-  description:
-Programmable Burst Length (tx and rx)
-  $ref: /schemas/types.yaml#/definitions/uint32
-  enum: [2, 4, 8]
-
-snps,txpbl:
-  description:
-Tx Programmable Burst Length. If set, DMA tx will use this
-value rather than snps,pbl.
-  $ref: /schemas/types.yaml#/definitions/uint32
-  enum: [2, 4, 8]
-
-snps,rxpbl:
-  description:
-Rx Programmable Burst Length. If set, DMA rx will use this
-value rather than snps,pbl.
-  $ref: /schemas/types.yaml#/definitions/uint32
-  enum: [2, 4, 8]
-
-snps,no-pbl-x8:
-  $ref: /schemas/types.yaml#/definitions/flag
-  description:
-Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core
-rev < 3.50, don\'t multiply the values by 4.
-
   - if:
   properties:
 compatible:
-- 
2.29.2



[PATCH v2 02/24] dt-bindings: net: dwmac: Extend number of PBL values

2021-02-08 Thread Serge Semin
In accordance with [1] the permitted PBL values can be set as one of [1,
2, 4, 8, 16, 32]. The rest of the values result in undefined behavior. At
the same time some of the permitted values can be also invalid depending
on the controller FIFOs size and the data bus width. Due to having too
many variables all the possible PBL property constraints can't be
implemented in the bindings schema, let's extend the set of permitted PBL
values to be as much as the configuration register supports leaving the
undefined behaviour cases for developers to handle.

[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 380.

Signed-off-by: Serge Semin 
Reviewed-by: Rob Herring 

Changelog v2:
- Use correct syntax of the JSON pointers, so the later would begin
  with a '/' after the '#'.
---
 Documentation/devicetree/bindings/net/snps,dwmac.yaml | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 40a002770441..cb68a8dcafd7 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -267,23 +267,26 @@ properties:
 
   snps,pbl:
 description:
-  Programmable Burst Length (tx and rx)
+  Programmable Burst Length (tx and rx). Note some of these values
+  can be still invalid due to HW limitations connected with the data
+  bus width and the FIFOs depth, so a total length of a single DMA
+  burst shouldn't exceed half the FIFO depth.
 $ref: /schemas/types.yaml#/definitions/uint32
-enum: [2, 4, 8]
+enum: [1, 2, 4, 8, 16, 32]
 
   snps,txpbl:
 description:
   Tx Programmable Burst Length. If set, DMA tx will use this
   value rather than snps,pbl.
 $ref: /schemas/types.yaml#/definitions/uint32
-enum: [2, 4, 8]
+enum: [1, 2, 4, 8, 16, 32]
 
   snps,rxpbl:
 description:
   Rx Programmable Burst Length. If set, DMA rx will use this
   value rather than snps,pbl.
 $ref: /schemas/types.yaml#/definitions/uint32
-enum: [2, 4, 8]
+enum: [1, 2, 4, 8, 16, 32]
 
   snps,no-pbl-x8:
 $ref: /schemas/types.yaml#/definitions/flag
-- 
2.29.2



[PATCH v5 07/10] arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name

2021-02-08 Thread Serge Semin
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
Reviewed-by: Patrice Chotard 
---
 arch/arm/boot/dts/stih407-family.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index 23a1746f3baa..2352f76b5a69 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -681,7 +681,7 @@ st_dwc3: dwc3@8f94000 {
 
status = "disabled";
 
-   dwc3: dwc3@990 {
+   dwc3: usb@990 {
compatible  = "snps,dwc3";
reg = <0x0990 0x10>;
interrupts  = ;
-- 
2.29.2



[PATCH v5 10/10] arm64: dts: qcom: Harmonize DWC USB3 DT nodes name

2021-02-08 Thread Serge Semin
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
Reviewed-by: Bjorn Andersson 
---
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++--
 arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++--
 arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +-
 arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
 9 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index defcbd15edf9..34e97da98270 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -1064,7 +1064,7 @@  {
status = "okay";
extcon = <_id>;
 
-   dwc3@760 {
+   usb@760 {
extcon = <_id>;
dr_mode = "otg";
maximum-speed = "high-speed";
@@ -1075,7 +1075,7 @@  {
status = "okay";
extcon = <_id>;
 
-   dwc3@6a0 {
+   usb@6a0 {
extcon = <_id>;
dr_mode = "otg";
};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi 
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index a32e5e79ab0b..7df4eb710aae 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -427,7 +427,7 @@ usb_0: usb@8af8800 {
resets = < GCC_USB0_BCR>;
status = "disabled";
 
-   dwc_0: dwc3@8a0 {
+   dwc_0: usb@8a0 {
compatible = "snps,dwc3";
reg = <0x8a0 0xcd00>;
interrupts = ;
@@ -468,7 +468,7 @@ usb_1: usb@8cf8800 {
resets = < GCC_USB1_BCR>;
status = "disabled";
 
-   dwc_1: dwc3@8c0 {
+   dwc_1: usb@8c0 {
compatible = "snps,dwc3";
reg = <0x8c0 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 7eef07e73e25..374bb7b557e4 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -1768,7 +1768,7 @@ usb3: usb@6af8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
 
-   dwc3@6a0 {
+   usb@6a0 {
compatible = "snps,dwc3";
reg = <0x06a0 0xcc00>;
interrupts = <0 131 IRQ_TYPE_LEVEL_HIGH>;
@@ -1979,7 +1979,7 @@ usb2: usb@76f8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
 
-   dwc3@760 {
+   usb@760 {
compatible = "snps,dwc3";
reg = <0x0760 0xcc00>;
interrupts = <0 138 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index ebdaaf1dfca4..1a7fb9d3ccab 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -1678,7 +1678,7 @@ usb3: usb@a8f8800 {
 
resets = < GCC_USB_30_BCR>;
 
-   usb3_dwc3: dwc3@a80 {
+   usb3_dwc3: usb@a80 {
compatible = "snps,dwc3";
reg = <0x0a80 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi 
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index a80c578484ba..f8a55307b855 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -337,7 +337,7 @@ _phy_sec {
  {
status = "okay";
 
-   dwc3@758 {
+   usb@758 {
dr_mode = "host";
};
 };
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi 
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
inde

[PATCH v5 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names

2021-02-08 Thread Serge Semin
In accordance with the USB HCD/DRD schema all the USB controllers are
supposed to have DT-nodes named with prefix "^usb(@.*)?".  Since the
existing DT-nodes will be renamed in a subsequent patch let's first make
sure the DWC3 Qualcomm driver supports them and second falls back to the
deprecated naming so not to fail on the legacy DTS-files passed to the
newer kernels.

Signed-off-by: Serge Semin 
Reviewed-by: Bjorn Andersson 
---
 drivers/usb/dwc3/dwc3-qcom.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index c703d552bbcf..49ad8d507d37 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct 
platform_device *pdev)
struct device   *dev = >dev;
int ret;
 
-   dwc3_np = of_get_child_by_name(np, "dwc3");
+   dwc3_np = of_get_child_by_name(np, "usb") ?:
+ of_get_child_by_name(np, "dwc3");
if (!dwc3_np) {
dev_err(dev, "failed to find dwc3 core child\n");
return -ENODEV;
-- 
2.29.2



[PATCH v5 08/10] arm64: dts: apm: Harmonize DWC USB3 DT nodes name

2021-02-08 Thread Serge Semin
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named despite of the warning comment about possible backward
compatibility issues.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++--
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index a83c82c50e29..832dd85b00bd 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -597,8 +597,8 @@ serial0: serial@1060 {
interrupts = <0x0 0x4c 0x4>;
};
 
-   /* Do not change dwusb name, coded for backward compatibility */
-   usb0: dwusb@1900 {
+   /* Node-name might need to be coded as dwusb for backward 
compatibility */
+   usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg =  <0x0 0x1900 0x0 0x10>;
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 0f37e77f5459..1520a945b7f9 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -923,8 +923,8 @@ sata3: sata@1a80 {
phy-names = "sata-phy";
};
 
-   /* Do not change dwusb name, coded for backward compatibility */
-   usb0: dwusb@1900 {
+   /* Node-name might need to be coded as dwusb for backward 
compatibility */
+   usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg =  <0x0 0x1900 0x0 0x10>;
@@ -933,7 +933,7 @@ usb0: dwusb@1900 {
dr_mode = "host";
};
 
-   usb1: dwusb@1980 {
+   usb1: usb@1980 {
status = "disabled";
compatible = "snps,dwc3";
reg =  <0x0 0x1980 0x0 0x10>;
-- 
2.29.2



[PATCH v5 06/10] arm: dts: keystone: Harmonize DWC USB3 DT nodes name

2021-02-08 Thread Serge Semin
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/keystone-k2e.dtsi | 4 ++--
 arch/arm/boot/dts/keystone.dtsi | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi 
b/arch/arm/boot/dts/keystone-k2e.dtsi
index fa1b8499c5a7..b8f152e7af7f 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -52,7 +52,7 @@  {
 
usb: usb@268 {
interrupts = ;
-   dwc3@269 {
+   usb@269 {
interrupts = ;
};
};
@@ -78,7 +78,7 @@ keystone_usb1: usb@2500 {
dma-ranges;
status = "disabled";
 
-   usb1: dwc3@2501 {
+   usb1: usb@2501 {
compatible = "snps,dwc3";
reg = <0x2501 0x7>;
interrupts = ;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 8d046a1b690c..fc9fdc857ae8 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -217,7 +217,7 @@ keystone_usb0: usb@268 {
dma-ranges;
status = "disabled";
 
-   usb0: dwc3@269 {
+   usb0: usb@269 {
compatible = "snps,dwc3";
reg = <0x269 0x7>;
interrupts = ;
-- 
2.29.2



[PATCH v5 05/10] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name

2021-02-08 Thread Serge Semin
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
---
 arch/powerpc/boot/dts/akebono.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/boot/dts/akebono.dts 
b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@301 {
interrupts = <93 2>;
};
 
-   EHCI0: ehci@3001000 {
+   EHCI0: usb@3001000 {
compatible = "ibm,476gtr-ehci", "generic-ehci";
reg = <0x300 0x1000 0x0 0x1>;
interrupt-parent = <>;
@@ -140,14 +140,14 @@ SD0: sd@300 {
interrupt-parent = <>;
};
 
-   OHCI0: ohci@3001001 {
+   OHCI0: usb@3001001 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1001 0x0 0x1>;
interrupt-parent = <>;
interrupts = <89 1>;
};
 
-   OHCI1: ohci@3001002 {
+   OHCI1: usb@3001002 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1002 0x0 0x1>;
interrupt-parent = <>;
-- 
2.29.2



[PATCH v5 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name

2021-02-08 Thread Serge Semin
atrice Chotard 
Cc: Maxime Ripard 
Cc: Khuong Dinh 
Cc: Andy Gross 
Cc: Alexey Brodkin 
Cc: Hauke Mehrtens 
Cc: Maxime Coquelin 
Cc: Alexandre Torgue 
Cc: Amelie Delaunay 
Cc: Vladimir Zapolskiy 
Cc: Paul Cercueil 
Cc: Matthias Brugger 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Sebastian Hesselbarth 
Cc: Kukjin Kim 
Cc: Li Yang 
Cc: Tony Lindgren 
Cc: Chen-Yu Tsai 
Cc: Bjorn Andersson 
Cc: Jun Li 
Cc: linux-snps-...@lists.infradead.org
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Serge Semin (10):
  arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
  arm: dts: keystone: Correct DWC USB3 compatible string
  arc: dts: Harmonize EHCI/OHCI DT nodes name
  arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
  powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
  arm: dts: keystone: Harmonize DWC USB3 DT nodes name
  arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name
  arm64: dts: apm: Harmonize DWC USB3 DT nodes name
  usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
  arm64: dts: qcom: Harmonize DWC USB3 DT nodes name

 arch/arc/boot/dts/axc003.dtsi| 4 ++--
 arch/arc/boot/dts/axc003_idu.dtsi| 4 ++--
 arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++--
 arch/arc/boot/dts/hsdk.dts   | 4 ++--
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +-
 arch/arm/boot/dts/keystone-k2e.dtsi  | 6 +++---
 arch/arm/boot/dts/keystone.dtsi  | 4 ++--
 arch/arm/boot/dts/lpc18xx.dtsi   | 4 ++--
 arch/arm/boot/dts/ls1021a.dtsi   | 2 +-
 arch/arm/boot/dts/stih407-family.dtsi| 2 +-
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi   | 4 ++--
 arch/arm64/boot/dts/apm/apm-storm.dtsi   | 6 +++---
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++--
 arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++--
 arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +-
 arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
 arch/powerpc/boot/dts/akebono.dts| 6 +++---
 drivers/usb/dwc3/dwc3-qcom.c | 3 ++-
 23 files changed, 42 insertions(+), 41 deletions(-)

-- 
2.29.2



[PATCH v5 04/10] arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name

2021-02-08 Thread Serge Semin
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.

Signed-off-by: Serge Semin 
Acked-by: Vladimir Zapolskiy 
Acked-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/lpc18xx.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 10b8249b8ab6..82ffd7b0ad8a 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -121,7 +121,7 @@ mmcsd: mmcsd@40004000 {
status = "disabled";
};
 
-   usb0: ehci@40006100 {
+   usb0: usb@40006100 {
compatible = "nxp,lpc1850-ehci", "generic-ehci";
reg = <0x40006100 0x100>;
interrupts = <8>;
@@ -133,7 +133,7 @@ usb0: ehci@40006100 {
status = "disabled";
};
 
-   usb1: ehci@40007100 {
+   usb1: usb@40007100 {
compatible = "nxp,lpc1850-ehci", "generic-ehci";
reg = <0x40007100 0x100>;
interrupts = <9>;
-- 
2.29.2



[PATCH v5 02/10] arm: dts: keystone: Correct DWC USB3 compatible string

2021-02-08 Thread Serge Semin
Syonpsys IP cores are supposed to be defined with "snps" vendor-prefix.
Use it instead of the deprecated "synopsys" one.

Signed-off-by: Serge Semin 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/keystone-k2e.dtsi | 2 +-
 arch/arm/boot/dts/keystone.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi 
b/arch/arm/boot/dts/keystone-k2e.dtsi
index 2d94faf31fab..fa1b8499c5a7 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -79,7 +79,7 @@ keystone_usb1: usb@2500 {
status = "disabled";
 
usb1: dwc3@2501 {
-   compatible = "synopsys,dwc3";
+   compatible = "snps,dwc3";
reg = <0x2501 0x7>;
interrupts = ;
usb-phy = <_phy>, <_phy>;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index c298675a29a5..8d046a1b690c 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -218,7 +218,7 @@ keystone_usb0: usb@268 {
status = "disabled";
 
usb0: dwc3@269 {
-   compatible = "synopsys,dwc3";
+   compatible = "snps,dwc3";
reg = <0x269 0x7>;
interrupts = ;
usb-phy = <_phy>, <_phy>;
-- 
2.29.2



[PATCH v5 03/10] arc: dts: Harmonize EHCI/OHCI DT nodes name

2021-02-08 Thread Serge Semin
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.

Signed-off-by: Serge Semin 
Acked-by: Alexey Brodkin 
Acked-by: Krzysztof Kozlowski 
---
 arch/arc/boot/dts/axc003.dtsi| 4 ++--
 arch/arc/boot/dts/axc003_idu.dtsi| 4 ++--
 arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++--
 arch/arc/boot/dts/hsdk.dts   | 4 ++--
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index cd1edcf4f95e..3434c8131ecd 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -103,11 +103,11 @@ ethernet@18000 {
dma-coherent;
};
 
-   ehci@4 {
+   usb@4 {
dma-coherent;
};
 
-   ohci@6 {
+   usb@6 {
dma-coherent;
};
 
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi 
b/arch/arc/boot/dts/axc003_idu.dtsi
index 70779386ca79..67556f4b7057 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -110,11 +110,11 @@ ethernet@18000 {
dma-coherent;
};
 
-   ehci@4 {
+   usb@4 {
dma-coherent;
};
 
-   ohci@6 {
+   usb@6 {
dma-coherent;
};
 
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 99d3e7175bf7..b64435385304 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -87,13 +87,13 @@ gmac: ethernet@18000 {
mac-address = [00 00 00 00 00 00]; /* Filled in by 
U-Boot */
};
 
-   ehci@4 {
+   usb@4 {
compatible = "generic-ehci";
reg = < 0x4 0x100 >;
interrupts = < 8 >;
};
 
-   ohci@6 {
+   usb@6 {
compatible = "generic-ohci";
reg = < 0x6 0x100 >;
interrupts = < 8 >;
diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
index dcaa44e408ac..fdd4f7f635d3 100644
--- a/arch/arc/boot/dts/hsdk.dts
+++ b/arch/arc/boot/dts/hsdk.dts
@@ -234,7 +234,7 @@ phy0: ethernet-phy@0 { /* Micrel KSZ9031 */
};
};
 
-   ohci@6 {
+   usb@6 {
compatible = "snps,hsdk-v1.0-ohci", "generic-ohci";
reg = <0x6 0x100>;
interrupts = <15>;
@@ -242,7 +242,7 @@ ohci@6 {
dma-coherent;
};
 
-   ehci@4 {
+   usb@4 {
compatible = "snps,hsdk-v1.0-ehci", "generic-ehci";
reg = <0x4 0x100>;
interrupts = <15>;
diff --git a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi 
b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
index cbb179770293..90a412026e64 100644
--- a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
@@ -46,7 +46,7 @@ ethernet@18000 {
clock-names = "stmmaceth";
};
 
-   ehci@4 {
+   usb@4 {
compatible = "generic-ehci";
reg = < 0x4 0x100 >;
interrupts = < 8 >;
-- 
2.29.2



[PATCH v5 01/10] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name

2021-02-08 Thread Serge Semin
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
Cc: Shawn Guo 

---

Changelog v5:
- Get back the patch to the series as it has been missing in the kernel
  5.11-rc7.
---
 arch/arm/boot/dts/ls1021a.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 007dd2bd0595..85462f234fc7 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -871,7 +871,7 @@ usb2: usb@860 {
phy_type = "ulpi";
};
 
-   usb3: usb3@310 {
+   usb3: usb@310 {
compatible = "snps,dwc3";
reg = <0x0 0x310 0x0 0x1>;
interrupts = ;
-- 
2.29.2



[PATCH] Revert "mips: Manually call fdt_init_reserved_mem() method"

2021-02-08 Thread Serge Semin
This reverts commit 3751cbda8f223549d7ea28803cbec8ac87e43ed2.

Originally the patch was created to fix the reserved-memory DT-node
parsing failure on the early stages of the platform memory initialization.
That happened due to the two early memory allocators utilization that
time: bootmem and memblock. At first the platform-specific memory mapping
array was initialized. Then the early_init_fdt_scan_reserved_mem() was
called, which couldn't fully parse the "reserved-memory" DT-node since
neither memblock nor bootmem allocators hadn't been initialized at that
stage, so the fdt_init_reserved_mem() method failed on the memory
allocation calls. Only after that the platform-specific memory mapping
were used to create proper bootmem and memblock structures and let the
early memory allocations work.  That's why we had to call the
fdt_init_reserved_mem() method one more time to retry the initialization
of the features like CMA.

The necessity to have that fix was disappeared after the full memblock
support had been added to the MIPS kernel and all plat_mem_setup() had
been fixed to add the memory regions right into the memblock memory pool.
Let's revert that patch then especially after having Paul reported that
the second fdt_init_reserved_mem() call causes the reserved memory pool
being created twice bigger than implied.

Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map")
Reported-by: Paul Cercueil 
Signed-off-by: Serge Semin 
---
 arch/mips/kernel/setup.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 101812960ca0..a60ecd6db0c3 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -686,8 +685,6 @@ static void __init arch_mem_init(char **cmdline_p)
memblock_reserve(__pa_symbol(&__nosave_begin),
__pa_symbol(&__nosave_end) - __pa_symbol(&__nosave_begin));
 
-   fdt_init_reserved_mem();
-
early_memtest(PFN_PHYS(ARCH_PFN_OFFSET), PFN_PHYS(max_low_pfn));
 }
 
-- 
2.29.2



Re: [PATCH] bus: bt1-apb:Fix duplicate included linux/clk.h

2021-02-08 Thread Serge Semin
On Sun, Feb 07, 2021 at 10:20:50PM +0800, alex_l...@163.com wrote:
> From: Zhang Kun 
> 
> Remove one of the duplicate header hlinux/clk.h which isn't necessary.

Thanks!
Acked-by: Serge Semin 

Arnd, could you merge it in?

-Sergey

> 
> Signed-off-by: Zhang Kun 
> ---
>  drivers/bus/bt1-apb.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/bus/bt1-apb.c b/drivers/bus/bt1-apb.c
> index b25ff941e7c7..e9e196cd9253 100644
> --- a/drivers/bus/bt1-apb.c
> +++ b/drivers/bus/bt1-apb.c
> @@ -19,7 +19,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.17.1
> 
> 


Re: [PATCH v3 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names

2021-02-03 Thread Serge Semin
On Wed, Feb 03, 2021 at 10:06:46AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 02, 2021 at 05:02:08PM -0600, Bjorn Andersson wrote:
> > On Sat 05 Dec 09:56 CST 2020, Serge Semin wrote:
> > 
> > > In accordance with the USB HCD/DRD schema all the USB controllers are
> > > supposed to have DT-nodes named with prefix "^usb(@.*)?".  Since the
> > > existing DT-nodes will be renamed in a subsequent patch let's first make
> > > sure the DWC3 Qualcomm driver supports them and second falls back to the
> > > deprecated naming so not to fail on the legacy DTS-files passed to the
> > > newer kernels.
> > > 
> > 
> > Felipe, will you merge this, so that I can merge the dts patch depending
> > on this into the Qualcomm DT tree?
> 
> Patches this old are long-gone out of our queues.  If it needs to be
> applied to a linux-usb tree, please resend.

Hello Greg,
I'll revise the series and resend the patches, which haven't been
merged in yet, on this week. Sorry for a delay. I should have done
that earlier, but I have been kind of drown with fixes for DW GMAC
(stmmac) driver, so couldn't pay much attention to the rest of the
work.

-Sergey

> 
> thanks,
> 
> greg k-h


Re: [PATCH v1] gpio: dwapb: mask/unmask IRQ when disable/enable it

2021-01-07 Thread Serge Semin
Hello folks,
My comments are below.

On Wed, Jan 06, 2021 at 01:44:28PM +0200, Andy Shevchenko wrote:
> On Wednesday, January 6, 2021, Bartosz Golaszewski <
> bgolaszew...@baylibre.com> wrote:
> 
> > On Mon, Dec 7, 2020 at 2:10 PM luojiaxing  wrote:
> > >
> > >
> > > On 2020/12/7 2:50, Marc Zyngier wrote:
> > > > On 2020-12-06 15:02, Linus Walleij wrote:
> > > >> On Sat, Dec 5, 2020 at 11:15 PM Serge Semin 
> > > >> wrote:
> > > >>

> > > >>> Hmm, that sounds like a problem, but the explanation is a bit unclear
> > > >>> to me. AFAICS you are saying that the only callbacks which are
> > > >>> called during the IRQ request/release are the irq_enable(), right? If
> > > >>> so then the only reason why we haven't got a problem reported due to
> > > >>> that so far is that the IRQs actually unmasked by default.

As I said the problem explanation stated in the log is a bit unclear
to me.  It needs elaboration at the very least in v2 with more details
why masking and masking needs to be performed in the IRQ
disable/enable callback. But AFAICS from the code invocation stack and
the Luo further messages the problem with having both mask/unmask and
disable/enable IRQ-chip functionality may indeed exist.

Judging by the irq_enable() and irq_disable() functions code both of them
use only one pair of the IRQ switchers with giving more favor to the
IRQ disable/enable methods. So if the later are specified for an IRQ
chip, then the IRQ mask/unmask functions just won't be called. (Though
I might be wrong in this matter. Marc, please correct me if I am.) In our
case if for some reason any of the GPIO lane IRQ has been masked for
instance by a bootloader or the default state has been changed on
IP-core level, then the corresponding IRQ just won't be activated by
the kernel IRQs subsystem. In case of my DW APB core and most likely in
the most of the cases all the IRQs are unmasked, but disabled by default.
That's why we haven't got any report about the problem until now.

> > > >>

> > > >> What we usually do in cases like that (and I have discussed this
> > > >> with tglx in the past I think) is to simply mask off all IRQs in
> > > >> probe().
> > > >> Then they will be unmasked when requested by drivers.
> > > >>
> > > >> See e.g. gpio-pl061 that has this line in probe():
> > > >> writeb(0, pl061->base + GPIOIE); /* disable irqs */
> > > >
> > > > This should definitely be the default behaviour. The code code
> > > > expects all interrupt sources to be masked until actively enabled,
> > > > usually with the IRQ being requested.

What DW APB driver has different with respect to the others is that it
provides both IRQ mask/unmask and disable/enable functionality. So
if we get to mask all the IRQs in the probe method, then according to
the irq_enable()/irq_disable() code semantics and as Luo said the
corresponding IRQ won't be unmasked in request_irq(), but will be just
enabled. So effectively the IRQ will be left masked, which of course
we don't want to happen after the successful request_irq() method
return.

As I see it the problem either needs to be worked around in the local
driver (for instance in a way Luo suggests) or fixed in the IRQ subsystem
level.

> > >
> > >

> > > I think this patch is used for that purpose. I do two things in
> > > irq_enable(): unmask irq and then enable IRQ;
> > >
> > > and for irq_disable(), it's similar; mask IRQ then disable it.

Yeah, this patch provides a work around for the problem. So the
chip->irq_enable() callback enables and unmasks the corresponding
GPIO IRQ, while chip->irq_disable() masks and disables it. In this
case the irq_mask()/irq_unmask() methods just get to be redundant
since won't be used by the core anyway.

But before accepting the solution in my opinion it would be better to
at least discuss whether it is possible to fix the
irq_enable()/irq_disable() methods so the similar problem wouldn't
happen for the hardware like DW APB.

Marc, Linus, Andy, Bartosz, Luo what do you think? Wouldn't that be
better to fix the IRQ subsystem code instead seeing it doesn't cover
all the possible hardware like with both types of IRQ enable/mask
callback provided?

> >
> > Hi!
> >
> > Could you please resend this patch rebased on top of v5.11-rc2 and
> > with the detailed explanation you responded with to Andy as part of
> > the commit message?
> >
> >

> I guess it’s more than that. What’s the driver maintainer position here?

Andy, thanks for sending a notification about this patch. Please see my
comments above.

-Sergey

> 
> 
> 
> > Thanks!
> > Bart
> >
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko


Re: [PATCH 5.10 134/717] spi: dw: fix build error by selecting MULTIPLEXER

2020-12-31 Thread Serge Semin
On Thu, Dec 31, 2020 at 09:51:21AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Dec 31, 2020 at 11:49:56AM +0300, Serge Semin wrote:
> > Hello Greg,
> > The next patch has been created to supersede the one you've applied:
> > https://lore.kernel.org/linux-spi/20201127144612.4204-1-sergey.se...@baikalelectronics.ru/
> > Mark has already merged it in his repo.
> 

> Ok, so should that one be queued up as well?  Let us know the git commit
> id of it when it reaches Linus's kernel and we will be glad to take it.

I believe it is already there:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7218838109fef61cdec988ff728e902d434c9cc5
Yeah, it's better to queue that patch up too, otherwise the build
error will be indeed fixed by the commit you've merged in, but the
probe procedure will still always fail.

-Sergey

> 
> thanks,
> 
> greg k-h


Re: [PATCH 5.10 134/717] spi: dw: fix build error by selecting MULTIPLEXER

2020-12-31 Thread Serge Semin
Hello Greg,
The next patch has been created to supersede the one you've applied:
https://lore.kernel.org/linux-spi/20201127144612.4204-1-sergey.se...@baikalelectronics.ru/
Mark has already merged it in his repo.

-Sergey

On Mon, Dec 28, 2020 at 01:42:12PM +0100, Greg Kroah-Hartman wrote:
> From: Randy Dunlap 
> 
> [ Upstream commit 1241f0787578136ab58f49adc52f2dcd2bbc4bf2 ]
> 
> Fix build error for spi-dw-bt1.o by selecting MULTIPLEXER.
> 
> hppa-linux-ld: drivers/spi/spi-dw-bt1.o: in function `dw_spi_bt1_sys_init':
> (.text+0x1ac): undefined reference to `devm_mux_control_get'
> 
> Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver")
> Reported-by: kernel test robot 
> Signed-off-by: Randy Dunlap 
> Cc: Serge Semin 
> Cc: Ramil Zaripov 
> Cc: Mark Brown 
> Cc: linux-...@vger.kernel.org
> Acked-by: Serge Semin 
> Link: https://lore.kernel.org/r/20201116040721.8001-1-rdun...@infradead.org
> Signed-off-by: Mark Brown 
> Signed-off-by: Sasha Levin 
> ---
>  drivers/spi/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 5cff60de8e834..3fd16b7f61507 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -255,6 +255,7 @@ config SPI_DW_MMIO
>  config SPI_DW_BT1
>   tristate "Baikal-T1 SPI driver for DW SPI core"
>   depends on MIPS_BAIKAL_T1 || COMPILE_TEST
> + select MULTIPLEXER
>   help
> Baikal-T1 SoC is equipped with three DW APB SSI-based MMIO SPI
> controllers. Two of them are pretty much normal: with IRQ, DMA,
> -- 
> 2.27.0
> 
> 
> 


Re: [PATCH 07/25] dt-bindings: net: dwmac: Detach Generic DW MAC bindings

2020-12-16 Thread Serge Semin
On Tue, Dec 15, 2020 at 11:50:02AM -0600, Rob Herring wrote:
> On Mon, Dec 14, 2020 at 12:15:57PM +0300, Serge Semin wrote:
> > Currently the snps,dwmac.yaml DT bindings file is used for both DT nodes
> > describing generic DW MAC devices and as DT schema with common properties
> > to be evaluated against a vendor-specific DW MAC IP-cores. Due to such
> > dual-purpose design the "compatible" property of the common DW MAC schema
> > needs to contain the vendor-specific strings to successfully pass the
> > schema evaluation in case if it's referenced from the vendor-specific DT
> > bindings. That's a bad design from maintainability point of view, since
> > adding/removing any DW MAC-based device bindings requires the common
> > schema modification. In order to fix that let's detach the schema which
> > provides the generic DW MAC DT nodes evaluation into a dedicated DT
> > bindings file preserving the common DW MAC properties declaration in the
> > snps,dwmac.yaml file. By doing so we'll still provide a common properties
> > evaluation for each vendor-specific MAC bindings which refer to the
> > common bindings file, while the generic DW MAC DT nodes will be checked
> > against the new snps,dwmac-generic.yaml DT schema.
> 

> I'm okay with the change, but it needs a big fat note that 
> snps,dwmac-generic.yaml should not have new users. New users should have 
> an SoC specific compatible. History has shown that even IP versions are 
> not enough to handle all the integration crap vendors do.

Agreed. I'll add such note to the "description" text of the
snps,dwmac-generic.yaml schema. Is that ok?

-Sergey

> 
> > 
> > Signed-off-by: Serge Semin 
> > ---
> >  .../bindings/net/snps,dwmac-generic.yaml  | 148 ++
> >  .../devicetree/bindings/net/snps,dwmac.yaml   | 139 +---
> >  2 files changed, 149 insertions(+), 138 deletions(-)
> >  create mode 100644 
> > Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml 
> > b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
> > new file mode 100644
> > index ..f1b387911390
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
> > @@ -0,0 +1,148 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/snps,dwmac-generic.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Synopsys DesignWare Generic MAC Device Tree Bindings
> > +
> > +maintainers:
> > +  - Alexandre Torgue 
> > +  - Giuseppe Cavallaro 
> > +  - Jose Abreu 
> > +
> > +# Select the DT nodes, which have got compatible strings either as just a
> > +# single string with IP-core name optionally followed by the IP version or
> > +# two strings: one with IP-core name plus the IP version, another as just
> > +# the IP-core name.
> > +select:
> > +  properties:
> > +compatible:
> > +  oneOf:
> > +- items:
> > +- pattern: "^snps,dw(xg)+mac(-[0-9]+\\.[0-9]+a?)?$"
> > +- items:
> > +- pattern: "^snps,dwmac-[0-9]+\\.[0-9]+a?$"
> > +- const: snps,dwmac
> > +- items:
> > +- pattern: "^snps,dwxgmac-[0-9]+\\.[0-9]+a?$"
> > +- const: snps,dwxgmac
> > +
> > +  required:
> > +- compatible
> > +
> > +allOf:
> > +  - $ref: snps,dwmac.yaml#
> > +
> > +properties:
> > +  compatible:
> > +oneOf:
> > +  - description: Generic Synopsys DW MAC
> > +oneOf:
> > +  - items:
> > +  - enum:
> > +  - snps,dwmac-3.50a
> > +  - snps,dwmac-3.610
> > +  - snps,dwmac-3.70a
> > +  - snps,dwmac-3.710
> > +  - snps,dwmac-4.00
> > +  - snps,dwmac-4.10a
> > +  - snps,dwmac-4.20a
> > +  - const: snps,dwmac
> > +  - const: snps,dwmac
> > +  - description: Generic Synopsys DW xGMAC
> > +oneOf:
> > +  - items:
> > +  - enum:
> > +  - snps,dwxgmac-2.10
> > +  - const: snps,dwxgmac
> > +  - const: snps,dwxgmac
> > +  - description: ST SPEAr SoC Family GMAC
> > +deprecated: true
> > +const: st,spear600-gmac
> > +
&g

Re: [PATCH 03/25] dt-bindings: net: dwmac: Fix the TSO property declaration

2020-12-16 Thread Serge Semin
On Tue, Dec 15, 2020 at 11:22:40AM -0600, Rob Herring wrote:
> On Mon, Dec 14, 2020 at 12:15:53PM +0300, Serge Semin wrote:
> > Indeed the STMMAC driver doesn't take the vendor-specific compatible
> > string into account to parse the "snps,tso" boolean property. It just
> > makes sure the node is compatible with DW MAC 4.x, 5.x and DW xGMAC
> > IP-cores. Fix the conditional statement so the TSO-property would be
> > evaluated for the compatibles having the corresponding IP-core version.
> > 
> > While at it move the whole allOf-block from the tail of the binding file
> > to the head of it, as it's normally done in the most of the DT schemas.
> > 
> > Signed-off-by: Serge Semin 
> > 
> > ---
> > 
> > Note this won't break the bindings description, since the "snps,tso"
> > property isn't parsed by the Allwinner SunX GMAC glue driver, but only
> > by the generic platform DT-parser.
> 

> But still should be valid for Allwinner?

I don't know. It seems to me that even the original driver developer
didn't know what DW MAC IP has been used to create the Allwinner
EMAC, since in the cover letter to the original patch he said:
"During the development, it appeared that in fact the hardware was
a modified version of some dwmac." (See https://lwn.net/Articles/721459/)
Most likely Maxime Ripard also didn't know that when he was converting
the legacy bindings to the DT schema.

What I do know the TSO is supported by the driver only for IP-cores with
version higher than 4.00. (See the stmmac_probe_config_dt() method
implementation). Version is determined by checking whether the DT
device node compatible property having the "snps,dwmac-*" or
"snps,dwxgmac" strings. Allwinner EMAC nodes aren't defined with
those strings, so they won't have the TSO property parsed and set.

> 
> > ---
> >  .../devicetree/bindings/net/snps,dwmac.yaml   | 52 +--
> >  1 file changed, 24 insertions(+), 28 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
> > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > index e084fbbf976e..0dd543c6c08e 100644
> > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > @@ -37,6 +37,30 @@ select:
> >required:
> >  - compatible
> >  
> > +allOf:
> > +  - $ref: "ethernet-controller.yaml#"
> > +  - if:
> > +  properties:
> > +compatible:
> > +  contains:
> > +enum:
> > +  - snps,dwmac-4.00
> > +  - snps,dwmac-4.10a
> > +  - snps,dwmac-4.20a
> > +  - snps,dwmac-5.10a
> > +  - snps,dwxgmac
> > +  - snps,dwxgmac-2.10
> > +
> > +  required:
> > +- compatible
> > +then:
> > +  properties:
> > +snps,tso:
> > +  $ref: /schemas/types.yaml#definitions/flag
> > +  description:
> > +Enables the TSO feature otherwise it will be managed by
> > +MAC HW capability register.
> 

> BTW, I prefer that properties are defined unconditionally, and then 
> restricted in conditional schemas (or ones that include this schema).

Are you saying that it's ok to have all the properties unconditionally
defined in some generic schema and then being un-defined (like redefined
to a false-schema) in a schema including (allOf-ing) it?

> 
> > +
> >  properties:
> >  
> ># We need to include all the compatibles from schemas that will
> > @@ -314,34 +338,6 @@ dependencies:
> >snps,reset-active-low: ["snps,reset-gpio"]
> >snps,reset-delay-us: ["snps,reset-gpio"]
> >  
> > -allOf:
> > -  - $ref: "ethernet-controller.yaml#"
> > -  - if:
> > -  properties:
> > -compatible:
> > -  contains:
> > -enum:
> > -  - allwinner,sun7i-a20-gmac
> 

> This does not have a fallback, so snps,tso is no longer validated. I 
> didn't check the rest.

Until the DT node is having a compatible string with the DW MAC
IP-core version the property won't be checked by the driver anyway.
AFAICS noone really knows what IP was that. So most likely the
allwinner emacs have been added to this conditional schema by
mistake...

-Sergey

> 
> > -  - allwinner,sun8i-a83t-emac
> > -  - allwinner,sun8i-h3-emac
> > -  - allwinner,sun8i-r40-emac
> > -  - allwinner,sun8i-v3s-emac
> > -  - allwinner,sun5

Re: [PATCH 04/25] dt-bindings: net: dwmac: Refactor snps,*-config properties

2020-12-15 Thread Serge Semin
On Tue, Dec 15, 2020 at 08:08:35AM -0600, Rob Herring wrote:
> On Tue, Dec 15, 2020 at 2:54 AM Serge Semin
>  wrote:
> >
> > Hello Rob,
> >
> > On Mon, Dec 14, 2020 at 08:30:06AM -0600, Rob Herring wrote:
> > > On Mon, Dec 14, 2020 at 12:15:54PM +0300, Serge Semin wrote:
> > > > Currently the "snps,axi-config", "snps,mtl-rx-config" and
> > > > "snps,mtl-tx-config" properties are declared as a single phandle 
> > > > reference
> > > > to a node with corresponding parameters defined. That's not good for
> > > > several reasons. First of all scattering around a device tree some
> > > > particular device-specific configs with no visual relation to that 
> > > > device
> > > > isn't suitable from maintainability point of view. That leads to a
> > > > disturbed representation of the actual device tree mixing actual device
> > > > nodes and some vendor-specific configs. Secondly using the same configs
> > > > set for several device nodes doesn't represent well the devices 
> > > > structure,
> > > > since the interfaces these configs describe in hardware belong to
> > > > different devices and may actually differ. In the later case having the
> > > > configs node separated from the corresponding device nodes gets to be
> > > > even unjustified.
> > > >
> > > > So instead of having a separate DW *MAC configs nodes we suggest to
> > > > define them as sub-nodes of the device nodes, which interfaces they
> > > > actually describe. By doing so we'll make the DW *MAC nodes visually
> > > > correct describing all the aspects of the IP-core configuration. Thus
> > > > we'll be able to describe the configs sub-nodes bindings right in the
> > > > snps,dwmac.yaml file.
> > > >
> > > > Note the former "snps,axi-config", "snps,mtl-rx-config" and
> > > > "snps,mtl-tx-config" bindings have been marked as deprecated.
> > > >
> > > > Signed-off-by: Serge Semin 
> > > >
> > > > ---
> > > >
> > > > Note the current DT schema tool requires the vendor-specific properties 
> > > > to be
> > > > defined in accordance with the schema: 
> > > > dtschema/meta-schemas/vendor-props.yaml
> > > > It means the property can be;
> > > > - boolean,
> > > > - string,
> > > > - defined with $ref and additional constraints,
> > > > - defined with allOf: [ $ref ] and additional constraints.
> > > >
> > > > The modification provided by this commit needs to extend that 
> > > > definition to
> > > > make the DT schema tool correctly parse this schema. That is we need to 
> > > > let
> > > > the vendors-specific properties to also accept the oneOf-based combined
> > > > sub-schema. Like this:
> > > >
> > > > --- a/dtschema/meta-schemas/vendor-props.yaml
> > > > +++ b/dtschema/meta-schemas/vendor-props.yaml
> > > > @@ -48,15 +48,24 @@
> > > >- properties:   # A property with a type and additional 
> > > > constraints
> > > >$ref:
> > > >  pattern: "types.yaml#[\/]{0,1}definitions\/.*"
> > > > -  allOf:
> > > > -items:
> > > > -  - properties:
> > > > +
> > > > +if:
> > > > +  not:
> > > > +required:
> > > > +  - $ref
> > > > +then:
> > > > +  patternProperties:
> > > > +"^(all|one)Of$":
> > > > +  contains:
> > > > +properties:
> > > >$ref:
> > > >  pattern: "types.yaml#[\/]{0,1}definitions\/.*"
> > > >  required:
> > > >- $ref
> > > > -oneOf:
> > > > +
> > > > +anyOf:
> > > >- required: [ $ref ]
> > > >- required: [ allOf ]
> > > > +  - required: [ oneOf ]
> > > >
> > > >  ...
> > > > ---
> > > >  .../devicetree/bindings/net/snps,dwmac.yaml   | 380 +-
> > > >  1 file changed, 288 insertions(+), 92 deletions(-)
> > > >
> > > &g

Re: [PATCH 06/25] dt-bindings: net: dwmac: Add Tx/Rx clock sources

2020-12-15 Thread Serge Semin
On Tue, Dec 15, 2020 at 11:32:04AM -0600, Rob Herring wrote:
> On Mon, Dec 14, 2020 at 12:15:56PM +0300, Serge Semin wrote:
> > Generic DW *MAC can be connected to an external Tramit and Receive clock
> 

> s/Tramit/Transmit/

Thanks. I'll fix it in v2.

-Sergey

> 
> > generators. Add the corresponding clocks description and clock-names to
> > the generic bindings schema so new DW *MAC-based bindings wouldn't declare
> > its own names of the same clocks.
> > 
> > Signed-off-by: Serge Semin 
> > ---
> >  .../devicetree/bindings/net/snps,dwmac.yaml| 14 ++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
> > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > index e1ebe5c8b1da..74820f491346 100644
> > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > @@ -126,6 +126,18 @@ properties:
> >MCI, CSR and SMA interfaces run on this clock. If it's omitted,
> >the CSR interfaces are considered as synchronous to the system
> >clock domain.
> > +  - description:
> > +  GMAC Tx clock or so called Transmit clock. The clock is supplied
> > +  by an external with respect to the DW MAC clock generator.
> > +  The clock source and its frequency depends on the DW MAC xMII 
> > mode.
> > +  In case if it's supplied by PHY/SerDes this property can be
> > +  omitted.
> > +  - description:
> > +  GMAC Rx clock or so called Receive clock. The clock is supplied
> > +  by an external with respect to the DW MAC clock generator.
> > +  The clock source and its frequency depends on the DW MAC xMII 
> > mode.
> > +  In case if it's supplied by PHY/SerDes or it's synchronous to
> > +  the Tx clock this property can be omitted.
> >- description:
> >PTP reference clock. This clock is used for programming the
> >Timestamp Addend Register. If not passed then the system
> > @@ -139,6 +151,8 @@ properties:
> >enum:
> >  - stmmaceth
> >  - pclk
> > +- tx
> > +- rx
> >  - ptp_ref
> >  
> >resets:
> > -- 
> > 2.29.2
> > 


Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

2020-12-15 Thread Serge Semin
On Wed, Dec 16, 2020 at 03:03:55AM +0100, Andrew Lunn wrote:
> > > From what you are saying, it sounds like from software you cannot
> > > independently control the GPIO controller reset?
> > 
> > No. The hardware implements the default MAC reset behavior. So the
> > GPIO controller gets reset synchronously with the MAC reset and that
> > can't be changed.
> 

> Is there pinmux support for these pins?  Can you disconnect them from
> the MAC? Often pins can be connected to different internal IP
> blocks. Maybe you can flip the pin mux, perform the MAC reset, and
> then put the pinmux back to connect the pins to the MAC IP again?

Alas no. Pins multiplexing isn't implemented in the Baikal-T1 SoC at all.
Each pin has been assigned with a single function. In this case DW GMAC
GPO/GPI pins always serve as GPO/GPI and nothing else.

-Sergey

> 
>  Andrew


Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

2020-12-15 Thread Serge Semin
On Tue, Dec 15, 2020 at 02:58:37PM +0100, Andrew Lunn wrote:
> > > > Anyway the hardware setup depicted above doesn't seem
> > > > problematic at the first glance, but in fact it is. See, the DW *MAC 
> > > > driver
> > > > (STMMAC ethernet driver) is doing the MAC reset each time it performs 
> > > > the
> > > > device open or resume by means of the call-chain:
> > > > 
> > > >   stmmac_open()---+
> > > >   
> > > > +->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset().
> > > >   stmmac_resume()-+
> > > > 
> > > > Such reset causes the whole interface reset: MAC, DMA and, what is more
> > > > important, GPIOs as being exposed as part of the MAC registers. That
> > > > in our case automatically causes the external PHY reset, what neither
> > > > the STTMAC driver nor the PHY subsystem expect at all.
> > > 
> > 
> > > Is the reset of the GPIO sub block under software control? When you
> > > have a GPIO controller implemented, you would want to disable this.
> > 
> > Not sure I've fully understood your question. The GPIO sub-block of
> > the MAC is getting reset together with the MAC.
> 

> And my question is, is that under software control, or is the hardware
> synthesised so that the GPIO controller is reset as part of the MAC
> reset?

Alas the SoC has already been synthesized and multiple devices have
already been produced as I described in the initial message. So we can't
change the way the MAC reset works.

> 
> From what you are saying, it sounds like from software you cannot
> independently control the GPIO controller reset?

No. The hardware implements the default MAC reset behavior. So the
GPIO controller gets reset synchronously with the MAC reset and that
can't be changed.

> 
> This is something i would be asking the hardware people. Look at the
> VHDL, etc.

Alas it's too late. I have to fix it in software somehow. As I see it
the only possible ways to bypass the problem are either to re-init the
PHY each time the reset happens or somehow to get rid of the MAC
reset. That's why I have sent this RFC to ask the driver maintainers
whether my suggestions are correct or of a better idea to work around
the problem.

-Sergey

> 
>   Andrew


Re: [PATCH 04/25] dt-bindings: net: dwmac: Refactor snps,*-config properties

2020-12-15 Thread Serge Semin
Hello Rob,

On Mon, Dec 14, 2020 at 08:30:06AM -0600, Rob Herring wrote:
> On Mon, Dec 14, 2020 at 12:15:54PM +0300, Serge Semin wrote:
> > Currently the "snps,axi-config", "snps,mtl-rx-config" and
> > "snps,mtl-tx-config" properties are declared as a single phandle reference
> > to a node with corresponding parameters defined. That's not good for
> > several reasons. First of all scattering around a device tree some
> > particular device-specific configs with no visual relation to that device
> > isn't suitable from maintainability point of view. That leads to a
> > disturbed representation of the actual device tree mixing actual device
> > nodes and some vendor-specific configs. Secondly using the same configs
> > set for several device nodes doesn't represent well the devices structure,
> > since the interfaces these configs describe in hardware belong to
> > different devices and may actually differ. In the later case having the
> > configs node separated from the corresponding device nodes gets to be
> > even unjustified.
> > 
> > So instead of having a separate DW *MAC configs nodes we suggest to
> > define them as sub-nodes of the device nodes, which interfaces they
> > actually describe. By doing so we'll make the DW *MAC nodes visually
> > correct describing all the aspects of the IP-core configuration. Thus
> > we'll be able to describe the configs sub-nodes bindings right in the
> > snps,dwmac.yaml file.
> > 
> > Note the former "snps,axi-config", "snps,mtl-rx-config" and
> > "snps,mtl-tx-config" bindings have been marked as deprecated.
> > 
> > Signed-off-by: Serge Semin 
> > 
> > ---
> > 
> > Note the current DT schema tool requires the vendor-specific properties to 
> > be
> > defined in accordance with the schema: 
> > dtschema/meta-schemas/vendor-props.yaml
> > It means the property can be;
> > - boolean,
> > - string,
> > - defined with $ref and additional constraints,
> > - defined with allOf: [ $ref ] and additional constraints.
> > 
> > The modification provided by this commit needs to extend that definition to
> > make the DT schema tool correctly parse this schema. That is we need to let
> > the vendors-specific properties to also accept the oneOf-based combined
> > sub-schema. Like this:
> > 
> > --- a/dtschema/meta-schemas/vendor-props.yaml
> > +++ b/dtschema/meta-schemas/vendor-props.yaml
> > @@ -48,15 +48,24 @@
> >- properties:   # A property with a type and additional constraints
> >$ref:
> >  pattern: "types.yaml#[\/]{0,1}definitions\/.*"
> > -  allOf:
> > -items:
> > -  - properties:
> > +
> > +if:
> > +  not:
> > +required:
> > +  - $ref
> > +then:
> > +  patternProperties:
> > +"^(all|one)Of$":
> > +  contains:
> > +properties:
> >$ref:
> >  pattern: "types.yaml#[\/]{0,1}definitions\/.*"
> >  required:
> >- $ref
> > -oneOf:
> > +
> > +anyOf:
> >- required: [ $ref ]
> >- required: [ allOf ]
> > +  - required: [ oneOf ]
> > 
> >  ...
> > ---
> >  .../devicetree/bindings/net/snps,dwmac.yaml   | 380 +-
> >  1 file changed, 288 insertions(+), 92 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
> > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > index 0dd543c6c08e..44aa88151cba 100644
> > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > @@ -150,69 +150,251 @@ properties:
> >in a different mode than the PHY in order to function.
> >  
> >snps,axi-config:
> > -$ref: /schemas/types.yaml#definitions/phandle
> > -description:
> > -  AXI BUS Mode parameters. Phandle to a node that can contain the
> > -  following properties
> > -* snps,lpi_en, enable Low Power Interface
> > -* snps,xit_frm, unlock on WoL
> > -* snps,wr_osr_lmt, max write outstanding req. limit
> > -* snps,rd_osr_lmt, max read outstanding req. limit
> > -* snps,kbbe, do not cross 1KiB boundary.
> > -* snps,blen, this is a vector of supported burst length.
>

Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

2020-12-15 Thread Serge Semin
Hello Andrew,

On Mon, Dec 14, 2020 at 04:31:43PM +0100, Andrew Lunn wrote:
> On Mon, Dec 14, 2020 at 12:25:16PM +0300, Serge Semin wrote:
> > Hello folks,
> > 
> > I've got a problem, which has been blowing by head up for more than three
> > weeks now, and I'm desperately need your help in that matter. See our
> > Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core
> > has been synthesized with two GPIOs: one as GPI and another as GPO. There
> > are multiple Baikal-T1-based devices have been created so far with active
> > GMAC interface usage and each of them has been designed like this:
> > 
> >  ++
> >  | Baikal-T1 ++   ++
> >  |   SoC | DW GMAC|   |   Some PHY |
> >  |   |  Rx-clk+<--+Rx-clk  |
> >  |   ||   ||
> >  |   | GPI+<--+#IRQ|
> >  |   ||   ||
> >  |   |   RGMII+<->+RGMII   |
> >  |   |MDIO+<->+MDIO|
> >  |   ||   ||
> >  |   | GPO+-->+#RST|
> >  |   ||   ||
> >  |   |  Tx-clk+-->+Tx-clk  |
> >  |   ||   ||
> >  |   ++   ++
> >  ++
> > 
> > Each of such devices has got en external RGMII-PHY attached configured via 
> > the
> > MDIO bus with Rx-clock supplied by the PHY and Tx-clock consumed by it. The
> > main peculiarity of such configuration is that the DW GMAC GPIOs have been 
> > used
> > to catch the PHY IRQs and to reset the PHY. Seeing the GPIOs support hasn't
> > been added to the STMMAC driver it's the very first setup for now, which has
> > been using them.
> 

> It sounds like you need to cleanly implement a GPIO controller within
> the stmmac driver. But you probably want to make it conditional on a
> DT property. For example, look to see if there is the
> 'gpio-controller;'

Yeap, that's what I have already done. The problem is that the
GPOs state is getting reset together with the MAC reset. So we don't
have a full control over the GPOs state when the MAC gets reset.

> 
> > Anyway the hardware setup depicted above doesn't seem
> > problematic at the first glance, but in fact it is. See, the DW *MAC driver
> > (STMMAC ethernet driver) is doing the MAC reset each time it performs the
> > device open or resume by means of the call-chain:
> > 
> >   stmmac_open()---+
> >   
> > +->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset().
> >   stmmac_resume()-+
> > 
> > Such reset causes the whole interface reset: MAC, DMA and, what is more
> > important, GPIOs as being exposed as part of the MAC registers. That
> > in our case automatically causes the external PHY reset, what neither
> > the STTMAC driver nor the PHY subsystem expect at all.
> 

> Is the reset of the GPIO sub block under software control? When you
> have a GPIO controller implemented, you would want to disable this.

Not sure I've fully understood your question. The GPIO sub-block of
the MAC is getting reset together with the MAC. So when we reset the
MAC, the GPOs state will get reset too. Seeing the STMMAC driver
performs the reset on open() and resume() callbacks the GPIOs gets to
reset synchronously there too. That's the main problem. We can't
somehow change the MAC reset behavior. So it's either to get rid of
the reset or somehow take the results of the reset into account in
software (like reinitialize the PHY too after it).

> 
> Once you have a GPIO controller, you can make use of the standard PHY
> DT properties to allow the PHY driver to make use of the interrupt,
> and to control the reset of the PHY.

Yeah, that's what I initially intended to implement. If only the
GPIO-control register wasn't reset on the MAC reset, I wouldn't even
asked the question.

-Sergey

> 
>  Andrew


Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

2020-12-15 Thread Serge Semin
Hello Alexandre,

Thanks for the response. My comments are below.

On Mon, Dec 14, 2020 at 11:52:14AM +0100, Alexandre Torgue wrote:
> Hi Serge,
> 

> Sorry I never used GPIO provided by DWMAC IP. Obviously, I think is to late
> for you to use GPIOs provided by your SoC directly. Unfortunately, it seems
> to be a "perfect" chicken and eggs problem :(.

If you meant the problem that the PHY is getting reset together with
the MAC reset, then at some extent it's indeed the chicken-eggs
problem, but it affects the STMMAC driver only due to the
stmmac_reset() procedure implementation (it waits for the SWR flag
being cleared right in the same method, but the flag won't be cleared
until all the clocks are ready, which isn't possible until PHY reset
isn't cleared, so it causes the DMA-reset timeout). The solution of
that is simple. If we first performed the reset procedure, then
initialized/attached the PHY and after that would have made sure the
DMA_BUS_MODE.SFT_RESET flag was cleared, then the problem wouldn't be
even noticeable. But still that would have solved just a part of the
problem. The driver would still perform the MAC reset in the PM
resume() callback, which in my case will automatically reset the PHY,
while the PHY subsystem doesn't expect that.

So in order to make the driver properly working for any situation we
either need to take the possible PHY reset into account in both open()
and PM-resume() callbacks, or get rid of the reset completely there.

The perfect solution would be not to reset the MAC all the time on the
network device open and resume procedures. In that case we could have
reset the controller in the stmmac_dvr_probe() just once, then
register the GPIO interface and use it for the MDIO-bus, whatever with
no problems. What do you think of that? Is that even possible seeing,
for example, AMD xGBE driver doesn't reset the MAC on network dev
open?  Yeah, the GMAC manual states, that the DMA initialization needs
to start with the GMAC reset, but in fact do we really need to do that
all the time on the device open/resume? Wouldn't that be enough to
reset the device just on probe?

> 
> Do you have possibilty to "play" with gpio setting. I mean change
> configuration of them (at least for reset one) before perform a DMA reset:
> If you have a pull-up on RST line and you could "disconnect" GPO inside GMAC
> then your PHY should remain on during DMA reset phase.

Alas no. It is impossible to do anything with hardware now. We need to
deal with what we currently have. The GPO lane is externally
pulled-down to GND on all the Baikal-T1 SoC-based hardware and these
are not a single type of device, but multiple of them, which have been
produced for more than three years now. We also can't somehow
detach/disconnect GPO inside the GMAC or somehow else, because the SoC
has already been synthesized with no such feature. So when the GPIO
register is reset or the GPIO.GPO field is cleared PHY gets to be in
reset state, and it concerns all the devices.(

-Sergey

> 
> regards
> Alex
> 
> On 12/14/20 10:25 AM, Serge Semin wrote:
> > Hello folks,
> > 
> > I've got a problem, which has been blowing by head up for more than three
> > weeks now, and I'm desperately need your help in that matter. See our
> > Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core
> > has been synthesized with two GPIOs: one as GPI and another as GPO. There
> > are multiple Baikal-T1-based devices have been created so far with active
> > GMAC interface usage and each of them has been designed like this:
> > 
> >   ++
> >   | Baikal-T1 ++   ++
> >   |   SoC | DW GMAC|   |   Some PHY |
> >   |   |  Rx-clk+<--+Rx-clk  |
> >   |   ||   ||
> >   |   | GPI+<--+#IRQ|
> >   |   ||   ||
> >   |   |   RGMII+<->+RGMII   |
> >   |   |MDIO+<->+MDIO|
> >   |   ||   ||
> >   |   | GPO+-->+#RST|
> >   |   ||   ||
> >   |   |  Tx-clk+-->+Tx-clk  |
> >   |   ||   ||
> >   |   ++   ++
> >   ++
> > 
> > Each of such devices has got en external RGMII-PHY attached configured via 
> > the
> > MDIO bus with Rx-clock supplied by the PHY and Tx-clock consumed by it. The
> > main peculiarity of such configuration is that the DW GMAC GPIOs have been 
> > used
> > to catch the PHY IRQs and to reset the PHY. Seei

[PATCH 01/25] dt-bindings: net: dwmac: Validate PBL for all IP-cores

2020-12-14 Thread Serge Semin
Indeed the maximum DMA burst length can be programmed not only for DW
xGMACs, Allwinner EMACs and Spear SoC GMAC, but in accordance with [1]
for Generic DW *MAC IP-cores. Moreover the STMMAC set of drivers parse
the property and then apply the configuration for all supported DW MAC
devices. All of that makes the property being available for all IP-cores
the bindings supports. Let's make sure the PBL-related properties are
validated for all of them by the common DW MAC DT schema.

[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 380.

Signed-off-by: Serge Semin 
---
 .../devicetree/bindings/net/snps,dwmac.yaml   | 69 +++
 1 file changed, 26 insertions(+), 43 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 11a6fdb657c9..4b672499f20d 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -262,6 +262,32 @@ properties:
   is supported. For example, this is used in case of SGMII and
   MAC2MAC connection.
 
+  snps,pbl:
+description:
+  Programmable Burst Length (tx and rx)
+$ref: /schemas/types.yaml#definitions/uint32
+enum: [2, 4, 8]
+
+  snps,txpbl:
+description:
+  Tx Programmable Burst Length. If set, DMA tx will use this
+  value rather than snps,pbl.
+$ref: /schemas/types.yaml#definitions/uint32
+enum: [2, 4, 8]
+
+  snps,rxpbl:
+description:
+  Rx Programmable Burst Length. If set, DMA rx will use this
+  value rather than snps,pbl.
+$ref: /schemas/types.yaml#definitions/uint32
+enum: [2, 4, 8]
+
+  snps,no-pbl-x8:
+$ref: /schemas/types.yaml#definitions/flag
+description:
+  Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core
+  rev < 3.50, don\'t multiply the values by 4.
+
   mdio:
 type: object
 description:
@@ -287,49 +313,6 @@ dependencies:
 
 allOf:
   - $ref: "ethernet-controller.yaml#"
-  - if:
-  properties:
-compatible:
-  contains:
-enum:
-  - allwinner,sun7i-a20-gmac
-  - allwinner,sun8i-a83t-emac
-  - allwinner,sun8i-h3-emac
-  - allwinner,sun8i-r40-emac
-  - allwinner,sun8i-v3s-emac
-  - allwinner,sun50i-a64-emac
-  - snps,dwxgmac
-  - snps,dwxgmac-2.10
-  - st,spear600-gmac
-
-then:
-  properties:
-snps,pbl:
-  description:
-Programmable Burst Length (tx and rx)
-  $ref: /schemas/types.yaml#definitions/uint32
-  enum: [2, 4, 8]
-
-snps,txpbl:
-  description:
-Tx Programmable Burst Length. If set, DMA tx will use this
-value rather than snps,pbl.
-  $ref: /schemas/types.yaml#definitions/uint32
-  enum: [2, 4, 8]
-
-snps,rxpbl:
-  description:
-Rx Programmable Burst Length. If set, DMA rx will use this
-value rather than snps,pbl.
-  $ref: /schemas/types.yaml#definitions/uint32
-  enum: [2, 4, 8]
-
-snps,no-pbl-x8:
-  $ref: /schemas/types.yaml#definitions/flag
-  description:
-Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core
-rev < 3.50, don\'t multiply the values by 4.
-
   - if:
   properties:
 compatible:
-- 
2.29.2



[PATCH 25/25] net: stmmac: dwc-qos: Save master/slave clocks in the plat-data

2020-12-14 Thread Serge Semin
Currently the "master_bus" clock of the DW QoS Eth controller isn't
preserved in the STMMAC platform data, while the "slave_bus" clock is
assigned to the stmmaceth clock pointer. It isn't correct from the
platform clock bindings point of view. The "stmmaceth" clock is supposed
to be the system clock, which is responsible for clocking the DMA
transfers from/to the controller FIFOs to/from the system memory and the
CSR interface if the later isn't separately clocked. If it's clocked
separately then the STMMAC platform code expects to also have "pclk"
specified. So in order to have the STMMAC platform data properly
initialized we need to set the "master_bus" clock handler to the
"stmmaceth" clock pointer, and the "slave_bus" clock handler to the "pclk"
clock pointer.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index f53a78448988..b90d7e4c3d4a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -315,6 +315,8 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
if (err < 0)
goto error;
 
+   data->stmmac_clk = eqos->clk_master;
+
eqos->clk_slave = devm_clk_get(>dev, "slave_bus");
if (IS_ERR(eqos->clk_slave)) {
err = PTR_ERR(eqos->clk_slave);
@@ -325,7 +327,7 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
if (err < 0)
goto disable_master;
 
-   data->stmmac_clk = eqos->clk_slave;
+   data->pclk = eqos->clk_slave;
 
eqos->reset = devm_gpiod_get(>dev, "phy-reset", GPIOD_OUT_HIGH);
if (IS_ERR(eqos->reset)) {
@@ -375,9 +377,10 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
gpiod_set_value(eqos->reset, 1);
 disable_slave:
clk_disable_unprepare(eqos->clk_slave);
-   data->stmmac_clk = NULL;
+   data->pclk = NULL;
 disable_master:
clk_disable_unprepare(eqos->clk_master);
+   data->stmmac_clk = NULL;
 error:
eqos = ERR_PTR(err);
goto out;
@@ -397,6 +400,7 @@ static int tegra_eqos_remove(struct platform_device *pdev)
 * data so the stmmac_remove_config_dt() method wouldn't have disabled
 * the clocks too.
 */
+   priv->plat->pclk = NULL;
priv->plat->stmmac_clk = NULL;
 
return 0;
-- 
2.29.2



[PATCH 15/25] net: stmmac: Use optional clock request method to get pclk

2020-12-14 Thread Serge Semin
Let's replace the manual implementation of the optional "pclk"
functionality with using devm_clk_get_optional(). By doing so we'll
improve the code maintainability, and fix a hidden bug which will cause
problems if the "pclk" clock has been actually passed to the device, but
the clock framework failed to request it.

Signed-off-by: Serge Semin 
---
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c| 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index e79b3e3351a9..3809b00d3077 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -579,15 +579,13 @@ stmmac_probe_config_dt(struct platform_device *pdev, 
const char **mac)
 
clk_prepare_enable(plat->stmmac_clk);
 
-   plat->pclk = devm_clk_get(>dev, "pclk");
+   plat->pclk = devm_clk_get_optional(>dev, "pclk");
if (IS_ERR(plat->pclk)) {
-   if (PTR_ERR(plat->pclk) == -EPROBE_DEFER) {
-   rc = PTR_ERR(plat->pclk);
-   goto error_pclk_get;
-   }
-
-   plat->pclk = NULL;
+   rc = PTR_ERR(plat->pclk);
+   dev_err_probe(>dev, rc, "Cannot get CSR clock\n");
+   goto error_pclk_get;
}
+
clk_prepare_enable(plat->pclk);
 
/* Fall-back to main clock in case of no PTP ref is passed */
-- 
2.29.2



[PATCH 22/25] net: stmmac: dwmac-imx: Discard Tx clock request

2020-12-14 Thread Serge Semin
Since the Tx clock is now requested and enabled/disabled in the STMMAC
DT-based platform config method, there is no need in duplicating the same
procedures in the DW MAC iMX sub-driver.

Signed-off-by: Serge Semin 
---
 .../net/ethernet/stmicro/stmmac/dwmac-imx.c   | 21 +--
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
index efef5476a577..7b4590670b4e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
@@ -40,7 +40,6 @@ struct imx_dwmac_ops {
 
 struct imx_priv_data {
struct device *dev;
-   struct clk *clk_tx;
struct clk *clk_mem;
struct regmap *intf_regmap;
u32 intf_reg_off;
@@ -104,12 +103,6 @@ static int imx_dwmac_init(struct platform_device *pdev, 
void *priv)
return ret;
}
 
-   ret = clk_prepare_enable(dwmac->clk_tx);
-   if (ret) {
-   dev_err(>dev, "tx clock enable failed\n");
-   goto clk_tx_en_failed;
-   }
-
if (dwmac->ops->set_intf_mode) {
ret = dwmac->ops->set_intf_mode(plat_dat);
if (ret)
@@ -119,8 +112,6 @@ static int imx_dwmac_init(struct platform_device *pdev, 
void *priv)
return 0;
 
 intf_mode_failed:
-   clk_disable_unprepare(dwmac->clk_tx);
-clk_tx_en_failed:
clk_disable_unprepare(dwmac->clk_mem);
return ret;
 }
@@ -129,7 +120,6 @@ static void imx_dwmac_exit(struct platform_device *pdev, 
void *priv)
 {
struct imx_priv_data *dwmac = priv;
 
-   clk_disable_unprepare(dwmac->clk_tx);
clk_disable_unprepare(dwmac->clk_mem);
 }
 
@@ -162,7 +152,7 @@ static void imx_dwmac_fix_speed(void *priv, unsigned int 
speed)
return;
}
 
-   err = clk_set_rate(dwmac->clk_tx, rate);
+   err = clk_set_rate(plat_dat->tx_clk, rate);
if (err < 0)
dev_err(dwmac->dev, "failed to set tx rate %lu\n", rate);
 }
@@ -176,10 +166,9 @@ imx_dwmac_parse_dt(struct imx_priv_data *dwmac, struct 
device *dev)
if (of_get_property(np, "snps,rmii_refclk_ext", NULL))
dwmac->rmii_refclk_ext = true;
 
-   dwmac->clk_tx = devm_clk_get(dev, "tx");
-   if (IS_ERR(dwmac->clk_tx)) {
-   dev_err(dev, "failed to get tx clock\n");
-   return PTR_ERR(dwmac->clk_tx);
+   if (!dwmac->plat_dat->tx_clk) {
+   dev_err(dev, "no tx clock found\n");
+   return -EINVAL;
}
 
dwmac->clk_mem = NULL;
@@ -239,6 +228,7 @@ static int imx_dwmac_probe(struct platform_device *pdev)
 
dwmac->ops = data;
dwmac->dev = >dev;
+   dwmac->plat_dat = plat_dat;
 
ret = imx_dwmac_parse_dt(dwmac, >dev);
if (ret) {
@@ -257,7 +247,6 @@ static int imx_dwmac_probe(struct platform_device *pdev)
plat_dat->exit = imx_dwmac_exit;
plat_dat->fix_mac_speed = imx_dwmac_fix_speed;
plat_dat->bsp_priv = dwmac;
-   dwmac->plat_dat = plat_dat;
 
ret = imx_dwmac_init(pdev, dwmac);
if (ret)
-- 
2.29.2



[RFC] net: stmmac: Problem with adding the native GPIOs support

2020-12-14 Thread Serge Semin
Hello folks,

I've got a problem, which has been blowing by head up for more than three
weeks now, and I'm desperately need your help in that matter. See our
Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core
has been synthesized with two GPIOs: one as GPI and another as GPO. There
are multiple Baikal-T1-based devices have been created so far with active
GMAC interface usage and each of them has been designed like this:

 ++
 | Baikal-T1 ++   ++
 |   SoC | DW GMAC|   |   Some PHY |
 |   |  Rx-clk+<--+Rx-clk  |
 |   ||   ||
 |   | GPI+<--+#IRQ|
 |   ||   ||
 |   |   RGMII+<->+RGMII   |
 |   |MDIO+<->+MDIO|
 |   ||   ||
 |   | GPO+-->+#RST|
 |   ||   ||
 |   |  Tx-clk+-->+Tx-clk  |
 |   ||   ||
 |   ++   ++
 ++

Each of such devices has got en external RGMII-PHY attached configured via the
MDIO bus with Rx-clock supplied by the PHY and Tx-clock consumed by it. The
main peculiarity of such configuration is that the DW GMAC GPIOs have been used
to catch the PHY IRQs and to reset the PHY. Seeing the GPIOs support hasn't
been added to the STMMAC driver it's the very first setup for now, which has
been using them. Anyway the hardware setup depicted above doesn't seem
problematic at the first glance, but in fact it is. See, the DW *MAC driver
(STMMAC ethernet driver) is doing the MAC reset each time it performs the
device open or resume by means of the call-chain:

  stmmac_open()---+
  
+->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset().
  stmmac_resume()-+

Such reset causes the whole interface reset: MAC, DMA and, what is more
important, GPIOs as being exposed as part of the MAC registers. That
in our case automatically causes the external PHY reset, what neither
the STTMAC driver nor the PHY subsystem expect at all.

Moreover the stmmac_reset() method polls the DMA_BUS_MODE.SFT_RESET flag
state to be sure the MAC is successfully completed. But since the external
PHY has got in reset state it doesn't generate the Rx-clk signal. Due to
that the MAC-DMA won't get out of the reset state so the stmmac_reset()
method will return timeout error. Of course I could manually restore the
GPIOs state in the stmmac_reset() before start to poll the SFT_RESET flag,
which may release the PHY reset. But that seems more like a workaround,
because the PHY still has been in reset and need to be reinitialized
anyway. Moreover some PHY may need to have more complicated reset cycle
with certain delays between RST assertion/de-assertion, so the workaround
won't work well for them.

To sum it up my question is what is the right way to resolve the problem
described above? My first idea was to just move the MAC reset from the
net-device open()/close() callbacks to the
stmmac_dvr_probe()/stmmac_dvr_remove() functions and don't reset the whole
interface on each device open. The problems we may have in that case is
due to the suspend/resume procedures, which for some reason require the
MAC reset too. That's why I need your help in this matter. Do you have any
idea how to gently add the GPIOs support and don't break the STMMAC
driver?

One more tiny question regarding the DW *MAC drivers available in kernel.
Aside of the DW GMAC Baikal-T1 SoC has also got DW xGMAC v2.11a embedded
with XPCS PHY attached. My question is what driver should we better use to
handle our xGMAC interface? AFAICS there are three DW *MAC-related drivers
the kernel currently provides:
1) drivers/net/ethernet/stmicro/stmmac
2) drivers/net/ethernet/amd/
3) drivers/net/ethernet/synopsys/
xGBE interface is supported by the drivers 1) and 2). In accordance with
https://www.spinics.net/lists/netdev/msg414148.html all xGMAC related
parts should have been added to 2), but recently the XGMAC support has
been added to 1). So I am confused what driver is now supposed to be used
for new xGMACs?

Regards,
-Sergey


[PATCH 21/25] net: stmmac: dwc-qos: Discard Tx/Rx clocks request

2020-12-14 Thread Serge Semin
Since the Tx/Rx clocks with the same names are now requested and
enabled/disabled in the STMMAC DT-based platform config method, there is
no need in duplicating the same procedures in the DWC QoS Eth sub-driver.
Discard it then, but make sure the denoted clocks have been specified
for the platform.

Note also the deprecated clock "phy_ref_clk" have been defined as the Tx
clock in the DWC QoS Eth bindings. Let's use a pointer to the Tx clock
defined in the platform data then instead of the unrelated pclk pointer.

Signed-off-by: Serge Semin 
---
 .../stmicro/stmmac/dwmac-dwc-qos-eth.c| 44 +--
 1 file changed, 11 insertions(+), 33 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index 57f957898b60..f53a78448988 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -31,8 +31,6 @@ struct tegra_eqos {
struct reset_control *rst;
struct clk *clk_master;
struct clk *clk_slave;
-   struct clk *clk_tx;
-   struct clk *clk_rx;
 
struct gpio_desc *reset;
 };
@@ -155,7 +153,7 @@ static void *dwc_qos_probe(struct platform_device *pdev,
goto disable;
}
 
-   plat_dat->pclk = clk;
+   plat_dat->tx_clk = clk;
 
return NULL;
 
@@ -175,8 +173,8 @@ static int dwc_qos_remove(struct platform_device *pdev)
 * data so the stmmac_remove_config_dt() method wouldn't have disabled
 * the clocks too.
 */
-   clk_disable_unprepare(priv->plat->pclk);
-   priv->plat->pclk = NULL;
+   clk_disable_unprepare(priv->plat->tx_clk);
+   priv->plat->tx_clk = NULL;
 
clk_disable_unprepare(priv->plat->stmmac_clk);
priv->plat->stmmac_clk = NULL;
@@ -197,6 +195,7 @@ static int dwc_qos_remove(struct platform_device *pdev)
 static void tegra_eqos_fix_speed(void *priv, unsigned int speed)
 {
struct tegra_eqos *eqos = priv;
+   struct stmmac_priv *sp = netdev_priv(dev_get_drvdata(eqos->dev));
unsigned long rate = 12500;
bool needs_calibration = false;
u32 value;
@@ -262,7 +261,7 @@ static void tegra_eqos_fix_speed(void *priv, unsigned int 
speed)
writel(value, eqos->regs + AUTO_CAL_CONFIG);
}
 
-   err = clk_set_rate(eqos->clk_tx, rate);
+   err = clk_set_rate(sp->plat->tx_clk, rate);
if (err < 0)
dev_err(eqos->dev, "failed to set TX rate: %d\n", err);
 }
@@ -301,6 +300,11 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
if (!is_of_node(dev->fwnode))
goto bypass_clk_reset_gpio;
 
+   if (!data->tx_clk || !data->rx_clk) {
+   err = -EINVAL;
+   goto error;
+   }
+
eqos->clk_master = devm_clk_get(>dev, "master_bus");
if (IS_ERR(eqos->clk_master)) {
err = PTR_ERR(eqos->clk_master);
@@ -323,30 +327,10 @@ static void *tegra_eqos_probe(struct platform_device 
*pdev,
 
data->stmmac_clk = eqos->clk_slave;
 
-   eqos->clk_rx = devm_clk_get(>dev, "rx");
-   if (IS_ERR(eqos->clk_rx)) {
-   err = PTR_ERR(eqos->clk_rx);
-   goto disable_slave;
-   }
-
-   err = clk_prepare_enable(eqos->clk_rx);
-   if (err < 0)
-   goto disable_slave;
-
-   eqos->clk_tx = devm_clk_get(>dev, "tx");
-   if (IS_ERR(eqos->clk_tx)) {
-   err = PTR_ERR(eqos->clk_tx);
-   goto disable_rx;
-   }
-
-   err = clk_prepare_enable(eqos->clk_tx);
-   if (err < 0)
-   goto disable_rx;
-
eqos->reset = devm_gpiod_get(>dev, "phy-reset", GPIOD_OUT_HIGH);
if (IS_ERR(eqos->reset)) {
err = PTR_ERR(eqos->reset);
-   goto disable_tx;
+   goto disable_slave;
}
 
usleep_range(2000, 4000);
@@ -389,10 +373,6 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
reset_control_assert(eqos->rst);
 reset_phy:
gpiod_set_value(eqos->reset, 1);
-disable_tx:
-   clk_disable_unprepare(eqos->clk_tx);
-disable_rx:
-   clk_disable_unprepare(eqos->clk_rx);
 disable_slave:
clk_disable_unprepare(eqos->clk_slave);
data->stmmac_clk = NULL;
@@ -410,8 +390,6 @@ static int tegra_eqos_remove(struct platform_device *pdev)
 
reset_control_assert(eqos->rst);
gpiod_set_value(eqos->reset, 1);
-   clk_disable_unprepare(eqos->clk_tx);
-   clk_disable_unprepare(eqos->clk_rx);
clk_disable_unprepare(eqos->clk_slave);
clk_disable_unprepare(eqos->clk_master);
 
-- 
2.29.2



[PATCH 10/25] net: stmmac: dwmac-sti: Cleanup STMMAC DT-config in remove cb

2020-12-14 Thread Serge Semin
The stmmac_remove_config_dt() method needs to be called on the device
remove procedure otherwise for at least some of device-nodes will be left
requested.

Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev 
leaks")
Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
index e1b63df6f96f..3454c5eff822 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
@@ -370,11 +370,14 @@ static int sti_dwmac_probe(struct platform_device *pdev)
 
 static int sti_dwmac_remove(struct platform_device *pdev)
 {
+   struct stmmac_priv *priv = netdev_priv(platform_get_drvdata(pdev));
struct sti_dwmac *dwmac = get_stmmac_bsp_priv(>dev);
int ret = stmmac_dvr_remove(>dev);
 
clk_disable_unprepare(dwmac->clk);
 
+   stmmac_remove_config_dt(pdev, priv->plat);
+
return ret;
 }
 
-- 
2.29.2



[PATCH 08/25] net: stmmac: Add snps,*-config sub-nodes support

2020-12-14 Thread Serge Semin
Currently the "snps,axi-config", "snps,mtl-rx-config" and
"snps,mtl-tx-config" DT node properties are marked as deprecated when
being defined as a phandle reference to a node with parameters. The new
way of defining the DW MAC interfaces config is to add an eponymous
sub-nodes to the DW MAC device DT node. Make sure the STMMAC driver
supports it.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index af34a4cadbb0..b4720e477d90 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -95,7 +95,8 @@ static struct stmmac_axi *stmmac_axi_setup(struct 
platform_device *pdev)
struct device_node *np;
struct stmmac_axi *axi;
 
-   np = of_parse_phandle(pdev->dev.of_node, "snps,axi-config", 0);
+   np = of_parse_phandle(pdev->dev.of_node, "snps,axi-config", 0) ?:
+of_get_child_by_name(pdev->dev.of_node, "snps,axi-config");
if (!np)
return NULL;
 
@@ -150,11 +151,13 @@ static int stmmac_mtl_setup(struct platform_device *pdev,
plat->rx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB;
plat->tx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB;
 
-   rx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-rx-config", 0);
+   rx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-rx-config", 0) 
?:
+ of_get_child_by_name(pdev->dev.of_node, "snps,mtl-rx-config");
if (!rx_node)
return ret;
 
-   tx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-tx-config", 0);
+   tx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-tx-config", 0) 
?:
+ of_get_child_by_name(pdev->dev.of_node, "snps,mtl-tx-config");
if (!tx_node) {
of_node_put(rx_node);
return ret;
-- 
2.29.2



[PATCH 06/25] dt-bindings: net: dwmac: Add Tx/Rx clock sources

2020-12-14 Thread Serge Semin
Generic DW *MAC can be connected to an external Tramit and Receive clock
generators. Add the corresponding clocks description and clock-names to
the generic bindings schema so new DW *MAC-based bindings wouldn't declare
its own names of the same clocks.

Signed-off-by: Serge Semin 
---
 .../devicetree/bindings/net/snps,dwmac.yaml| 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index e1ebe5c8b1da..74820f491346 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -126,6 +126,18 @@ properties:
   MCI, CSR and SMA interfaces run on this clock. If it's omitted,
   the CSR interfaces are considered as synchronous to the system
   clock domain.
+  - description:
+  GMAC Tx clock or so called Transmit clock. The clock is supplied
+  by an external with respect to the DW MAC clock generator.
+  The clock source and its frequency depends on the DW MAC xMII mode.
+  In case if it's supplied by PHY/SerDes this property can be
+  omitted.
+  - description:
+  GMAC Rx clock or so called Receive clock. The clock is supplied
+  by an external with respect to the DW MAC clock generator.
+  The clock source and its frequency depends on the DW MAC xMII mode.
+  In case if it's supplied by PHY/SerDes or it's synchronous to
+  the Tx clock this property can be omitted.
   - description:
   PTP reference clock. This clock is used for programming the
   Timestamp Addend Register. If not passed then the system
@@ -139,6 +151,8 @@ properties:
   enum:
 - stmmaceth
 - pclk
+- tx
+- rx
 - ptp_ref
 
   resets:
-- 
2.29.2



[PATCH 19/25] net: stmmac: dwc-qos: Use dev_err_probe() for probe errors handling

2020-12-14 Thread Serge Semin
There is a very handy dev_err_probe() method to handle the deferred probe
error number. It reduces the code size, uniforms error handling, records
the defer probe reason, etc. Use it to print the probe callback error
message.

Signed-off-by: Serge Semin 
Cc: Anson Huang 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index 31ca299a1cfd..57f957898b60 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -473,11 +473,8 @@ static int dwc_eth_dwmac_probe(struct platform_device 
*pdev)
priv = data->probe(pdev, plat_dat, _res);
if (IS_ERR(priv)) {
ret = PTR_ERR(priv);
-
-   if (ret != -EPROBE_DEFER)
-   dev_err(>dev, "failed to probe subdriver: %d\n",
-   ret);
-
+   dev_err_probe(>dev, ret, "failed to probe subdriver: 
%d\n",
+ ret);
goto remove_config;
}
 
-- 
2.29.2



[PATCH 14/25] net: stmmac: Use optional clock request method to get stmmaceth

2020-12-14 Thread Serge Semin
The "stmmaceth" clock is expected to be optional by the current driver
design, but there are several problems in the implementation. First if the
clock is specified, but failed to be requested due to an internal error or
due to not being ready yet for configuration, then the DT-probe procedure
will just proceed with further initializations. It is erroneous in both
cases. Secondly if we'd use the clock API, which expect the clock being
optional we wouldn't have needed to avoid the clock request procedure for
the "snps,dwc-qos-ethernet-4.10"-compatible devices to prevent the error
message from being printed. All of that can be fixed by using the
devm_clk_get_optional() method here provided by the common clock
framework.

Signed-off-by: Serge Semin 
---
 .../ethernet/stmicro/stmmac/stmmac_platform.c | 20 ++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 56419f511a48..e79b3e3351a9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -566,17 +566,19 @@ stmmac_probe_config_dt(struct platform_device *pdev, 
const char **mac)
if (rc)
goto error_dma_cfg_alloc;
 
-   /* clock setup */
-   if (!of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
-   plat->stmmac_clk = devm_clk_get(>dev,
-   STMMAC_RESOURCE_NAME);
-   if (IS_ERR(plat->stmmac_clk)) {
-   dev_warn(>dev, "Cannot get CSR clock\n");
-   plat->stmmac_clk = NULL;
-   }
-   clk_prepare_enable(plat->stmmac_clk);
+   /* All clocks are optional since the sub-drivers can have a specific
+* clocks set and their naming.
+*/
+   plat->stmmac_clk = devm_clk_get_optional(>dev,
+STMMAC_RESOURCE_NAME);
+   if (IS_ERR(plat->stmmac_clk)) {
+   rc = PTR_ERR(plat->stmmac_clk);
+   dev_err_probe(>dev, rc, "Cannot get CSR clock\n");
+   goto error_dma_cfg_alloc;
}
 
+   clk_prepare_enable(plat->stmmac_clk);
+
plat->pclk = devm_clk_get(>dev, "pclk");
if (IS_ERR(plat->pclk)) {
if (PTR_ERR(plat->pclk) == -EPROBE_DEFER) {
-- 
2.29.2



[PATCH 13/25] net: stmmac: Fix clocks left enabled on glue-probes failure

2020-12-14 Thread Serge Semin
The generic clocks request and preparation have been moved from
stmmac_dvr_probe()/stmmac_init_ptp() to the stmmac_probe_config_dt()
method in the framework of commit f573c0b9c4e0 ("stmmac: move stmmac_clk,
pclk, clk_ptp_ref and stmmac_rst to platform structure"). At the same time
the clocks disabling and reset assertion have been left in
stmmac_dvr_remove() instead of also being moved to the symmetric
antagonistic method - stmmac_remove_config_dt(). Due to that all the glue
drivers probe cleanup-on-failure paths don't perform the generic clocks
disable/unprepare procedure, which of course is wrong. Fix it by moving
the clocks disable/unprepare methods invocation to the
stmmac_remove_config_dt() function.

Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst 
to platform structure")
Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 2 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 --
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 4 +++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 81ee0a071b4e..884b8d661442 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -667,6 +667,8 @@ static void intel_eth_pci_remove(struct pci_dev *pdev)
 
pci_free_irq_vectors(pdev);
 
+   clk_disable_unprepare(priv->plat->stmmac_clk);
+
clk_unregister_fixed_rate(priv->plat->stmmac_clk);
 
pcim_iounmap_regions(pdev, BIT(0));
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d833908b660a..13681027dd09 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5103,8 +5103,6 @@ int stmmac_dvr_remove(struct device *dev)
phylink_destroy(priv->phylink);
if (priv->plat->stmmac_rst)
reset_control_assert(priv->plat->stmmac_rst);
-   clk_disable_unprepare(priv->plat->pclk);
-   clk_disable_unprepare(priv->plat->stmmac_clk);
if (priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 5110545090d2..56419f511a48 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -630,11 +630,13 @@ stmmac_probe_config_dt(struct platform_device *pdev, 
const char **mac)
  * @pdev: platform_device structure
  * @plat: driver data platform structure
  *
- * Release resources claimed by stmmac_probe_config_dt().
+ * Disable and release resources claimed by stmmac_probe_config_dt().
  */
 void stmmac_remove_config_dt(struct platform_device *pdev,
 struct plat_stmmacenet_data *plat)
 {
+   clk_disable_unprepare(plat->pclk);
+   clk_disable_unprepare(plat->stmmac_clk);
of_node_put(plat->phy_node);
of_node_put(plat->mdio_node);
 }
-- 
2.29.2



[PATCH 24/25] net: stmmac: Use pclk to set MDC clock frequency

2020-12-14 Thread Serge Semin
In accordance with [1] the MDC clock frequency is supposed to be selected
with respect to the CSR clock frequency. CSR clock can be either tied to
the DW MAC system clock (GMAC main clock) or supplied via a dedicated
clk_csr_i signal. Current MDC clock selection procedure handles the former
case while having no support of the later one. That's wrong for the
devices which have separate system and CSR clocks. Let's fix it by first
trying to get the synchro-signal rate from the "pclk" clock, if it hasn't
been specified then fall-back to the "stmmaceth" clock.

[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 424.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7f4d54d2fc72..719b00fd2a70 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -206,7 +206,12 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
 {
u32 clk_rate;
 
-   clk_rate = clk_get_rate(priv->plat->stmmac_clk);
+   /* If APB clock has been specified then it is supposed to be used
+* to select the CSR mode. Otherwise the application clock is the
+* source of the periodic signal for the CSR interface.
+*/
+   clk_rate = clk_get_rate(priv->plat->pclk) ?:
+  clk_get_rate(priv->plat->stmmac_clk);
 
/* Platform provided default clk_csr would be assumed valid
 * for all other cases except for the below mentioned ones.
-- 
2.29.2



[PATCH 18/25] net: stmmac: dwc-qos: Cleanup STMMAC platform data clock pointers

2020-12-14 Thread Serge Semin
The pointers need to be nullified otherwise the stmmac_remove_config_dt()
method called after them being initialized will disable the clocks. That
then will cause a WARN() backtrace being printed since the clocks would be
also disabled in the locally defined remove method.

Signed-off-by: Serge Semin 
---
 .../stmicro/stmmac/dwmac-dwc-qos-eth.c| 42 ++-
 1 file changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index 2342d497348e..31ca299a1cfd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -123,39 +123,46 @@ static void *dwc_qos_probe(struct platform_device *pdev,
   struct plat_stmmacenet_data *plat_dat,
   struct stmmac_resources *stmmac_res)
 {
+   struct clk *clk;
int err;
 
-   plat_dat->stmmac_clk = devm_clk_get(>dev, "apb_pclk");
-   if (IS_ERR(plat_dat->stmmac_clk)) {
+   clk = devm_clk_get(>dev, "apb_pclk");
+   if (IS_ERR(clk)) {
dev_err(>dev, "apb_pclk clock not found.\n");
-   return ERR_CAST(plat_dat->stmmac_clk);
+   return ERR_CAST(clk);
}
 
-   err = clk_prepare_enable(plat_dat->stmmac_clk);
+   err = clk_prepare_enable(clk);
if (err < 0) {
dev_err(>dev, "failed to enable apb_pclk clock: %d\n",
err);
return ERR_PTR(err);
}
 
-   plat_dat->pclk = devm_clk_get(>dev, "phy_ref_clk");
-   if (IS_ERR(plat_dat->pclk)) {
+   plat_dat->stmmac_clk = clk;
+
+   clk = devm_clk_get(>dev, "phy_ref_clk");
+   if (IS_ERR(clk)) {
dev_err(>dev, "phy_ref_clk clock not found.\n");
-   err = PTR_ERR(plat_dat->pclk);
+   err = PTR_ERR(clk);
goto disable;
}
 
-   err = clk_prepare_enable(plat_dat->pclk);
+   err = clk_prepare_enable(clk);
if (err < 0) {
dev_err(>dev, "failed to enable phy_ref clock: %d\n",
err);
goto disable;
}
 
+   plat_dat->pclk = clk;
+
return NULL;
 
 disable:
clk_disable_unprepare(plat_dat->stmmac_clk);
+   plat_dat->stmmac_clk = NULL;
+
return ERR_PTR(err);
 }
 
@@ -164,8 +171,15 @@ static int dwc_qos_remove(struct platform_device *pdev)
struct net_device *ndev = platform_get_drvdata(pdev);
struct stmmac_priv *priv = netdev_priv(ndev);
 
+   /* Cleanup the pointers to the clock handlers hidden in the platform
+* data so the stmmac_remove_config_dt() method wouldn't have disabled
+* the clocks too.
+*/
clk_disable_unprepare(priv->plat->pclk);
+   priv->plat->pclk = NULL;
+
clk_disable_unprepare(priv->plat->stmmac_clk);
+   priv->plat->stmmac_clk = NULL;
 
return 0;
 }
@@ -303,12 +317,12 @@ static void *tegra_eqos_probe(struct platform_device 
*pdev,
goto disable_master;
}
 
-   data->stmmac_clk = eqos->clk_slave;
-
err = clk_prepare_enable(eqos->clk_slave);
if (err < 0)
goto disable_master;
 
+   data->stmmac_clk = eqos->clk_slave;
+
eqos->clk_rx = devm_clk_get(>dev, "rx");
if (IS_ERR(eqos->clk_rx)) {
err = PTR_ERR(eqos->clk_rx);
@@ -381,6 +395,7 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
clk_disable_unprepare(eqos->clk_rx);
 disable_slave:
clk_disable_unprepare(eqos->clk_slave);
+   data->stmmac_clk = NULL;
 disable_master:
clk_disable_unprepare(eqos->clk_master);
 error:
@@ -390,6 +405,7 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
 
 static int tegra_eqos_remove(struct platform_device *pdev)
 {
+   struct stmmac_priv *priv = netdev_priv(platform_get_drvdata(pdev));
struct tegra_eqos *eqos = get_stmmac_bsp_priv(>dev);
 
reset_control_assert(eqos->rst);
@@ -399,6 +415,12 @@ static int tegra_eqos_remove(struct platform_device *pdev)
clk_disable_unprepare(eqos->clk_slave);
clk_disable_unprepare(eqos->clk_master);
 
+   /* Cleanup the pointers to the clock handlers hidden in the platform
+* data so the stmmac_remove_config_dt() method wouldn't have disabled
+* the clocks too.
+*/
+   priv->plat->stmmac_clk = NULL;
+
return 0;
 }
 
-- 
2.29.2



[PATCH 17/25] net: stmmac: Use optional reset control API to work with stmmaceth

2020-12-14 Thread Serge Semin
Replace the manual implementation of the optional device reset control
functionality with using the devm_reset_control_get_optional() method in
order to improve the code maintainability and fix a potential bug. It
will come out if the reset control handler has been specified, but the
reset framework failed to request it.

Note there is no need in checking the priv->plat->stmmac_rst pointer for
being not NULL in order to perform the reset control assertion/deassertion
because the passed NULL will be considered by the reset framework as
absent optional reset control handler anyway.

Signed-off-by: Serge Semin 
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ---
 .../ethernet/stmicro/stmmac/stmmac_platform.c | 14 +-
 2 files changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e9003684efc8..7f4d54d2fc72 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4889,15 +4889,13 @@ int stmmac_dvr_probe(struct device *device,
if ((phyaddr >= 0) && (phyaddr <= 31))
priv->plat->phy_addr = phyaddr;
 
-   if (priv->plat->stmmac_rst) {
-   ret = reset_control_assert(priv->plat->stmmac_rst);
-   reset_control_deassert(priv->plat->stmmac_rst);
-   /* Some reset controllers have only reset callback instead of
-* assert + deassert callbacks pair.
-*/
-   if (ret == -ENOTSUPP)
-   reset_control_reset(priv->plat->stmmac_rst);
-   }
+   ret = reset_control_assert(priv->plat->stmmac_rst);
+   reset_control_deassert(priv->plat->stmmac_rst);
+   /* Some reset controllers have only reset callback instead of
+* assert + deassert callbacks pair.
+*/
+   if (ret == -ENOTSUPP)
+   reset_control_reset(priv->plat->stmmac_rst);
 
/* Init MAC and get the capabilities */
ret = stmmac_hw_init(priv);
@@ -5101,8 +5099,7 @@ int stmmac_dvr_remove(struct device *dev)
stmmac_exit_fs(ndev);
 #endif
phylink_destroy(priv->phylink);
-   if (priv->plat->stmmac_rst)
-   reset_control_assert(priv->plat->stmmac_rst);
+   reset_control_assert(priv->plat->stmmac_rst);
if (priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 367d1458d66d..38e8836861c4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -602,16 +602,12 @@ stmmac_probe_config_dt(struct platform_device *pdev, 
const char **mac)
dev_dbg(>dev, "PTP rate %d\n", plat->clk_ptp_rate);
}
 
-   plat->stmmac_rst = devm_reset_control_get(>dev,
- STMMAC_RESOURCE_NAME);
+   plat->stmmac_rst = devm_reset_control_get_optional(>dev,
+  
STMMAC_RESOURCE_NAME);
if (IS_ERR(plat->stmmac_rst)) {
-   if (PTR_ERR(plat->stmmac_rst) == -EPROBE_DEFER) {
-   rc = PTR_ERR(plat->stmmac_rst);
-   goto error_hw_init;
-   }
-
-   dev_info(>dev, "no reset control found\n");
-   plat->stmmac_rst = NULL;
+   rc = PTR_ERR(plat->stmmac_rst);
+   dev_err_probe(>dev, rc, "Cannot get reset control\n");
+   goto error_hw_init;
}
 
return plat;
-- 
2.29.2



[PATCH 23/25] net: stmmac: Call stmmaceth clock as system clock in warn-message

2020-12-14 Thread Serge Semin
By all means of the stmmac_clk clock usage it isn't CSR clock, but the
system or application clock, which in particular cases can be used as a
clock source for the CSR interface. Make sure the warning message
correctly identify the clock.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 943498d57e3a..6e22036eab60 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -573,7 +573,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
 STMMAC_RESOURCE_NAME);
if (IS_ERR(plat->stmmac_clk)) {
rc = PTR_ERR(plat->stmmac_clk);
-   dev_err_probe(>dev, rc, "Cannot get CSR clock\n");
+   dev_err_probe(>dev, rc, "Cannot get system clock\n");
goto error_dma_cfg_alloc;
}
 
-- 
2.29.2



[PATCH 12/25] net: stmmac: Directly call reverse methods in stmmac_probe_config_dt()

2020-12-14 Thread Serge Semin
Calling an antagonistic method from the corresponding protagonist isn't
good from maintainability point of view, since prevents us from directly
adding a functionality in the later, which needs to be reverted in the
former. Since that's what we are about to do in order to fix the commit
573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to
platform structure"), let's replace the stmmac_remove_config_dt() method
invocation in stmmac_probe_config_dt() with direct reversal procedures.

Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst 
to platform structure")
Signed-off-by: Serge Semin 
---
 .../ethernet/stmicro/stmmac/stmmac_platform.c | 26 ---
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index b4720e477d90..5110545090d2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -457,7 +457,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
/* To Configure PHY by using all device-tree supported properties */
rc = stmmac_dt_phy(plat, np, >dev);
if (rc)
-   return ERR_PTR(rc);
+   goto error_dt_phy_parse;
 
of_property_read_u32(np, "tx-fifo-depth", >tx_fifo_size);
 
@@ -535,8 +535,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
dma_cfg = devm_kzalloc(>dev, sizeof(*dma_cfg),
   GFP_KERNEL);
if (!dma_cfg) {
-   stmmac_remove_config_dt(pdev, plat);
-   return ERR_PTR(-ENOMEM);
+   rc = -ENOMEM;
+   goto error_dma_cfg_alloc;
}
plat->dma_cfg = dma_cfg;
 
@@ -563,10 +563,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
plat->axi = stmmac_axi_setup(pdev);
 
rc = stmmac_mtl_setup(pdev, plat);
-   if (rc) {
-   stmmac_remove_config_dt(pdev, plat);
-   return ERR_PTR(rc);
-   }
+   if (rc)
+   goto error_dma_cfg_alloc;
 
/* clock setup */
if (!of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
@@ -581,8 +579,10 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
 
plat->pclk = devm_clk_get(>dev, "pclk");
if (IS_ERR(plat->pclk)) {
-   if (PTR_ERR(plat->pclk) == -EPROBE_DEFER)
+   if (PTR_ERR(plat->pclk) == -EPROBE_DEFER) {
+   rc = PTR_ERR(plat->pclk);
goto error_pclk_get;
+   }
 
plat->pclk = NULL;
}
@@ -602,8 +602,10 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
plat->stmmac_rst = devm_reset_control_get(>dev,
  STMMAC_RESOURCE_NAME);
if (IS_ERR(plat->stmmac_rst)) {
-   if (PTR_ERR(plat->stmmac_rst) == -EPROBE_DEFER)
+   if (PTR_ERR(plat->stmmac_rst) == -EPROBE_DEFER) {
+   rc = PTR_ERR(plat->stmmac_rst);
goto error_hw_init;
+   }
 
dev_info(>dev, "no reset control found\n");
plat->stmmac_rst = NULL;
@@ -615,8 +617,12 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
clk_disable_unprepare(plat->pclk);
 error_pclk_get:
clk_disable_unprepare(plat->stmmac_clk);
+error_dma_cfg_alloc:
+   of_node_put(plat->mdio_node);
+error_dt_phy_parse:
+   of_node_put(plat->phy_node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return ERR_PTR(rc);
 }
 
 /**
-- 
2.29.2



[PATCH 16/25] net: stmmac: Use optional clock request method to get ptp_clk

2020-12-14 Thread Serge Semin
Let's replace the manual implementation of the optional ptp_clk
functionality with method devm_clk_get_optional() provided by the common
clock kernel framework. First of all it will be better from
maintainability point of view. Secondly by doing so we'll also fix a
potential problem, which will come out if the PTP clock has been actually
specified, but the clock framework failed to request it.

Note since we are switching the code to using the optional common clock
API, then there is no need in checking the clk_ptp_ref pointer for being
not NULL before calling the clk_prepare_enable() method. The later will
correctly handle it. So just discard the conditional statement of
priv->plat->clk_ptp_ref pointer value testing in the stmmac_resume()
method.

Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +--
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 13681027dd09..e9003684efc8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5230,8 +5230,7 @@ int stmmac_resume(struct device *dev)
/* enable the clk previously disabled */
clk_prepare_enable(priv->plat->stmmac_clk);
clk_prepare_enable(priv->plat->pclk);
-   if (priv->plat->clk_ptp_ref)
-   clk_prepare_enable(priv->plat->clk_ptp_ref);
+   clk_prepare_enable(priv->plat->clk_ptp_ref);
/* reset the phy so that it's ready */
if (priv->mii)
stmmac_mdio_reset(priv->mii);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 3809b00d3077..367d1458d66d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -589,10 +589,13 @@ stmmac_probe_config_dt(struct platform_device *pdev, 
const char **mac)
clk_prepare_enable(plat->pclk);
 
/* Fall-back to main clock in case of no PTP ref is passed */
-   plat->clk_ptp_ref = devm_clk_get(>dev, "ptp_ref");
+   plat->clk_ptp_ref = devm_clk_get_optional(>dev, "ptp_ref");
if (IS_ERR(plat->clk_ptp_ref)) {
+   rc = PTR_ERR(plat->clk_ptp_ref);
+   dev_err_probe(>dev, rc, "Cannot get PTP clock\n");
+   goto error_hw_init;
+   } else if (!plat->clk_ptp_ref) {
plat->clk_ptp_rate = clk_get_rate(plat->stmmac_clk);
-   plat->clk_ptp_ref = NULL;
dev_info(>dev, "PTP uses main clock\n");
} else {
plat->clk_ptp_rate = clk_get_rate(plat->clk_ptp_ref);
-- 
2.29.2



[PATCH 20/25] net: stmmac: Add Tx/Rx platform clocks support

2020-12-14 Thread Serge Semin
Depending on the DW *MAC configuration it can be at least connected to an
external Transmit clock, but in some cases to an external Receive clock
generator. In order to simplify/unify the sub-drivers code and to prevent
having the same clocks named differently add the Tx/Rx clocks support to
the generic STMMAC DT-based platform data initialization method under the
names "tx" and "rx" respectively. The bindings schema has already been
altered in accordance with that.

Signed-off-by: Serge Semin 
---
 .../ethernet/stmicro/stmmac/stmmac_platform.c | 24 +++
 include/linux/stmmac.h|  2 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 38e8836861c4..943498d57e3a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -588,6 +588,24 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
 
clk_prepare_enable(plat->pclk);
 
+   plat->tx_clk = devm_clk_get_optional(>dev, "tx");
+   if (IS_ERR(plat->tx_clk)) {
+   rc = PTR_ERR(plat->tx_clk);
+   dev_err_probe(>dev, rc, "Cannot get Tx clock\n");
+   goto error_tx_clk_get;
+   }
+
+   clk_prepare_enable(plat->tx_clk);
+
+   plat->rx_clk = devm_clk_get_optional(>dev, "rx");
+   if (IS_ERR(plat->rx_clk)) {
+   rc = PTR_ERR(plat->rx_clk);
+   dev_err_probe(>dev, rc, "Cannot get Rx clock\n");
+   goto error_rx_clk_get;
+   }
+
+   clk_prepare_enable(plat->rx_clk);
+
/* Fall-back to main clock in case of no PTP ref is passed */
plat->clk_ptp_ref = devm_clk_get_optional(>dev, "ptp_ref");
if (IS_ERR(plat->clk_ptp_ref)) {
@@ -613,6 +631,10 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
return plat;
 
 error_hw_init:
+   clk_disable_unprepare(plat->rx_clk);
+error_rx_clk_get:
+   clk_disable_unprepare(plat->tx_clk);
+error_tx_clk_get:
clk_disable_unprepare(plat->pclk);
 error_pclk_get:
clk_disable_unprepare(plat->stmmac_clk);
@@ -634,6 +656,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
 void stmmac_remove_config_dt(struct platform_device *pdev,
 struct plat_stmmacenet_data *plat)
 {
+   clk_disable_unprepare(plat->rx_clk);
+   clk_disable_unprepare(plat->tx_clk);
clk_disable_unprepare(plat->pclk);
clk_disable_unprepare(plat->stmmac_clk);
of_node_put(plat->phy_node);
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 628e28903b8b..b75cf13d088c 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -185,6 +185,8 @@ struct plat_stmmacenet_data {
void *bsp_priv;
struct clk *stmmac_clk;
struct clk *pclk;
+   struct clk *tx_clk;
+   struct clk *rx_clk;
struct clk *clk_ptp_ref;
unsigned int clk_ptp_rate;
unsigned int clk_ref_rate;
-- 
2.29.2



[PATCH 07/25] dt-bindings: net: dwmac: Detach Generic DW MAC bindings

2020-12-14 Thread Serge Semin
Currently the snps,dwmac.yaml DT bindings file is used for both DT nodes
describing generic DW MAC devices and as DT schema with common properties
to be evaluated against a vendor-specific DW MAC IP-cores. Due to such
dual-purpose design the "compatible" property of the common DW MAC schema
needs to contain the vendor-specific strings to successfully pass the
schema evaluation in case if it's referenced from the vendor-specific DT
bindings. That's a bad design from maintainability point of view, since
adding/removing any DW MAC-based device bindings requires the common
schema modification. In order to fix that let's detach the schema which
provides the generic DW MAC DT nodes evaluation into a dedicated DT
bindings file preserving the common DW MAC properties declaration in the
snps,dwmac.yaml file. By doing so we'll still provide a common properties
evaluation for each vendor-specific MAC bindings which refer to the
common bindings file, while the generic DW MAC DT nodes will be checked
against the new snps,dwmac-generic.yaml DT schema.

Signed-off-by: Serge Semin 
---
 .../bindings/net/snps,dwmac-generic.yaml  | 148 ++
 .../devicetree/bindings/net/snps,dwmac.yaml   | 139 +---
 2 files changed, 149 insertions(+), 138 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
new file mode 100644
index ..f1b387911390
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/snps,dwmac-generic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare Generic MAC Device Tree Bindings
+
+maintainers:
+  - Alexandre Torgue 
+  - Giuseppe Cavallaro 
+  - Jose Abreu 
+
+# Select the DT nodes, which have got compatible strings either as just a
+# single string with IP-core name optionally followed by the IP version or
+# two strings: one with IP-core name plus the IP version, another as just
+# the IP-core name.
+select:
+  properties:
+compatible:
+  oneOf:
+- items:
+- pattern: "^snps,dw(xg)+mac(-[0-9]+\\.[0-9]+a?)?$"
+- items:
+- pattern: "^snps,dwmac-[0-9]+\\.[0-9]+a?$"
+- const: snps,dwmac
+- items:
+- pattern: "^snps,dwxgmac-[0-9]+\\.[0-9]+a?$"
+- const: snps,dwxgmac
+
+  required:
+- compatible
+
+allOf:
+  - $ref: snps,dwmac.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - description: Generic Synopsys DW MAC
+oneOf:
+  - items:
+  - enum:
+  - snps,dwmac-3.50a
+  - snps,dwmac-3.610
+  - snps,dwmac-3.70a
+  - snps,dwmac-3.710
+  - snps,dwmac-4.00
+  - snps,dwmac-4.10a
+  - snps,dwmac-4.20a
+  - const: snps,dwmac
+  - const: snps,dwmac
+  - description: Generic Synopsys DW xGMAC
+oneOf:
+  - items:
+  - enum:
+  - snps,dwxgmac-2.10
+  - const: snps,dwxgmac
+  - const: snps,dwxgmac
+  - description: ST SPEAr SoC Family GMAC
+deprecated: true
+const: st,spear600-gmac
+
+  reg:
+maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+  - |
+gmac0: ethernet@e080 {
+  compatible = "snps,dwxgmac-2.10", "snps,dwxgmac";
+  reg = <0xe080 0x8000>;
+  interrupt-parent = <>;
+  interrupts = <24 23 22>;
+  interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+  mac-address = []; /* Filled in by U-Boot */
+  max-frame-size = <3800>;
+  phy-mode = "gmii";
+  snps,multicast-filter-bins = <256>;
+  snps,perfect-filter-entries = <128>;
+  rx-fifo-depth = <16384>;
+  tx-fifo-depth = <16384>;
+  clocks = <>;
+  clock-names = "stmmaceth";
+  snps,axi-config = <_axi_setup>;
+  snps,mtl-rx-config = <_rx_setup>;
+  snps,mtl-tx-config = <_tx_setup>;
+  mdio0 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "snps,dwmac-mdio";
+phy1: ethernet-phy@0 {
+  reg = <0>;
+};
+  };
+};
+  - |
+gmac1: ethernet@f801 {
+  compatible = "snps,dwmac-4.10a", "snps,dwmac";
+  reg = <0xf801 0x4000>;
+  interrupts = <0 98 4>;
+  interrupt-names = "macirq";
+  clock-names = "stmmaceth", "ptp_ref";
+  clocks = < 4>, < 5>;
+  phy-mode = &

[PATCH 05/25] dt-bindings: net: dwmac: Elaborate stmmaceth/pclk description

2020-12-14 Thread Serge Semin
Current clocks description doesn't provide a comprehensive notion about
what "stmmaceth" and "pclk" actually represent from the IP-core manual
point of view. The bindings file states:
stmmaceth - "GMAC main clock",
apb - "Peripheral registers interface clock".
It isn't that easy to understand what they actually mean especially seeing
the DW *MAC manual operates with clock definitions like Application,
System, Host, CSR, Transmit, Receive, etc clocks. Moreover the clocks
usage in the driver doesn't shade a full light on their essence. What
inferred from there is that the "stmmaceth" name has been assigned to the
common clock, which feeds both system and CSR interfaces. But what about
"apb"? The bindings defines it as the clock for "peripheral registers
interface". So it's close to the CSR clock in the IP-core manual notation.
If so then when "apb" clock is specified aside with the "stmmaceth", it
represents a case when the DW *MAC is synthesized with CSR_SLV_CLK=y
(separate system and CSR clocks). But even though the "apb" clock is
requested in the MAC driver, the driver doesn't actually use it as a
separate CSR clock where the IP-core manual requires. All of that makes me
thinking that the case of separate system and CSR clocks isn't correctly
implemented in the driver.

Let's start with elaborating the clocks description so anyone reading
the DW *MAC bindings file would understand that "stmmaceth" is the
system clock and "pclk" is actually the CSR clock. Indeed in accordance
with sheets depicted in [1]:
system/application clock can be either of: hclk_i, aclk_i, clk_app_i;
CSR clock can be either of: hclk_i, aclk_i, clk_app_i, clk_csr_i.
(Most likely the similar definitions present in the others IP-core
manuals.) So the CSR clock can be tied to the application clock
considering the later as the main clock, but not the other way around. In
case if there is only "stmmaceth" clock specified in a DT node, then it
will be considered as a source of clocks for both application and CSR. But
if "pclk" is also specified in the list of the device clocks, then it will
be perceived as the separate CSR clock.

[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 564.

Signed-off-by: Serge Semin 
---
 .../devicetree/bindings/net/snps,dwmac.yaml  | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 44aa88151cba..e1ebe5c8b1da 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -116,8 +116,16 @@ properties:
 maxItems: 5
 additionalItems: true
 items:
-  - description: GMAC main clock
-  - description: Peripheral registers interface clock
+  - description:
+  GMAC main clock, also called as system/application clock.
+  This clock is used to provide a periodic signal for the DMA/MTL
+  interface and optionally for CSR, if the later isn't separately
+  clocked.
+  - description:
+  Peripheral registers interface clock, also called as CSR clock.
+  MCI, CSR and SMA interfaces run on this clock. If it's omitted,
+  the CSR interfaces are considered as synchronous to the system
+  clock domain.
   - description:
   PTP reference clock. This clock is used for programming the
   Timestamp Addend Register. If not passed then the system
-- 
2.29.2



[PATCH 11/25] net: stmmac: dwmac-stm32: Cleanup STMMAC DT-config in remove cb

2020-12-14 Thread Serge Semin
The stmmac_remove_config_dt() method needs to be called on the device
remove procedure otherwise for at least some of device-nodes will be left
requested.

Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev 
leaks")
Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
index 5d4df4c5254e..b45aab38c7b0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -426,6 +426,8 @@ static int stm32_dwmac_remove(struct platform_device *pdev)
 
stm32_dwmac_clk_disable(priv->plat->bsp_priv);
 
+   stmmac_remove_config_dt(pdev, priv->plat);
+
if (dwmac->irq_pwr_wakeup >= 0) {
dev_pm_clear_wake_irq(>dev);
device_init_wakeup(>dev, false);
-- 
2.29.2



[PATCH 09/25] net: stmmac: dwmac-rk: Cleanup STMMAC DT-config in remove cb

2020-12-14 Thread Serge Semin
The stmmac_remove_config_dt() method needs to be called on the device
remove procedure otherwise for at least some of device-nodes will be left
requested.

Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev 
leaks")
Signed-off-by: Serge Semin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 6ef30252bfe0..01c10ca80f1a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1433,11 +1433,14 @@ static int rk_gmac_probe(struct platform_device *pdev)
 
 static int rk_gmac_remove(struct platform_device *pdev)
 {
+   struct stmmac_priv *priv = netdev_priv(platform_get_drvdata(pdev));
struct rk_priv_data *bsp_priv = get_stmmac_bsp_priv(>dev);
int ret = stmmac_dvr_remove(>dev);
 
rk_gmac_powerdown(bsp_priv);
 
+   stmmac_remove_config_dt(pdev, priv->plat);
+
return ret;
 }
 
-- 
2.29.2



[PATCH 00/25] net: stmmac: Fix clocks/reset-related procedures

2020-12-14 Thread Serge Semin
Baikal-T1 SoC is equipped with two Synopsys DesignWare GMAC v3.73a-based
ethernet interfaces with no internal Ethernet PHY attached. The IP-cores
are configured as GMAC-AXI with CSR interface clocked by a dedicated
signal. Each of which has got Rx/Tx FIFOs of 16KB, up to 8 MAC addresses
capability, no embedded filter hash table logic, EEE enabled, IEEE 1588
and 1588-2008 Advanced timestamping capabilities, power management with
remote wake-up, IP CSUM hardware acceleration, a single PHY interface -
RGMII with MDIO bus, 1xGPI and 1xGPO.

This is a very first series of patches with fixes we've found to be
required in order to make things working well for our setup. The series
has turned to be rather large, but most of the patches are trivial and
some of them are just cleanups, so it shouldn't be that hard to review.

The series starts with fixes of the PBL (Programmable DMA Burst length)
DT-property, which is supposed to be defined for each DW *MAC IP-core, but
not only for a Allwinner sun* GMAC and DW xGMAC. The number of possible
PBL values need to be also extended in accordance with the DW *MAC manual.
Then the TSO flag property should be also declared free of the
vendor-specific conditional schema, because the driver expects the
compatible string to have the IP-core version specified anyway and none of
the glue-drivers refer to the property directly.

Then we suggest to refactor the "snps,{axi,mtl-rx,mtl-tx}-config"
properties/nodes declaration, so the configs would be able to be defined
as the sub-nodes of the DW *MAC DT nodes. The reason is that the DW MAC
DT-schema doesn't validate them at the moment and having them defined as
separate from the DW MAC nodes isn't descriptive at all. (Please note the
patch log, since the DT-schema tool needs to be fixed in order to make the
change working).

Another big modification of the DW *MAC bindings file is the generic
DT-properties and generic DT-nodes schema splitting up. So in order to
improve the DW *MAC bindings maintainability we suggest to leave the
generic DW *MAC properties definition in the "snps,dwmac.yaml" file and
move the bindings for the generic DW *MAC DT-nodes validation in the
dedicated DT-schema "snps,dwmac-generic.yaml".

Another concern has been related with the System/CSR clocks. We have
discovered that currently the "stmmaceth" clocks are considered by the
driver as the combined system+CSR clocks, while in fact CSR interface can
be equipped with a dedicated clock source (this is our case). If so then
the clock with "pclk" can be used to define the later one. But neither
bindings are descriptive enough nor the DW *MAC driver is fixed to support
that feature. So first we suggest to elaborate stmmaceth/pclk description
in the bindings file and then fix the MDIO-bus clock selection procedure
so pclk would be used there if specified. The DW QoS Eth MAC driver is
also fixed in accordance with that modification.

The biggest part of the series concerns adding the generic Tx/Rx clocks
support to the DT-schema and to the DW MAC drivers and with fixed related
to that. It is really a good decision to add the generic Tx/Rx clocks,
because a lot of the glue-drivers expect them to be specified in the
DT-node. So first we add the "tx"/"rx" clocks declaration in the generic
DW MAC DT-schema. Then the glue-drivers like
dwmac-rk/dwmac-sti/dwmac-stm32 remove() callbacks need to be fixed to call
stmmac_remove_config_dt() otherwise the resources allocated in the
stmmac_probe_config_dt() won't be freed on the device removal. A small
modification needs to be provided for the cleanup-on-failure path of the
stmmac_probe_config_dt() method in order to improve its maintainability.
Then we've discovered that the "stmmaceth" and "pclk" clocks while being
acquired and enabled in the stmmac_probe_config_dt() method are disabled
in the stmmac_dvr_remove() function, which is erroneous for every
cleanup-on-failure path of the glue-driver probe methods. Finally before
adding the Tx/Rx clocks support we provide a set of optimizations of the
"stmmaceth"/"pclk"/"ptp_clk" clocks and the "stmmaceth" reset procedures
by removing the manual optional resources acquisition/enable/disable
implementation with the one provided by the corresponding subsystems.
Since the generic Tx/Rx clocks have been added we can freely remove the
similar clocks handling from the glue-drivers.

(Please note I have also discovered, but didn't try to fix the Allwinner
Sun8i cleanup-on-failure path implemented in the DW MAC probe() procedure.
It has been broken since don't know what time and it's a bit too
complicated to be fixed with no hardware at hands.)

That's it for now. The next series will concern the GPIOs support and
Baikal-T1 SoC specific bindings.

Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev 
leaks")
Fixes: f573c0b9

[PATCH 04/25] dt-bindings: net: dwmac: Refactor snps,*-config properties

2020-12-14 Thread Serge Semin
Currently the "snps,axi-config", "snps,mtl-rx-config" and
"snps,mtl-tx-config" properties are declared as a single phandle reference
to a node with corresponding parameters defined. That's not good for
several reasons. First of all scattering around a device tree some
particular device-specific configs with no visual relation to that device
isn't suitable from maintainability point of view. That leads to a
disturbed representation of the actual device tree mixing actual device
nodes and some vendor-specific configs. Secondly using the same configs
set for several device nodes doesn't represent well the devices structure,
since the interfaces these configs describe in hardware belong to
different devices and may actually differ. In the later case having the
configs node separated from the corresponding device nodes gets to be
even unjustified.

So instead of having a separate DW *MAC configs nodes we suggest to
define them as sub-nodes of the device nodes, which interfaces they
actually describe. By doing so we'll make the DW *MAC nodes visually
correct describing all the aspects of the IP-core configuration. Thus
we'll be able to describe the configs sub-nodes bindings right in the
snps,dwmac.yaml file.

Note the former "snps,axi-config", "snps,mtl-rx-config" and
"snps,mtl-tx-config" bindings have been marked as deprecated.

Signed-off-by: Serge Semin 

---

Note the current DT schema tool requires the vendor-specific properties to be
defined in accordance with the schema: dtschema/meta-schemas/vendor-props.yaml
It means the property can be;
- boolean,
- string,
- defined with $ref and additional constraints,
- defined with allOf: [ $ref ] and additional constraints.

The modification provided by this commit needs to extend that definition to
make the DT schema tool correctly parse this schema. That is we need to let
the vendors-specific properties to also accept the oneOf-based combined
sub-schema. Like this:

--- a/dtschema/meta-schemas/vendor-props.yaml
+++ b/dtschema/meta-schemas/vendor-props.yaml
@@ -48,15 +48,24 @@
   - properties:   # A property with a type and additional constraints
   $ref:
 pattern: "types.yaml#[\/]{0,1}definitions\/.*"
-  allOf:
-items:
-  - properties:
+
+if:
+  not:
+required:
+  - $ref
+then:
+  patternProperties:
+"^(all|one)Of$":
+  contains:
+properties:
   $ref:
 pattern: "types.yaml#[\/]{0,1}definitions\/.*"
 required:
   - $ref
-oneOf:
+
+anyOf:
   - required: [ $ref ]
   - required: [ allOf ]
+  - required: [ oneOf ]

 ...
---
 .../devicetree/bindings/net/snps,dwmac.yaml   | 380 +-
 1 file changed, 288 insertions(+), 92 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 0dd543c6c08e..44aa88151cba 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -150,69 +150,251 @@ properties:
   in a different mode than the PHY in order to function.
 
   snps,axi-config:
-$ref: /schemas/types.yaml#definitions/phandle
-description:
-  AXI BUS Mode parameters. Phandle to a node that can contain the
-  following properties
-* snps,lpi_en, enable Low Power Interface
-* snps,xit_frm, unlock on WoL
-* snps,wr_osr_lmt, max write outstanding req. limit
-* snps,rd_osr_lmt, max read outstanding req. limit
-* snps,kbbe, do not cross 1KiB boundary.
-* snps,blen, this is a vector of supported burst length.
-* snps,fb, fixed-burst
-* snps,mb, mixed-burst
-* snps,rb, rebuild INCRx Burst
+description: AXI BUS Mode parameters
+oneOf:
+  - deprecated: true
+$ref: /schemas/types.yaml#definitions/phandle
+  - type: object
+properties:
+  snps,lpi_en:
+$ref: /schemas/types.yaml#definitions/flag
+description: Enable Low Power Interface
+
+  snps,xit_frm:
+$ref: /schemas/types.yaml#definitions/flag
+description: Unlock on WoL
+
+  snps,wr_osr_lmt:
+$ref: /schemas/types.yaml#definitions/uint32
+description: Max write outstanding req. limit
+default: 1
+minimum: 0
+maximum: 15
+
+  snps,rd_osr_lmt:
+$ref: /schemas/types.yaml#definitions/uint32
+description: Max read outstanding req. limit
+default: 1
+minimum: 0
+maximum: 15
+
+  snps,kbbe:
+$ref: /schemas/types.yaml#definitions/flag
+description: Do not cross 1KiB bounda

[PATCH 03/25] dt-bindings: net: dwmac: Fix the TSO property declaration

2020-12-14 Thread Serge Semin
Indeed the STMMAC driver doesn't take the vendor-specific compatible
string into account to parse the "snps,tso" boolean property. It just
makes sure the node is compatible with DW MAC 4.x, 5.x and DW xGMAC
IP-cores. Fix the conditional statement so the TSO-property would be
evaluated for the compatibles having the corresponding IP-core version.

While at it move the whole allOf-block from the tail of the binding file
to the head of it, as it's normally done in the most of the DT schemas.

Signed-off-by: Serge Semin 

---

Note this won't break the bindings description, since the "snps,tso"
property isn't parsed by the Allwinner SunX GMAC glue driver, but only
by the generic platform DT-parser.
---
 .../devicetree/bindings/net/snps,dwmac.yaml   | 52 +--
 1 file changed, 24 insertions(+), 28 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index e084fbbf976e..0dd543c6c08e 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -37,6 +37,30 @@ select:
   required:
 - compatible
 
+allOf:
+  - $ref: "ethernet-controller.yaml#"
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - snps,dwmac-4.00
+  - snps,dwmac-4.10a
+  - snps,dwmac-4.20a
+  - snps,dwmac-5.10a
+  - snps,dwxgmac
+  - snps,dwxgmac-2.10
+
+  required:
+- compatible
+then:
+  properties:
+snps,tso:
+  $ref: /schemas/types.yaml#definitions/flag
+  description:
+Enables the TSO feature otherwise it will be managed by
+MAC HW capability register.
+
 properties:
 
   # We need to include all the compatibles from schemas that will
@@ -314,34 +338,6 @@ dependencies:
   snps,reset-active-low: ["snps,reset-gpio"]
   snps,reset-delay-us: ["snps,reset-gpio"]
 
-allOf:
-  - $ref: "ethernet-controller.yaml#"
-  - if:
-  properties:
-compatible:
-  contains:
-enum:
-  - allwinner,sun7i-a20-gmac
-  - allwinner,sun8i-a83t-emac
-  - allwinner,sun8i-h3-emac
-  - allwinner,sun8i-r40-emac
-  - allwinner,sun8i-v3s-emac
-  - allwinner,sun50i-a64-emac
-  - snps,dwmac-4.00
-  - snps,dwmac-4.10a
-  - snps,dwmac-4.20a
-  - snps,dwxgmac
-  - snps,dwxgmac-2.10
-  - st,spear600-gmac
-
-then:
-  properties:
-snps,tso:
-  $ref: /schemas/types.yaml#definitions/flag
-  description:
-Enables the TSO feature otherwise it will be managed by
-MAC HW capability register.
-
 additionalProperties: true
 
 examples:
-- 
2.29.2



[PATCH 02/25] dt-bindings: net: dwmac: Extend number of PBL values

2020-12-14 Thread Serge Semin
In accordance with [1] the permitted PBL values can be set as one of
[1, 2, 4, 8, 16, 32]. The rest of the values results in undefined
behavior. At the same time some of the permitted values can be also
invalid depending on the controller FIFOs size and the data bus width.
Seeing due to having too many variables all the possible PBL property
constraints can't be implemented in the bindings schema, let's extend
the set of permitted PBL values to be as much as the configuration
register supports leaving the undefined behaviour cases for developers
to handle.

[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 380.

Signed-off-by: Serge Semin 
---
 Documentation/devicetree/bindings/net/snps,dwmac.yaml | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 4b672499f20d..e084fbbf976e 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -264,23 +264,26 @@ properties:
 
   snps,pbl:
 description:
-  Programmable Burst Length (tx and rx)
+  Programmable Burst Length (tx and rx). Note some of these values
+  can be still invalid due to HW limitations connected with the data
+  bus width and the FIFOs depth, so a total length of a single DMA
+  burst shouldn't exceed half the FIFO depth.
 $ref: /schemas/types.yaml#definitions/uint32
-enum: [2, 4, 8]
+enum: [1, 2, 4, 8, 16, 32]
 
   snps,txpbl:
 description:
   Tx Programmable Burst Length. If set, DMA tx will use this
   value rather than snps,pbl.
 $ref: /schemas/types.yaml#definitions/uint32
-enum: [2, 4, 8]
+enum: [1, 2, 4, 8, 16, 32]
 
   snps,rxpbl:
 description:
   Rx Programmable Burst Length. If set, DMA rx will use this
   value rather than snps,pbl.
 $ref: /schemas/types.yaml#definitions/uint32
-enum: [2, 4, 8]
+enum: [1, 2, 4, 8, 16, 32]
 
   snps,no-pbl-x8:
 $ref: /schemas/types.yaml#definitions/flag
-- 
2.29.2



[PATCH v4 01/10] arm: dts: keystone: Correct DWC USB3 compatible string

2020-12-10 Thread Serge Semin
Syonpsys IP cores are supposed to be defined with "snps" vendor-prefix.
Use it instead of the deprecated "synopsys" one.

Signed-off-by: Serge Semin 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/keystone-k2e.dtsi | 2 +-
 arch/arm/boot/dts/keystone.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi 
b/arch/arm/boot/dts/keystone-k2e.dtsi
index 2d94faf31fab..fa1b8499c5a7 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -79,7 +79,7 @@ keystone_usb1: usb@2500 {
status = "disabled";
 
usb1: dwc3@2501 {
-   compatible = "synopsys,dwc3";
+   compatible = "snps,dwc3";
reg = <0x2501 0x7>;
interrupts = ;
usb-phy = <_phy>, <_phy>;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index c298675a29a5..8d046a1b690c 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -218,7 +218,7 @@ keystone_usb0: usb@268 {
status = "disabled";
 
usb0: dwc3@269 {
-   compatible = "synopsys,dwc3";
+   compatible = "snps,dwc3";
reg = <0x269 0x7>;
interrupts = ;
usb-phy = <_phy>, <_phy>;
-- 
2.29.2



[PATCH v4 08/10] arm64: dts: apm: Harmonize DWC USB3 DT nodes name

2020-12-10 Thread Serge Semin
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named despite of the warning comment about possible backward
compatibility issues.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++--
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index a83c82c50e29..832dd85b00bd 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -597,8 +597,8 @@ serial0: serial@1060 {
interrupts = <0x0 0x4c 0x4>;
};
 
-   /* Do not change dwusb name, coded for backward compatibility */
-   usb0: dwusb@1900 {
+   /* Node-name might need to be coded as dwusb for backward 
compatibility */
+   usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg =  <0x0 0x1900 0x0 0x10>;
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 0f37e77f5459..1520a945b7f9 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -923,8 +923,8 @@ sata3: sata@1a80 {
phy-names = "sata-phy";
};
 
-   /* Do not change dwusb name, coded for backward compatibility */
-   usb0: dwusb@1900 {
+   /* Node-name might need to be coded as dwusb for backward 
compatibility */
+   usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg =  <0x0 0x1900 0x0 0x10>;
@@ -933,7 +933,7 @@ usb0: dwusb@1900 {
dr_mode = "host";
};
 
-   usb1: dwusb@1980 {
+   usb1: usb@1980 {
status = "disabled";
compatible = "snps,dwc3";
reg =  <0x0 0x1980 0x0 0x10>;
-- 
2.29.2



[PATCH v4 05/10] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name

2020-12-10 Thread Serge Semin
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
---
 arch/powerpc/boot/dts/akebono.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/boot/dts/akebono.dts 
b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@301 {
interrupts = <93 2>;
};
 
-   EHCI0: ehci@3001000 {
+   EHCI0: usb@3001000 {
compatible = "ibm,476gtr-ehci", "generic-ehci";
reg = <0x300 0x1000 0x0 0x1>;
interrupt-parent = <>;
@@ -140,14 +140,14 @@ SD0: sd@300 {
interrupt-parent = <>;
};
 
-   OHCI0: ohci@3001001 {
+   OHCI0: usb@3001001 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1001 0x0 0x1>;
interrupt-parent = <>;
interrupts = <89 1>;
};
 
-   OHCI1: ohci@3001002 {
+   OHCI1: usb@3001002 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1002 0x0 0x1>;
interrupt-parent = <>;
-- 
2.29.2



[PATCH v4 10/10] arm64: dts: qcom: Harmonize DWC USB3 DT nodes name

2020-12-10 Thread Serge Semin
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
Reviewed-by: Bjorn Andersson 
---
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++--
 arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++--
 arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +-
 arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
 9 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index defcbd15edf9..34e97da98270 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -1064,7 +1064,7 @@  {
status = "okay";
extcon = <_id>;
 
-   dwc3@760 {
+   usb@760 {
extcon = <_id>;
dr_mode = "otg";
maximum-speed = "high-speed";
@@ -1075,7 +1075,7 @@  {
status = "okay";
extcon = <_id>;
 
-   dwc3@6a0 {
+   usb@6a0 {
extcon = <_id>;
dr_mode = "otg";
};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi 
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index 829e37ac82f6..984e855bd8fd 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -427,7 +427,7 @@ usb_0: usb@8af8800 {
resets = < GCC_USB0_BCR>;
status = "disabled";
 
-   dwc_0: dwc3@8a0 {
+   dwc_0: usb@8a0 {
compatible = "snps,dwc3";
reg = <0x8a0 0xcd00>;
interrupts = ;
@@ -468,7 +468,7 @@ usb_1: usb@8cf8800 {
resets = < GCC_USB1_BCR>;
status = "disabled";
 
-   dwc_1: dwc3@8c0 {
+   dwc_1: usb@8c0 {
compatible = "snps,dwc3";
reg = <0x8c0 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index fd6ae5464dea..4b073b8584de 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -1768,7 +1768,7 @@ usb3: usb@6af8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
 
-   dwc3@6a0 {
+   usb@6a0 {
compatible = "snps,dwc3";
reg = <0x06a0 0xcc00>;
interrupts = <0 131 IRQ_TYPE_LEVEL_HIGH>;
@@ -1979,7 +1979,7 @@ usb2: usb@76f8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
 
-   dwc3@760 {
+   usb@760 {
compatible = "snps,dwc3";
reg = <0x0760 0xcc00>;
interrupts = <0 138 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index c45870600909..7cc7897e7b83 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -1678,7 +1678,7 @@ usb3: usb@a8f8800 {
 
resets = < GCC_USB_30_BCR>;
 
-   usb3_dwc3: dwc3@a80 {
+   usb3_dwc3: usb@a80 {
compatible = "snps,dwc3";
reg = <0x0a80 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi 
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index a80c578484ba..f8a55307b855 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -337,7 +337,7 @@ _phy_sec {
  {
status = "okay";
 
-   dwc3@758 {
+   usb@758 {
dr_mode = "host";
};
 };
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi 
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
inde

[PATCH v4 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names

2020-12-10 Thread Serge Semin
In accordance with the USB HCD/DRD schema all the USB controllers are
supposed to have DT-nodes named with prefix "^usb(@.*)?".  Since the
existing DT-nodes will be renamed in a subsequent patch let's first make
sure the DWC3 Qualcomm driver supports them and second falls back to the
deprecated naming so not to fail on the legacy DTS-files passed to the
newer kernels.

Signed-off-by: Serge Semin 
Reviewed-by: Bjorn Andersson 
---
 drivers/usb/dwc3/dwc3-qcom.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index c703d552bbcf..49ad8d507d37 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct 
platform_device *pdev)
struct device   *dev = >dev;
int ret;
 
-   dwc3_np = of_get_child_by_name(np, "dwc3");
+   dwc3_np = of_get_child_by_name(np, "usb") ?:
+ of_get_child_by_name(np, "dwc3");
if (!dwc3_np) {
dev_err(dev, "failed to find dwc3 core child\n");
return -ENODEV;
-- 
2.29.2



[PATCH v4 07/10] arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name

2020-12-10 Thread Serge Semin
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
Reviewed-by: Patrice Chotard 
---
 arch/arm/boot/dts/stih407-family.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index 23a1746f3baa..2352f76b5a69 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -681,7 +681,7 @@ st_dwc3: dwc3@8f94000 {
 
status = "disabled";
 
-   dwc3: dwc3@990 {
+   dwc3: usb@990 {
compatible  = "snps,dwc3";
reg = <0x0990 0x10>;
interrupts  = ;
-- 
2.29.2



[PATCH v4 06/10] arm: dts: keystone: Harmonize DWC USB3 DT nodes name

2020-12-10 Thread Serge Semin
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/keystone-k2e.dtsi | 4 ++--
 arch/arm/boot/dts/keystone.dtsi | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi 
b/arch/arm/boot/dts/keystone-k2e.dtsi
index fa1b8499c5a7..b8f152e7af7f 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -52,7 +52,7 @@  {
 
usb: usb@268 {
interrupts = ;
-   dwc3@269 {
+   usb@269 {
interrupts = ;
};
};
@@ -78,7 +78,7 @@ keystone_usb1: usb@2500 {
dma-ranges;
status = "disabled";
 
-   usb1: dwc3@2501 {
+   usb1: usb@2501 {
compatible = "snps,dwc3";
reg = <0x2501 0x7>;
interrupts = ;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 8d046a1b690c..fc9fdc857ae8 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -217,7 +217,7 @@ keystone_usb0: usb@268 {
dma-ranges;
status = "disabled";
 
-   usb0: dwc3@269 {
+   usb0: usb@269 {
compatible = "snps,dwc3";
reg = <0x269 0x7>;
interrupts = ;
-- 
2.29.2



[PATCH RESEND v4 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name

2020-12-10 Thread Serge Semin
un Li 
Cc: linux-snps-...@lists.infradead.org
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Serge Semin (10):
  arm: dts: keystone: Correct DWC USB3 compatible string
  arm64: dts: amlogic: meson-g12: Set FL-adj property value
  arc: dts: Harmonize EHCI/OHCI DT nodes name
  arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
  powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
  arm: dts: keystone: Harmonize DWC USB3 DT nodes name
  arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name
  arm64: dts: apm: Harmonize DWC USB3 DT nodes name
  usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
  arm64: dts: qcom: Harmonize DWC USB3 DT nodes name

 arch/arc/boot/dts/axc003.dtsi | 4 ++--
 arch/arc/boot/dts/axc003_idu.dtsi | 4 ++--
 arch/arc/boot/dts/axs10x_mb.dtsi  | 4 ++--
 arch/arc/boot/dts/hsdk.dts| 4 ++--
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi  | 2 +-
 arch/arm/boot/dts/keystone-k2e.dtsi   | 6 +++---
 arch/arm/boot/dts/keystone.dtsi   | 4 ++--
 arch/arm/boot/dts/lpc18xx.dtsi| 4 ++--
 arch/arm/boot/dts/stih407-family.dtsi | 2 +-
 arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 +-
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi| 4 ++--
 arch/arm64/boot/dts/apm/apm-storm.dtsi| 6 +++---
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi  | 4 ++--
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/qcs404-evb.dtsi  | 2 +-
 arch/arm64/boot/dts/qcom/qcs404.dtsi  | 4 ++--
 arch/arm64/boot/dts/qcom/sc7180.dtsi  | 2 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi  | 4 ++--
 arch/arm64/boot/dts/qcom/sm8150.dtsi  | 2 +-
 arch/powerpc/boot/dts/akebono.dts | 6 +++---
 drivers/usb/dwc3/dwc3-qcom.c  | 3 ++-
 23 files changed, 42 insertions(+), 41 deletions(-)

-- 
2.29.2



<    1   2   3   4   5   6   7   8   9   10   >