[PATCH net-next v12 00/15] stmmac: Add Loongson platform support

[PATCH net-next v12 00/15] stmmac: Add Loongson platform support

[Yanteng Si]

v12:
* The biggest change is the re-splitting of patches.
* Add a "gmac_version" in loongson_data, then we only
  read it once in the _probe().
* Drop Serge's patch.
* Rebase to the latest code state.
* Fixed the gnet commit message.

v11:
* Break loongson_phylink_get_caps(), fix bad logic.
* Remove a unnecessary ";".
* Remove some unnecessary "{}".
* add a blank.
* Move the code of fix _force_1000 to patch 6/6.

The main changes occur in these two functions:
loongson_dwmac_probe();
loongson_dwmac_setup();

v10:
As Andrew's comment:
* Add a #define for the 0x37.
* Add a #define for Port Select.

others:
* Pick Serge's patch, This patch resulted from the process
  of reviewing our patch set.
* Based on Serge's patch, modify our loongson_phylink_get_caps().
* Drop patch 3/6, we need mac_interface.
* Adjusted the code layout of gnet patch.
* Corrected several errata in commit message.
* Move DISABLE_FORCE flag to loongson_gnet_data().

v9:
We have not provided a detailed list of equipment for a long time,
and I apologize for this. During this period, I have collected some
information and now present it to you, hoping to alleviate the pressure
of review.

1. IP core
We now have two types of IP cores, one is 0x37, similar to dwmac1000;
The other is 0x10.  Compared to 0x37, we split several DMA registers
from one to two, and it is not worth adding a new entry for this.
According to Serge's comment, we made these devices work by overwriting
priv->synopsys_id = 0x37 and mac->dma = <LS_dma_ops>.

1.1.  Some more detailed information
The number of DMA channels for 0x37 is 1; The number of DMA channels
for 0x10 is 8.  Except for channel 0, otherchannels do not support
sending hardware checksums. Supported AV features are Qav, Qat, and Qas,
and the rest are consistent with 3.73.

2. DEVICE
We have two types of devices,
one is GMAC, which only has a MAC chip inside and needs an external PHY
chip;
the other is GNET, which integrates both MAC and PHY chips inside.

2.1.  Some more detailed information
GMAC device: LS7A1000, LS2K1000, these devices do not support any pause
mode.
gnet device: LS7A2000, LS2K2000, the chip connection between the mac and
             phy of these devices is not normal and requires two rounds of
             negotiation; LS7A2000 does not support half-duplex and
multi-channel;
             to enable multi-channel on LS2K2000, you need to turn off
hardware checksum.
**Note**: Only the LS2K2000's IP core is 0x10, while the IP cores of other
devices are 0x37.

3. TABLE

device    type    pci_id    ip_core
ls7a1000  gmac    7a03      0x35/0x37
ls2k1000  gmac    7a03      0x35/0x37
ls7a2000  gnet    7a13      0x37
ls2k2000  gnet    7a13      0x10
-----------------------------------------------
Changes:

* passed the CI
  <https://github.com/linux-netdev/nipa/blob/main/tests/patch/checkpatch
  /checkpatch.sh>
* reverse xmas tree order.
* Silence build warning.
* Re-split the patch.
* Add more detailed commit message.
* Add more code comment.
* Reduce modification of generic code.
* using the GNET-specific prefix.
* define a new macro for the GNET MAC.
* Use an easier way to overwrite mac.
* Removed some useless printk.


v8:
* The biggest change is according to Serge's comment in the previous
  edition:
   Seeing the patch in the current state would overcomplicate the generic
   code and the only functions you need to update are
   dwmac_dma_interrupt()
   dwmac1000_dma_init_channel()
   you can have these methods re-defined with all the Loongson GNET
   specifics in the low-level platform driver (dwmac-loongson.c). After
   that you can just override the mac_device_info.dma pointer with a
   fixed stmmac_dma_ops descriptor. Here is what should be done for that:

   1. Keep the Patch 4/9 with my comments fixed. First it will be partly
   useful for your GNET device. Second in general it's a correct
   implementation of the normal DW GMAC v3.x multi-channels feature and
   will be useful for the DW GMACs with that feature enabled.

   2. Create the Loongson GNET-specific
   stmmac_dma_ops.dma_interrupt()
   stmmac_dma_ops.init_chan()
   methods in the dwmac-loongson.c driver. Don't forget to move all the
   Loongson-specific macros from dwmac_dma.h to dwmac-loongson.c.

   3. Create a Loongson GNET-specific platform setup method with the next
   semantics:
      + allocate stmmac_dma_ops instance and initialize it with
        dwmac1000_dma_ops.
      + override the stmmac_dma_ops.{dma_interrupt, init_chan} with
        the pointers to the methods defined in 2.
      + allocate mac_device_info instance and initialize the
        mac_device_info.dma field with a pointer to the new
        stmmac_dma_ops instance.
      + call dwmac1000_setup() or initialize mac_device_info in a way
        it's done in dwmac1000_setup() (the later might be better so you
        wouldn't need to export the dwmac1000_setup() function).
      + override stmmac_priv.synopsys_id with a correct value.

   4. Initialize plat_stmmacenet_data.setup() with the pointer to the
   method created in 3.

* Others:
  Re-split the patch.
  Passed checkpatch.pl test.

v7:
* Refer to andrew's suggestion:
  - Add DMA_INTR_ENA_NIE_RX and DMA_INTR_ENA_NIE_TX #define's, etc.

* Others:
  - Using --subject-prefix="PATCH net-next vN" to indicate that the
    patches are for the networking tree.
  - Rebase to the latest networking tree:
    <git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git>


v6:

* Refer to Serge's suggestion:
  - Add new platform feature flag:
    include/linux/stmmac.h:
    +#define STMMAC_FLAG_HAS_LGMAC			BIT(13)

  - Add the IRQs macros specific to the Loongson Multi-channels GMAC:
     drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h:
     +#define DMA_INTR_ENA_NIE_LOONGSON 0x00060000      /* ...*/
     #define DMA_INTR_ENA_NIE 0x00010000	/* Normal Summary */
     ...

  - Drop all of redundant changes that don't require the
    prototypes being converted to accepting the stmmac_priv
    pointer.

* Refer to andrew's suggestion:
  - Drop white space changes.
  - break patch up into lots of smaller parts.
     Some small patches have been put into another series as a preparation
     see <https://lore.kernel.org/loongarch/cover.1702289232.git.siyanteng@loongson.cn/T/#t>
     
     *note* : This series of patches relies on the three small patches above.
* others
  - Drop irq_flags changes.
  - Changed patch order.


v4 -> v5:

* Remove an ugly and useless patch (fix channel number).
* Remove the non-standard dma64 driver code, and also remove
  the HWIF entries, since the associated custom callbacks no
  longer exist.
* Refer to Serge's suggestion: Update the dwmac1000_dma.c to
  support the multi-DMA-channels controller setup.

See:
v4: <https://lore.kernel.org/loongarch/cover.1692696115.git.chenfeiyang@loongson.cn/>
v3: <https://lore.kernel.org/loongarch/cover.1691047285.git.chenfeiyang@loongson.cn/>
v2: <https://lore.kernel.org/loongarch/cover.1690439335.git.chenfeiyang@loongson.cn/>
v1: <https://lore.kernel.org/loongarch/cover.1689215889.git.chenfeiyang@loongson.cn/>

Yanteng Si (15):
  net: stmmac: Move the atds flag to the stmmac_dma_cfg structure
  net: stmmac: Add multi-channel support
  net: stmmac: Export dwmac1000_dma_ops
  net: stmmac: dwmac-loongson: Drop useless platform data
  net: stmmac: dwmac-loongson: Use PCI_DEVICE_DATA() macro for device
    identification
  net: stmmac: dwmac-loongson: Split up the platform data initialization
  net: stmmac: dwmac-loongson: Add ref and ptp clocks for Loongson
  net: stmmac: dwmac-loongson: Add phy mask for Loongson GMAC
  net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC
  net: stmmac: dwmac-loongson: Add full PCI support
  net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
  net: stmmac: dwmac-loongson: Fixed failure to set network speed to
    1000.
  net: stmmac: dwmac-loongson: Add Loongson GNET support
  net: stmmac: dwmac-loongson: Move disable_force flag to _gnet_date
  net: stmmac: dwmac-loongson: Add loongson module author

 drivers/net/ethernet/stmicro/stmmac/common.h  |   1 +
 .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 519 ++++++++++++++++--
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c |   4 +-
 .../ethernet/stmicro/stmmac/dwmac1000_dma.c   |  35 +-
 .../ethernet/stmicro/stmmac/dwmac100_dma.c    |   2 +-
 .../net/ethernet/stmicro/stmmac/dwmac4_dma.c  |   2 +-
 .../net/ethernet/stmicro/stmmac/dwmac_dma.h   |  20 +-
 .../net/ethernet/stmicro/stmmac/dwmac_lib.c   |  30 +-
 .../ethernet/stmicro/stmmac/dwxgmac2_dma.c    |   2 +-
 drivers/net/ethernet/stmicro/stmmac/hwif.h    |   5 +-
 .../ethernet/stmicro/stmmac/stmmac_ethtool.c  |   6 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  11 +-
 include/linux/stmmac.h                        |   2 +
 13 files changed, 536 insertions(+), 103 deletions(-)

-- 
2.31.4

[PATCH net-next v12 01/15] net: stmmac: Move the atds flag to the stmmac_dma_cfg structure

[Yanteng Si]

Alternate Descriptor Size (ATDS) is a part of the DMA-configs together
with the PBL, ALL, AEME, etc so the structure is the most suitable
place for it.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c   | 2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 4 ++--
 drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c  | 2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c    | 2 +-
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c  | 2 +-
 drivers/net/ethernet/stmicro/stmmac/hwif.h          | 3 +--
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c   | 5 ++---
 include/linux/stmmac.h                              | 1 +
 8 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index e1b761dcfa1d..d87079016952 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -299,7 +299,7 @@ static int sun8i_dwmac_dma_reset(void __iomem *ioaddr)
  * Called from stmmac via stmmac_dma_ops->init
  */
 static void sun8i_dwmac_dma_init(void __iomem *ioaddr,
-				 struct stmmac_dma_cfg *dma_cfg, int atds)
+				 struct stmmac_dma_cfg *dma_cfg)
 {
 	writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
 	writel(0x1FFFFFF, ioaddr + EMAC_INT_STA);
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index daf79cdbd3ec..bb82ee9b855f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -71,7 +71,7 @@ static void dwmac1000_dma_axi(void __iomem *ioaddr, struct stmmac_axi *axi)
 }
 
 static void dwmac1000_dma_init(void __iomem *ioaddr,
-			       struct stmmac_dma_cfg *dma_cfg, int atds)
+			       struct stmmac_dma_cfg *dma_cfg)
 {
 	u32 value = readl(ioaddr + DMA_BUS_MODE);
 	int txpbl = dma_cfg->txpbl ?: dma_cfg->pbl;
@@ -98,7 +98,7 @@ static void dwmac1000_dma_init(void __iomem *ioaddr,
 	if (dma_cfg->mixed_burst)
 		value |= DMA_BUS_MODE_MB;
 
-	if (atds)
+	if (dma_cfg->atds)
 		value |= DMA_BUS_MODE_ATDS;
 
 	if (dma_cfg->aal)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
index dea270f60cc3..f861babc06f9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
@@ -19,7 +19,7 @@
 #include "dwmac_dma.h"
 
 static void dwmac100_dma_init(void __iomem *ioaddr,
-			      struct stmmac_dma_cfg *dma_cfg, int atds)
+			      struct stmmac_dma_cfg *dma_cfg)
 {
 	/* Enable Application Access by writing to DMA CSR0 */
 	writel(DMA_BUS_MODE_DEFAULT | (dma_cfg->pbl << DMA_BUS_MODE_PBL_SHIFT),
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 84d3a8551b03..e0165358c4ac 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -153,7 +153,7 @@ static void dwmac410_dma_init_channel(struct stmmac_priv *priv,
 }
 
 static void dwmac4_dma_init(void __iomem *ioaddr,
-			    struct stmmac_dma_cfg *dma_cfg, int atds)
+			    struct stmmac_dma_cfg *dma_cfg)
 {
 	u32 value = readl(ioaddr + DMA_SYS_BUS_MODE);
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index dd2ab6185c40..7840bc403788 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -20,7 +20,7 @@ static int dwxgmac2_dma_reset(void __iomem *ioaddr)
 }
 
 static void dwxgmac2_dma_init(void __iomem *ioaddr,
-			      struct stmmac_dma_cfg *dma_cfg, int atds)
+			      struct stmmac_dma_cfg *dma_cfg)
 {
 	u32 value = readl(ioaddr + XGMAC_DMA_SYSBUS_MODE);
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 90384db228b5..413441eb6ea0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -175,8 +175,7 @@ struct dma_features;
 struct stmmac_dma_ops {
 	/* DMA core initialization */
 	int (*reset)(void __iomem *ioaddr);
-	void (*init)(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg,
-		     int atds);
+	void (*init)(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg);
 	void (*init_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
 			  struct stmmac_dma_cfg *dma_cfg, u32 chan);
 	void (*init_rx_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 59bf83904b62..188514ca6c47 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3006,7 +3006,6 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv)
 	struct stmmac_rx_queue *rx_q;
 	struct stmmac_tx_queue *tx_q;
 	u32 chan = 0;
-	int atds = 0;
 	int ret = 0;
 
 	if (!priv->plat->dma_cfg || !priv->plat->dma_cfg->pbl) {
@@ -3015,7 +3014,7 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv)
 	}
 
 	if (priv->extend_desc && (priv->mode == STMMAC_RING_MODE))
-		atds = 1;
+		priv->plat->dma_cfg->atds = 1;
 
 	ret = stmmac_reset(priv, priv->ioaddr);
 	if (ret) {
@@ -3024,7 +3023,7 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv)
 	}
 
 	/* DMA Configuration */
-	stmmac_dma_init(priv, priv->ioaddr, priv->plat->dma_cfg, atds);
+	stmmac_dma_init(priv, priv->ioaddr, priv->plat->dma_cfg);
 
 	if (priv->plat->axi)
 		stmmac_axi(priv, priv->ioaddr, priv->plat->axi);
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index dfa1828cd756..1b54b84a6785 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -100,6 +100,7 @@ struct stmmac_dma_cfg {
 	bool eame;
 	bool multi_msi_en;
 	bool dche;
+	bool atds;
 };
 
 #define AXI_BLEN	7
-- 
2.31.4

[PATCH net-next v12 02/15] net: stmmac: Add multi-channel support

[Yanteng Si]

DW GMAC v3.x multi-channels feature is implemented as multiple
sets of the same CSRs. Here is only preliminary support, it will
be useful for the driver further evolution and for the users
having multi-channel DWGMAC v3.x devices.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c |  2 +-
 .../ethernet/stmicro/stmmac/dwmac1000_dma.c   | 32 ++++++++++---------
 .../net/ethernet/stmicro/stmmac/dwmac_dma.h   | 20 ++++++++++--
 .../net/ethernet/stmicro/stmmac/dwmac_lib.c   | 30 ++++++++---------
 drivers/net/ethernet/stmicro/stmmac/hwif.h    |  2 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  6 ++--
 6 files changed, 55 insertions(+), 37 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index d87079016952..cc93f73a380e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -395,7 +395,7 @@ static void sun8i_dwmac_dma_start_tx(struct stmmac_priv *priv,
 	writel(v, ioaddr + EMAC_TX_CTL1);
 }
 
-static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr)
+static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr, u32 chan)
 {
 	u32 v;
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index bb82ee9b855f..f161ec9ac490 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -70,15 +70,17 @@ static void dwmac1000_dma_axi(void __iomem *ioaddr, struct stmmac_axi *axi)
 	writel(value, ioaddr + DMA_AXI_BUS_MODE);
 }
 
-static void dwmac1000_dma_init(void __iomem *ioaddr,
-			       struct stmmac_dma_cfg *dma_cfg)
+static void dwmac1000_dma_init_channel(struct stmmac_priv *priv,
+				       void __iomem *ioaddr,
+				       struct stmmac_dma_cfg *dma_cfg, u32 chan)
 {
-	u32 value = readl(ioaddr + DMA_BUS_MODE);
 	int txpbl = dma_cfg->txpbl ?: dma_cfg->pbl;
 	int rxpbl = dma_cfg->rxpbl ?: dma_cfg->pbl;
+	u32 value;
 
-	/*
-	 * Set the DMA PBL (Programmable Burst Length) mode.
+	value = readl(ioaddr + DMA_CHAN_BUS_MODE(chan));
+
+	/* Set the DMA PBL (Programmable Burst Length) mode.
 	 *
 	 * Note: before stmmac core 3.50 this mode bit was 4xPBL, and
 	 * post 3.5 mode bit acts as 8*PBL.
@@ -104,10 +106,10 @@ static void dwmac1000_dma_init(void __iomem *ioaddr,
 	if (dma_cfg->aal)
 		value |= DMA_BUS_MODE_AAL;
 
-	writel(value, ioaddr + DMA_BUS_MODE);
+	writel(value, ioaddr + DMA_CHAN_BUS_MODE(chan));
 
 	/* Mask interrupts by writing to CSR7 */
-	writel(DMA_INTR_DEFAULT_MASK, ioaddr + DMA_INTR_ENA);
+	writel(DMA_INTR_DEFAULT_MASK, ioaddr + DMA_CHAN_INTR_ENA(chan));
 }
 
 static void dwmac1000_dma_init_rx(struct stmmac_priv *priv,
@@ -116,7 +118,7 @@ static void dwmac1000_dma_init_rx(struct stmmac_priv *priv,
 				  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);
+	writel(lower_32_bits(dma_rx_phy), ioaddr + DMA_CHAN_RCV_BASE_ADDR(chan));
 }
 
 static void dwmac1000_dma_init_tx(struct stmmac_priv *priv,
@@ -125,7 +127,7 @@ static void dwmac1000_dma_init_tx(struct stmmac_priv *priv,
 				  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);
+	writel(lower_32_bits(dma_tx_phy), ioaddr + DMA_CHAN_TX_BASE_ADDR(chan));
 }
 
 static u32 dwmac1000_configure_fc(u32 csr6, int rxfifosz)
@@ -153,7 +155,7 @@ static void dwmac1000_dma_operation_mode_rx(struct stmmac_priv *priv,
 					    void __iomem *ioaddr, int mode,
 					    u32 channel, int fifosz, u8 qmode)
 {
-	u32 csr6 = readl(ioaddr + DMA_CONTROL);
+	u32 csr6 = readl(ioaddr + DMA_CHAN_CONTROL(channel));
 
 	if (mode == SF_DMA_MODE) {
 		pr_debug("GMAC: enable RX store and forward mode\n");
@@ -175,14 +177,14 @@ static void dwmac1000_dma_operation_mode_rx(struct stmmac_priv *priv,
 	/* Configure flow control based on rx fifo size */
 	csr6 = dwmac1000_configure_fc(csr6, fifosz);
 
-	writel(csr6, ioaddr + DMA_CONTROL);
+	writel(csr6, ioaddr + DMA_CHAN_CONTROL(channel));
 }
 
 static void dwmac1000_dma_operation_mode_tx(struct stmmac_priv *priv,
 					    void __iomem *ioaddr, int mode,
 					    u32 channel, int fifosz, u8 qmode)
 {
-	u32 csr6 = readl(ioaddr + DMA_CONTROL);
+	u32 csr6 = readl(ioaddr + DMA_CHAN_CONTROL(channel));
 
 	if (mode == SF_DMA_MODE) {
 		pr_debug("GMAC: enable TX store and forward mode\n");
@@ -209,7 +211,7 @@ static void dwmac1000_dma_operation_mode_tx(struct stmmac_priv *priv,
 			csr6 |= DMA_CONTROL_TTC_256;
 	}
 
-	writel(csr6, ioaddr + DMA_CONTROL);
+	writel(csr6, ioaddr + DMA_CHAN_CONTROL(channel));
 }
 
 static void dwmac1000_dump_dma_regs(struct stmmac_priv *priv,
@@ -271,12 +273,12 @@ static int dwmac1000_get_hw_feature(void __iomem *ioaddr,
 static void dwmac1000_rx_watchdog(struct stmmac_priv *priv,
 				  void __iomem *ioaddr, u32 riwt, u32 queue)
 {
-	writel(riwt, ioaddr + DMA_RX_WATCHDOG);
+	writel(riwt, ioaddr + DMA_CHAN_RX_WATCHDOG(queue));
 }
 
 const struct stmmac_dma_ops dwmac1000_dma_ops = {
 	.reset = dwmac_dma_reset,
-	.init = dwmac1000_dma_init,
+	.init_chan = dwmac1000_dma_init_channel,
 	.init_rx_chan = dwmac1000_dma_init_rx,
 	.init_tx_chan = dwmac1000_dma_init_tx,
 	.axi = dwmac1000_dma_axi,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h b/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
index 72672391675f..363a85469594 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
@@ -22,6 +22,23 @@
 #define DMA_INTR_ENA		0x0000101c	/* Interrupt Enable */
 #define DMA_MISSED_FRAME_CTR	0x00001020	/* Missed Frame Counter */
 
+/* Following DMA defines are channels oriented */
+#define DMA_CHAN_BASE_OFFSET			0x100
+
+static inline u32 dma_chan_base_addr(u32 base, u32 chan)
+{
+	return base + chan * DMA_CHAN_BASE_OFFSET;
+}
+
+#define DMA_CHAN_XMT_POLL_DEMAND(chan)	dma_chan_base_addr(DMA_XMT_POLL_DEMAND, chan)
+#define DMA_CHAN_INTR_ENA(chan)	dma_chan_base_addr(DMA_INTR_ENA, chan)
+#define DMA_CHAN_CONTROL(chan)		dma_chan_base_addr(DMA_CONTROL, chan)
+#define DMA_CHAN_STATUS(chan)		dma_chan_base_addr(DMA_STATUS, chan)
+#define DMA_CHAN_BUS_MODE(chan)	dma_chan_base_addr(DMA_BUS_MODE, chan)
+#define DMA_CHAN_RCV_BASE_ADDR(chan)	dma_chan_base_addr(DMA_RCV_BASE_ADDR, chan)
+#define DMA_CHAN_TX_BASE_ADDR(chan)	dma_chan_base_addr(DMA_TX_BASE_ADDR, chan)
+#define DMA_CHAN_RX_WATCHDOG(chan)	dma_chan_base_addr(DMA_RX_WATCHDOG, chan)
+
 /* SW Reset */
 #define DMA_BUS_MODE_SFT_RESET	0x00000001	/* Software Reset */
 
@@ -152,7 +169,7 @@
 #define NUM_DWMAC1000_DMA_REGS	23
 #define NUM_DWMAC4_DMA_REGS	27
 
-void dwmac_enable_dma_transmission(void __iomem *ioaddr);
+void dwmac_enable_dma_transmission(void __iomem *ioaddr, u32 chan);
 void dwmac_enable_dma_irq(struct stmmac_priv *priv, void __iomem *ioaddr,
 			  u32 chan, bool rx, bool tx);
 void dwmac_disable_dma_irq(struct stmmac_priv *priv, void __iomem *ioaddr,
@@ -168,5 +185,4 @@ void dwmac_dma_stop_rx(struct stmmac_priv *priv, void __iomem *ioaddr,
 int dwmac_dma_interrupt(struct stmmac_priv *priv, void __iomem *ioaddr,
 			struct stmmac_extra_stats *x, u32 chan, u32 dir);
 int dwmac_dma_reset(void __iomem *ioaddr);
-
 #endif /* __DWMAC_DMA_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index 85e18f9a22f9..4846bf49c576 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -28,65 +28,65 @@ int dwmac_dma_reset(void __iomem *ioaddr)
 }
 
 /* CSR1 enables the transmit DMA to check for new descriptor */
-void dwmac_enable_dma_transmission(void __iomem *ioaddr)
+void dwmac_enable_dma_transmission(void __iomem *ioaddr, u32 chan)
 {
-	writel(1, ioaddr + DMA_XMT_POLL_DEMAND);
+	writel(1, ioaddr + DMA_CHAN_XMT_POLL_DEMAND(chan));
 }
 
 void dwmac_enable_dma_irq(struct stmmac_priv *priv, void __iomem *ioaddr,
 			  u32 chan, bool rx, bool tx)
 {
-	u32 value = readl(ioaddr + DMA_INTR_ENA);
+	u32 value = readl(ioaddr + DMA_CHAN_INTR_ENA(chan));
 
 	if (rx)
 		value |= DMA_INTR_DEFAULT_RX;
 	if (tx)
 		value |= DMA_INTR_DEFAULT_TX;
 
-	writel(value, ioaddr + DMA_INTR_ENA);
+	writel(value, ioaddr + DMA_CHAN_INTR_ENA(chan));
 }
 
 void dwmac_disable_dma_irq(struct stmmac_priv *priv, void __iomem *ioaddr,
 			   u32 chan, bool rx, bool tx)
 {
-	u32 value = readl(ioaddr + DMA_INTR_ENA);
+	u32 value = readl(ioaddr + DMA_CHAN_INTR_ENA(chan));
 
 	if (rx)
 		value &= ~DMA_INTR_DEFAULT_RX;
 	if (tx)
 		value &= ~DMA_INTR_DEFAULT_TX;
 
-	writel(value, ioaddr + DMA_INTR_ENA);
+	writel(value, ioaddr + DMA_CHAN_INTR_ENA(chan));
 }
 
 void dwmac_dma_start_tx(struct stmmac_priv *priv, void __iomem *ioaddr,
 			u32 chan)
 {
-	u32 value = readl(ioaddr + DMA_CONTROL);
+	u32 value = readl(ioaddr + DMA_CHAN_CONTROL(chan));
 	value |= DMA_CONTROL_ST;
-	writel(value, ioaddr + DMA_CONTROL);
+	writel(value, ioaddr + DMA_CHAN_CONTROL(chan));
 }
 
 void dwmac_dma_stop_tx(struct stmmac_priv *priv, void __iomem *ioaddr, u32 chan)
 {
-	u32 value = readl(ioaddr + DMA_CONTROL);
+	u32 value = readl(ioaddr + DMA_CHAN_CONTROL(chan));
 	value &= ~DMA_CONTROL_ST;
-	writel(value, ioaddr + DMA_CONTROL);
+	writel(value, ioaddr + DMA_CHAN_CONTROL(chan));
 }
 
 void dwmac_dma_start_rx(struct stmmac_priv *priv, void __iomem *ioaddr,
 			u32 chan)
 {
-	u32 value = readl(ioaddr + DMA_CONTROL);
+	u32 value = readl(ioaddr + DMA_CHAN_CONTROL(chan));
 	value |= DMA_CONTROL_SR;
-	writel(value, ioaddr + DMA_CONTROL);
+	writel(value, ioaddr + DMA_CHAN_CONTROL(chan));
 }
 
 void dwmac_dma_stop_rx(struct stmmac_priv *priv, void __iomem *ioaddr, u32 chan)
 {
-	u32 value = readl(ioaddr + DMA_CONTROL);
+	u32 value = readl(ioaddr + DMA_CHAN_CONTROL(chan));
 	value &= ~DMA_CONTROL_SR;
-	writel(value, ioaddr + DMA_CONTROL);
+	writel(value, ioaddr + DMA_CHAN_CONTROL(chan));
 }
 
 #ifdef DWMAC_DMA_DEBUG
@@ -165,7 +165,7 @@ int dwmac_dma_interrupt(struct stmmac_priv *priv, void __iomem *ioaddr,
 	struct stmmac_pcpu_stats *stats = this_cpu_ptr(priv->xstats.pcpu_stats);
 	int ret = 0;
 	/* read the status register (CSR5) */
-	u32 intr_status = readl(ioaddr + DMA_STATUS);
+	u32 intr_status = readl(ioaddr + DMA_CHAN_STATUS(chan));
 
 #ifdef DWMAC_DMA_DEBUG
 	/* Enable it to monitor DMA rx/tx status in case of critical problems */
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 413441eb6ea0..d807ee4b066e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -197,7 +197,7 @@ struct stmmac_dma_ops {
 	/* To track extra statistic (if supported) */
 	void (*dma_diagnostic_fr)(struct stmmac_extra_stats *x,
 				  void __iomem *ioaddr);
-	void (*enable_dma_transmission) (void __iomem *ioaddr);
+	void (*enable_dma_transmission)(void __iomem *ioaddr, u32 chan);
 	void (*enable_dma_irq)(struct stmmac_priv *priv, void __iomem *ioaddr,
 			       u32 chan, bool rx, bool tx);
 	void (*disable_dma_irq)(struct stmmac_priv *priv, void __iomem *ioaddr,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 188514ca6c47..9ae28f4bafaa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2556,7 +2556,7 @@ static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget)
 				       true, priv->mode, true, true,
 				       xdp_desc.len);
 
-		stmmac_enable_dma_transmission(priv, priv->ioaddr);
+		stmmac_enable_dma_transmission(priv, priv->ioaddr, queue);
 
 		xsk_tx_metadata_to_compl(meta,
 					 &tx_q->tx_skbuff_dma[entry].xsk_meta);
@@ -4752,7 +4752,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	netdev_tx_sent_queue(netdev_get_tx_queue(dev, queue), skb->len);
 
-	stmmac_enable_dma_transmission(priv, priv->ioaddr);
+	stmmac_enable_dma_transmission(priv, priv->ioaddr, queue);
 
 	stmmac_flush_tx_descriptors(priv, queue);
 	stmmac_tx_timer_arm(priv, queue);
@@ -4979,7 +4979,7 @@ static int stmmac_xdp_xmit_xdpf(struct stmmac_priv *priv, int queue,
 		u64_stats_update_end(&txq_stats->q_syncp);
 	}
 
-	stmmac_enable_dma_transmission(priv, priv->ioaddr);
+	stmmac_enable_dma_transmission(priv, priv->ioaddr, queue);
 
 	entry = STMMAC_GET_ENTRY(entry, priv->dma_conf.dma_tx_size);
 	tx_q->cur_tx = entry;
-- 
2.31.4

[PATCH net-next v12 03/15] net: stmmac: Export dwmac1000_dma_ops

[Yanteng Si]

The loongson gnet will call it in the future.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index f161ec9ac490..66c0c22908b1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -296,3 +296,4 @@ const struct stmmac_dma_ops dwmac1000_dma_ops = {
 	.get_hw_feature = dwmac1000_get_hw_feature,
 	.rx_watchdog = dwmac1000_rx_watchdog,
 };
+EXPORT_SYMBOL_GPL(dwmac1000_dma_ops);
-- 
2.31.4

[PATCH net-next v12 04/15] net: stmmac: dwmac-loongson: Drop useless platform data

[Yanteng Si]

The multicast_filter_bins is initialized twice, it should
be 256, let's drop the first useless assignment.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 9e40c28d453a..19906ea67636 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -15,9 +15,6 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
 	plat->has_gmac = 1;
 	plat->force_sf_dma_mode = 1;
 
-	/* Set default value for multicast hash bins */
-	plat->multicast_filter_bins = HASH_TABLE_SIZE;
-
 	/* Set default value for unicast filter entries */
 	plat->unicast_filter_entries = 1;
 
-- 
2.31.4

[PATCH net-next v12 05/15] net: stmmac: dwmac-loongson: Use PCI_DEVICE_DATA() macro for device identification

[Yanteng Si]

Just use PCI_DEVICE_DATA() macro for device identification,
No changes to function functionality.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 19906ea67636..4e0838db4259 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -9,6 +9,8 @@
 #include <linux/of_irq.h>
 #include "stmmac.h"
 
+#define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
+
 static int loongson_default_data(struct plat_stmmacenet_data *plat)
 {
 	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
@@ -210,7 +212,7 @@ static SIMPLE_DEV_PM_OPS(loongson_dwmac_pm_ops, loongson_dwmac_suspend,
 			 loongson_dwmac_resume);
 
 static const struct pci_device_id loongson_dwmac_id_table[] = {
-	{ PCI_VDEVICE(LOONGSON, 0x7a03) },
+	{ PCI_DEVICE_DATA(LOONGSON, GMAC, NULL) },
 	{}
 };
 MODULE_DEVICE_TABLE(pci, loongson_dwmac_id_table);
-- 
2.31.4

[PATCH net-next v12 06/15] net: stmmac: dwmac-loongson: Split up the platform data initialization

[Yanteng Si]

Based on IP core classification, loongson has two types of network
devices: GMAC and GNET. GMAC's ip_core id is 0x35/0x37, while GNET's
ip_core id is 0x37/0x10.

Device tables:

device    type    pci_id    snps_id    channel
ls2k1000  gmac    7a03      0x35/0x37   1
ls7a1000  gmac    7a03      0x35/0x37   1
ls2k2000  gnet    7a13      0x10        8
ls7a2000  gnet    7a13      0x37        1

The GMAC device only has a MAC chip inside and needs an
external PHY chip;

To later distinguish 8-channel gnet devices from single-channel
gnet/gmac devices, move rx_queues_to_use loongson_default_data
to loongson_dwmac_probe(). Also move mac_interface to
loongson_default_data().

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 20 ++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 4e0838db4259..904e288d0be0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -11,22 +11,20 @@
 
 #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
 
-static int loongson_default_data(struct plat_stmmacenet_data *plat)
+static void loongson_default_data(struct plat_stmmacenet_data *plat)
 {
 	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
 	plat->has_gmac = 1;
 	plat->force_sf_dma_mode = 1;
 
+	plat->mac_interface = PHY_INTERFACE_MODE_GMII;
+
 	/* Set default value for unicast filter entries */
 	plat->unicast_filter_entries = 1;
 
 	/* Set the maxmtu to a default of JUMBO_LEN */
 	plat->maxmtu = JUMBO_LEN;
 
-	/* Set default number of RX and TX queues to use */
-	plat->tx_queues_to_use = 1;
-	plat->rx_queues_to_use = 1;
-
 	/* Disable Priority config by default */
 	plat->tx_queues_cfg[0].use_prio = false;
 	plat->rx_queues_cfg[0].use_prio = false;
@@ -41,6 +39,12 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
 	plat->dma_cfg->pblx8 = true;
 
 	plat->multicast_filter_bins = 256;
+}
+
+static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
+{
+	loongson_default_data(plat);
+
 	return 0;
 }
 
@@ -109,11 +113,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 	}
 
 	plat->phy_interface = phy_mode;
-	plat->mac_interface = PHY_INTERFACE_MODE_GMII;
 
 	pci_set_master(pdev);
 
-	loongson_default_data(plat);
+	loongson_gmac_data(plat);
 	pci_enable_msi(pdev);
 	memset(&res, 0, sizeof(res));
 	res.addr = pcim_iomap_table(pdev)[0];
@@ -138,6 +141,9 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 		goto err_disable_msi;
 	}
 
+	plat->tx_queues_to_use = 1;
+	plat->rx_queues_to_use = 1;
+
 	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
 	if (ret)
 		goto err_disable_msi;
-- 
2.31.4

[PATCH net-next v12 07/15] net: stmmac: dwmac-loongson: Add ref and ptp clocks for Loongson

[Yanteng Si]

The ref/ptp clock of gmac(amd gnet) is 125000000.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 904e288d0be0..9f208f84c1e7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -32,6 +32,9 @@ static void loongson_default_data(struct plat_stmmacenet_data *plat)
 	/* Disable RX queues routing by default */
 	plat->rx_queues_cfg[0].pkt_route = 0x0;
 
+	plat->clk_ref_rate = 125000000;
+	plat->clk_ptp_rate = 125000000;
+
 	/* Default to phy auto-detection */
 	plat->phy_addr = -1;
 
-- 
2.31.4

[PATCH net-next v12 08/15] net: stmmac: dwmac-loongson: Add phy mask for Loongson GMAC

[Yanteng Si]

The phy mask of gmac(and gnet) is 0.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 9f208f84c1e7..f7618edf4a3a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -48,6 +48,8 @@ static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
 {
 	loongson_default_data(plat);
 
+	plat->mdio_bus_data->phy_mask = 0;
+
 	return 0;
 }
 
-- 
2.31.4

[PATCH net-next v12 09/15] net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC

[Yanteng Si]

The mac_interface of gmac is PHY_INTERFACE_MODE_RGMII_ID.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index f7618edf4a3a..e989cb835340 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -49,6 +49,7 @@ static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
 	loongson_default_data(plat);
 
 	plat->mdio_bus_data->phy_mask = 0;
+	plat->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
 
 	return 0;
 }
-- 
2.31.4

[PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support

[Yanteng Si]

Current dwmac-loongson only support LS2K in the "probed with PCI and
configured with DT" manner. Add LS7A support on which the devices are
fully PCI (non-DT).

Others:
LS2K is a SoC and LS7A is a bridge chip.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 113 ++++++++++--------
 1 file changed, 65 insertions(+), 48 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index e989cb835340..1022bceaa680 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -11,8 +11,17 @@
 
 #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
 
-static void loongson_default_data(struct plat_stmmacenet_data *plat)
+struct stmmac_pci_info {
+	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
+};
+
+static void loongson_default_data(struct pci_dev *pdev,
+				  struct plat_stmmacenet_data *plat)
 {
+	/* Get bus_id, this can be overloaded later */
+	plat->bus_id = (pci_domain_nr(pdev->bus) << 16) |
+			PCI_DEVID(pdev->bus->number, pdev->devfn);
+
 	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
 	plat->has_gmac = 1;
 	plat->force_sf_dma_mode = 1;
@@ -44,9 +53,10 @@ static void loongson_default_data(struct plat_stmmacenet_data *plat)
 	plat->multicast_filter_bins = 256;
 }
 
-static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
+static int loongson_gmac_data(struct pci_dev *pdev,
+			      struct plat_stmmacenet_data *plat)
 {
-	loongson_default_data(plat);
+	loongson_default_data(pdev, plat);
 
 	plat->mdio_bus_data->phy_mask = 0;
 	plat->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
@@ -54,20 +64,20 @@ static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
 	return 0;
 }
 
+static struct stmmac_pci_info loongson_gmac_pci_info = {
+	.setup = loongson_gmac_data,
+};
+
 static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
 	struct plat_stmmacenet_data *plat;
+	int ret, i, bus_id, phy_mode;
+	struct stmmac_pci_info *info;
 	struct stmmac_resources res;
 	struct device_node *np;
-	int ret, i, phy_mode;
 
 	np = dev_of_node(&pdev->dev);
 
-	if (!np) {
-		pr_info("dwmac_loongson_pci: No OF node\n");
-		return -ENODEV;
-	}
-
 	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
 	if (!plat)
 		return -ENOMEM;
@@ -78,12 +88,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 	if (!plat->mdio_bus_data)
 		return -ENOMEM;
 
-	plat->mdio_node = of_get_child_by_name(np, "mdio");
-	if (plat->mdio_node) {
-		dev_info(&pdev->dev, "Found MDIO subnode\n");
-		plat->mdio_bus_data->needs_reset = true;
-	}
-
 	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
 	if (!plat->dma_cfg) {
 		ret = -ENOMEM;
@@ -107,46 +111,59 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 		break;
 	}
 
-	plat->bus_id = of_alias_get_id(np, "ethernet");
-	if (plat->bus_id < 0)
-		plat->bus_id = pci_dev_id(pdev);
+	pci_set_master(pdev);
 
-	phy_mode = device_get_phy_mode(&pdev->dev);
-	if (phy_mode < 0) {
-		dev_err(&pdev->dev, "phy_mode not found\n");
-		ret = phy_mode;
+	info = (struct stmmac_pci_info *)id->driver_data;
+	ret = info->setup(pdev, plat);
+	if (ret)
 		goto err_disable_device;
-	}
 
-	plat->phy_interface = phy_mode;
-
-	pci_set_master(pdev);
+	if (np) {
+		plat->mdio_node = of_get_child_by_name(np, "mdio");
+		if (plat->mdio_node) {
+			dev_info(&pdev->dev, "Found MDIO subnode\n");
+			plat->mdio_bus_data->needs_reset = true;
+		}
+
+		bus_id = of_alias_get_id(np, "ethernet");
+		if (bus_id >= 0)
+			plat->bus_id = bus_id;
+
+		phy_mode = device_get_phy_mode(&pdev->dev);
+		if (phy_mode < 0) {
+			dev_err(&pdev->dev, "phy_mode not found\n");
+			ret = phy_mode;
+			goto err_disable_device;
+		}
+		plat->phy_interface = phy_mode;
+
+		res.irq = of_irq_get_byname(np, "macirq");
+		if (res.irq < 0) {
+			dev_err(&pdev->dev, "IRQ macirq not found\n");
+			ret = -ENODEV;
+			goto err_disable_msi;
+		}
+
+		res.wol_irq = of_irq_get_byname(np, "eth_wake_irq");
+		if (res.wol_irq < 0) {
+			dev_info(&pdev->dev, "IRQ eth_wake_irq not found, using macirq\n");
+			res.wol_irq = res.irq;
+		}
+
+		res.lpi_irq = of_irq_get_byname(np, "eth_lpi");
+		if (res.lpi_irq < 0) {
+			dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
+			ret = -ENODEV;
+			goto err_disable_msi;
+		}
+	} else {
+		res.irq = pdev->irq;
+	}
 
-	loongson_gmac_data(plat);
 	pci_enable_msi(pdev);
 	memset(&res, 0, sizeof(res));
 	res.addr = pcim_iomap_table(pdev)[0];
 
-	res.irq = of_irq_get_byname(np, "macirq");
-	if (res.irq < 0) {
-		dev_err(&pdev->dev, "IRQ macirq not found\n");
-		ret = -ENODEV;
-		goto err_disable_msi;
-	}
-
-	res.wol_irq = of_irq_get_byname(np, "eth_wake_irq");
-	if (res.wol_irq < 0) {
-		dev_info(&pdev->dev, "IRQ eth_wake_irq not found, using macirq\n");
-		res.wol_irq = res.irq;
-	}
-
-	res.lpi_irq = of_irq_get_byname(np, "eth_lpi");
-	if (res.lpi_irq < 0) {
-		dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
-		ret = -ENODEV;
-		goto err_disable_msi;
-	}
-
 	plat->tx_queues_to_use = 1;
 	plat->rx_queues_to_use = 1;
 
@@ -224,7 +241,7 @@ static SIMPLE_DEV_PM_OPS(loongson_dwmac_pm_ops, loongson_dwmac_suspend,
 			 loongson_dwmac_resume);
 
 static const struct pci_device_id loongson_dwmac_id_table[] = {
-	{ PCI_DEVICE_DATA(LOONGSON, GMAC, NULL) },
+	{ PCI_DEVICE_DATA(LOONGSON, GMAC, &loongson_gmac_pci_info) },
 	{}
 };
 MODULE_DEVICE_TABLE(pci, loongson_dwmac_id_table);
-- 
2.31.4

[PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy

[Yanteng Si]

Move res._irq to loongson_dwmac_config_legacy().
No function changes.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 56 +++++++++++--------
 1 file changed, 34 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 1022bceaa680..df5899bec91a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -68,6 +68,38 @@ static struct stmmac_pci_info loongson_gmac_pci_info = {
 	.setup = loongson_gmac_data,
 };
 
+static int loongson_dwmac_config_legacy(struct pci_dev *pdev,
+					struct plat_stmmacenet_data *plat,
+					struct stmmac_resources *res,
+					struct device_node *np)
+{
+	if (np) {
+		res->irq = of_irq_get_byname(np, "macirq");
+		if (res->irq < 0) {
+			dev_err(&pdev->dev, "IRQ macirq not found\n");
+			return -ENODEV;
+		}
+
+		res->wol_irq = of_irq_get_byname(np, "eth_wake_irq");
+		if (res->wol_irq < 0) {
+			dev_info(&pdev->dev,
+				 "IRQ eth_wake_irq not found, using macirq\n");
+			res->wol_irq = res->irq;
+		}
+
+		res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
+		if (res->lpi_irq < 0) {
+			dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
+			return -ENODEV;
+		}
+	} else {
+		res->irq = pdev->irq;
+		res->wol_irq = res->irq;
+	}
+
+	return 0;
+}
+
 static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
 	struct plat_stmmacenet_data *plat;
@@ -136,28 +168,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 			goto err_disable_device;
 		}
 		plat->phy_interface = phy_mode;
-
-		res.irq = of_irq_get_byname(np, "macirq");
-		if (res.irq < 0) {
-			dev_err(&pdev->dev, "IRQ macirq not found\n");
-			ret = -ENODEV;
-			goto err_disable_msi;
-		}
-
-		res.wol_irq = of_irq_get_byname(np, "eth_wake_irq");
-		if (res.wol_irq < 0) {
-			dev_info(&pdev->dev, "IRQ eth_wake_irq not found, using macirq\n");
-			res.wol_irq = res.irq;
-		}
-
-		res.lpi_irq = of_irq_get_byname(np, "eth_lpi");
-		if (res.lpi_irq < 0) {
-			dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
-			ret = -ENODEV;
-			goto err_disable_msi;
-		}
-	} else {
-		res.irq = pdev->irq;
 	}
 
 	pci_enable_msi(pdev);
@@ -167,6 +177,8 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 	plat->tx_queues_to_use = 1;
 	plat->rx_queues_to_use = 1;
 
+	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
+
 	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
 	if (ret)
 		goto err_disable_msi;
-- 
2.31.4

[PATCH net-next v12 12/15] net: stmmac: dwmac-loongson: Fixed failure to set network speed to 1000.

[Yanteng Si]

GNET devices with dev revision 0x00 do not support manually
setting the speed to 1000.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 8 ++++++++
 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 6 ++++++
 include/linux/stmmac.h                               | 1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index df5899bec91a..a16bba389417 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -10,6 +10,7 @@
 #include "stmmac.h"
 
 #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
+#define PCI_DEVICE_ID_LOONGSON_GNET	0x7a13
 
 struct stmmac_pci_info {
 	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
@@ -179,6 +180,13 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 
 	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
 
+	/* GNET devices with dev revision 0x00 do not support manually
+	 * setting the speed to 1000.
+	 */
+	if (pdev->device == PCI_DEVICE_ID_LOONGSON_GNET &&
+	    pdev->revision == 0x00)
+		plat->flags |= STMMAC_FLAG_DISABLE_FORCE_1000;
+
 	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
 	if (ret)
 		goto err_disable_msi;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 542e2633a6f5..eb4b3eaf9e17 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -422,6 +422,12 @@ stmmac_ethtool_set_link_ksettings(struct net_device *dev,
 		return 0;
 	}
 
+	if (priv->plat->flags & STMMAC_FLAG_DISABLE_FORCE_1000) {
+		if (cmd->base.speed == SPEED_1000 &&
+		    cmd->base.autoneg != AUTONEG_ENABLE)
+			return -EOPNOTSUPP;
+	}
+
 	return phylink_ethtool_ksettings_set(priv->phylink, cmd);
 }
 
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 1b54b84a6785..c5d3d0ddb6f8 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -223,6 +223,7 @@ struct dwmac4_addrs {
 #define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI		BIT(10)
 #define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING	BIT(11)
 #define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY	BIT(12)
+#define STMMAC_FLAG_DISABLE_FORCE_1000		BIT(13)
 
 struct plat_stmmacenet_data {
 	int bus_id;
-- 
2.31.4

[PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Yanteng Si]

There are two types of Loongson DWGMAC. The first type shares the same
register definitions and has similar logic as dwmac1000. The second type
uses several different register definitions, we think it is necessary to
distinguish rx and tx, so we split these bits into two.

Simply put, we split some single bit fields into double bits fileds:

     Name              Tx          Rx

DMA_INTR_ENA_NIE = 0x00040000 | 0x00020000;
DMA_INTR_ENA_AIE = 0x00010000 | 0x00008000;
DMA_STATUS_NIS   = 0x00040000 | 0x00020000;
DMA_STATUS_AIS   = 0x00010000 | 0x00008000;
DMA_STATUS_FBI   = 0x00002000 | 0x00001000;

Therefore, when using, TX and RX must be set at the same time.

How to use them:
 1. Create the Loongson GNET-specific
 stmmac_dma_ops.dma_interrupt()
 stmmac_dma_ops.init_chan()
 methods in the dwmac-loongson.c driver. Adding all the
 Loongson-specific macros

 2. Create a Loongson GNET-specific platform setup method with the next
 semantics:
    + allocate stmmac_dma_ops instance and initialize it with
      dwmac1000_dma_ops.
    + override the stmmac_dma_ops.{dma_interrupt, init_chan} with
      the pointers to the methods defined in 2.
    + allocate mac_device_info instance and initialize the
      mac_device_info.dma field with a pointer to the new
      stmmac_dma_ops instance.
    + initialize mac_device_info in a way it's done in
      dwmac1000_setup().

 3. Initialize plat_stmmacenet_data.setup() with the pointer to the
 method created in 2.

GNET features:

 Speeds: 10/100/1000Mbps
 DMA-descriptors type: enhanced
 L3/L4 filters availability: support
 VLAN hash table filter: support
 PHY-interface: GMII
 Remote Wake-up support: support
 Mac Management Counters (MMC): support
 Number of additional MAC addresses: 5
 MAC Hash-based filter: support
 Number of ash table size: 256
 DMA chennel number: 0x10 device is 8 and 0x37 device is 1

Others:

 GNET integrates both MAC and PHY chips inside.
 GNET device: LS2K2000, LS7A2000, the chip connection between the mac and
             phy of these devices is not normal and requires two rounds of
             negotiation; LS7A2000 does not support half-duplex and
             multi-channel;

             To enable multi-channel on LS2K2000, you need to turn off
             hardware checksum.

**Note**: Currently, only the LS2K2000's synopsys_id is 0x10, while the
synopsys_id of other devices are 0x37.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 drivers/net/ethernet/stmicro/stmmac/common.h  |   1 +
 .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 381 +++++++++++++++++-
 2 files changed, 371 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index 9cd62b2110a1..aed6ae80cc7c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -29,6 +29,7 @@
 /* Synopsys Core versions */
 #define	DWMAC_CORE_3_40		0x34
 #define	DWMAC_CORE_3_50		0x35
+#define	DWMAC_CORE_3_70		0x37
 #define	DWMAC_CORE_4_00		0x40
 #define DWMAC_CORE_4_10		0x41
 #define DWMAC_CORE_5_00		0x50
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index a16bba389417..68de90c44feb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -8,9 +8,71 @@
 #include <linux/device.h>
 #include <linux/of_irq.h>
 #include "stmmac.h"
+#include "dwmac_dma.h"
+#include "dwmac1000.h"
+
+/* Normal Loongson Tx Summary */
+#define DMA_INTR_ENA_NIE_TX_LOONGSON	0x00040000
+/* Normal Loongson Rx Summary */
+#define DMA_INTR_ENA_NIE_RX_LOONGSON	0x00020000
+
+#define DMA_INTR_NORMAL_LOONGSON	(DMA_INTR_ENA_NIE_TX_LOONGSON | \
+					 DMA_INTR_ENA_NIE_RX_LOONGSON | \
+					 DMA_INTR_ENA_RIE | DMA_INTR_ENA_TIE)
+
+/* Abnormal Loongson Tx Summary */
+#define DMA_INTR_ENA_AIE_TX_LOONGSON	0x00010000
+/* Abnormal Loongson Rx Summary */
+#define DMA_INTR_ENA_AIE_RX_LOONGSON	0x00008000
+
+#define DMA_INTR_ABNORMAL_LOONGSON	(DMA_INTR_ENA_AIE_TX_LOONGSON | \
+					 DMA_INTR_ENA_AIE_RX_LOONGSON | \
+					 DMA_INTR_ENA_FBE | DMA_INTR_ENA_UNE)
+
+#define DMA_INTR_DEFAULT_MASK_LOONGSON	(DMA_INTR_NORMAL_LOONGSON | \
+					 DMA_INTR_ABNORMAL_LOONGSON)
+
+/* Normal Loongson Tx Interrupt Summary */
+#define DMA_STATUS_NIS_TX_LOONGSON	0x00040000
+/* Normal Loongson Rx Interrupt Summary */
+#define DMA_STATUS_NIS_RX_LOONGSON	0x00020000
+
+/* Abnormal Loongson Tx Interrupt Summary */
+#define DMA_STATUS_AIS_TX_LOONGSON	0x00010000
+/* Abnormal Loongson Rx Interrupt Summary */
+#define DMA_STATUS_AIS_RX_LOONGSON	0x00008000
+
+/* Fatal Loongson Tx Bus Error Interrupt */
+#define DMA_STATUS_FBI_TX_LOONGSON	0x00002000
+/* Fatal Loongson Rx Bus Error Interrupt */
+#define DMA_STATUS_FBI_RX_LOONGSON	0x00001000
+
+#define DMA_STATUS_MSK_COMMON_LOONGSON	(DMA_STATUS_NIS_TX_LOONGSON | \
+					 DMA_STATUS_NIS_RX_LOONGSON | \
+					 DMA_STATUS_AIS_TX_LOONGSON | \
+					 DMA_STATUS_AIS_RX_LOONGSON | \
+					 DMA_STATUS_FBI_TX_LOONGSON | \
+					 DMA_STATUS_FBI_RX_LOONGSON)
+
+#define DMA_STATUS_MSK_RX_LOONGSON	(DMA_STATUS_ERI | DMA_STATUS_RWT | \
+					 DMA_STATUS_RPS | DMA_STATUS_RU  | \
+					 DMA_STATUS_RI  | DMA_STATUS_OVF | \
+					 DMA_STATUS_MSK_COMMON_LOONGSON)
+
+#define DMA_STATUS_MSK_TX_LOONGSON	(DMA_STATUS_ETI | DMA_STATUS_UNF | \
+					 DMA_STATUS_TJT | DMA_STATUS_TU  | \
+					 DMA_STATUS_TPS | DMA_STATUS_TI  | \
+					 DMA_STATUS_MSK_COMMON_LOONGSON)
 
 #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
 #define PCI_DEVICE_ID_LOONGSON_GNET	0x7a13
+#define LOONGSON_DWMAC_CORE_1_00	0x10	/* Loongson custom IP */
+#define CHANNEL_NUM			8
+
+struct loongson_data {
+	u32 gmac_verion;
+	struct device *dev;
+};
 
 struct stmmac_pci_info {
 	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
@@ -69,6 +131,168 @@ static struct stmmac_pci_info loongson_gmac_pci_info = {
 	.setup = loongson_gmac_data,
 };
 
+static void loongson_gnet_dma_init_channel(struct stmmac_priv *priv,
+					   void __iomem *ioaddr,
+					   struct stmmac_dma_cfg *dma_cfg,
+					   u32 chan)
+{
+	int txpbl = dma_cfg->txpbl ?: dma_cfg->pbl;
+	int rxpbl = dma_cfg->rxpbl ?: dma_cfg->pbl;
+	u32 value;
+
+	value = readl(ioaddr + DMA_CHAN_BUS_MODE(chan));
+
+	if (dma_cfg->pblx8)
+		value |= DMA_BUS_MODE_MAXPBL;
+
+	value |= DMA_BUS_MODE_USP;
+	value &= ~(DMA_BUS_MODE_PBL_MASK | DMA_BUS_MODE_RPBL_MASK);
+	value |= (txpbl << DMA_BUS_MODE_PBL_SHIFT);
+	value |= (rxpbl << DMA_BUS_MODE_RPBL_SHIFT);
+
+	/* Set the Fixed burst mode */
+	if (dma_cfg->fixed_burst)
+		value |= DMA_BUS_MODE_FB;
+
+	/* Mixed Burst has no effect when fb is set */
+	if (dma_cfg->mixed_burst)
+		value |= DMA_BUS_MODE_MB;
+
+	if (dma_cfg->atds)
+		value |= DMA_BUS_MODE_ATDS;
+
+	if (dma_cfg->aal)
+		value |= DMA_BUS_MODE_AAL;
+
+	writel(value, ioaddr + DMA_CHAN_BUS_MODE(chan));
+
+	/* Mask interrupts by writing to CSR7 */
+	writel(DMA_INTR_DEFAULT_MASK_LOONGSON, ioaddr +
+	       DMA_CHAN_INTR_ENA(chan));
+}
+
+static int loongson_gnet_dma_interrupt(struct stmmac_priv *priv,
+				       void __iomem *ioaddr,
+				       struct stmmac_extra_stats *x,
+				       u32 chan, u32 dir)
+{
+	struct stmmac_pcpu_stats *stats = this_cpu_ptr(priv->xstats.pcpu_stats);
+	u32 abnor_intr_status;
+	u32 nor_intr_status;
+	u32 fb_intr_status;
+	u32 intr_status;
+	int ret = 0;
+
+	/* read the status register (CSR5) */
+	intr_status = readl(ioaddr + DMA_CHAN_STATUS(chan));
+
+	if (dir == DMA_DIR_RX)
+		intr_status &= DMA_STATUS_MSK_RX_LOONGSON;
+	else if (dir == DMA_DIR_TX)
+		intr_status &= DMA_STATUS_MSK_TX_LOONGSON;
+
+	nor_intr_status = intr_status & (DMA_STATUS_NIS_TX_LOONGSON |
+		DMA_STATUS_NIS_RX_LOONGSON);
+	abnor_intr_status = intr_status & (DMA_STATUS_AIS_TX_LOONGSON |
+		DMA_STATUS_AIS_RX_LOONGSON);
+	fb_intr_status = intr_status & (DMA_STATUS_FBI_TX_LOONGSON |
+		DMA_STATUS_FBI_RX_LOONGSON);
+
+	/* ABNORMAL interrupts */
+	if (unlikely(abnor_intr_status)) {
+		if (unlikely(intr_status & DMA_STATUS_UNF)) {
+			ret = tx_hard_error_bump_tc;
+			x->tx_undeflow_irq++;
+		}
+		if (unlikely(intr_status & DMA_STATUS_TJT))
+			x->tx_jabber_irq++;
+		if (unlikely(intr_status & DMA_STATUS_OVF))
+			x->rx_overflow_irq++;
+		if (unlikely(intr_status & DMA_STATUS_RU))
+			x->rx_buf_unav_irq++;
+		if (unlikely(intr_status & DMA_STATUS_RPS))
+			x->rx_process_stopped_irq++;
+		if (unlikely(intr_status & DMA_STATUS_RWT))
+			x->rx_watchdog_irq++;
+		if (unlikely(intr_status & DMA_STATUS_ETI))
+			x->tx_early_irq++;
+		if (unlikely(intr_status & DMA_STATUS_TPS)) {
+			x->tx_process_stopped_irq++;
+			ret = tx_hard_error;
+		}
+		if (unlikely(fb_intr_status)) {
+			x->fatal_bus_error_irq++;
+			ret = tx_hard_error;
+		}
+	}
+	/* TX/RX NORMAL interrupts */
+	if (likely(nor_intr_status)) {
+		if (likely(intr_status & DMA_STATUS_RI)) {
+			u32 value = readl(ioaddr + DMA_INTR_ENA);
+			/* to schedule NAPI on real RIE event. */
+			if (likely(value & DMA_INTR_ENA_RIE)) {
+				u64_stats_update_begin(&stats->syncp);
+				u64_stats_inc(&stats->rx_normal_irq_n[chan]);
+				u64_stats_update_end(&stats->syncp);
+				ret |= handle_rx;
+			}
+		}
+		if (likely(intr_status & DMA_STATUS_TI)) {
+			u64_stats_update_begin(&stats->syncp);
+			u64_stats_inc(&stats->tx_normal_irq_n[chan]);
+			u64_stats_update_end(&stats->syncp);
+			ret |= handle_tx;
+		}
+		if (unlikely(intr_status & DMA_STATUS_ERI))
+			x->rx_early_irq++;
+	}
+	/* Optional hardware blocks, interrupts should be disabled */
+	if (unlikely(intr_status &
+		     (DMA_STATUS_GPI | DMA_STATUS_GMI | DMA_STATUS_GLI)))
+		pr_warn("%s: unexpected status %08x\n", __func__, intr_status);
+
+	/* Clear the interrupt by writing a logic 1 to the CSR5[15-0] */
+	writel((intr_status & 0x7ffff), ioaddr + DMA_CHAN_STATUS(chan));
+
+	return ret;
+}
+
+static void loongson_gnet_fix_speed(void *priv, unsigned int speed,
+				    unsigned int mode)
+{
+	struct loongson_data *ld = (struct loongson_data *)priv;
+	struct net_device *ndev = dev_get_drvdata(ld->dev);
+	struct stmmac_priv *ptr = netdev_priv(ndev);
+
+	/* The controller and PHY don't work well together.
+	 * We need to use the PS bit to check if the controller's status
+	 * is correct and reset PHY if necessary.
+	 * MAC_CTRL_REG.15 is defined by the GMAC_CONTROL_PS macro.
+	 */
+	if (speed == SPEED_1000) {
+		if (readl(ptr->ioaddr + MAC_CTRL_REG) &
+		    GMAC_CONTROL_PS)
+			/* Word around hardware bug, restart autoneg */
+			phy_restart_aneg(ndev->phydev);
+	}
+}
+
+static int loongson_gnet_data(struct pci_dev *pdev,
+			      struct plat_stmmacenet_data *plat)
+{
+	loongson_default_data(pdev, plat);
+
+	plat->phy_interface = PHY_INTERFACE_MODE_GMII;
+	plat->mdio_bus_data->phy_mask = ~(u32)BIT(2);
+	plat->fix_mac_speed = loongson_gnet_fix_speed;
+
+	return 0;
+}
+
+static struct stmmac_pci_info loongson_gnet_pci_info = {
+	.setup = loongson_gnet_data,
+};
+
 static int loongson_dwmac_config_legacy(struct pci_dev *pdev,
 					struct plat_stmmacenet_data *plat,
 					struct stmmac_resources *res,
@@ -101,12 +325,126 @@ static int loongson_dwmac_config_legacy(struct pci_dev *pdev,
 	return 0;
 }
 
+static int loongson_dwmac_config_msi(struct pci_dev *pdev,
+				     struct plat_stmmacenet_data *plat,
+				     struct stmmac_resources *res,
+				     struct device_node *np)
+{
+	int i, ret, vecs;
+
+	vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
+	ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
+	if (ret < 0) {
+		dev_info(&pdev->dev,
+			 "MSI enable failed, Fallback to legacy interrupt\n");
+		return loongson_dwmac_config_legacy(pdev, plat, res, np);
+	}
+
+	res->irq = pci_irq_vector(pdev, 0);
+	res->wol_irq = 0;
+
+	/* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
+	 * --------- ----- -------- --------  ...  -------- --------
+	 * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
+	 */
+	for (i = 0; i < CHANNEL_NUM; i++) {
+		res->rx_irq[CHANNEL_NUM - 1 - i] =
+			pci_irq_vector(pdev, 1 + i * 2);
+		res->tx_irq[CHANNEL_NUM - 1 - i] =
+			pci_irq_vector(pdev, 2 + i * 2);
+	}
+
+	plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
+
+	return 0;
+}
+
+static struct mac_device_info *loongson_dwmac_setup(void *apriv)
+{
+	struct stmmac_priv *priv = apriv;
+	struct mac_device_info *mac;
+	struct stmmac_dma_ops *dma;
+	struct loongson_data *ld;
+	struct pci_dev *pdev;
+
+	ld = priv->plat->bsp_priv;
+	pdev = to_pci_dev(priv->device);
+
+	mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
+	if (!mac)
+		return NULL;
+
+	dma = devm_kzalloc(priv->device, sizeof(*dma), GFP_KERNEL);
+	if (!dma)
+		return NULL;
+
+	/* The original IP-core version is 0x37 in all Loongson GNET
+	 * (ls2k2000 and ls7a2000), but the GNET HW designers have changed the
+	 * GMAC_VERSION.SNPSVER field to the custom 0x10 value on the Loongson
+	 * ls2k2000 MAC to emphasize the differences: multiple DMA-channels,
+	 * AV feature and GMAC_INT_STATUS CSR flags layout. Get back the
+	 * original value so the correct HW-interface would be selected.
+	 */
+	if (ld->gmac_verion == LOONGSON_DWMAC_CORE_1_00) {
+		priv->synopsys_id = DWMAC_CORE_3_70;
+		*dma = dwmac1000_dma_ops;
+		dma->init_chan = loongson_gnet_dma_init_channel;
+		dma->dma_interrupt = loongson_gnet_dma_interrupt;
+		mac->dma = dma;
+	}
+
+	mac->mac = &dwmac1000_ops;
+	priv->dev->priv_flags |= IFF_UNICAST_FLT;
+
+	/* Pre-initialize the respective "mac" fields as it's done in
+	 * dwmac1000_setup()
+	 */
+	mac->pcsr = priv->ioaddr;
+	mac->multicast_filter_bins = priv->plat->multicast_filter_bins;
+	mac->unicast_filter_entries = priv->plat->unicast_filter_entries;
+	mac->mcast_bits_log2 = 0;
+
+	if (mac->multicast_filter_bins)
+		mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
+
+	/* The GMAC devices with PCI ID 0x7a03 does not support any pause mode.
+	 * The GNET devices without CORE ID 0x10 does not support half-duplex.
+	 */
+	if (pdev->device == PCI_DEVICE_ID_LOONGSON_GMAC) {
+		mac->link.caps = MAC_10 | MAC_100 | MAC_1000;
+	} else {
+		if (ld->gmac_verion == LOONGSON_DWMAC_CORE_1_00)
+			mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
+					 MAC_10 | MAC_100 | MAC_1000;
+		else
+			mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
+					 MAC_10FD | MAC_100FD | MAC_1000FD;
+	}
+
+	mac->link.duplex = GMAC_CONTROL_DM;
+	mac->link.speed10 = GMAC_CONTROL_PS;
+	mac->link.speed100 = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
+	mac->link.speed1000 = 0;
+	mac->link.speed_mask = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
+	mac->mii.addr = GMAC_MII_ADDR;
+	mac->mii.data = GMAC_MII_DATA;
+	mac->mii.addr_shift = 11;
+	mac->mii.addr_mask = 0x0000F800;
+	mac->mii.reg_shift = 6;
+	mac->mii.reg_mask = 0x000007C0;
+	mac->mii.clk_csr_shift = 2;
+	mac->mii.clk_csr_mask = GENMASK(5, 2);
+
+	return mac;
+}
+
 static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
 	struct plat_stmmacenet_data *plat;
 	int ret, i, bus_id, phy_mode;
 	struct stmmac_pci_info *info;
 	struct stmmac_resources res;
+	struct loongson_data *ld;
 	struct device_node *np;
 
 	np = dev_of_node(&pdev->dev);
@@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 		return -ENOMEM;
 
 	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
-	if (!plat->dma_cfg) {
-		ret = -ENOMEM;
-		goto err_put_node;
-	}
+	if (!plat->dma_cfg)
+		return -ENOMEM;
+
+	ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
+	if (!ld)
+		return -ENOMEM;
 
 	/* Enable pci device */
 	ret = pci_enable_device(pdev);
@@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 		plat->phy_interface = phy_mode;
 	}
 
-	pci_enable_msi(pdev);
+	plat->bsp_priv = ld;
+	plat->setup = loongson_dwmac_setup;
+	ld->dev = &pdev->dev;
+
 	memset(&res, 0, sizeof(res));
 	res.addr = pcim_iomap_table(pdev)[0];
+	ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
+
+	switch (ld->gmac_verion) {
+	case LOONGSON_DWMAC_CORE_1_00:
+		plat->rx_queues_to_use = CHANNEL_NUM;
+		plat->tx_queues_to_use = CHANNEL_NUM;
+
+		/* Only channel 0 supports checksum,
+		 * so turn off checksum to enable multiple channels.
+		 */
+		for (i = 1; i < CHANNEL_NUM; i++)
+			plat->tx_queues_cfg[i].coe_unsupported = 1;
 
-	plat->tx_queues_to_use = 1;
-	plat->rx_queues_to_use = 1;
+		ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
+		break;
+	default:	/* 0x35 device and 0x37 device. */
+		plat->tx_queues_to_use = 1;
+		plat->rx_queues_to_use = 1;
 
-	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
+		ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
+		break;
+	}
 
 	/* GNET devices with dev revision 0x00 do not support manually
 	 * setting the speed to 1000.
@@ -189,12 +549,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 
 	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
 	if (ret)
-		goto err_disable_msi;
+		goto err_disable_device;
 
 	return ret;
 
-err_disable_msi:
-	pci_disable_msi(pdev);
 err_disable_device:
 	pci_disable_device(pdev);
 err_put_node:
@@ -262,6 +620,7 @@ static SIMPLE_DEV_PM_OPS(loongson_dwmac_pm_ops, loongson_dwmac_suspend,
 
 static const struct pci_device_id loongson_dwmac_id_table[] = {
 	{ PCI_DEVICE_DATA(LOONGSON, GMAC, &loongson_gmac_pci_info) },
+	{ PCI_DEVICE_DATA(LOONGSON, GNET, &loongson_gnet_pci_info) },
 	{}
 };
 MODULE_DEVICE_TABLE(pci, loongson_dwmac_id_table);
-- 
2.31.4

[PATCH net-next v12 14/15] net: stmmac: dwmac-loongson: Move disable_force flag to _gnet_date

[Yanteng Si]

We've already introduced loongson_gnet_data(), so the
STMMAC_FLAG_DISABLE_FORCE_1000 should be take away from
loongson_dwmac_probe().

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../net/ethernet/stmicro/stmmac/dwmac-loongson.c    | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 68de90c44feb..dea02de030e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -286,6 +286,12 @@ static int loongson_gnet_data(struct pci_dev *pdev,
 	plat->mdio_bus_data->phy_mask = ~(u32)BIT(2);
 	plat->fix_mac_speed = loongson_gnet_fix_speed;
 
+	/* GNET devices with dev revision 0x00 do not support manually
+	 * setting the speed to 1000.
+	 */
+	if (pdev->revision == 0x00)
+		plat->flags |= STMMAC_FLAG_DISABLE_FORCE_1000;
+
 	return 0;
 }
 
@@ -540,13 +546,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 		break;
 	}
 
-	/* GNET devices with dev revision 0x00 do not support manually
-	 * setting the speed to 1000.
-	 */
-	if (pdev->device == PCI_DEVICE_ID_LOONGSON_GNET &&
-	    pdev->revision == 0x00)
-		plat->flags |= STMMAC_FLAG_DISABLE_FORCE_1000;
-
 	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
 	if (ret)
 		goto err_disable_device;
-- 
2.31.4

[PATCH net-next v12 15/15] net: stmmac: dwmac-loongson: Add loongson module author

[Yanteng Si]

Add Yanteng Si as MODULE_AUTHOR of  Loongson DWMAC PCI driver.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index dea02de030e6..f0eebed751f3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -638,4 +638,5 @@ module_pci_driver(loongson_dwmac_driver);
 
 MODULE_DESCRIPTION("Loongson DWMAC PCI driver");
 MODULE_AUTHOR("Qing Zhang <zhangqing@loongson.cn>");
+MODULE_AUTHOR("Yanteng Si <siyanteng@loongson.cn>");
 MODULE_LICENSE("GPL v2");
-- 
2.31.4

Re: [PATCH net-next v12 00/15] stmmac: Add Loongson platform support

[Serge Semin]

Yanteng,

On Thu, Apr 25, 2024 at 09:01:53PM +0800, Yanteng Si wrote:
> v12:
> * The biggest change is the re-splitting of patches.
> * Add a "gmac_version" in loongson_data, then we only
>   read it once in the _probe().
> * Drop Serge's patch.
> * Rebase to the latest code state.
> * Fixed the gnet commit message.

V11 review hasn't finished yet. You posted a question to me just four
hours ago, waited for an answer a tiny bit and decided to submit v12.
Really, what the rush for? Do you expect the reviewer to react in an
instant?

Please understand, the review process isn't a quick-road process. The
most of the maintainers and reviewers have their own jobs and can't
react just at the moment you want it or need it. It's better to
collect all the review comments, wait for all questions being answered
(ping the person you need if you waited long enough) and resubmit the
series with all the notes taken into account. Needlessly rushing and
spamming out the maintainers inboxes with your series containing just
a part of the requested changes, won't help you much but will likely
irritate the reviewers.

What do you expect me to do now? Move on with v11 review? Copy my
questions to v12 and continue the discussion here? By not waiting for
all the discussions done you made the my life harder. What was the
point? Sigh...

-Serge(y)

> 
> v11:
> * Break loongson_phylink_get_caps(), fix bad logic.
> * Remove a unnecessary ";".
> * Remove some unnecessary "{}".
> * add a blank.
> * Move the code of fix _force_1000 to patch 6/6.
> 
> The main changes occur in these two functions:
> loongson_dwmac_probe();
> loongson_dwmac_setup();
> 
> v10:
> As Andrew's comment:
> * Add a #define for the 0x37.
> * Add a #define for Port Select.
> 
> others:
> * Pick Serge's patch, This patch resulted from the process
>   of reviewing our patch set.
> * Based on Serge's patch, modify our loongson_phylink_get_caps().
> * Drop patch 3/6, we need mac_interface.
> * Adjusted the code layout of gnet patch.
> * Corrected several errata in commit message.
> * Move DISABLE_FORCE flag to loongson_gnet_data().
> 
> v9:
> We have not provided a detailed list of equipment for a long time,
> and I apologize for this. During this period, I have collected some
> information and now present it to you, hoping to alleviate the pressure
> of review.
> 
> 1. IP core
> We now have two types of IP cores, one is 0x37, similar to dwmac1000;
> The other is 0x10.  Compared to 0x37, we split several DMA registers
> from one to two, and it is not worth adding a new entry for this.
> According to Serge's comment, we made these devices work by overwriting
> priv->synopsys_id = 0x37 and mac->dma = <LS_dma_ops>.
> 
> 1.1.  Some more detailed information
> The number of DMA channels for 0x37 is 1; The number of DMA channels
> for 0x10 is 8.  Except for channel 0, otherchannels do not support
> sending hardware checksums. Supported AV features are Qav, Qat, and Qas,
> and the rest are consistent with 3.73.
> 
> 2. DEVICE
> We have two types of devices,
> one is GMAC, which only has a MAC chip inside and needs an external PHY
> chip;
> the other is GNET, which integrates both MAC and PHY chips inside.
> 
> 2.1.  Some more detailed information
> GMAC device: LS7A1000, LS2K1000, these devices do not support any pause
> mode.
> gnet device: LS7A2000, LS2K2000, the chip connection between the mac and
>              phy of these devices is not normal and requires two rounds of
>              negotiation; LS7A2000 does not support half-duplex and
> multi-channel;
>              to enable multi-channel on LS2K2000, you need to turn off
> hardware checksum.
> **Note**: Only the LS2K2000's IP core is 0x10, while the IP cores of other
> devices are 0x37.
> 
> 3. TABLE
> 
> device    type    pci_id    ip_core
> ls7a1000  gmac    7a03      0x35/0x37
> ls2k1000  gmac    7a03      0x35/0x37
> ls7a2000  gnet    7a13      0x37
> ls2k2000  gnet    7a13      0x10
> -----------------------------------------------
> Changes:
> 
> * passed the CI
>   <https://github.com/linux-netdev/nipa/blob/main/tests/patch/checkpatch
>   /checkpatch.sh>
> * reverse xmas tree order.
> * Silence build warning.
> * Re-split the patch.
> * Add more detailed commit message.
> * Add more code comment.
> * Reduce modification of generic code.
> * using the GNET-specific prefix.
> * define a new macro for the GNET MAC.
> * Use an easier way to overwrite mac.
> * Removed some useless printk.
> 
> 
> v8:
> * The biggest change is according to Serge's comment in the previous
>   edition:
>    Seeing the patch in the current state would overcomplicate the generic
>    code and the only functions you need to update are
>    dwmac_dma_interrupt()
>    dwmac1000_dma_init_channel()
>    you can have these methods re-defined with all the Loongson GNET
>    specifics in the low-level platform driver (dwmac-loongson.c). After
>    that you can just override the mac_device_info.dma pointer with a
>    fixed stmmac_dma_ops descriptor. Here is what should be done for that:
> 
>    1. Keep the Patch 4/9 with my comments fixed. First it will be partly
>    useful for your GNET device. Second in general it's a correct
>    implementation of the normal DW GMAC v3.x multi-channels feature and
>    will be useful for the DW GMACs with that feature enabled.
> 
>    2. Create the Loongson GNET-specific
>    stmmac_dma_ops.dma_interrupt()
>    stmmac_dma_ops.init_chan()
>    methods in the dwmac-loongson.c driver. Don't forget to move all the
>    Loongson-specific macros from dwmac_dma.h to dwmac-loongson.c.
> 
>    3. Create a Loongson GNET-specific platform setup method with the next
>    semantics:
>       + allocate stmmac_dma_ops instance and initialize it with
>         dwmac1000_dma_ops.
>       + override the stmmac_dma_ops.{dma_interrupt, init_chan} with
>         the pointers to the methods defined in 2.
>       + allocate mac_device_info instance and initialize the
>         mac_device_info.dma field with a pointer to the new
>         stmmac_dma_ops instance.
>       + call dwmac1000_setup() or initialize mac_device_info in a way
>         it's done in dwmac1000_setup() (the later might be better so you
>         wouldn't need to export the dwmac1000_setup() function).
>       + override stmmac_priv.synopsys_id with a correct value.
> 
>    4. Initialize plat_stmmacenet_data.setup() with the pointer to the
>    method created in 3.
> 
> * Others:
>   Re-split the patch.
>   Passed checkpatch.pl test.
> 
> v7:
> * Refer to andrew's suggestion:
>   - Add DMA_INTR_ENA_NIE_RX and DMA_INTR_ENA_NIE_TX #define's, etc.
> 
> * Others:
>   - Using --subject-prefix="PATCH net-next vN" to indicate that the
>     patches are for the networking tree.
>   - Rebase to the latest networking tree:
>     <git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git>
> 
> 
> v6:
> 
> * Refer to Serge's suggestion:
>   - Add new platform feature flag:
>     include/linux/stmmac.h:
>     +#define STMMAC_FLAG_HAS_LGMAC			BIT(13)
> 
>   - Add the IRQs macros specific to the Loongson Multi-channels GMAC:
>      drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h:
>      +#define DMA_INTR_ENA_NIE_LOONGSON 0x00060000      /* ...*/
>      #define DMA_INTR_ENA_NIE 0x00010000	/* Normal Summary */
>      ...
> 
>   - Drop all of redundant changes that don't require the
>     prototypes being converted to accepting the stmmac_priv
>     pointer.
> 
> * Refer to andrew's suggestion:
>   - Drop white space changes.
>   - break patch up into lots of smaller parts.
>      Some small patches have been put into another series as a preparation
>      see <https://lore.kernel.org/loongarch/cover.1702289232.git.siyanteng@loongson.cn/T/#t>
>      
>      *note* : This series of patches relies on the three small patches above.
> * others
>   - Drop irq_flags changes.
>   - Changed patch order.
> 
> 
> v4 -> v5:
> 
> * Remove an ugly and useless patch (fix channel number).
> * Remove the non-standard dma64 driver code, and also remove
>   the HWIF entries, since the associated custom callbacks no
>   longer exist.
> * Refer to Serge's suggestion: Update the dwmac1000_dma.c to
>   support the multi-DMA-channels controller setup.
> 
> See:
> v4: <https://lore.kernel.org/loongarch/cover.1692696115.git.chenfeiyang@loongson.cn/>
> v3: <https://lore.kernel.org/loongarch/cover.1691047285.git.chenfeiyang@loongson.cn/>
> v2: <https://lore.kernel.org/loongarch/cover.1690439335.git.chenfeiyang@loongson.cn/>
> v1: <https://lore.kernel.org/loongarch/cover.1689215889.git.chenfeiyang@loongson.cn/>
> 
> Yanteng Si (15):
>   net: stmmac: Move the atds flag to the stmmac_dma_cfg structure
>   net: stmmac: Add multi-channel support
>   net: stmmac: Export dwmac1000_dma_ops
>   net: stmmac: dwmac-loongson: Drop useless platform data
>   net: stmmac: dwmac-loongson: Use PCI_DEVICE_DATA() macro for device
>     identification
>   net: stmmac: dwmac-loongson: Split up the platform data initialization
>   net: stmmac: dwmac-loongson: Add ref and ptp clocks for Loongson
>   net: stmmac: dwmac-loongson: Add phy mask for Loongson GMAC
>   net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC
>   net: stmmac: dwmac-loongson: Add full PCI support
>   net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
>   net: stmmac: dwmac-loongson: Fixed failure to set network speed to
>     1000.
>   net: stmmac: dwmac-loongson: Add Loongson GNET support
>   net: stmmac: dwmac-loongson: Move disable_force flag to _gnet_date
>   net: stmmac: dwmac-loongson: Add loongson module author
> 
>  drivers/net/ethernet/stmicro/stmmac/common.h  |   1 +
>  .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 519 ++++++++++++++++--
>  .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c |   4 +-
>  .../ethernet/stmicro/stmmac/dwmac1000_dma.c   |  35 +-
>  .../ethernet/stmicro/stmmac/dwmac100_dma.c    |   2 +-
>  .../net/ethernet/stmicro/stmmac/dwmac4_dma.c  |   2 +-
>  .../net/ethernet/stmicro/stmmac/dwmac_dma.h   |  20 +-
>  .../net/ethernet/stmicro/stmmac/dwmac_lib.c   |  30 +-
>  .../ethernet/stmicro/stmmac/dwxgmac2_dma.c    |   2 +-
>  drivers/net/ethernet/stmicro/stmmac/hwif.h    |   5 +-
>  .../ethernet/stmicro/stmmac/stmmac_ethtool.c  |   6 +
>  .../net/ethernet/stmicro/stmmac/stmmac_main.c |  11 +-
>  include/linux/stmmac.h                        |   2 +
>  13 files changed, 536 insertions(+), 103 deletions(-)
> 
> -- 
> 2.31.4
> 

Re: [PATCH net-next v12 09/15] net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC

[Russell King (Oracle)]

On Thu, Apr 25, 2024 at 09:06:12PM +0800, Yanteng Si wrote:
> The mac_interface of gmac is PHY_INTERFACE_MODE_RGMII_ID.

No it isn't!

> +	plat->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;

You don't touch mac_interface here. Please read the big comment I put
in include/linux/stmmac.h above these fields in struct
plat_stmmacenet_data to indicate what the difference between
mac_interface and phy_interface are, and then correct which-ever
of the above needs to be corrected.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next v12 00/15] stmmac: Add Loongson platform support

[Yanteng Si]

Hi Serge,

在 2024/4/25 21:19, Serge Semin 写道:
>> v12:
>> * The biggest change is the re-splitting of patches.
>> * Add a "gmac_version" in loongson_data, then we only
>>    read it once in the _probe().
>> * Drop Serge's patch.
>> * Rebase to the latest code state.
>> * Fixed the gnet commit message.
> V11 review hasn't finished yet. You posted a question to me just four
> hours ago, waited for an answer a tiny bit and decided to submit v12.
> Really, what the rush for? Do you expect the reviewer to react in an
> instant?

I'm sorry. It's my fault.


I did this because I didn't want to repeat the v8 process, we talked 
about v8 for

two months, after I collected all the comments and changed the code, a 
lot of

changes happened, and I seemed to misunderstand the comments about patch

splitting, which made v9-v11 look bad.


v12 is actually still based on v8, but it's just resplit the patches 
again, maybe

it's easier to review,

>
> Please understand, the review process isn't a quick-road process. The
> most of the maintainers and reviewers have their own jobs and can't
> react just at the moment you want it or need it. It's better to

Yes, I quite agree with you. In fact, we have been working together 
happily for

almost a year. I appreciate your patience. With your help, this patch 
set has

gotten better and better since the beginning.

> collect all the review comments, wait for all questions being answered
> (ping the person you need if you waited long enough) and resubmit the

Yes, I understand, because I also do some kernel document translation in my

spare time, and I understand this very well.

> series with all the notes taken into account. Needlessly rushing and
> spamming out the maintainers inboxes with your series containing just
> a part of the requested changes, won't help you much but will likely
> irritate the reviewers.
Ok, I will reduce the frequency of my emails unless all comments are 
clearly answered.
>
> What do you expect me to do now? Move on with v11 review? Copy my
> questions to v12 and continue the discussion here? By not waiting for
> all the discussions done you made the my life harder. What was the
> point? Sigh...

v11 is not much different from v12, except that it removes your patch 
and then

resplits the patch, which improves the review efficiency to some extent.


loongson_dwmac_config_multi_msi() is the only comment left that didn't 
end in

v11. I originally wanted to include this question in the cover letter of 
v12, but I

did send it in a hurry and lost it. I'm sorry about that, let me copy 
this question

to v12.


Thanks,

Yanteng

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Yanteng Si]

Copy here a comment from v11 that didn't get a clear response.


In v11:

在 2024/4/25 21:11, Yanteng Si 写道:
> +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
> +				     struct plat_stmmacenet_data *plat,
> +				     struct stmmac_resources *res,
> +				     struct device_node *np)
> +{
> +	int i, ret, vecs;
> +
> +	vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
> +	ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
> +	if (ret < 0) {
> +		dev_info(&pdev->dev,
> +			 "MSI enable failed, Fallback to legacy interrupt\n");
> +		return loongson_dwmac_config_legacy(pdev, plat, res, np);
> +	}
> +
> +	res->irq = pci_irq_vector(pdev, 0);
> +	res->wol_irq = 0;
> +
> +	/* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> +	 * --------- ----- -------- --------  ...  -------- --------
> +	 * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> +	 */
> +	for (i = 0; i < CHANNEL_NUM; i++) {
> +		res->rx_irq[CHANNEL_NUM - 1 - i] =
> +			pci_irq_vector(pdev, 1 + i * 2);
> +		res->tx_irq[CHANNEL_NUM - 1 - i] =
> +			pci_irq_vector(pdev, 2 + i * 2);
> +	}
> +
> +	plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> +
> +	return 0;
> +}

* First,Serge wrote:


   Once again. Please replace this with simpler solution:

   static int loongson_dwmac_config_multi_msi(struct pci_dev *pdev,
   +					   struct plat_stmmacenet_data *plat,
   +					   struct stmmac_resources *res)
   +{
   +	int i, ret, vecs;
   +
   +	/* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
   +	 * --------- ----- -------- --------  ...  -------- --------
   +	 * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
   +	 */
   +	vecs = plat->rx_queues_to_use + plat->tx_queues_to_use + 1;
   +	ret = pci_alloc_irq_vectors(pdev, 1, vecs, PCI_IRQ_MSI | PCI_IRQ_LEGACY);
   +	if (ret < 0) {
   +		dev_err(&pdev->dev, "Failed to allocate PCI IRQs\n");
   +		return ret;
   +	} else if (ret >= vecs) {
   +		for (i = 0; i < plat->rx_queues_to_use; i++) {
   +			res->rx_irq[CHANNELS_NUM - 1 - i] =
   +				pci_irq_vector(pdev, 1 + i * 2);
   +		}
   +		for (i = 0; i < plat->tx_queues_to_use; i++) {
   +			res->tx_irq[CHANNELS_NUM - 1 - i] =
   +				pci_irq_vector(pdev, 2 + i * 2);
   +		}
   +
   +		plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
   +	}
   +
   +	res->irq = pci_irq_vector(pdev, 0);
   +
   +	return 0;
   +}

* Then, Yanteng wrote:

   Well, I'll try again.

* And then,Hiacai wrote:

   In full PCI system the below function works fine, because alloc irq
   vectors with PCI_IRQ_LEGACY do the same thing as fallback to call
   loongson_dwmac_config_legacy(). But for a DT-based system it doesn't
   work.

* Last, Yanteng wrote:

   Hi Serge,
   How about we stay the same in v12?


Thanks,
Yanteng

Re: [PATCH net-next v12 09/15] net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC

[Yanteng Si]

Hi Russell,

在 2024/4/25 22:36, Russell King (Oracle) 写道:
>> The mac_interface of gmac is PHY_INTERFACE_MODE_RGMII_ID.
> No it isn't!
Ok, that's a typo.
>
>> +	plat->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
> You don't touch mac_interface here. Please read the big comment I put
> in include/linux/stmmac.h above these fields in struct
> plat_stmmacenet_data to indicate what the difference between
> mac_interface and phy_interface are, and then correct which-ever
> of the above needs to be corrected.

Copy your big comment here:

     int phy_addr;
     /* MAC ----- optional PCS ----- SerDes ----- optional PHY ----- Media
      *       ^                               ^
      * mac_interface                   phy_interface
      *
      * mac_interface is the MAC-side interface, which may be the same
      * as phy_interface if there is no intervening PCS. If there is a
      * PCS, then mac_interface describes the interface mode between the
      * MAC and PCS, and phy_interface describes the interface mode
      * between the PCS and PHY.
      */
     phy_interface_t mac_interface;
     /* phy_interface is the PHY-side interface - the interface used by
      * an attached PHY.
      */

Our hardware engineer said we don't support pcs, and if I understand

your comment correctly, our mac_interface and phy_interface should

be the same, right?


Thanks,

Yanteng

Re: [PATCH net-next v12 09/15] net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC

[Russell King (Oracle)]

On Fri, Apr 26, 2024 at 06:16:42PM +0800, Yanteng Si wrote:
> Hi Russell,
> 
> 在 2024/4/25 22:36, Russell King (Oracle) 写道:
> > > The mac_interface of gmac is PHY_INTERFACE_MODE_RGMII_ID.
> > No it isn't!
> Ok, that's a typo.
> > 
> > > +	plat->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
> > You don't touch mac_interface here. Please read the big comment I put
> > in include/linux/stmmac.h above these fields in struct
> > plat_stmmacenet_data to indicate what the difference between
> > mac_interface and phy_interface are, and then correct which-ever
> > of the above needs to be corrected.
> 
> Copy your big comment here:
> 
>     int phy_addr;
>     /* MAC ----- optional PCS ----- SerDes ----- optional PHY ----- Media
>      *       ^                               ^
>      * mac_interface                   phy_interface
>      *
>      * mac_interface is the MAC-side interface, which may be the same
>      * as phy_interface if there is no intervening PCS. If there is a
>      * PCS, then mac_interface describes the interface mode between the
>      * MAC and PCS, and phy_interface describes the interface mode
>      * between the PCS and PHY.
>      */
>     phy_interface_t mac_interface;
>     /* phy_interface is the PHY-side interface - the interface used by
>      * an attached PHY.
>      */
> 
> Our hardware engineer said we don't support pcs, and if I understand
> 
> your comment correctly, our mac_interface and phy_interface should
> 
> be the same, right?

It only matters to the core code if priv->dma_cap.pcs is set true.
If it isn't, then mac_interface doesn't seem to be relevent (it
does get used by a truck load of platform specific code though
which I haven't looked at to answer this.)

I would suggest that if priv->dma_cap.pcs is false, then setting
mac_interface to PHY_INTERFACE_MODE_NA to make it explicit that
it's not used would be a good idea.

While looking at this, however, I've come across the fact that
stmmac manipulates the netif carrier via netif_carrier_off() and
netif_carrier_on(), which is a _big_ no no when using phylink.
Phylink manages the carrier for the driver, and its part of
phylink's state. Fiddling with the carrier totally breaks the
guarantee that phylink will make calls to mac_link_down() and
mac_link_up().

If a driver wants to fiddle with the netif carrier, it must NOT
use phylink. If it wants to use phylink, it must NOT fiddle with
the netif carrier state. The two are mutually exclusive.

stmmac is quickly becoming a driver I don't care about whether my
changes to phylink end up breaking it or not because of abuses
like this.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next v12 00/15] stmmac: Add Loongson platform support

[Serge Semin]

On Fri, Apr 26, 2024 at 12:55:34PM +0800, Yanteng Si wrote:
> Hi Serge,
> 
> 在 2024/4/25 21:19, Serge Semin 写道:
> > > v12:
> > > * The biggest change is the re-splitting of patches.
> > > * Add a "gmac_version" in loongson_data, then we only
> > >    read it once in the _probe().
> > > * Drop Serge's patch.
> > > * Rebase to the latest code state.
> > > * Fixed the gnet commit message.
> > V11 review hasn't finished yet. You posted a question to me just four
> > hours ago, waited for an answer a tiny bit and decided to submit v12.
> > Really, what the rush for? Do you expect the reviewer to react in an
> > instant?
> 
> I'm sorry. It's my fault.
> 
> 
> I did this because I didn't want to repeat the v8 process, we talked about
> v8 for
> 
> two months, after I collected all the comments and changed the code, a lot
> of
> 
> changes happened, and I seemed to misunderstand the comments about patch
> 
> splitting, which made v9-v11 look bad.
> 
> 
> v12 is actually still based on v8, but it's just resplit the patches again,
> maybe
> 
> it's easier to review,
> 
> > 
> > Please understand, the review process isn't a quick-road process. The
> > most of the maintainers and reviewers have their own jobs and can't
> > react just at the moment you want it or need it. It's better to
> 
> Yes, I quite agree with you. In fact, we have been working together happily
> for
> 
> almost a year. I appreciate your patience. With your help, this patch set
> has
> 
> gotten better and better since the beginning.
> 
> > collect all the review comments, wait for all questions being answered
> > (ping the person you need if you waited long enough) and resubmit the
> 
> Yes, I understand, because I also do some kernel document translation in my
> 
> spare time, and I understand this very well.
> 
> > series with all the notes taken into account. Needlessly rushing and
> > spamming out the maintainers inboxes with your series containing just
> > a part of the requested changes, won't help you much but will likely
> > irritate the reviewers.

> Ok, I will reduce the frequency of my emails unless all comments are clearly
> answered.

Not all emails, but just the series _resubmissions_. It's much better
not to rush, make sure you got all the comments correctly and resubmit
only then. Should you have any doubts, just ask and wait for some time
(day-two-three). It will be easier and much less troublesome to fully
clarify things first and then send out a close-to-what-was-requested
patchset - less emails traffic in the inboxes, a discussion
concentrated in a single place in the LKML archive, more happy
reviewers/maintainers - less meticulous notes.)

> > 
> > What do you expect me to do now? Move on with v11 review? Copy my
> > questions to v12 and continue the discussion here? By not waiting for
> > all the discussions done you made the my life harder. What was the
> > point? Sigh...
> 
> v11 is not much different from v12, except that it removes your patch and
> then
> 
> resplits the patch, which improves the review efficiency to some extent.
> 
> 
> loongson_dwmac_config_multi_msi() is the only comment left that didn't end
> in
> 
> v11. I originally wanted to include this question in the cover letter of
> v12, but I
> 
> did send it in a hurry and lost it. I'm sorry about that, let me copy
> this question
> 
> to v12.

Ok. Thanks for re-submitting the MSI-related discussion to the
respective patch. I'll revise the rest of the v11 discussions anyway
so not to miss the notes gist and get back to reviewing your series in
2-4 days.

-Serge(y)

> 
> 
> Thanks,
> 
> Yanteng
> 
> 

Re: [PATCH net-next v12 01/15] net: stmmac: Move the atds flag to the stmmac_dma_cfg structure

[Serge Semin]

On Thu, Apr 25, 2024 at 09:01:54PM +0800, Yanteng Si wrote:
> Alternate Descriptor Size (ATDS) is a part of the DMA-configs together
> with the PBL, ALL, AEME, etc so the structure is the most suitable
> place for it.

The better description would be:

"ATDS (Alternate Descriptor Size) is a part of the DMA Bus Mode configs
(together with PBL, ALL, EME, etc) of the DW GMAC controllers. Seeing
it's not changed at runtime but is activated as long as the IP-core
has it supported (at least due to the Type 2 Full Checksum Offload
Engine feature), move the respective parameter from the
stmmac_dma_ops::init() callback argument to the stmmac_dma_cfg
structure, which already have the rest of the DMA-related configs
defined.

Besides the being added in the next commit DW GMAC multi-channels
support will require to add the stmmac_dma_ops::init_chan() callback
and have the ATDS flag set/cleared for each channel in there. Having
the atds-flag in the stmmac_dma_cfg structure will make the parameter
accessible from stmmac_dma_ops::init_chan() callback too."

Other than that the change looks good. Thanks.

Reviewed-by: Serge Semin <fancer.lancer@gmail.com>

-Serge(y)

> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c   | 2 +-
>  drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 4 ++--
>  drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c  | 2 +-
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c    | 2 +-
>  drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c  | 2 +-
>  drivers/net/ethernet/stmicro/stmmac/hwif.h          | 3 +--
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c   | 5 ++---
>  include/linux/stmmac.h                              | 1 +
>  8 files changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> index e1b761dcfa1d..d87079016952 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> @@ -299,7 +299,7 @@ static int sun8i_dwmac_dma_reset(void __iomem *ioaddr)
>   * Called from stmmac via stmmac_dma_ops->init
>   */
>  static void sun8i_dwmac_dma_init(void __iomem *ioaddr,
> -				 struct stmmac_dma_cfg *dma_cfg, int atds)
> +				 struct stmmac_dma_cfg *dma_cfg)
>  {
>  	writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
>  	writel(0x1FFFFFF, ioaddr + EMAC_INT_STA);
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> index daf79cdbd3ec..bb82ee9b855f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> @@ -71,7 +71,7 @@ static void dwmac1000_dma_axi(void __iomem *ioaddr, struct stmmac_axi *axi)
>  }
>  
>  static void dwmac1000_dma_init(void __iomem *ioaddr,
> -			       struct stmmac_dma_cfg *dma_cfg, int atds)
> +			       struct stmmac_dma_cfg *dma_cfg)
>  {
>  	u32 value = readl(ioaddr + DMA_BUS_MODE);
>  	int txpbl = dma_cfg->txpbl ?: dma_cfg->pbl;
> @@ -98,7 +98,7 @@ static void dwmac1000_dma_init(void __iomem *ioaddr,
>  	if (dma_cfg->mixed_burst)
>  		value |= DMA_BUS_MODE_MB;
>  
> -	if (atds)
> +	if (dma_cfg->atds)
>  		value |= DMA_BUS_MODE_ATDS;
>  
>  	if (dma_cfg->aal)
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
> index dea270f60cc3..f861babc06f9 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
> @@ -19,7 +19,7 @@
>  #include "dwmac_dma.h"
>  
>  static void dwmac100_dma_init(void __iomem *ioaddr,
> -			      struct stmmac_dma_cfg *dma_cfg, int atds)
> +			      struct stmmac_dma_cfg *dma_cfg)
>  {
>  	/* Enable Application Access by writing to DMA CSR0 */
>  	writel(DMA_BUS_MODE_DEFAULT | (dma_cfg->pbl << DMA_BUS_MODE_PBL_SHIFT),
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> index 84d3a8551b03..e0165358c4ac 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> @@ -153,7 +153,7 @@ static void dwmac410_dma_init_channel(struct stmmac_priv *priv,
>  }
>  
>  static void dwmac4_dma_init(void __iomem *ioaddr,
> -			    struct stmmac_dma_cfg *dma_cfg, int atds)
> +			    struct stmmac_dma_cfg *dma_cfg)
>  {
>  	u32 value = readl(ioaddr + DMA_SYS_BUS_MODE);
>  
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
> index dd2ab6185c40..7840bc403788 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
> @@ -20,7 +20,7 @@ static int dwxgmac2_dma_reset(void __iomem *ioaddr)
>  }
>  
>  static void dwxgmac2_dma_init(void __iomem *ioaddr,
> -			      struct stmmac_dma_cfg *dma_cfg, int atds)
> +			      struct stmmac_dma_cfg *dma_cfg)
>  {
>  	u32 value = readl(ioaddr + XGMAC_DMA_SYSBUS_MODE);
>  
> diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
> index 90384db228b5..413441eb6ea0 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
> @@ -175,8 +175,7 @@ struct dma_features;
>  struct stmmac_dma_ops {
>  	/* DMA core initialization */
>  	int (*reset)(void __iomem *ioaddr);
> -	void (*init)(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg,
> -		     int atds);
> +	void (*init)(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg);
>  	void (*init_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
>  			  struct stmmac_dma_cfg *dma_cfg, u32 chan);
>  	void (*init_rx_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 59bf83904b62..188514ca6c47 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3006,7 +3006,6 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv)
>  	struct stmmac_rx_queue *rx_q;
>  	struct stmmac_tx_queue *tx_q;
>  	u32 chan = 0;
> -	int atds = 0;
>  	int ret = 0;
>  
>  	if (!priv->plat->dma_cfg || !priv->plat->dma_cfg->pbl) {
> @@ -3015,7 +3014,7 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv)
>  	}
>  
>  	if (priv->extend_desc && (priv->mode == STMMAC_RING_MODE))
> -		atds = 1;
> +		priv->plat->dma_cfg->atds = 1;
>  
>  	ret = stmmac_reset(priv, priv->ioaddr);
>  	if (ret) {
> @@ -3024,7 +3023,7 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv)
>  	}
>  
>  	/* DMA Configuration */
> -	stmmac_dma_init(priv, priv->ioaddr, priv->plat->dma_cfg, atds);
> +	stmmac_dma_init(priv, priv->ioaddr, priv->plat->dma_cfg);
>  
>  	if (priv->plat->axi)
>  		stmmac_axi(priv, priv->ioaddr, priv->plat->axi);
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index dfa1828cd756..1b54b84a6785 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -100,6 +100,7 @@ struct stmmac_dma_cfg {
>  	bool eame;
>  	bool multi_msi_en;
>  	bool dche;
> +	bool atds;
>  };
>  
>  #define AXI_BLEN	7
> -- 
> 2.31.4
> 

Re: [PATCH net-next v12 02/15] net: stmmac: Add multi-channel support

[Serge Semin]

On Thu, Apr 25, 2024 at 09:01:55PM +0800, Yanteng Si wrote:
> DW GMAC v3.x multi-channels feature is implemented as multiple
> sets of the same CSRs. Here is only preliminary support, it will
> be useful for the driver further evolution and for the users
> having multi-channel DWGMAC v3.x devices.

Why do you call it "preliminary"? AFAICS it's a fully functional
support with no restrictions. Am I wrong?

I would reformulate the commit message as:

"DW GMAC v3.73 can be equipped with the Audio Video (AV) feature which
enables transmission of time-sensitive traffic over bridged local area
networks (DWC Ethernet QoS Product). In that case there can be up to two
additional DMA-channels available with no Tx COE support (unless there is
vendor-specific IP-core alterations). Each channel is implemented as a
separate Control and Status register (CSR) for managing the transmit and
receive functions, descriptor handling, and interrupt handling.

Add the multi-channels DW GMAC controllers support just by making sure the
already implemented DMA-configs are performed on the per-channel basis.

Note the only currently known instance of the multi-channel DW GMAC
IP-core is the LS2K2000 GNET controller, which has been released with the
vendor-specific feature extension of having eight DMA-channels. The device
support will be added in one of the following up commits."

> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c |  2 +-
>  .../ethernet/stmicro/stmmac/dwmac1000_dma.c   | 32 ++++++++++---------
>  .../net/ethernet/stmicro/stmmac/dwmac_dma.h   | 20 ++++++++++--
>  .../net/ethernet/stmicro/stmmac/dwmac_lib.c   | 30 ++++++++---------
>  drivers/net/ethernet/stmicro/stmmac/hwif.h    |  2 +-
>  .../net/ethernet/stmicro/stmmac/stmmac_main.c |  6 ++--
>  6 files changed, 55 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> index d87079016952..cc93f73a380e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> @@ -395,7 +395,7 @@ static void sun8i_dwmac_dma_start_tx(struct stmmac_priv *priv,
>  	writel(v, ioaddr + EMAC_TX_CTL1);
>  }
>  
> -static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr)
> +static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr, u32 chan)
>  {
>  	u32 v;
>  
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> index bb82ee9b855f..f161ec9ac490 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> @@ -70,15 +70,17 @@ static void dwmac1000_dma_axi(void __iomem *ioaddr, struct stmmac_axi *axi)
>  	writel(value, ioaddr + DMA_AXI_BUS_MODE);
>  }
>  
> -static void dwmac1000_dma_init(void __iomem *ioaddr,
> -			       struct stmmac_dma_cfg *dma_cfg)
> +static void dwmac1000_dma_init_channel(struct stmmac_priv *priv,
> +				       void __iomem *ioaddr,
> +				       struct stmmac_dma_cfg *dma_cfg, u32 chan)
>  {
> -	u32 value = readl(ioaddr + DMA_BUS_MODE);
>  	int txpbl = dma_cfg->txpbl ?: dma_cfg->pbl;
>  	int rxpbl = dma_cfg->rxpbl ?: dma_cfg->pbl;
> +	u32 value;
>  
> -	/*
> -	 * Set the DMA PBL (Programmable Burst Length) mode.
> +	value = readl(ioaddr + DMA_CHAN_BUS_MODE(chan));
> +
> +	/* Set the DMA PBL (Programmable Burst Length) mode.
>  	 *
>  	 * Note: before stmmac core 3.50 this mode bit was 4xPBL, and
>  	 * post 3.5 mode bit acts as 8*PBL.
> @@ -104,10 +106,10 @@ static void dwmac1000_dma_init(void __iomem *ioaddr,
>  	if (dma_cfg->aal)
>  		value |= DMA_BUS_MODE_AAL;
>  
> -	writel(value, ioaddr + DMA_BUS_MODE);
> +	writel(value, ioaddr + DMA_CHAN_BUS_MODE(chan));
>  
>  	/* Mask interrupts by writing to CSR7 */
> -	writel(DMA_INTR_DEFAULT_MASK, ioaddr + DMA_INTR_ENA);
> +	writel(DMA_INTR_DEFAULT_MASK, ioaddr + DMA_CHAN_INTR_ENA(chan));
>  }
>  
>  static void dwmac1000_dma_init_rx(struct stmmac_priv *priv,
> @@ -116,7 +118,7 @@ static void dwmac1000_dma_init_rx(struct stmmac_priv *priv,
>  				  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);
> +	writel(lower_32_bits(dma_rx_phy), ioaddr + DMA_CHAN_RCV_BASE_ADDR(chan));
>  }
>  
>  static void dwmac1000_dma_init_tx(struct stmmac_priv *priv,
> @@ -125,7 +127,7 @@ static void dwmac1000_dma_init_tx(struct stmmac_priv *priv,
>  				  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);
> +	writel(lower_32_bits(dma_tx_phy), ioaddr + DMA_CHAN_TX_BASE_ADDR(chan));
>  }
>  
>  static u32 dwmac1000_configure_fc(u32 csr6, int rxfifosz)



> @@ -153,7 +155,7 @@ static void dwmac1000_dma_operation_mode_rx(struct stmmac_priv *priv,
>  					    void __iomem *ioaddr, int mode,
>  					    u32 channel, int fifosz, u8 qmode)
>  {
> -	u32 csr6 = readl(ioaddr + DMA_CONTROL);
> +	u32 csr6 = readl(ioaddr + DMA_CHAN_CONTROL(channel));
>  
>  	if (mode == SF_DMA_MODE) {
>  		pr_debug("GMAC: enable RX store and forward mode\n");
> @@ -175,14 +177,14 @@ static void dwmac1000_dma_operation_mode_rx(struct stmmac_priv *priv,
>  	/* Configure flow control based on rx fifo size */
>  	csr6 = dwmac1000_configure_fc(csr6, fifosz);
>  
> -	writel(csr6, ioaddr + DMA_CONTROL);
> +	writel(csr6, ioaddr + DMA_CHAN_CONTROL(channel));
>  }
>  
>  static void dwmac1000_dma_operation_mode_tx(struct stmmac_priv *priv,
>  					    void __iomem *ioaddr, int mode,
>  					    u32 channel, int fifosz, u8 qmode)
>  {
> -	u32 csr6 = readl(ioaddr + DMA_CONTROL);
> +	u32 csr6 = readl(ioaddr + DMA_CHAN_CONTROL(channel));
>  
>  	if (mode == SF_DMA_MODE) {
>  		pr_debug("GMAC: enable TX store and forward mode\n");
> @@ -209,7 +211,7 @@ static void dwmac1000_dma_operation_mode_tx(struct stmmac_priv *priv,
>  			csr6 |= DMA_CONTROL_TTC_256;
>  	}
>  
> -	writel(csr6, ioaddr + DMA_CONTROL);
> +	writel(csr6, ioaddr + DMA_CHAN_CONTROL(channel));
>  }
>  

Just figured out that besides of the channel-related changes you also need
to have the stmmac_dma_operation_mode() method fixed. So one wouldn't
redistribute the detected Tx/Rx FIFO between the channels. Each DW GMAC
channel has separate FIFO of the same size. The databook explicitly says
about that:

"The Tx FIFO size of all selected Transmit channels is always same.
Similarly, the Rx FIFO size of all selected Receive channels is same.
These channels cannot be of different sizes."

-Serge(y)

> [...] 

Re: [PATCH net-next v12 03/15] net: stmmac: Export dwmac1000_dma_ops

[Serge Semin]

On Thu, Apr 25, 2024 at 09:01:56PM +0800, Yanteng Si wrote:
> The loongson gnet will call it in the future.

More descriptive commit log:

"Export the DW GMAC DMA-ops descriptor so one could be available in
the low-level platform drivers. It will be utilized to override some
callbacks in order to handle the LS2K2000 GNET device specifics. The
GNET controller support is being added in one of the following up
commits."

Other than that the change looks good. Thanks.

Reviewed-by: Serge Semin <fancer.lancer@gmail.com>

-Serge(y)

> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> index f161ec9ac490..66c0c22908b1 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> @@ -296,3 +296,4 @@ const struct stmmac_dma_ops dwmac1000_dma_ops = {
>  	.get_hw_feature = dwmac1000_get_hw_feature,
>  	.rx_watchdog = dwmac1000_rx_watchdog,
>  };
> +EXPORT_SYMBOL_GPL(dwmac1000_dma_ops);
> -- 
> 2.31.4
> 

Re: [PATCH net-next v12 04/15] net: stmmac: dwmac-loongson: Drop useless platform data

[Serge Semin]

On Thu, Apr 25, 2024 at 09:04:35PM +0800, Yanteng Si wrote:
> The multicast_filter_bins is initialized twice, it should
> be 256, let's drop the first useless assignment.

Please drop the second plat_stmmacenet_data::multicast_filter_bins
init statement and just change the first one to initializing the
correct value - 256. Thus you'll have
1. the multicast and unicast filters size inits done in the same place;
2. the in-situ comments preserved (it's not like they're that much
helpful, but seeing the rest of the lines have a comment above it
would be nice to have the comment preserved here too);
3. dropped the statement closely attached to the return statement
(in kernel it's a widespread practice to separate the return
statement with an empty line).

The unit 1. is the main reason of course.

A bit more readable commit log would be:

"The plat_stmmacenet_data::multicast_filter_bins field is twice
initialized in the loongson_default_data() method. Drop the redundant
initialization, but for the readability sake keep the filters init
statements defined in the same place of the method."

-Serge(y)

> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 9e40c28d453a..19906ea67636 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -15,9 +15,6 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>  	plat->has_gmac = 1;
>  	plat->force_sf_dma_mode = 1;
>  
> -	/* Set default value for multicast hash bins */
> -	plat->multicast_filter_bins = HASH_TABLE_SIZE;
> -
>  	/* Set default value for unicast filter entries */
>  	plat->unicast_filter_entries = 1;
>  
> -- 
> 2.31.4
> 

Re: [PATCH net-next v12 05/15] net: stmmac: dwmac-loongson: Use PCI_DEVICE_DATA() macro for device identification

[Serge Semin]

On Thu, Apr 25, 2024 at 09:04:36PM +0800, Yanteng Si wrote:
> Just use PCI_DEVICE_DATA() macro for device identification,
> No changes to function functionality.

Some more verbose commit log:

"For the readability sake convert the hard-coded Loongson GMAC PCI ID to
the respective macro and use the PCI_DEVICE_DATA() macro-function to
create the pci_device_id array entry. The later change will be
specifically useful in order to assign the device-specific data for the
currently supported device and for about to be added Loongson GNET
controller."

Other than that the change looks good:

Reviewed-by: Serge Semin <fancer.lancer@gmail.com>

-Serge(y)

> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 19906ea67636..4e0838db4259 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -9,6 +9,8 @@
>  #include <linux/of_irq.h>
>  #include "stmmac.h"
>  
> +#define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
> +
>  static int loongson_default_data(struct plat_stmmacenet_data *plat)
>  {
>  	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
> @@ -210,7 +212,7 @@ static SIMPLE_DEV_PM_OPS(loongson_dwmac_pm_ops, loongson_dwmac_suspend,
>  			 loongson_dwmac_resume);
>  
>  static const struct pci_device_id loongson_dwmac_id_table[] = {
> -	{ PCI_VDEVICE(LOONGSON, 0x7a03) },
> +	{ PCI_DEVICE_DATA(LOONGSON, GMAC, NULL) },
>  	{}
>  };
>  MODULE_DEVICE_TABLE(pci, loongson_dwmac_id_table);
> -- 
> 2.31.4
> 

Re: [PATCH net-next v12 04/15] net: stmmac: dwmac-loongson: Drop useless platform data

[Serge Semin]

On Fri, May 03, 2024 at 01:55:38PM +0300, Serge Semin wrote:
> On Thu, Apr 25, 2024 at 09:04:35PM +0800, Yanteng Si wrote:
> > The multicast_filter_bins is initialized twice, it should
> > be 256, let's drop the first useless assignment.
> 
> Please drop the second plat_stmmacenet_data::multicast_filter_bins
> init statement and just change the first one to initializing the
> correct value - 256. Thus you'll have
> 1. the multicast and unicast filters size inits done in the same place;
> 2. the in-situ comments preserved (it's not like they're that much
> helpful, but seeing the rest of the lines have a comment above it
> would be nice to have the comment preserved here too);
> 3. dropped the statement closely attached to the return statement
> (in kernel it's a widespread practice to separate the return
> statement with an empty line).
> 
> The unit 1. is the main reason of course.
> 
> A bit more readable commit log would be:
> 

> "The plat_stmmacenet_data::multicast_filter_bins field is twice
> initialized in the loongson_default_data() method. Drop the redundant
> initialization, but for the readability sake keep the filters init
> statements defined in the same place of the method."

[PATCH net-next v12 04/15] net: stmmac: dwmac-loongson: Drop useless platform data

The patch subject is too generic. Just make it:

[PATCH net-next v12 04/15] net: stmmac: dwmac-loongson: Drop duplicated hash-based filter size init

-Serge(y)

> 
> -Serge(y)
> 
> > 
> > Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> > Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> > Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> > ---
> >  drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 3 ---
> >  1 file changed, 3 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > index 9e40c28d453a..19906ea67636 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > @@ -15,9 +15,6 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
> >  	plat->has_gmac = 1;
> >  	plat->force_sf_dma_mode = 1;
> >  
> > -	/* Set default value for multicast hash bins */
> > -	plat->multicast_filter_bins = HASH_TABLE_SIZE;
> > -
> >  	/* Set default value for unicast filter entries */
> >  	plat->unicast_filter_entries = 1;
> >  
> > -- 
> > 2.31.4
> > 

Re: [PATCH net-next v12 06/15] net: stmmac: dwmac-loongson: Split up the platform data initialization

[Serge Semin]

> [PATCH net-next v12 06/15] net: stmmac: dwmac-loongson: Split up the platform data initialization

Please convert the subject to being more specific, like this:

net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

On Thu, Apr 25, 2024 at 09:04:37PM +0800, Yanteng Si wrote:
> Based on IP core classification, loongson has two types of network

What is the real company name? At least start the name with the
capital letter.
* everywhere 

> devices: GMAC and GNET. GMAC's ip_core id is 0x35/0x37, while GNET's
> ip_core id is 0x37/0x10.

s/ip_core/IP-core

Once again the IP-core ID isn't _hex_, but a number of the format:
"v+Major.Minor"
so use the _real_ IP-core version number everywhere. Note mentioning
that some of your GNET device has the GMAC_VERSION.SNPSVER hardwired
to 0x10 is completely redundant in this and many other context. The
only place where it's relevant is the patch(es) where you have the
Snps ID override.

> 
> Device tables:
> 

> device    type    pci_id    snps_id    channel
> ls2k1000  gmac    7a03      0x35/0x37   1
> ls7a1000  gmac    7a03      0x35/0x37   1
> ls2k2000  gnet    7a13      0x10        8
> ls7a2000  gnet    7a13      0x37        1

s/gmac/GMAC
s/gnet/GNET
s/pci_id/PCI Dev ID
s/snsp_id/Synopys Version
s/channels/DMA-channels
s/ls2k/LS2K
s/ls7a/LS7A

* everywhere

> 
> The GMAC device only has a MAC chip inside and needs an
> external PHY chip;
> 
> To later distinguish 8-channel gnet devices from single-channel
> gnet/gmac devices, move rx_queues_to_use loongson_default_data
> to loongson_dwmac_probe(). Also move mac_interface to
> loongson_default_data().

Again. This is only a part of the reason why you need this change.
The main reason is to provide the two-leveled platform data init
functions: fist one is the common method initializing the data common
for both GMAC and GNET, second one is the device-specific data
initializer.

To sum up I would change the commit log to something like this:

"Loongson delivers two types of the network devices: Loongson GMAC and
Loongson GNET in the framework of four CPU/Chipsets revisions:

   Chip             Network  PCI Dev ID   Synopys Version   DMA-channel
LS2K1000 CPU         GMAC      0x7a03       v3.50a/v3.73a        1
LS7A1000 Chipset     GMAC      0x7a03       v3.50a/v3.73a        1
LS2K2000 CPU         GNET      0x7a13          v3.73a            8
LS7A2000 Chipset     GNET      0x7a13          v3.73a            1

The driver currently supports the chips with the Loongson GMAC network
device. As a preparation before adding the Loongson GNET support
detach the Loongson GMAC-specific platform data initializations to the
loongson_gmac_data() method and preserve the common settings in the
loongson_default_data().

While at it drop the return value statement from the
loongson_default_data() method as redundant."

> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 20 ++++++++++++-------
>  1 file changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 4e0838db4259..904e288d0be0 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -11,22 +11,20 @@
>  
>  #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
>  
> -static int loongson_default_data(struct plat_stmmacenet_data *plat)
> +static void loongson_default_data(struct plat_stmmacenet_data *plat)
>  {
>  	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
>  	plat->has_gmac = 1;
>  	plat->force_sf_dma_mode = 1;
>  

> +	plat->mac_interface = PHY_INTERFACE_MODE_GMII;
> +

I double-checked this part in my HW and in the databooks. DW GMAC with
_RGMII_ PHY-interfaces can't be equipped with a PCS (STMMAC driver is
wrong in considering otherwise at least in the Auto-negotiation part).
PCS is only available for the RTI, RTBI and SGMII interfaces.

You can double-check that by checking out the DMA_HW_FEATURE.PCSSEL
flag state. I'll be surprised if it's set in your case. If it isn't
then either drop the plat_stmmacenet_data::mac_interface
initialization or (as Russell suggested) initialize it with
PHY_INTERFACE_MODE_NA. But do that in a separate pre-requisite patch!

>  	/* Set default value for unicast filter entries */
>  	plat->unicast_filter_entries = 1;
>  
>  	/* Set the maxmtu to a default of JUMBO_LEN */
>  	plat->maxmtu = JUMBO_LEN;
>  
> -	/* Set default number of RX and TX queues to use */
> -	plat->tx_queues_to_use = 1;
> -	plat->rx_queues_to_use = 1;
> -
>  	/* Disable Priority config by default */
>  	plat->tx_queues_cfg[0].use_prio = false;
>  	plat->rx_queues_cfg[0].use_prio = false;
> @@ -41,6 +39,12 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>  	plat->dma_cfg->pblx8 = true;
>  
>  	plat->multicast_filter_bins = 256;
> +}
> +
> +static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
> +{
> +	loongson_default_data(plat);
> +
>  	return 0;
>  }
>  
> @@ -109,11 +113,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  	}
>  
>  	plat->phy_interface = phy_mode;
> -	plat->mac_interface = PHY_INTERFACE_MODE_GMII;
>  
>  	pci_set_master(pdev);
>  
> -	loongson_default_data(plat);
> +	loongson_gmac_data(plat);
>  	pci_enable_msi(pdev);
>  	memset(&res, 0, sizeof(res));
>  	res.addr = pcim_iomap_table(pdev)[0];
> @@ -138,6 +141,9 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  		goto err_disable_msi;
>  	}
>  

> +	plat->tx_queues_to_use = 1;
> +	plat->rx_queues_to_use = 1;
> +

You can freely move this to loongson_gmac_data() method. And then, in
the patch adding the GNET-support, you'll be able to provide these fields
initialization in the loongson_gnet_data() method together with the
plat->tx_queues_cfg[*].coe_unsupported flag init. Thus the probe()
method will get to be smaller and easier to read, and the
loongson_*_data() method will be more coherent.

-Serge(y)

>  	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>  	if (ret)
>  		goto err_disable_msi;
> -- 
> 2.31.4
> 

Re: [PATCH net-next v12 07/15] net: stmmac: dwmac-loongson: Add ref and ptp clocks for Loongson

[Serge Semin]

> [PATCH net-next v12 07/15] net: stmmac: dwmac-loongson: Add ref and ptp clocks for Loongson

s/ptp/PTP

Mentioning Loongson is redundant. Just:

net: stmmac: dwmac-loongson: Init ref and PTP clocks rate

On Thu, Apr 25, 2024 at 09:06:10PM +0800, Yanteng Si wrote:
> The ref/ptp clock of gmac(amd gnet) is 125000000.

What about a log like this?

"Reference and PTP clocks rate of the Loongson GMAC devices is 125MHz.
(So is in the GNET devices which support is about to be added.) Set
the respective plat_stmmacenet_data field up in accordance with that
so to have the coalesce command and timestamping work correctly."

-Serge(y)

> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 904e288d0be0..9f208f84c1e7 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -32,6 +32,9 @@ static void loongson_default_data(struct plat_stmmacenet_data *plat)
>  	/* Disable RX queues routing by default */
>  	plat->rx_queues_cfg[0].pkt_route = 0x0;
>  
> +	plat->clk_ref_rate = 125000000;
> +	plat->clk_ptp_rate = 125000000;
> +
>  	/* Default to phy auto-detection */
>  	plat->phy_addr = -1;
>  
> -- 
> 2.31.4
> 

Re: [PATCH net-next v12 08/15] net: stmmac: dwmac-loongson: Add phy mask for Loongson GMAC

[Serge Semin]

On Thu, Apr 25, 2024 at 09:06:11PM +0800, Yanteng Si wrote:
> The phy mask of gmac(and gnet) is 0.

First of all the GNET PHY mask won't be zero as you setting it up to
~BIT(2) in the patch 13 yourself. Secondly the stmmac_mdio_bus_data
structure instance is Z-malloced, thus it will be zeroed anyway. So
the only reason why the explicit stmmac_mdio_bus_data::phy_mask
zeroing would be useful is to signify the difference between the GMAC
and GNET devices. But that difference could be relatively easy
inferred from the code. So to speak IMO the patch has a little value.
I would drop it.

-Serge(y)

> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 9f208f84c1e7..f7618edf4a3a 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -48,6 +48,8 @@ static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
>  {
>  	loongson_default_data(plat);
>  
> +	plat->mdio_bus_data->phy_mask = 0;
> +
>  	return 0;
>  }
>  
> -- 
> 2.31.4
> 

Re: [PATCH net-next v12 09/15] net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC

[Serge Semin]

On Fri, Apr 26, 2024 at 12:00:25PM +0100, Russell King (Oracle) wrote:
> On Fri, Apr 26, 2024 at 06:16:42PM +0800, Yanteng Si wrote:
> > Hi Russell,
> > 
> > 在 2024/4/25 22:36, Russell King (Oracle) 写道:
> > > > The mac_interface of gmac is PHY_INTERFACE_MODE_RGMII_ID.
> > > No it isn't!
> > Ok, that's a typo.
> > > 
> > > > +	plat->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
> > > You don't touch mac_interface here. Please read the big comment I put
> > > in include/linux/stmmac.h above these fields in struct
> > > plat_stmmacenet_data to indicate what the difference between
> > > mac_interface and phy_interface are, and then correct which-ever
> > > of the above needs to be corrected.
> > 
> > Copy your big comment here:
> > 
> >     int phy_addr;
> >     /* MAC ----- optional PCS ----- SerDes ----- optional PHY ----- Media
> >      *       ^                               ^
> >      * mac_interface                   phy_interface
> >      *
> >      * mac_interface is the MAC-side interface, which may be the same
> >      * as phy_interface if there is no intervening PCS. If there is a
> >      * PCS, then mac_interface describes the interface mode between the
> >      * MAC and PCS, and phy_interface describes the interface mode
> >      * between the PCS and PHY.
> >      */
> >     phy_interface_t mac_interface;
> >     /* phy_interface is the PHY-side interface - the interface used by
> >      * an attached PHY.
> >      */
> > 
> > Our hardware engineer said we don't support pcs, and if I understand
> > 
> > your comment correctly, our mac_interface and phy_interface should
> > 
> > be the same, right?
> 

> It only matters to the core code if priv->dma_cap.pcs is set true.
> If it isn't, then mac_interface doesn't seem to be relevent

Absolutely correct. Moreover AFAICS from the databooks the PCS module
is only available for the DW GMACs with the TBI, RTBI and SGMII
interfaces. So the STMMAC_PCS_RGMII PCS flag seems misleading. The only
info about the link state that could be runtime detected on the MAC
side is: link speed, duplex mode and link status. It's done by means
of the RGMII in-band status signals. That's what is implemented in the
dwmac1000_rgsmii() method. I've checked it works as soon as the
GMAC_INT_DISABLE_RGMII IRQ is unmask. But the RGMII-capable DW GMACs
don't support the Auto-negotiation feature, because it has no PCS
inside. Thus what has been implemented for the RGMII case in
stmmac_ethtool_get_link_ksettings() and
stmmac_ethtool_set_link_ksettings() seems incorrect to me.

> (it
> does get used by a truck load of platform specific code though
> which I haven't looked at to answer this.)

IMO the most of them are using the plat_stmmacenet_data::mac_interface
field as just an additional storage of the PHY-interface type. The
only cases which I would consider as validly using the field are the
ones with the SGMII interface support (and TBI/RTBI).

BTW I see the "mac-mode" DT-property support was introduced in 2019 by
the commit 0060c8783330 ("net: stmmac: implement support for passive
mode converters via dt"). The commit didn't touch any of the platform
drivers, but merely changed the plat_stmmacenet_data::mac_interface
semantics to containing the intermediate interface type if the
property was specified. So IMO all the platform drivers which had been
available by the time the change was introduced can be converted to
using the plat_stmmacenet_data::phy_interface field with a small
probability to break things.

I can't help but notice that since that commit there have been no any
DW MAC DT-node introduced with the "mac-mode" property specified. So
all of that makes me thinking that the code implemented around the
mac_interface data has been mainly unused and most likely was needless
overcomplication. Sigh...

> 
> I would suggest that if priv->dma_cap.pcs is false, then setting
> mac_interface to PHY_INTERFACE_MODE_NA to make it explicit that
> it's not used would be a good idea.

I bet it will be false. But Yanteng, could you please double check
that?

If it is could you convert this patch to setting
plat_stmmacenet_data::mac_interface with PHY_INTERFACE_MODE_NA by
default for all your device and setting the
plat_stmmacenet_data::phy_interface with PHY_INTERFACE_MODE_RGMII_ID
for the Loongson GMAC devices?

BTW Yanteng, are you sure it's supposed to
PHY_INTERFACE_MODE_RGMII_ID? AFAICS from the Loongson DTS files
(loongson64-2k1000.dtsi, ls7a-pch.dtsi) the phy-mode is just
PHY_INTERFACE_MODE_RGMII with no internal delays.

-Serge(y)

> 
> While looking at this, however, I've come across the fact that
> stmmac manipulates the netif carrier via netif_carrier_off() and
> netif_carrier_on(), which is a _big_ no no when using phylink.
> Phylink manages the carrier for the driver, and its part of
> phylink's state. Fiddling with the carrier totally breaks the
> guarantee that phylink will make calls to mac_link_down() and
> mac_link_up().
> 
> If a driver wants to fiddle with the netif carrier, it must NOT
> use phylink. If it wants to use phylink, it must NOT fiddle with
> the netif carrier state. The two are mutually exclusive.
> 
> stmmac is quickly becoming a driver I don't care about whether my
> changes to phylink end up breaking it or not because of abuses
> like this.
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support

[Serge Semin]

> [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support

I would have changed the subject to:

net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support

On Thu, Apr 25, 2024 at 09:10:35PM +0800, Yanteng Si wrote:
> Current dwmac-loongson only support LS2K in the "probed with PCI and
> configured with DT" manner. Add LS7A support on which the devices are
> fully PCI (non-DT).
> 
> Others:
> LS2K is a SoC and LS7A is a bridge chip.

The text seems like misleading or just wrong. I see both of these
platforms having the GMAC defined in the DT source:

arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
arch/mips/boot/dts/loongson/ls7a-pch.dtsi

What do I miss in your description?

If nothing has been missed and it's just wrong I suggest to convert
the commit log to something like this:

"The Loongson GMAC driver currently supports the network controllers
installed on the LS2K1000 SoC and LS7A1000 chipset, for which the GMAC
devices are required to be defined in the platform device tree source.
Let's extend the driver functionality with the case of having the
Loongson GMAC probed on the PCI bus with no device tree node defined
for it. That requires to make the device DT-node optional, to rely on
the IRQ line detected by the PCI core and to have the MDIO bus ID
calculated using the PCIe Domain+BDF numbers."


> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 113 ++++++++++--------
>  1 file changed, 65 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index e989cb835340..1022bceaa680 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -11,8 +11,17 @@
>  
>  #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
>  
> -static void loongson_default_data(struct plat_stmmacenet_data *plat)

> +struct stmmac_pci_info {
> +	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
> +};

Please move this and the rest of the setup-callback introduction
change into a separate patch. It' subject could be something like
this:
net: stmmac: dwmac-loongson: Introduce PCI device info data

> +
> +static void loongson_default_data(struct pci_dev *pdev,
> +				  struct plat_stmmacenet_data *plat)
>  {

> +	/* Get bus_id, this can be overloaded later */

s/overloaded/overwritten

> +	plat->bus_id = (pci_domain_nr(pdev->bus) << 16) |

> +			PCI_DEVID(pdev->bus->number, pdev->devfn);

Em, so you removed the code from the probe() function:
-     plat->bus_id = of_alias_get_id(np, "ethernet");
-     if (plat->bus_id < 0)
-             plat->bus_id = pci_dev_id(pdev);
and instead of using the pci_dev_id() method here just opencoded it'
content. Nice. Why not to use pci_dev_id() instead of PCI_DEVID()?

> +
>  	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
>  	plat->has_gmac = 1;
>  	plat->force_sf_dma_mode = 1;
> @@ -44,9 +53,10 @@ static void loongson_default_data(struct plat_stmmacenet_data *plat)
>  	plat->multicast_filter_bins = 256;
>  }
>  
> -static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
> +static int loongson_gmac_data(struct pci_dev *pdev,
> +			      struct plat_stmmacenet_data *plat)
>  {
> -	loongson_default_data(plat);
> +	loongson_default_data(pdev, plat);
>  
>  	plat->mdio_bus_data->phy_mask = 0;
>  	plat->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
> @@ -54,20 +64,20 @@ static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
>  	return 0;
>  }
>  

> +static struct stmmac_pci_info loongson_gmac_pci_info = {
> +	.setup = loongson_gmac_data,
> +};
> +

To the separate patch please.

>  static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  {
>  	struct plat_stmmacenet_data *plat;

> +	int ret, i, bus_id, phy_mode;
> +	struct stmmac_pci_info *info;
>  	struct stmmac_resources res;
>  	struct device_node *np;
> -	int ret, i, phy_mode;

You can drop the bus_id and phy_mode variables, and use ret in the
respective statements instead.

>  
>  	np = dev_of_node(&pdev->dev);
>  
> -	if (!np) {
> -		pr_info("dwmac_loongson_pci: No OF node\n");
> -		return -ENODEV;
> -	}
> -
>  	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
>  	if (!plat)
>  		return -ENOMEM;
> @@ -78,12 +88,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  	if (!plat->mdio_bus_data)
>  		return -ENOMEM;
>  
> -	plat->mdio_node = of_get_child_by_name(np, "mdio");
> -	if (plat->mdio_node) {
> -		dev_info(&pdev->dev, "Found MDIO subnode\n");
> -		plat->mdio_bus_data->needs_reset = true;
> -	}
> -
>  	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
>  	if (!plat->dma_cfg) {
>  		ret = -ENOMEM;
> @@ -107,46 +111,59 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  		break;
>  	}
>  
> -	plat->bus_id = of_alias_get_id(np, "ethernet");
> -	if (plat->bus_id < 0)
> -		plat->bus_id = pci_dev_id(pdev);
> +	pci_set_master(pdev);
>  
> -	phy_mode = device_get_phy_mode(&pdev->dev);
> -	if (phy_mode < 0) {
> -		dev_err(&pdev->dev, "phy_mode not found\n");
> -		ret = phy_mode;

> +	info = (struct stmmac_pci_info *)id->driver_data;
> +	ret = info->setup(pdev, plat);
> +	if (ret)
>  		goto err_disable_device;

To the separate patch please.

> -	}
>  
> -	plat->phy_interface = phy_mode;
> -
> -	pci_set_master(pdev);
> +	if (np) {
> +		plat->mdio_node = of_get_child_by_name(np, "mdio");
> +		if (plat->mdio_node) {
> +			dev_info(&pdev->dev, "Found MDIO subnode\n");
> +			plat->mdio_bus_data->needs_reset = true;
> +		}
> +

> +		bus_id = of_alias_get_id(np, "ethernet");
> +		if (bus_id >= 0)
> +			plat->bus_id = bus_id;

		ret = of_alias_get_id(np, "ethernet");
		if (ret >= 0)
			plat->bus_id = ret;

> +

> +		phy_mode = device_get_phy_mode(&pdev->dev);
> +		if (phy_mode < 0) {
> +			dev_err(&pdev->dev, "phy_mode not found\n");
> +			ret = phy_mode;
> +			goto err_disable_device;
> +		}
> +		plat->phy_interface = phy_mode;

		ret = device_get_phy_mode(&pdev->dev);
		if (ret < 0) {
			dev_err(&pdev->dev, "phy_mode not found\n");
			goto err_disable_device;
		}
		
		plat->phy_interface = ret;

* note empty line between the if-clause and the last statement.

> +
> +		res.irq = of_irq_get_byname(np, "macirq");
> +		if (res.irq < 0) {
> +			dev_err(&pdev->dev, "IRQ macirq not found\n");
> +			ret = -ENODEV;
> +			goto err_disable_msi;
> +		}
> +
> +		res.wol_irq = of_irq_get_byname(np, "eth_wake_irq");
> +		if (res.wol_irq < 0) {
> +			dev_info(&pdev->dev, "IRQ eth_wake_irq not found, using macirq\n");
> +			res.wol_irq = res.irq;
> +		}
> +
> +		res.lpi_irq = of_irq_get_byname(np, "eth_lpi");
> +		if (res.lpi_irq < 0) {
> +			dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
> +			ret = -ENODEV;
> +			goto err_disable_msi;
> +		}
> +	} else {
> +		res.irq = pdev->irq;
> +	}
>  

> -	loongson_gmac_data(plat);

To the separate patch please.

>  	pci_enable_msi(pdev);
>  	memset(&res, 0, sizeof(res));
>  	res.addr = pcim_iomap_table(pdev)[0];
>  
> -	res.irq = of_irq_get_byname(np, "macirq");
> -	if (res.irq < 0) {
> -		dev_err(&pdev->dev, "IRQ macirq not found\n");
> -		ret = -ENODEV;
> -		goto err_disable_msi;
> -	}
> -
> -	res.wol_irq = of_irq_get_byname(np, "eth_wake_irq");
> -	if (res.wol_irq < 0) {
> -		dev_info(&pdev->dev, "IRQ eth_wake_irq not found, using macirq\n");
> -		res.wol_irq = res.irq;
> -	}
> -
> -	res.lpi_irq = of_irq_get_byname(np, "eth_lpi");
> -	if (res.lpi_irq < 0) {
> -		dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
> -		ret = -ENODEV;
> -		goto err_disable_msi;
> -	}
> -
>  	plat->tx_queues_to_use = 1;
>  	plat->rx_queues_to_use = 1;
>  
> @@ -224,7 +241,7 @@ static SIMPLE_DEV_PM_OPS(loongson_dwmac_pm_ops, loongson_dwmac_suspend,
>  			 loongson_dwmac_resume);
>  
>  static const struct pci_device_id loongson_dwmac_id_table[] = {
> -	{ PCI_DEVICE_DATA(LOONGSON, GMAC, NULL) },

> +	{ PCI_DEVICE_DATA(LOONGSON, GMAC, &loongson_gmac_pci_info) },

To the separate patch please.

-Serge(y)

>  	{}
>  };
>  MODULE_DEVICE_TABLE(pci, loongson_dwmac_id_table);
> -- 
> 2.31.4
> 

Re: [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy

[Serge Semin]

On Thu, Apr 25, 2024 at 09:10:36PM +0800, Yanteng Si wrote:
> Move res._irq to loongson_dwmac_config_legacy().
> No function changes.

Since the code affected by this patch has just been touched by the
previous patch
[PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
just merge this patch content into there. But add a note to the
commit message of that patch like this:

"While at it move the IRQ initialization procedure into a dedicated
method. It will be useful in one of the subsequent commit adding the
Loongson GNET device support."

> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 56 +++++++++++--------
>  1 file changed, 34 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 1022bceaa680..df5899bec91a 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -68,6 +68,38 @@ static struct stmmac_pci_info loongson_gmac_pci_info = {
>  	.setup = loongson_gmac_data,
>  };
>  
> +static int loongson_dwmac_config_legacy(struct pci_dev *pdev,
> +					struct plat_stmmacenet_data *plat,
> +					struct stmmac_resources *res,
> +					struct device_node *np)
> +{
> +	if (np) {
> +		res->irq = of_irq_get_byname(np, "macirq");
> +		if (res->irq < 0) {
> +			dev_err(&pdev->dev, "IRQ macirq not found\n");
> +			return -ENODEV;
> +		}
> +
> +		res->wol_irq = of_irq_get_byname(np, "eth_wake_irq");
> +		if (res->wol_irq < 0) {
> +			dev_info(&pdev->dev,
> +				 "IRQ eth_wake_irq not found, using macirq\n");
> +			res->wol_irq = res->irq;
> +		}
> +
> +		res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
> +		if (res->lpi_irq < 0) {
> +			dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
> +			return -ENODEV;
> +		}
> +	} else {
> +		res->irq = pdev->irq;

> +		res->wol_irq = res->irq;

Once again - drop this, unless you can justify it's required.

> +	}
> +
> +	return 0;
> +}
> +
>  static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  {
>  	struct plat_stmmacenet_data *plat;
> @@ -136,28 +168,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  			goto err_disable_device;
>  		}
>  		plat->phy_interface = phy_mode;
> -
> -		res.irq = of_irq_get_byname(np, "macirq");
> -		if (res.irq < 0) {
> -			dev_err(&pdev->dev, "IRQ macirq not found\n");
> -			ret = -ENODEV;
> -			goto err_disable_msi;
> -		}
> -
> -		res.wol_irq = of_irq_get_byname(np, "eth_wake_irq");
> -		if (res.wol_irq < 0) {
> -			dev_info(&pdev->dev, "IRQ eth_wake_irq not found, using macirq\n");
> -			res.wol_irq = res.irq;
> -		}
> -
> -		res.lpi_irq = of_irq_get_byname(np, "eth_lpi");
> -		if (res.lpi_irq < 0) {
> -			dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
> -			ret = -ENODEV;
> -			goto err_disable_msi;
> -		}
> -	} else {
> -		res.irq = pdev->irq;
>  	}
>  
>  	pci_enable_msi(pdev);
> @@ -167,6 +177,8 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  	plat->tx_queues_to_use = 1;
>  	plat->rx_queues_to_use = 1;
>  

> +	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> +

By not checking the return value the patch turns to in fact containing
the functional change, which contradicts to what you say in the commit
log. Besides it's just wrong in this case. So please add the return
value check.

-Serge(y)

>  	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>  	if (ret)
>  		goto err_disable_msi;
> -- 
> 2.31.4
> 
> 

Re: [PATCH net-next v12 12/15] net: stmmac: dwmac-loongson: Fixed failure to set network speed to 1000.

[Serge Semin]

On Thu, Apr 25, 2024 at 09:10:37PM +0800, Yanteng Si wrote:
> GNET devices with dev revision 0x00 do not support manually
> setting the speed to 1000.
> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 8 ++++++++
>  drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 6 ++++++
>  include/linux/stmmac.h                               | 1 +
>  3 files changed, 15 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index df5899bec91a..a16bba389417 100644


> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -10,6 +10,7 @@
>  #include "stmmac.h"
>  
>  #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
> +#define PCI_DEVICE_ID_LOONGSON_GNET	0x7a13
>  
>  struct stmmac_pci_info {
>  	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
> @@ -179,6 +180,13 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  
>  	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
>  
> +	/* GNET devices with dev revision 0x00 do not support manually
> +	 * setting the speed to 1000.
> +	 */
> +	if (pdev->device == PCI_DEVICE_ID_LOONGSON_GNET &&
> +	    pdev->revision == 0x00)
> +		plat->flags |= STMMAC_FLAG_DISABLE_FORCE_1000;
> +

That's why it's important to wait for the discussions being finished.
If you waited for some time I would have told you that the only part
what was required to move to the separate patch was the changes in the
files:
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
include/linux/stmmac.h

So please move the changes above to the patch
[PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
* with the flag setup being done in the loongson_gnet_data() method.

Thus you'll be able to drop the patch 14
[PATCH net-next v12 14/15] net: stmmac: dwmac-loongson: Move disable_force flag to _gnet_date

-Serge(y)


>  	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>  	if (ret)
>  		goto err_disable_msi;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> index 542e2633a6f5..eb4b3eaf9e17 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> @@ -422,6 +422,12 @@ stmmac_ethtool_set_link_ksettings(struct net_device *dev,
>  		return 0;
>  	}
>  
> +	if (priv->plat->flags & STMMAC_FLAG_DISABLE_FORCE_1000) {
> +		if (cmd->base.speed == SPEED_1000 &&
> +		    cmd->base.autoneg != AUTONEG_ENABLE)
> +			return -EOPNOTSUPP;
> +	}
> +
>  	return phylink_ethtool_ksettings_set(priv->phylink, cmd);
>  }
>  
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index 1b54b84a6785..c5d3d0ddb6f8 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -223,6 +223,7 @@ struct dwmac4_addrs {
>  #define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI		BIT(10)
>  #define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING	BIT(11)
>  #define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY	BIT(12)
> +#define STMMAC_FLAG_DISABLE_FORCE_1000		BIT(13)
>  
>  struct plat_stmmacenet_data {
>  	int bus_id;
> -- 
> 2.31.4
> 
> 

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Serge Semin]

On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
> There are two types of Loongson DWGMAC. The first type shares the same

s/Loongson DWGMAC/Loongson GNET controllers

> register definitions and has similar logic as dwmac1000. The second type
> uses several different register definitions, we think it is necessary to
> distinguish rx and tx, so we split these bits into two.

s/rx/Rx
s/tx/Tx

> 
> Simply put, we split some single bit fields into double bits fileds:
> 
>      Name              Tx          Rx
> 
> DMA_INTR_ENA_NIE = 0x00040000 | 0x00020000;
> DMA_INTR_ENA_AIE = 0x00010000 | 0x00008000;
> DMA_STATUS_NIS   = 0x00040000 | 0x00020000;
> DMA_STATUS_AIS   = 0x00010000 | 0x00008000;
> DMA_STATUS_FBI   = 0x00002000 | 0x00001000;
> 
> Therefore, when using, TX and RX must be set at the same time.
> 
> How to use them:
>  1. Create the Loongson GNET-specific
>  stmmac_dma_ops.dma_interrupt()
>  stmmac_dma_ops.init_chan()
>  methods in the dwmac-loongson.c driver. Adding all the
>  Loongson-specific macros
> 
>  2. Create a Loongson GNET-specific platform setup method with the next
>  semantics:
>     + allocate stmmac_dma_ops instance and initialize it with
>       dwmac1000_dma_ops.
>     + override the stmmac_dma_ops.{dma_interrupt, init_chan} with
>       the pointers to the methods defined in 2.
>     + allocate mac_device_info instance and initialize the
>       mac_device_info.dma field with a pointer to the new
>       stmmac_dma_ops instance.
>     + initialize mac_device_info in a way it's done in
>       dwmac1000_setup().
> 
>  3. Initialize plat_stmmacenet_data.setup() with the pointer to the
>  method created in 2.
> 
> GNET features:
> 
>  Speeds: 10/100/1000Mbps
>  DMA-descriptors type: enhanced
>  L3/L4 filters availability: support
>  VLAN hash table filter: support
>  PHY-interface: GMII
>  Remote Wake-up support: support
>  Mac Management Counters (MMC): support
>  Number of additional MAC addresses: 5
>  MAC Hash-based filter: support
>  Number of ash table size: 256
>  DMA chennel number: 0x10 device is 8 and 0x37 device is 1
> 
> Others:
> 
>  GNET integrates both MAC and PHY chips inside.
>  GNET device: LS2K2000, LS7A2000, the chip connection between the mac and
>              phy of these devices is not normal and requires two rounds of
>              negotiation; LS7A2000 does not support half-duplex and
>              multi-channel;
> 
>              To enable multi-channel on LS2K2000, you need to turn off
>              hardware checksum.
> 
> **Note**: Currently, only the LS2K2000's synopsys_id is 0x10, while the
> synopsys_id of other devices are 0x37.

The entire commit log looks as a set of information and doesn't
explicitly explain what is going on in the patch body. Let's make it a
bit more coherent:

"Aside with the Loongson GMAC controllers which can be normally found
on the LS2K1000 SoC and LS7A1000 chipset, Loongson released a new
version of the network controllers called Loongson GNET. It has
been synthesized into the new generation LS2K2000 SoC and LS7A2000
chipset with the next DW GMAC features enabled:

  DW GMAC IP-core: v3.73a
  Speeds: 10/100/1000Mbps
  Duplex: Full (both versions), Half (LS2K2000 SoC only)
  DMA-descriptors type: enhanced
  L3/L4 filters availability: Y
  VLAN hash table filter: Y
  PHY-interface: GMII (PHY is integrated into the chips)
  Remote Wake-up support: Y
  Mac Management Counters (MMC): Y
  Number of additional MAC addresses: 5
  MAC Hash-based filter: Y
  Hash Table Size: 256
  AV feature: Y (LS2K2000 SoC only)
  DMA channels: 8 (LS2K2000 SoC), 1 (LS7A2000 chipset)

The integrated PHY has a weird problem with switching from the low
speeds to 1000Mbps mode. The speedup procedure requires the PHY-link
re-negotiation. Besides the LS2K2000 GNET controller the next
peculiarities:
1. Split up Tx and Rx DMA IRQ status/mask bits:
       Name              Tx          Rx
  DMA_INTR_ENA_NIE = 0x00040000 | 0x00020000;
  DMA_INTR_ENA_AIE = 0x00010000 | 0x00008000;
  DMA_STATUS_NIS   = 0x00040000 | 0x00020000;
  DMA_STATUS_AIS   = 0x00010000 | 0x00008000;
  DMA_STATUS_FBI   = 0x00002000 | 0x00001000;
2. Custom Synopsys ID hardwired into the GMAC_VERSION.SNPSVER field.
It's 0x10 while it should have been 0x37 in accordance with the actual
DW GMAC IP-core version.

Thus in order to have the Loongson GNET controllers supported let's
modify the Loongson DWMAC driver in accordance with all the
peculiarities described above:

1. Create the Loongson GNET-specific
   stmmac_dma_ops::dma_interrupt()
   stmmac_dma_ops::init_chan()
   callbacks due to the non-standard DMA IRQ CSR flags layout.
2. Create the Loongson GNET-specific platform setup() method which
gets to initialize the DMA-ops with the dwmac1000_dma_ops instance
and overrides the callbacks described in 1, and overrides the custom
Synopsys ID with the real one in order to have the rest of the
HW-specific callbacks correctly detected by the driver core.
3. Make sure the Loongson GNET-specific platform setup() method
enables the duplex modes supported by the controller.
4. Provide the plat_stmmacenet_data::fix_mac_speed() callback which
will restart the link Auto-negotiation in case of the speed change."


See, you don't need to mention the 0x10 ID all the time. Just once and
in the place where it's actually relevant.

> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  drivers/net/ethernet/stmicro/stmmac/common.h  |   1 +
>  .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 381 +++++++++++++++++-
>  2 files changed, 371 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
> index 9cd62b2110a1..aed6ae80cc7c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> @@ -29,6 +29,7 @@
>  /* Synopsys Core versions */
>  #define	DWMAC_CORE_3_40		0x34
>  #define	DWMAC_CORE_3_50		0x35
> +#define	DWMAC_CORE_3_70		0x37
>  #define	DWMAC_CORE_4_00		0x40
>  #define DWMAC_CORE_4_10		0x41
>  #define DWMAC_CORE_5_00		0x50
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index a16bba389417..68de90c44feb 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -8,9 +8,71 @@
>  #include <linux/device.h>
>  #include <linux/of_irq.h>
>  #include "stmmac.h"
> +#include "dwmac_dma.h"
> +#include "dwmac1000.h"
> +
> +/* Normal Loongson Tx Summary */
> +#define DMA_INTR_ENA_NIE_TX_LOONGSON	0x00040000
> +/* Normal Loongson Rx Summary */
> +#define DMA_INTR_ENA_NIE_RX_LOONGSON	0x00020000
> +
> +#define DMA_INTR_NORMAL_LOONGSON	(DMA_INTR_ENA_NIE_TX_LOONGSON | \
> +					 DMA_INTR_ENA_NIE_RX_LOONGSON | \
> +					 DMA_INTR_ENA_RIE | DMA_INTR_ENA_TIE)
> +
> +/* Abnormal Loongson Tx Summary */
> +#define DMA_INTR_ENA_AIE_TX_LOONGSON	0x00010000
> +/* Abnormal Loongson Rx Summary */
> +#define DMA_INTR_ENA_AIE_RX_LOONGSON	0x00008000
> +
> +#define DMA_INTR_ABNORMAL_LOONGSON	(DMA_INTR_ENA_AIE_TX_LOONGSON | \
> +					 DMA_INTR_ENA_AIE_RX_LOONGSON | \
> +					 DMA_INTR_ENA_FBE | DMA_INTR_ENA_UNE)
> +
> +#define DMA_INTR_DEFAULT_MASK_LOONGSON	(DMA_INTR_NORMAL_LOONGSON | \
> +					 DMA_INTR_ABNORMAL_LOONGSON)
> +
> +/* Normal Loongson Tx Interrupt Summary */
> +#define DMA_STATUS_NIS_TX_LOONGSON	0x00040000
> +/* Normal Loongson Rx Interrupt Summary */
> +#define DMA_STATUS_NIS_RX_LOONGSON	0x00020000
> +
> +/* Abnormal Loongson Tx Interrupt Summary */
> +#define DMA_STATUS_AIS_TX_LOONGSON	0x00010000
> +/* Abnormal Loongson Rx Interrupt Summary */
> +#define DMA_STATUS_AIS_RX_LOONGSON	0x00008000
> +
> +/* Fatal Loongson Tx Bus Error Interrupt */
> +#define DMA_STATUS_FBI_TX_LOONGSON	0x00002000
> +/* Fatal Loongson Rx Bus Error Interrupt */
> +#define DMA_STATUS_FBI_RX_LOONGSON	0x00001000
> +
> +#define DMA_STATUS_MSK_COMMON_LOONGSON	(DMA_STATUS_NIS_TX_LOONGSON | \
> +					 DMA_STATUS_NIS_RX_LOONGSON | \
> +					 DMA_STATUS_AIS_TX_LOONGSON | \
> +					 DMA_STATUS_AIS_RX_LOONGSON | \
> +					 DMA_STATUS_FBI_TX_LOONGSON | \
> +					 DMA_STATUS_FBI_RX_LOONGSON)
> +
> +#define DMA_STATUS_MSK_RX_LOONGSON	(DMA_STATUS_ERI | DMA_STATUS_RWT | \
> +					 DMA_STATUS_RPS | DMA_STATUS_RU  | \
> +					 DMA_STATUS_RI  | DMA_STATUS_OVF | \
> +					 DMA_STATUS_MSK_COMMON_LOONGSON)
> +
> +#define DMA_STATUS_MSK_TX_LOONGSON	(DMA_STATUS_ETI | DMA_STATUS_UNF | \
> +					 DMA_STATUS_TJT | DMA_STATUS_TU  | \
> +					 DMA_STATUS_TPS | DMA_STATUS_TI  | \
> +					 DMA_STATUS_MSK_COMMON_LOONGSON)
>  
>  #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
>  #define PCI_DEVICE_ID_LOONGSON_GNET	0x7a13

> +#define LOONGSON_DWMAC_CORE_1_00	0x10	/* Loongson custom IP */

What about using the name like calling as:
+#define DWMAC_CORE_LS2K2000		0x10
Thus you'll have the name similar to the rest of the DWMAC_CORE_*
macros and which would emphasize what the device for which the custom
ID is specific.

> +#define CHANNEL_NUM			8
> +
> +struct loongson_data {

> +	u32 gmac_verion;

Let's call it loongson_id thus referring to the
stmmac_priv::synopsys_id field.

> +	struct device *dev;
> +};
>  
>  struct stmmac_pci_info {
>  	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
> @@ -69,6 +131,168 @@ static struct stmmac_pci_info loongson_gmac_pci_info = {
>  	.setup = loongson_gmac_data,
>  };
>  
> +static void loongson_gnet_dma_init_channel(struct stmmac_priv *priv,
> +					   void __iomem *ioaddr,
> +					   struct stmmac_dma_cfg *dma_cfg,
> +					   u32 chan)
> +{
> +	int txpbl = dma_cfg->txpbl ?: dma_cfg->pbl;
> +	int rxpbl = dma_cfg->rxpbl ?: dma_cfg->pbl;
> +	u32 value;
> +
> +	value = readl(ioaddr + DMA_CHAN_BUS_MODE(chan));
> +
> +	if (dma_cfg->pblx8)
> +		value |= DMA_BUS_MODE_MAXPBL;
> +
> +	value |= DMA_BUS_MODE_USP;
> +	value &= ~(DMA_BUS_MODE_PBL_MASK | DMA_BUS_MODE_RPBL_MASK);
> +	value |= (txpbl << DMA_BUS_MODE_PBL_SHIFT);
> +	value |= (rxpbl << DMA_BUS_MODE_RPBL_SHIFT);
> +
> +	/* Set the Fixed burst mode */
> +	if (dma_cfg->fixed_burst)
> +		value |= DMA_BUS_MODE_FB;
> +
> +	/* Mixed Burst has no effect when fb is set */
> +	if (dma_cfg->mixed_burst)
> +		value |= DMA_BUS_MODE_MB;
> +
> +	if (dma_cfg->atds)
> +		value |= DMA_BUS_MODE_ATDS;
> +
> +	if (dma_cfg->aal)
> +		value |= DMA_BUS_MODE_AAL;
> +
> +	writel(value, ioaddr + DMA_CHAN_BUS_MODE(chan));
> +
> +	/* Mask interrupts by writing to CSR7 */
> +	writel(DMA_INTR_DEFAULT_MASK_LOONGSON, ioaddr +
> +	       DMA_CHAN_INTR_ENA(chan));
> +}
> +
> +static int loongson_gnet_dma_interrupt(struct stmmac_priv *priv,
> +				       void __iomem *ioaddr,
> +				       struct stmmac_extra_stats *x,
> +				       u32 chan, u32 dir)
> +{
> +	struct stmmac_pcpu_stats *stats = this_cpu_ptr(priv->xstats.pcpu_stats);
> +	u32 abnor_intr_status;
> +	u32 nor_intr_status;
> +	u32 fb_intr_status;
> +	u32 intr_status;
> +	int ret = 0;
> +
> +	/* read the status register (CSR5) */
> +	intr_status = readl(ioaddr + DMA_CHAN_STATUS(chan));
> +
> +	if (dir == DMA_DIR_RX)
> +		intr_status &= DMA_STATUS_MSK_RX_LOONGSON;
> +	else if (dir == DMA_DIR_TX)
> +		intr_status &= DMA_STATUS_MSK_TX_LOONGSON;
> +
> +	nor_intr_status = intr_status & (DMA_STATUS_NIS_TX_LOONGSON |
> +		DMA_STATUS_NIS_RX_LOONGSON);
> +	abnor_intr_status = intr_status & (DMA_STATUS_AIS_TX_LOONGSON |
> +		DMA_STATUS_AIS_RX_LOONGSON);
> +	fb_intr_status = intr_status & (DMA_STATUS_FBI_TX_LOONGSON |
> +		DMA_STATUS_FBI_RX_LOONGSON);
> +
> +	/* ABNORMAL interrupts */
> +	if (unlikely(abnor_intr_status)) {
> +		if (unlikely(intr_status & DMA_STATUS_UNF)) {
> +			ret = tx_hard_error_bump_tc;
> +			x->tx_undeflow_irq++;
> +		}
> +		if (unlikely(intr_status & DMA_STATUS_TJT))
> +			x->tx_jabber_irq++;
> +		if (unlikely(intr_status & DMA_STATUS_OVF))
> +			x->rx_overflow_irq++;
> +		if (unlikely(intr_status & DMA_STATUS_RU))
> +			x->rx_buf_unav_irq++;
> +		if (unlikely(intr_status & DMA_STATUS_RPS))
> +			x->rx_process_stopped_irq++;
> +		if (unlikely(intr_status & DMA_STATUS_RWT))
> +			x->rx_watchdog_irq++;
> +		if (unlikely(intr_status & DMA_STATUS_ETI))
> +			x->tx_early_irq++;
> +		if (unlikely(intr_status & DMA_STATUS_TPS)) {
> +			x->tx_process_stopped_irq++;
> +			ret = tx_hard_error;
> +		}
> +		if (unlikely(fb_intr_status)) {
> +			x->fatal_bus_error_irq++;
> +			ret = tx_hard_error;
> +		}
> +	}
> +	/* TX/RX NORMAL interrupts */
> +	if (likely(nor_intr_status)) {
> +		if (likely(intr_status & DMA_STATUS_RI)) {
> +			u32 value = readl(ioaddr + DMA_INTR_ENA);
> +			/* to schedule NAPI on real RIE event. */
> +			if (likely(value & DMA_INTR_ENA_RIE)) {
> +				u64_stats_update_begin(&stats->syncp);
> +				u64_stats_inc(&stats->rx_normal_irq_n[chan]);
> +				u64_stats_update_end(&stats->syncp);
> +				ret |= handle_rx;
> +			}
> +		}
> +		if (likely(intr_status & DMA_STATUS_TI)) {
> +			u64_stats_update_begin(&stats->syncp);
> +			u64_stats_inc(&stats->tx_normal_irq_n[chan]);
> +			u64_stats_update_end(&stats->syncp);
> +			ret |= handle_tx;
> +		}
> +		if (unlikely(intr_status & DMA_STATUS_ERI))
> +			x->rx_early_irq++;
> +	}
> +	/* Optional hardware blocks, interrupts should be disabled */
> +	if (unlikely(intr_status &
> +		     (DMA_STATUS_GPI | DMA_STATUS_GMI | DMA_STATUS_GLI)))
> +		pr_warn("%s: unexpected status %08x\n", __func__, intr_status);
> +

> +	/* Clear the interrupt by writing a logic 1 to the CSR5[15-0] */

0x7ffff != CSR5[15-0]

> +	writel((intr_status & 0x7ffff), ioaddr + DMA_CHAN_STATUS(chan));
> +
> +	return ret;
> +}
> +
> +static void loongson_gnet_fix_speed(void *priv, unsigned int speed,
> +				    unsigned int mode)
> +{
> +	struct loongson_data *ld = (struct loongson_data *)priv;
> +	struct net_device *ndev = dev_get_drvdata(ld->dev);
> +	struct stmmac_priv *ptr = netdev_priv(ndev);
> +

> +	/* The controller and PHY don't work well together.
> +	 * We need to use the PS bit to check if the controller's status
> +	 * is correct and reset PHY if necessary.

This doesn't correspond to what you're actually doing. Please align
the comment with what is done below (if what I provided in the commit
log regarding this problem is correct, use the description here).

> +	 * MAC_CTRL_REG.15 is defined by the GMAC_CONTROL_PS macro.

useless. please drop

> +	 */
> +	if (speed == SPEED_1000) {
> +		if (readl(ptr->ioaddr + MAC_CTRL_REG) &
> +		    GMAC_CONTROL_PS)
> +			/* Word around hardware bug, restart autoneg */
> +			phy_restart_aneg(ndev->phydev);
> +	}
> +}
> +
> +static int loongson_gnet_data(struct pci_dev *pdev,
> +			      struct plat_stmmacenet_data *plat)
> +{
> +	loongson_default_data(pdev, plat);
> +
> +	plat->phy_interface = PHY_INTERFACE_MODE_GMII;
> +	plat->mdio_bus_data->phy_mask = ~(u32)BIT(2);
> +	plat->fix_mac_speed = loongson_gnet_fix_speed;
> +
> +	return 0;
> +}
> +
> +static struct stmmac_pci_info loongson_gnet_pci_info = {
> +	.setup = loongson_gnet_data,
> +};
> +
>  static int loongson_dwmac_config_legacy(struct pci_dev *pdev,
>  					struct plat_stmmacenet_data *plat,
>  					struct stmmac_resources *res,
> @@ -101,12 +325,126 @@ static int loongson_dwmac_config_legacy(struct pci_dev *pdev,
>  	return 0;
>  }
>  
> +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
> +				     struct plat_stmmacenet_data *plat,
> +				     struct stmmac_resources *res,
> +				     struct device_node *np)
> +{
> +	int i, ret, vecs;
> +
> +	vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
> +	ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
> +	if (ret < 0) {
> +		dev_info(&pdev->dev,
> +			 "MSI enable failed, Fallback to legacy interrupt\n");
> +		return loongson_dwmac_config_legacy(pdev, plat, res, np);
> +	}
> +
> +	res->irq = pci_irq_vector(pdev, 0);
> +	res->wol_irq = 0;
> +
> +	/* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> +	 * --------- ----- -------- --------  ...  -------- --------
> +	 * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> +	 */
> +	for (i = 0; i < CHANNEL_NUM; i++) {
> +		res->rx_irq[CHANNEL_NUM - 1 - i] =
> +			pci_irq_vector(pdev, 1 + i * 2);
> +		res->tx_irq[CHANNEL_NUM - 1 - i] =
> +			pci_irq_vector(pdev, 2 + i * 2);
> +	}
> +
> +	plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> +
> +	return 0;
> +}
> +
> +static struct mac_device_info *loongson_dwmac_setup(void *apriv)
> +{
> +	struct stmmac_priv *priv = apriv;

> +	struct mac_device_info *mac;

seems unused. See my next comment.

> +	struct stmmac_dma_ops *dma;
> +	struct loongson_data *ld;
> +	struct pci_dev *pdev;
> +
> +	ld = priv->plat->bsp_priv;
> +	pdev = to_pci_dev(priv->device);
> +

> +	mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
> +	if (!mac)
> +		return NULL;

I see you no longer override the ops in dwmac1000_ops. If so this can
be dropped.

> +
> +	dma = devm_kzalloc(priv->device, sizeof(*dma), GFP_KERNEL);
> +	if (!dma)
> +		return NULL;
> +
> +	/* The original IP-core version is 0x37 in all Loongson GNET

s/0x37/v3.73a

> +	 * (ls2k2000 and ls7a2000), but the GNET HW designers have changed the
> +	 * GMAC_VERSION.SNPSVER field to the custom 0x10 value on the Loongson
> +	 * ls2k2000 MAC to emphasize the differences: multiple DMA-channels,

s/ls2k2000/LS2K2000
s/ls7a2000/LS7A2000

> +	 * AV feature and GMAC_INT_STATUS CSR flags layout. Get back the
> +	 * original value so the correct HW-interface would be selected.
> +	 */
> +	if (ld->gmac_verion == LOONGSON_DWMAC_CORE_1_00) {
> +		priv->synopsys_id = DWMAC_CORE_3_70;
> +		*dma = dwmac1000_dma_ops;
> +		dma->init_chan = loongson_gnet_dma_init_channel;
> +		dma->dma_interrupt = loongson_gnet_dma_interrupt;
> +		mac->dma = dma;
> +	}
> +

> +	mac->mac = &dwmac1000_ops;

Unused?

> +	priv->dev->priv_flags |= IFF_UNICAST_FLT;
> +
> +	/* Pre-initialize the respective "mac" fields as it's done in
> +	 * dwmac1000_setup()
> +	 */
> +	mac->pcsr = priv->ioaddr;
> +	mac->multicast_filter_bins = priv->plat->multicast_filter_bins;
> +	mac->unicast_filter_entries = priv->plat->unicast_filter_entries;
> +	mac->mcast_bits_log2 = 0;
> +
> +	if (mac->multicast_filter_bins)
> +		mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
> +

> +	/* The GMAC devices with PCI ID 0x7a03 does not support any pause mode.
> +	 * The GNET devices without CORE ID 0x10 does not support half-duplex.
> +	 */

No need to mention the IDs but just the actual devices:
	/* Loongson GMAC doesn't support the flow control. LS2K2000
	 * GNET doesn't support the half-duplex link mode.
	 */

> +	if (pdev->device == PCI_DEVICE_ID_LOONGSON_GMAC) {
> +		mac->link.caps = MAC_10 | MAC_100 | MAC_1000;
> +	} else {
> +		if (ld->gmac_verion == LOONGSON_DWMAC_CORE_1_00)
> +			mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
> +					 MAC_10 | MAC_100 | MAC_1000;
> +		else
> +			mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
> +					 MAC_10FD | MAC_100FD | MAC_1000FD;
> +	}
> +
> +	mac->link.duplex = GMAC_CONTROL_DM;
> +	mac->link.speed10 = GMAC_CONTROL_PS;
> +	mac->link.speed100 = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
> +	mac->link.speed1000 = 0;
> +	mac->link.speed_mask = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
> +	mac->mii.addr = GMAC_MII_ADDR;
> +	mac->mii.data = GMAC_MII_DATA;
> +	mac->mii.addr_shift = 11;
> +	mac->mii.addr_mask = 0x0000F800;
> +	mac->mii.reg_shift = 6;
> +	mac->mii.reg_mask = 0x000007C0;
> +	mac->mii.clk_csr_shift = 2;
> +	mac->mii.clk_csr_mask = GENMASK(5, 2);
> +
> +	return mac;
> +}
> +
>  static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  {
>  	struct plat_stmmacenet_data *plat;
>  	int ret, i, bus_id, phy_mode;
>  	struct stmmac_pci_info *info;
>  	struct stmmac_resources res;
> +	struct loongson_data *ld;
>  	struct device_node *np;
>  
>  	np = dev_of_node(&pdev->dev);
> @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  		return -ENOMEM;
>  

>  	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> -	if (!plat->dma_cfg) {
> -		ret = -ENOMEM;
> -		goto err_put_node;
> -	}
> +	if (!plat->dma_cfg)
> +		return -ENOMEM;

This change must have been introduced in the patch
[PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
which moves the mdio_node pointer initialization to under the if-clause.

> +
> +	ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
> +	if (!ld)
> +		return -ENOMEM;
>  
>  	/* Enable pci device */
>  	ret = pci_enable_device(pdev);
> @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  		plat->phy_interface = phy_mode;
>  	}
>  

> -	pci_enable_msi(pdev);

Hm, this must be justified and better being done in a separate patch.

> +	plat->bsp_priv = ld;
> +	plat->setup = loongson_dwmac_setup;
> +	ld->dev = &pdev->dev;
> +
>  	memset(&res, 0, sizeof(res));
>  	res.addr = pcim_iomap_table(pdev)[0];
> +	ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
> +
> +	switch (ld->gmac_verion) {
> +	case LOONGSON_DWMAC_CORE_1_00:

> +		plat->rx_queues_to_use = CHANNEL_NUM;
> +		plat->tx_queues_to_use = CHANNEL_NUM;
> +
> +		/* Only channel 0 supports checksum,
> +		 * so turn off checksum to enable multiple channels.
> +		 */
> +		for (i = 1; i < CHANNEL_NUM; i++)
> +			plat->tx_queues_cfg[i].coe_unsupported = 1;
>  
> -	plat->tx_queues_to_use = 1;
> -	plat->rx_queues_to_use = 1;
> +		ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
> +		break;
> +	default:	/* 0x35 device and 0x37 device. */
> +		plat->tx_queues_to_use = 1;
> +		plat->rx_queues_to_use = 1;
>  

Move the NoF queues (and coe flag) initializations to the respective
loongson_*_data() methods.

Besides I don't see you freeing the IRQ vectors allocated in the
loongson_dwmac_config_msi() method neither in probe(), nor in remove()
functions. That's definitely wrong. What you need is to have a
method antagonistic to loongson_dwmac_config_msi() (like
loongson_dwmac_clear_msi()) which would execute the cleanup procedure.

> -	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> +		ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> +		break;
> +	}
>  
>  	/* GNET devices with dev revision 0x00 do not support manually
>  	 * setting the speed to 1000.
> @@ -189,12 +549,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  
>  	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>  	if (ret)
> -		goto err_disable_msi;
> +		goto err_disable_device;
>  
>  	return ret;
>  

> -err_disable_msi:
> -	pci_disable_msi(pdev);

Once again. Justify the change. Moreover I don't see you dropping the
pci_disable_msi() from the remove() method.

-Serge(y)

>  err_disable_device:
>  	pci_disable_device(pdev);
>  err_put_node:
> @@ -262,6 +620,7 @@ static SIMPLE_DEV_PM_OPS(loongson_dwmac_pm_ops, loongson_dwmac_suspend,
>  
>  static const struct pci_device_id loongson_dwmac_id_table[] = {
>  	{ PCI_DEVICE_DATA(LOONGSON, GMAC, &loongson_gmac_pci_info) },
> +	{ PCI_DEVICE_DATA(LOONGSON, GNET, &loongson_gnet_pci_info) },
>  	{}
>  };
>  MODULE_DEVICE_TABLE(pci, loongson_dwmac_id_table);
> -- 
> 2.31.4
> 

Re: [PATCH net-next v12 14/15] net: stmmac: dwmac-loongson: Move disable_force flag to _gnet_date

[Serge Semin]

On Thu, Apr 25, 2024 at 09:11:37PM +0800, Yanteng Si wrote:
> We've already introduced loongson_gnet_data(), so the
> STMMAC_FLAG_DISABLE_FORCE_1000 should be take away from
> loongson_dwmac_probe().
> 
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../net/ethernet/stmicro/stmmac/dwmac-loongson.c    | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 68de90c44feb..dea02de030e6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -286,6 +286,12 @@ static int loongson_gnet_data(struct pci_dev *pdev,
>  	plat->mdio_bus_data->phy_mask = ~(u32)BIT(2);
>  	plat->fix_mac_speed = loongson_gnet_fix_speed;
>  

> +	/* GNET devices with dev revision 0x00 do not support manually
> +	 * setting the speed to 1000.
> +	 */
> +	if (pdev->revision == 0x00)
> +		plat->flags |= STMMAC_FLAG_DISABLE_FORCE_1000;
> +

Just introduce the change above in the framework of the patch 
[PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
and ...

>  	return 0;
>  }
>  
> @@ -540,13 +546,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  		break;
>  	}
>  

> -	/* GNET devices with dev revision 0x00 do not support manually
> -	 * setting the speed to 1000.
> -	 */
> -	if (pdev->device == PCI_DEVICE_ID_LOONGSON_GNET &&
> -	    pdev->revision == 0x00)
> -		plat->flags |= STMMAC_FLAG_DISABLE_FORCE_1000;
> -

... you won't to have this being undone. So this patch won't be even
needed to be introduced.

See my comment sent to
[PATCH net-next v12 12/15] net: stmmac: dwmac-loongson: Fixed failure to set network speed to 1000.

-Serge(y)

>  	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>  	if (ret)
>  		goto err_disable_device;
> -- 
> 2.31.4
> 

Re: [PATCH net-next v12 15/15] net: stmmac: dwmac-loongson: Add loongson module author

[Huacai Chen]

Hi, Yanteng,

On Thu, Apr 25, 2024 at 9:11 PM Yanteng Si <siyanteng@loongson.cn> wrote:
>
> Add Yanteng Si as MODULE_AUTHOR of  Loongson DWMAC PCI driver.
>
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index dea02de030e6..f0eebed751f3 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -638,4 +638,5 @@ module_pci_driver(loongson_dwmac_driver);
>
>  MODULE_DESCRIPTION("Loongson DWMAC PCI driver");
>  MODULE_AUTHOR("Qing Zhang <zhangqing@loongson.cn>");
> +MODULE_AUTHOR("Yanteng Si <siyanteng@loongson.cn>");
>  MODULE_LICENSE("GPL v2");
The patch splitting is toooo strange for this line. Since Qing Zhang
is the major author of GMAC, and you are the major author of GNET, I
think this line can be in Patch-13.

Huacai

> --
> 2.31.4
>

Re: [PATCH net-next v12 15/15] net: stmmac: dwmac-loongson: Add loongson module author

[Serge Semin]

On Mon, May 06, 2024 at 10:12:14AM +0800, Huacai Chen wrote:
> Hi, Yanteng,
> 
> On Thu, Apr 25, 2024 at 9:11 PM Yanteng Si <siyanteng@loongson.cn> wrote:
> >
> > Add Yanteng Si as MODULE_AUTHOR of  Loongson DWMAC PCI driver.
> >
> > Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> > Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> > Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> > ---
> >  drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > index dea02de030e6..f0eebed751f3 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > @@ -638,4 +638,5 @@ module_pci_driver(loongson_dwmac_driver);
> >
> >  MODULE_DESCRIPTION("Loongson DWMAC PCI driver");
> >  MODULE_AUTHOR("Qing Zhang <zhangqing@loongson.cn>");
> > +MODULE_AUTHOR("Yanteng Si <siyanteng@loongson.cn>");
> >  MODULE_LICENSE("GPL v2");

> The patch splitting is toooo strange for this line.

It's not.

> Since Qing Zhang
> is the major author of GMAC, and you are the major author of GNET, I
> think this line can be in Patch-13.

The patch size isn't something that determines the change placement,
but the change solving only one problem per patch. This patch is about
adding the driver author. The patch 13 is about adding the GNET device
support. It's perfectly fine to have these changes provided separately
and in the order they are submitted in v12. Besides the patch 13 has
just started getting to look reviewable enough. Stop trying to mix up
various changes in there again.

It was me who asked Yanteng to detach this changes into a separate and
final patch of the series, for the exact reasons I described above.

-Serge(y)

> 
> Huacai
> 
> > --
> > 2.31.4
> >

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Serge Semin]

On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
> ...
>  
> +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
> +				     struct plat_stmmacenet_data *plat,
> +				     struct stmmac_resources *res,
> +				     struct device_node *np)
> +{
> +	int i, ret, vecs;
> +
> +	vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
> +	ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
> +	if (ret < 0) {
> +		dev_info(&pdev->dev,
> +			 "MSI enable failed, Fallback to legacy interrupt\n");
> +		return loongson_dwmac_config_legacy(pdev, plat, res, np);
> +	}
> +
> +	res->irq = pci_irq_vector(pdev, 0);
> +	res->wol_irq = 0;
> +
> +	/* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> +	 * --------- ----- -------- --------  ...  -------- --------
> +	 * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> +	 */
> +	for (i = 0; i < CHANNEL_NUM; i++) {
> +		res->rx_irq[CHANNEL_NUM - 1 - i] =
> +			pci_irq_vector(pdev, 1 + i * 2);
> +		res->tx_irq[CHANNEL_NUM - 1 - i] =
> +			pci_irq_vector(pdev, 2 + i * 2);
> +	}
> +
> +	plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> +
> +	return 0;
> +}
> +
> ...
>  static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  {
>  	struct plat_stmmacenet_data *plat;
>  	int ret, i, bus_id, phy_mode;
>  	struct stmmac_pci_info *info;
>  	struct stmmac_resources res;
> +	struct loongson_data *ld;
>  	struct device_node *np;
>  
>  	np = dev_of_node(&pdev->dev);
> @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  		return -ENOMEM;
>  
>  	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> -	if (!plat->dma_cfg) {
> -		ret = -ENOMEM;
> -		goto err_put_node;
> -	}
> +	if (!plat->dma_cfg)
> +		return -ENOMEM;
> +
> +	ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
> +	if (!ld)
> +		return -ENOMEM;
>  
>  	/* Enable pci device */
>  	ret = pci_enable_device(pdev);
> @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  		plat->phy_interface = phy_mode;
>  	}
>  
> -	pci_enable_msi(pdev);
> +	plat->bsp_priv = ld;
> +	plat->setup = loongson_dwmac_setup;
> +	ld->dev = &pdev->dev;
> +
>  	memset(&res, 0, sizeof(res));
>  	res.addr = pcim_iomap_table(pdev)[0];
> +	ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
> +
> +	switch (ld->gmac_verion) {
> +	case LOONGSON_DWMAC_CORE_1_00:
> +		plat->rx_queues_to_use = CHANNEL_NUM;
> +		plat->tx_queues_to_use = CHANNEL_NUM;
> +
> +		/* Only channel 0 supports checksum,
> +		 * so turn off checksum to enable multiple channels.
> +		 */
> +		for (i = 1; i < CHANNEL_NUM; i++)
> +			plat->tx_queues_cfg[i].coe_unsupported = 1;
>  
> -	plat->tx_queues_to_use = 1;
> -	plat->rx_queues_to_use = 1;
> +		ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
> +		break;
> +	default:	/* 0x35 device and 0x37 device. */
> +		plat->tx_queues_to_use = 1;
> +		plat->rx_queues_to_use = 1;
>  
> -	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> +		ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> +		break;
> +	}
>  

Let's now talk about this change.

First of all, one more time. You can't miss the return value check
because if any of the IRQ config method fails then the driver won't
work! The first change that introduces the problem is in the patch
[PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy

Second, as I already mentioned in another message sent to this patch
you are missing the PCI MSI IRQs freeing in the cleanup-on-error path
and in the device/driver remove() function. It's definitely wrong.

Thirdly, you said that the node-pointer is now optional and introduced
the patch 
[PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
If so and the DT-based setting up isn't mandatory then I would
suggest to proceed with the entire so called legacy setups only if the
node-pointer has been found, otherwise the pure PCI-based setup would
be performed. So the patches 10-13 (in your v12 order) would look
like this:

1. Patch 10 introduces the two types of the configs - DT and PCI plus
the bus_id initialized based on the PCI domain and device ID.
[PATCH net-next v13 10/15] net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support
The DT and PCI config functions can look like this:

static int loongson_dwmac_config_dt(struct pci_dev *pdev,
				    struct plat_stmmacenet_data *plat,
				    struct stmmac_resources *res)
{
	struct device_node *np = dev_of_node(&pdev->dev);
	int ret;

	plat->mdio_node = of_get_child_by_name(np, "mdio");
	if (plat->mdio_node) {
		dev_info(&pdev->dev, "Found MDIO subnode\n");
		plat->mdio_bus_data->needs_reset = true;
	}

	ret = of_alias_get_id(np, "ethernet");
	if (ret >= 0)
		plat->bus_id = ret;

	res->irq = of_irq_get_byname(np, "macirq");
	if (res->irq < 0) {
		dev_err(&pdev->dev, "IRQ macirq not found\n");
		return -ENODEV;
	}

	res->wol_irq = of_irq_get_byname(np, "eth_wake_irq");
	if (res->wol_irq < 0) {
		dev_info(&pdev->dev,
			 "IRQ eth_wake_irq not found, using macirq\n");
		res->wol_irq = res->irq;
	}

	res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
	if (res->lpi_irq < 0) {
		dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
		return -ENODEV;
	}

	return 0;
}

static int loongson_dwmac_config_pci(struct pci_dev *pdev,
				     struct plat_stmmacenet_data *plat,
				     struct stmmac_resources *res)
{
	res.irq = pdev->irq;

	return 0;
}

...

static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
	...
	if (dev_of_node(&pdev->dev))
		ret = loongson_dwmac_dt_config(pdev, plat, res);
	else
		ret = loongson_dwmac_pci_config(pdev, plat, res);
	if (ret)
		goto err_disable_msi;

	...
}

2. Patch 11 introduces the stmmac_pci_info structure, makes the
stmmac_pci_info::setup() callback called in the probe() function and
assigns the loongson_gmac_data() method pointer to the GMAC info data. 
[PATCH net-next v13 11/15] net: stmmac: dwmac-loongson: Introduce PCI device info data

3. Patch 12 can be preserved as is (but see my notes regarding moving
a part of it to the patch 13).
[PATCH net-next v13 12/15] net: stmmac: dwmac-loongson: Add flag disabling AN-less 1Gbps setup

4. Patch 13 introduces the GNET support as it's mainly done in your
patch (see my notes in there though)
[PATCH net-next v13 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
but the loongson_dwmac_config_pci() method would now look as follows:

static int loongson_dwmac_config_pci(struct pci_dev *pdev,
				     struct plat_stmmacenet_data *plat,
				     struct stmmac_resources *res)
{
	int i, ret, vecs;

	/* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
	 * --------- ----- -------- --------  ...  -------- --------
	 * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
	 */
	vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
	ret = pci_alloc_irq_vectors(pdev, 1, vecs, PCI_IRQ_MSI | PCI_IRQ_LEGACY);
	if (ret < 0) {
		dev_err(&pdev->dev, "Failed to allocate PCI IRQs\n");
		return ret;
	} else if (ret >= vecs) {
		for (i = 0; i < CHANNEL_NUM; i++) {
			res->rx_irq[CHANNEL_NUM - 1 - i] =
				pci_irq_vector(pdev, 1 + i * 2);
			res->tx_irq[CHANNEL_NUM - 1 - i] =
				pci_irq_vector(pdev, 2 + i * 2);
		}

		plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
	} else {
		dev_warn(&pdev->dev, "Fall back to PCIe INTx IRQs\n");
	}

	res->irq = pci_irq_vector(pdev, 0);

	return 0;
}

What do you think?

-Serge(y)

Re: [PATCH net-next v12 09/15] net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC

[Russell King (Oracle)]

On Sat, May 04, 2024 at 12:01:42AM +0300, Serge Semin wrote:
> Absolutely correct. Moreover AFAICS from the databooks the PCS module
> is only available for the DW GMACs with the TBI, RTBI and SGMII
> interfaces. So the STMMAC_PCS_RGMII PCS flag seems misleading. The only
> info about the link state that could be runtime detected on the MAC
> side is: link speed, duplex mode and link status. It's done by means
> of the RGMII in-band status signals. That's what is implemented in the
> dwmac1000_rgsmii() method.

... which you've now made me look at, look at the whole
pcs_link/pcs_speed/pcs_duplex and made me wonder why the hell stmmac
is making this so figgin difficult, messing with the carrier behind
phylink's back (which is a no-no), and why it needs to have separate
paths for this.

It doesn't.

Just because it doesn't have something called an official "PCS" does
not mean you _can't_ use a phylink_pcs to represent something that
has PCS-like properties - such as the RGMII in-band status which is
no different to what Cisco SGMII does.

This isn't something new... this is something that mvneta has
supported since before phylink was a thing, and so phylink had to
allow it as well.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Yanteng Si]

Hi Serge,

在 2024/5/6 18:39, Serge Semin 写道:
> On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
>> ...
>>   
>> +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
>> +				     struct plat_stmmacenet_data *plat,
>> +				     struct stmmac_resources *res,
>> +				     struct device_node *np)
>> +{
>> +	int i, ret, vecs;
>> +
>> +	vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
>> +	ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
>> +	if (ret < 0) {
>> +		dev_info(&pdev->dev,
>> +			 "MSI enable failed, Fallback to legacy interrupt\n");
>> +		return loongson_dwmac_config_legacy(pdev, plat, res, np);
>> +	}
>> +
>> +	res->irq = pci_irq_vector(pdev, 0);
>> +	res->wol_irq = 0;
>> +
>> +	/* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
>> +	 * --------- ----- -------- --------  ...  -------- --------
>> +	 * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
>> +	 */
>> +	for (i = 0; i < CHANNEL_NUM; i++) {
>> +		res->rx_irq[CHANNEL_NUM - 1 - i] =
>> +			pci_irq_vector(pdev, 1 + i * 2);
>> +		res->tx_irq[CHANNEL_NUM - 1 - i] =
>> +			pci_irq_vector(pdev, 2 + i * 2);
>> +	}
>> +
>> +	plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
>> +
>> +	return 0;
>> +}
>> +
>> ...
>>   static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>>   {
>>   	struct plat_stmmacenet_data *plat;
>>   	int ret, i, bus_id, phy_mode;
>>   	struct stmmac_pci_info *info;
>>   	struct stmmac_resources res;
>> +	struct loongson_data *ld;
>>   	struct device_node *np;
>>   
>>   	np = dev_of_node(&pdev->dev);
>> @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   		return -ENOMEM;
>>   
>>   	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
>> -	if (!plat->dma_cfg) {
>> -		ret = -ENOMEM;
>> -		goto err_put_node;
>> -	}
>> +	if (!plat->dma_cfg)
>> +		return -ENOMEM;
>> +
>> +	ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
>> +	if (!ld)
>> +		return -ENOMEM;
>>   
>>   	/* Enable pci device */
>>   	ret = pci_enable_device(pdev);
>> @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   		plat->phy_interface = phy_mode;
>>   	}
>>   
>> -	pci_enable_msi(pdev);
>> +	plat->bsp_priv = ld;
>> +	plat->setup = loongson_dwmac_setup;
>> +	ld->dev = &pdev->dev;
>> +
>>   	memset(&res, 0, sizeof(res));
>>   	res.addr = pcim_iomap_table(pdev)[0];
>> +	ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
>> +
>> +	switch (ld->gmac_verion) {
>> +	case LOONGSON_DWMAC_CORE_1_00:
>> +		plat->rx_queues_to_use = CHANNEL_NUM;
>> +		plat->tx_queues_to_use = CHANNEL_NUM;
>> +
>> +		/* Only channel 0 supports checksum,
>> +		 * so turn off checksum to enable multiple channels.
>> +		 */
>> +		for (i = 1; i < CHANNEL_NUM; i++)
>> +			plat->tx_queues_cfg[i].coe_unsupported = 1;
>>   
>> -	plat->tx_queues_to_use = 1;
>> -	plat->rx_queues_to_use = 1;
>> +		ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
>> +		break;
>> +	default:	/* 0x35 device and 0x37 device. */
>> +		plat->tx_queues_to_use = 1;
>> +		plat->rx_queues_to_use = 1;
>>   
>> -	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
>> +		ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
>> +		break;
>> +	}
>>   
> Let's now talk about this change.
>
> First of all, one more time. You can't miss the return value check
> because if any of the IRQ config method fails then the driver won't
> work! The first change that introduces the problem is in the patch
> [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
OK!
>
> Second, as I already mentioned in another message sent to this patch
> you are missing the PCI MSI IRQs freeing in the cleanup-on-error path
> and in the device/driver remove() function. It's definitely wrong.
You are right! I will do it.
> Thirdly, you said that the node-pointer is now optional and introduced
> the patch
> [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> If so and the DT-based setting up isn't mandatory then I would
> suggest to proceed with the entire so called legacy setups only if the
> node-pointer has been found, otherwise the pure PCI-based setup would
> be performed. So the patches 10-13 (in your v12 order) would look

In this case, MSI will not be enabled when the node-pointer is found.

.


In fact, a large fraction of 2k devices are DT-based, of course, many 
are PCI-based.


Thanks,

Yanteng

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Serge Semin]

On Tue, May 07, 2024 at 09:35:24PM +0800, Yanteng Si wrote:
> Hi Serge,
> 
> 在 2024/5/6 18:39, Serge Semin 写道:
> > On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
> > > ...
> > > +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
> > > +				     struct plat_stmmacenet_data *plat,
> > > +				     struct stmmac_resources *res,
> > > +				     struct device_node *np)
> > > +{
> > > +	int i, ret, vecs;
> > > +
> > > +	vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
> > > +	ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
> > > +	if (ret < 0) {
> > > +		dev_info(&pdev->dev,
> > > +			 "MSI enable failed, Fallback to legacy interrupt\n");
> > > +		return loongson_dwmac_config_legacy(pdev, plat, res, np);
> > > +	}
> > > +
> > > +	res->irq = pci_irq_vector(pdev, 0);
> > > +	res->wol_irq = 0;
> > > +
> > > +	/* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> > > +	 * --------- ----- -------- --------  ...  -------- --------
> > > +	 * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> > > +	 */
> > > +	for (i = 0; i < CHANNEL_NUM; i++) {
> > > +		res->rx_irq[CHANNEL_NUM - 1 - i] =
> > > +			pci_irq_vector(pdev, 1 + i * 2);
> > > +		res->tx_irq[CHANNEL_NUM - 1 - i] =
> > > +			pci_irq_vector(pdev, 2 + i * 2);
> > > +	}
> > > +
> > > +	plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > ...
> > >   static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > >   {
> > >   	struct plat_stmmacenet_data *plat;
> > >   	int ret, i, bus_id, phy_mode;
> > >   	struct stmmac_pci_info *info;
> > >   	struct stmmac_resources res;
> > > +	struct loongson_data *ld;
> > >   	struct device_node *np;
> > >   	np = dev_of_node(&pdev->dev);
> > > @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > >   		return -ENOMEM;
> > >   	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> > > -	if (!plat->dma_cfg) {
> > > -		ret = -ENOMEM;
> > > -		goto err_put_node;
> > > -	}
> > > +	if (!plat->dma_cfg)
> > > +		return -ENOMEM;
> > > +
> > > +	ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
> > > +	if (!ld)
> > > +		return -ENOMEM;
> > >   	/* Enable pci device */
> > >   	ret = pci_enable_device(pdev);
> > > @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > >   		plat->phy_interface = phy_mode;
> > >   	}
> > > -	pci_enable_msi(pdev);
> > > +	plat->bsp_priv = ld;
> > > +	plat->setup = loongson_dwmac_setup;
> > > +	ld->dev = &pdev->dev;
> > > +
> > >   	memset(&res, 0, sizeof(res));
> > >   	res.addr = pcim_iomap_table(pdev)[0];
> > > +	ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
> > > +
> > > +	switch (ld->gmac_verion) {
> > > +	case LOONGSON_DWMAC_CORE_1_00:
> > > +		plat->rx_queues_to_use = CHANNEL_NUM;
> > > +		plat->tx_queues_to_use = CHANNEL_NUM;
> > > +
> > > +		/* Only channel 0 supports checksum,
> > > +		 * so turn off checksum to enable multiple channels.
> > > +		 */
> > > +		for (i = 1; i < CHANNEL_NUM; i++)
> > > +			plat->tx_queues_cfg[i].coe_unsupported = 1;
> > > -	plat->tx_queues_to_use = 1;
> > > -	plat->rx_queues_to_use = 1;
> > > +		ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
> > > +		break;
> > > +	default:	/* 0x35 device and 0x37 device. */
> > > +		plat->tx_queues_to_use = 1;
> > > +		plat->rx_queues_to_use = 1;
> > > -	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > +		ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > +		break;
> > > +	}
> > Let's now talk about this change.
> > 
> > First of all, one more time. You can't miss the return value check
> > because if any of the IRQ config method fails then the driver won't
> > work! The first change that introduces the problem is in the patch
> > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> OK!
> > 
> > Second, as I already mentioned in another message sent to this patch
> > you are missing the PCI MSI IRQs freeing in the cleanup-on-error path
> > and in the device/driver remove() function. It's definitely wrong.
> You are right! I will do it.
> > Thirdly, you said that the node-pointer is now optional and introduced
> > the patch
> > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > If so and the DT-based setting up isn't mandatory then I would
> > suggest to proceed with the entire so called legacy setups only if the
> > node-pointer has been found, otherwise the pure PCI-based setup would
> > be performed. So the patches 10-13 (in your v12 order) would look
> 
> In this case, MSI will not be enabled when the node-pointer is found.
> 
> .
> 
> 
> In fact, a large fraction of 2k devices are DT-based, of course, many are
> PCI-based.

Then please summarise which devices need the DT-node pointer which
don't? And most importantly if they do why do they need the DT-node?

AFAICS currently both LS2K1000 and LS7A1000 GMACs require the DT-node
to get the MAC and LPI IRQ signals. AFAICS from your series LS7A2000
GNET is also DT-based for the same reason. But the LS2K2000 GNET case
is different. You say that some of the platforms have the respective
DT-node some don't, but at the same time you submitting this patch
which permits the MSI IRQs only for the LS7A2000 GNET. It looks
contradicting. Does it mean that the GNET devices may generate the
IRQs via both legacy (an IRQ signal directly connected to the system
GIC) and the PCI MSI ways?

Let's get the question to the more generic level. Are the Loongson
GNET and GMAC controllers able to generate the IRQs via both ways:
physical IRQ signal and PCI MSI?

Please don't consider this as a vastly meticulous review. I am just
trying to figure out how to make things less complicated and fix the
driver to permitting only the cases which are actually possible.

-Serge(y)

> 
> 
> Thanks,
> 
> Yanteng
> 
> 

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Huacai Chen]

Hi, Serge,

On Wed, May 8, 2024 at 10:38 PM Serge Semin <fancer.lancer@gmail.com> wrote:
>
> On Tue, May 07, 2024 at 09:35:24PM +0800, Yanteng Si wrote:
> > Hi Serge,
> >
> > 在 2024/5/6 18:39, Serge Semin 写道:
> > > On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
> > > > ...
> > > > +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
> > > > +                              struct plat_stmmacenet_data *plat,
> > > > +                              struct stmmac_resources *res,
> > > > +                              struct device_node *np)
> > > > +{
> > > > + int i, ret, vecs;
> > > > +
> > > > + vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
> > > > + ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
> > > > + if (ret < 0) {
> > > > +         dev_info(&pdev->dev,
> > > > +                  "MSI enable failed, Fallback to legacy interrupt\n");
> > > > +         return loongson_dwmac_config_legacy(pdev, plat, res, np);
> > > > + }
> > > > +
> > > > + res->irq = pci_irq_vector(pdev, 0);
> > > > + res->wol_irq = 0;
> > > > +
> > > > + /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> > > > +  * --------- ----- -------- --------  ...  -------- --------
> > > > +  * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> > > > +  */
> > > > + for (i = 0; i < CHANNEL_NUM; i++) {
> > > > +         res->rx_irq[CHANNEL_NUM - 1 - i] =
> > > > +                 pci_irq_vector(pdev, 1 + i * 2);
> > > > +         res->tx_irq[CHANNEL_NUM - 1 - i] =
> > > > +                 pci_irq_vector(pdev, 2 + i * 2);
> > > > + }
> > > > +
> > > > + plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > ...
> > > >   static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > > >   {
> > > >           struct plat_stmmacenet_data *plat;
> > > >           int ret, i, bus_id, phy_mode;
> > > >           struct stmmac_pci_info *info;
> > > >           struct stmmac_resources res;
> > > > + struct loongson_data *ld;
> > > >           struct device_node *np;
> > > >           np = dev_of_node(&pdev->dev);
> > > > @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > >                   return -ENOMEM;
> > > >           plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> > > > - if (!plat->dma_cfg) {
> > > > -         ret = -ENOMEM;
> > > > -         goto err_put_node;
> > > > - }
> > > > + if (!plat->dma_cfg)
> > > > +         return -ENOMEM;
> > > > +
> > > > + ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
> > > > + if (!ld)
> > > > +         return -ENOMEM;
> > > >           /* Enable pci device */
> > > >           ret = pci_enable_device(pdev);
> > > > @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > >                   plat->phy_interface = phy_mode;
> > > >           }
> > > > - pci_enable_msi(pdev);
> > > > + plat->bsp_priv = ld;
> > > > + plat->setup = loongson_dwmac_setup;
> > > > + ld->dev = &pdev->dev;
> > > > +
> > > >           memset(&res, 0, sizeof(res));
> > > >           res.addr = pcim_iomap_table(pdev)[0];
> > > > + ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
> > > > +
> > > > + switch (ld->gmac_verion) {
> > > > + case LOONGSON_DWMAC_CORE_1_00:
> > > > +         plat->rx_queues_to_use = CHANNEL_NUM;
> > > > +         plat->tx_queues_to_use = CHANNEL_NUM;
> > > > +
> > > > +         /* Only channel 0 supports checksum,
> > > > +          * so turn off checksum to enable multiple channels.
> > > > +          */
> > > > +         for (i = 1; i < CHANNEL_NUM; i++)
> > > > +                 plat->tx_queues_cfg[i].coe_unsupported = 1;
> > > > - plat->tx_queues_to_use = 1;
> > > > - plat->rx_queues_to_use = 1;
> > > > +         ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
> > > > +         break;
> > > > + default:        /* 0x35 device and 0x37 device. */
> > > > +         plat->tx_queues_to_use = 1;
> > > > +         plat->rx_queues_to_use = 1;
> > > > - ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > +         ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > +         break;
> > > > + }
> > > Let's now talk about this change.
> > >
> > > First of all, one more time. You can't miss the return value check
> > > because if any of the IRQ config method fails then the driver won't
> > > work! The first change that introduces the problem is in the patch
> > > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > OK!
> > >
> > > Second, as I already mentioned in another message sent to this patch
> > > you are missing the PCI MSI IRQs freeing in the cleanup-on-error path
> > > and in the device/driver remove() function. It's definitely wrong.
> > You are right! I will do it.
> > > Thirdly, you said that the node-pointer is now optional and introduced
> > > the patch
> > > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > If so and the DT-based setting up isn't mandatory then I would
> > > suggest to proceed with the entire so called legacy setups only if the
> > > node-pointer has been found, otherwise the pure PCI-based setup would
> > > be performed. So the patches 10-13 (in your v12 order) would look
> >
> > In this case, MSI will not be enabled when the node-pointer is found.
> >
> > .
> >
> >
> > In fact, a large fraction of 2k devices are DT-based, of course, many are
> > PCI-based.
>
> Then please summarise which devices need the DT-node pointer which
> don't? And most importantly if they do why do they need the DT-node?
Whether we need DT-nodes doesn't depend on device type, but depends on
the BIOS type. When we boot with UEFI+ACPI, we don't need DT-node,
when we boot with PMON+FDT, we need DT-node. Loongson machines may
have either BIOS types.

Huacai

>
> AFAICS currently both LS2K1000 and LS7A1000 GMACs require the DT-node
> to get the MAC and LPI IRQ signals. AFAICS from your series LS7A2000
> GNET is also DT-based for the same reason. But the LS2K2000 GNET case
> is different. You say that some of the platforms have the respective
> DT-node some don't, but at the same time you submitting this patch
> which permits the MSI IRQs only for the LS7A2000 GNET. It looks
> contradicting. Does it mean that the GNET devices may generate the
> IRQs via both legacy (an IRQ signal directly connected to the system
> GIC) and the PCI MSI ways?
>
> Let's get the question to the more generic level. Are the Loongson
> GNET and GMAC controllers able to generate the IRQs via both ways:
> physical IRQ signal and PCI MSI?
>
> Please don't consider this as a vastly meticulous review. I am just
> trying to figure out how to make things less complicated and fix the
> driver to permitting only the cases which are actually possible.
>
> -Serge(y)
>
> >
> >
> > Thanks,
> >
> > Yanteng
> >
> >

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Serge Semin]

On Wed, May 08, 2024 at 10:58:16PM +0800, Huacai Chen wrote:
> Hi, Serge,
> 
> On Wed, May 8, 2024 at 10:38 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> >
> > On Tue, May 07, 2024 at 09:35:24PM +0800, Yanteng Si wrote:
> > > Hi Serge,
> > >
> > > 在 2024/5/6 18:39, Serge Semin 写道:
> > > > On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
> > > > > ...
> > > > > +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
> > > > > +                              struct plat_stmmacenet_data *plat,
> > > > > +                              struct stmmac_resources *res,
> > > > > +                              struct device_node *np)
> > > > > +{
> > > > > + int i, ret, vecs;
> > > > > +
> > > > > + vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
> > > > > + ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
> > > > > + if (ret < 0) {
> > > > > +         dev_info(&pdev->dev,
> > > > > +                  "MSI enable failed, Fallback to legacy interrupt\n");
> > > > > +         return loongson_dwmac_config_legacy(pdev, plat, res, np);
> > > > > + }
> > > > > +
> > > > > + res->irq = pci_irq_vector(pdev, 0);
> > > > > + res->wol_irq = 0;
> > > > > +
> > > > > + /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> > > > > +  * --------- ----- -------- --------  ...  -------- --------
> > > > > +  * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> > > > > +  */
> > > > > + for (i = 0; i < CHANNEL_NUM; i++) {
> > > > > +         res->rx_irq[CHANNEL_NUM - 1 - i] =
> > > > > +                 pci_irq_vector(pdev, 1 + i * 2);
> > > > > +         res->tx_irq[CHANNEL_NUM - 1 - i] =
> > > > > +                 pci_irq_vector(pdev, 2 + i * 2);
> > > > > + }
> > > > > +
> > > > > + plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > ...
> > > > >   static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > > > >   {
> > > > >           struct plat_stmmacenet_data *plat;
> > > > >           int ret, i, bus_id, phy_mode;
> > > > >           struct stmmac_pci_info *info;
> > > > >           struct stmmac_resources res;
> > > > > + struct loongson_data *ld;
> > > > >           struct device_node *np;
> > > > >           np = dev_of_node(&pdev->dev);
> > > > > @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > > >                   return -ENOMEM;
> > > > >           plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> > > > > - if (!plat->dma_cfg) {
> > > > > -         ret = -ENOMEM;
> > > > > -         goto err_put_node;
> > > > > - }
> > > > > + if (!plat->dma_cfg)
> > > > > +         return -ENOMEM;
> > > > > +
> > > > > + ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
> > > > > + if (!ld)
> > > > > +         return -ENOMEM;
> > > > >           /* Enable pci device */
> > > > >           ret = pci_enable_device(pdev);
> > > > > @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > > >                   plat->phy_interface = phy_mode;
> > > > >           }
> > > > > - pci_enable_msi(pdev);
> > > > > + plat->bsp_priv = ld;
> > > > > + plat->setup = loongson_dwmac_setup;
> > > > > + ld->dev = &pdev->dev;
> > > > > +
> > > > >           memset(&res, 0, sizeof(res));
> > > > >           res.addr = pcim_iomap_table(pdev)[0];
> > > > > + ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
> > > > > +
> > > > > + switch (ld->gmac_verion) {
> > > > > + case LOONGSON_DWMAC_CORE_1_00:
> > > > > +         plat->rx_queues_to_use = CHANNEL_NUM;
> > > > > +         plat->tx_queues_to_use = CHANNEL_NUM;
> > > > > +
> > > > > +         /* Only channel 0 supports checksum,
> > > > > +          * so turn off checksum to enable multiple channels.
> > > > > +          */
> > > > > +         for (i = 1; i < CHANNEL_NUM; i++)
> > > > > +                 plat->tx_queues_cfg[i].coe_unsupported = 1;
> > > > > - plat->tx_queues_to_use = 1;
> > > > > - plat->rx_queues_to_use = 1;
> > > > > +         ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
> > > > > +         break;
> > > > > + default:        /* 0x35 device and 0x37 device. */
> > > > > +         plat->tx_queues_to_use = 1;
> > > > > +         plat->rx_queues_to_use = 1;
> > > > > - ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > > +         ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > > +         break;
> > > > > + }
> > > > Let's now talk about this change.
> > > >
> > > > First of all, one more time. You can't miss the return value check
> > > > because if any of the IRQ config method fails then the driver won't
> > > > work! The first change that introduces the problem is in the patch
> > > > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > OK!
> > > >
> > > > Second, as I already mentioned in another message sent to this patch
> > > > you are missing the PCI MSI IRQs freeing in the cleanup-on-error path
> > > > and in the device/driver remove() function. It's definitely wrong.
> > > You are right! I will do it.
> > > > Thirdly, you said that the node-pointer is now optional and introduced
> > > > the patch
> > > > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > If so and the DT-based setting up isn't mandatory then I would
> > > > suggest to proceed with the entire so called legacy setups only if the
> > > > node-pointer has been found, otherwise the pure PCI-based setup would
> > > > be performed. So the patches 10-13 (in your v12 order) would look
> > >
> > > In this case, MSI will not be enabled when the node-pointer is found.
> > >
> > > .
> > >
> > >
> > > In fact, a large fraction of 2k devices are DT-based, of course, many are
> > > PCI-based.
> >
> > Then please summarise which devices need the DT-node pointer which
> > don't? And most importantly if they do why do they need the DT-node?

> Whether we need DT-nodes doesn't depend on device type, but depends on
> the BIOS type. When we boot with UEFI+ACPI, we don't need DT-node,
> when we boot with PMON+FDT, we need DT-node. Loongson machines may
> have either BIOS types.

Thanks for the answer. Just to fully clarify. Does it mean that all
Loongson Ethernet controllers (Loongson GNET and GMAC) are able to
deliver both PCI MSI IRQs and direct GIC IRQs (so called legacy)?

-Serge(y)

> 
> Huacai
> 
> >
> > AFAICS currently both LS2K1000 and LS7A1000 GMACs require the DT-node
> > to get the MAC and LPI IRQ signals. AFAICS from your series LS7A2000
> > GNET is also DT-based for the same reason. But the LS2K2000 GNET case
> > is different. You say that some of the platforms have the respective
> > DT-node some don't, but at the same time you submitting this patch
> > which permits the MSI IRQs only for the LS7A2000 GNET. It looks
> > contradicting. Does it mean that the GNET devices may generate the
> > IRQs via both legacy (an IRQ signal directly connected to the system
> > GIC) and the PCI MSI ways?
> >
> > Let's get the question to the more generic level. Are the Loongson
> > GNET and GMAC controllers able to generate the IRQs via both ways:
> > physical IRQ signal and PCI MSI?
> >
> > Please don't consider this as a vastly meticulous review. I am just
> > trying to figure out how to make things less complicated and fix the
> > driver to permitting only the cases which are actually possible.
> >
> > -Serge(y)
> >
> > >
> > >
> > > Thanks,
> > >
> > > Yanteng
> > >
> > >

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Yanteng Si]

Hi Serge

在 2024/5/8 23:10, Serge Semin 写道:
> On Wed, May 08, 2024 at 10:58:16PM +0800, Huacai Chen wrote:
>> Hi, Serge,
>>
>> On Wed, May 8, 2024 at 10:38 PM Serge Semin<fancer.lancer@gmail.com>  wrote:
>>> On Tue, May 07, 2024 at 09:35:24PM +0800, Yanteng Si wrote:
>>>> Hi Serge,
>>>>
>>>> 在 2024/5/6 18:39, Serge Semin 写道:
>>>>> On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
>>>>>> ...
>>>>>> +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
>>>>>> +                              struct plat_stmmacenet_data *plat,
>>>>>> +                              struct stmmac_resources *res,
>>>>>> +                              struct device_node *np)
>>>>>> +{
>>>>>> + int i, ret, vecs;
>>>>>> +
>>>>>> + vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
>>>>>> + ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
>>>>>> + if (ret < 0) {
>>>>>> +         dev_info(&pdev->dev,
>>>>>> +                  "MSI enable failed, Fallback to legacy interrupt\n");
>>>>>> +         return loongson_dwmac_config_legacy(pdev, plat, res, np);
>>>>>> + }
>>>>>> +
>>>>>> + res->irq = pci_irq_vector(pdev, 0);
>>>>>> + res->wol_irq = 0;
>>>>>> +
>>>>>> + /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
>>>>>> +  * --------- ----- -------- --------  ...  -------- --------
>>>>>> +  * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
>>>>>> +  */
>>>>>> + for (i = 0; i < CHANNEL_NUM; i++) {
>>>>>> +         res->rx_irq[CHANNEL_NUM - 1 - i] =
>>>>>> +                 pci_irq_vector(pdev, 1 + i * 2);
>>>>>> +         res->tx_irq[CHANNEL_NUM - 1 - i] =
>>>>>> +                 pci_irq_vector(pdev, 2 + i * 2);
>>>>>> + }
>>>>>> +
>>>>>> + plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
>>>>>> +
>>>>>> + return 0;
>>>>>> +}
>>>>>> +
>>>>>> ...
>>>>>>    static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>>>>>>    {
>>>>>>            struct plat_stmmacenet_data *plat;
>>>>>>            int ret, i, bus_id, phy_mode;
>>>>>>            struct stmmac_pci_info *info;
>>>>>>            struct stmmac_resources res;
>>>>>> + struct loongson_data *ld;
>>>>>>            struct device_node *np;
>>>>>>            np = dev_of_node(&pdev->dev);
>>>>>> @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>>>>>                    return -ENOMEM;
>>>>>>            plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
>>>>>> - if (!plat->dma_cfg) {
>>>>>> -         ret = -ENOMEM;
>>>>>> -         goto err_put_node;
>>>>>> - }
>>>>>> + if (!plat->dma_cfg)
>>>>>> +         return -ENOMEM;
>>>>>> +
>>>>>> + ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
>>>>>> + if (!ld)
>>>>>> +         return -ENOMEM;
>>>>>>            /* Enable pci device */
>>>>>>            ret = pci_enable_device(pdev);
>>>>>> @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>>>>>                    plat->phy_interface = phy_mode;
>>>>>>            }
>>>>>> - pci_enable_msi(pdev);
>>>>>> + plat->bsp_priv = ld;
>>>>>> + plat->setup = loongson_dwmac_setup;
>>>>>> + ld->dev = &pdev->dev;
>>>>>> +
>>>>>>            memset(&res, 0, sizeof(res));
>>>>>>            res.addr = pcim_iomap_table(pdev)[0];
>>>>>> + ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
>>>>>> +
>>>>>> + switch (ld->gmac_verion) {
>>>>>> + case LOONGSON_DWMAC_CORE_1_00:
>>>>>> +         plat->rx_queues_to_use = CHANNEL_NUM;
>>>>>> +         plat->tx_queues_to_use = CHANNEL_NUM;
>>>>>> +
>>>>>> +         /* Only channel 0 supports checksum,
>>>>>> +          * so turn off checksum to enable multiple channels.
>>>>>> +          */
>>>>>> +         for (i = 1; i < CHANNEL_NUM; i++)
>>>>>> +                 plat->tx_queues_cfg[i].coe_unsupported = 1;
>>>>>> - plat->tx_queues_to_use = 1;
>>>>>> - plat->rx_queues_to_use = 1;
>>>>>> +         ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
>>>>>> +         break;
>>>>>> + default:        /* 0x35 device and 0x37 device. */
>>>>>> +         plat->tx_queues_to_use = 1;
>>>>>> +         plat->rx_queues_to_use = 1;
>>>>>> - ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
>>>>>> +         ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
>>>>>> +         break;
>>>>>> + }
>>>>> Let's now talk about this change.
>>>>>
>>>>> First of all, one more time. You can't miss the return value check
>>>>> because if any of the IRQ config method fails then the driver won't
>>>>> work! The first change that introduces the problem is in the patch
>>>>> [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
>>>> OK!
>>>>> Second, as I already mentioned in another message sent to this patch
>>>>> you are missing the PCI MSI IRQs freeing in the cleanup-on-error path
>>>>> and in the device/driver remove() function. It's definitely wrong.
>>>> You are right! I will do it.
>>>>> Thirdly, you said that the node-pointer is now optional and introduced
>>>>> the patch
>>>>> [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
>>>>> If so and the DT-based setting up isn't mandatory then I would
>>>>> suggest to proceed with the entire so called legacy setups only if the
>>>>> node-pointer has been found, otherwise the pure PCI-based setup would
>>>>> be performed. So the patches 10-13 (in your v12 order) would look
>>>> In this case, MSI will not be enabled when the node-pointer is found.
>>>>
>>>> .
>>>>
>>>>
>>>> In fact, a large fraction of 2k devices are DT-based, of course, many are
>>>> PCI-based.
>>> Then please summarise which devices need the DT-node pointer which
>>> don't? And most importantly if they do why do they need the DT-node?
>> Whether we need DT-nodes doesn't depend on device type, but depends on
>> the BIOS type. When we boot with UEFI+ACPI, we don't need DT-node,
>> when we boot with PMON+FDT, we need DT-node. Loongson machines may
>> have either BIOS types.
> Thanks for the answer. Just to fully clarify. Does it mean that all
> Loongson Ethernet controllers (Loongson GNET and GMAC) are able to
> deliver both PCI MSI IRQs and direct GIC IRQs (so called legacy)?

No, only devices that support multiple channels can deliver both PCI MSI 
IRQs

and direct GIC IRQs, other devices can only deliver GIC IRQs.

Furthermore, multiple channel features are bundled with MSI. If we want to

enable multiple channels, we must enable MSI.

Thanks,

Yanteng

Re: [PATCH net-next v12 01/15] net: stmmac: Move the atds flag to the stmmac_dma_cfg structure

[Yanteng Si]

在 2024/5/3 03:10, Serge Semin 写道:
> "ATDS (Alternate Descriptor Size) is a part of the DMA Bus Mode configs
> (together with PBL, ALL, EME, etc) of the DW GMAC controllers. Seeing
> it's not changed at runtime but is activated as long as the IP-core
> has it supported (at least due to the Type 2 Full Checksum Offload
> Engine feature), move the respective parameter from the
> stmmac_dma_ops::init() callback argument to the stmmac_dma_cfg
> structure, which already have the rest of the DMA-related configs
> defined.
>
> Besides the being added in the next commit DW GMAC multi-channels
> support will require to add the stmmac_dma_ops::init_chan() callback
> and have the ATDS flag set/cleared for each channel in there. Having
> the atds-flag in the stmmac_dma_cfg structure will make the parameter
> accessible from stmmac_dma_ops::init_chan() callback too."
>
> Other than that the change looks good. Thanks.
>
> Reviewed-by: Serge Semin<fancer.lancer@gmail.com>

Ok, I'll pick them up, thanks for your comment.


Thanks,

Yanteng

Re: [PATCH net-next v12 07/15] net: stmmac: dwmac-loongson: Add ref and ptp clocks for Loongson

[Yanteng Si]

在 2024/5/4 02:21, Serge Semin 写道:
>> [PATCH net-next v12 07/15] net: stmmac: dwmac-loongson: Add ref and ptp clocks for Loongson
> s/ptp/PTP
>
> Mentioning Loongson is redundant. Just:
>
> net: stmmac: dwmac-loongson: Init ref and PTP clocks rate
OK.
>> The ref/ptp clock of gmac(amd gnet) is 125000000.
> What about a log like this?
>
> "Reference and PTP clocks rate of the Loongson GMAC devices is 125MHz.
> (So is in the GNET devices which support is about to be added.) Set
> the respective plat_stmmacenet_data field up in accordance with that
> so to have the coalesce command and timestamping work correctly."

Great!


Thanks,

Yanteng

Re: [PATCH net-next v12 02/15] net: stmmac: Add multi-channel support

[Yanteng Si]

Hi Serge

在 2024/5/3 06:02, Serge Semin 写道:
> On Thu, Apr 25, 2024 at 09:01:55PM +0800, Yanteng Si wrote:
>> DW GMAC v3.x multi-channels feature is implemented as multiple
>> sets of the same CSRs. Here is only preliminary support, it will
>> be useful for the driver further evolution and for the users
>> having multi-channel DWGMAC v3.x devices.
> Why do you call it "preliminary"? AFAICS it's a fully functional
> support with no restrictions. Am I wrong?
>
> I would reformulate the commit message as:
>
> "DW GMAC v3.73 can be equipped with the Audio Video (AV) feature which
> enables transmission of time-sensitive traffic over bridged local area
> networks (DWC Ethernet QoS Product). In that case there can be up to two
> additional DMA-channels available with no Tx COE support (unless there is
> vendor-specific IP-core alterations). Each channel is implemented as a
> separate Control and Status register (CSR) for managing the transmit and
> receive functions, descriptor handling, and interrupt handling.
>
> Add the multi-channels DW GMAC controllers support just by making sure the
> already implemented DMA-configs are performed on the per-channel basis.
>
> Note the only currently known instance of the multi-channel DW GMAC
> IP-core is the LS2K2000 GNET controller, which has been released with the
> vendor-specific feature extension of having eight DMA-channels. The device
> support will be added in one of the following up commits."
OK.
>
>
>> @@ -153,7 +155,7 @@ static void dwmac1000_dma_operation_mode_rx(struct stmmac_priv *priv,
>>   					    void __iomem *ioaddr, int mode,
>>   					    u32 channel, int fifosz, u8 qmode)
>>   {
>> -	u32 csr6 = readl(ioaddr + DMA_CONTROL);
>> +	u32 csr6 = readl(ioaddr + DMA_CHAN_CONTROL(channel));
>>   
>>   	if (mode == SF_DMA_MODE) {
>>   		pr_debug("GMAC: enable RX store and forward mode\n");
>> @@ -175,14 +177,14 @@ static void dwmac1000_dma_operation_mode_rx(struct stmmac_priv *priv,
>>   	/* Configure flow control based on rx fifo size */
>>   	csr6 = dwmac1000_configure_fc(csr6, fifosz);
>>   
>> -	writel(csr6, ioaddr + DMA_CONTROL);
>> +	writel(csr6, ioaddr + DMA_CHAN_CONTROL(channel));
>>   }
>>   
>>   static void dwmac1000_dma_operation_mode_tx(struct stmmac_priv *priv,
>>   					    void __iomem *ioaddr, int mode,
>>   					    u32 channel, int fifosz, u8 qmode)
>>   {
>> -	u32 csr6 = readl(ioaddr + DMA_CONTROL);
>> +	u32 csr6 = readl(ioaddr + DMA_CHAN_CONTROL(channel));
>>   
>>   	if (mode == SF_DMA_MODE) {
>>   		pr_debug("GMAC: enable TX store and forward mode\n");
>> @@ -209,7 +211,7 @@ static void dwmac1000_dma_operation_mode_tx(struct stmmac_priv *priv,
>>   			csr6 |= DMA_CONTROL_TTC_256;
>>   	}
>>   
>> -	writel(csr6, ioaddr + DMA_CONTROL);
>> +	writel(csr6, ioaddr + DMA_CHAN_CONTROL(channel));
>>   }
>>   
> Just figured out that besides of the channel-related changes you also need
> to have the stmmac_dma_operation_mode() method fixed. So one wouldn't
> redistribute the detected Tx/Rx FIFO between the channels. Each DW GMAC
> channel has separate FIFO of the same size. The databook explicitly says
> about that:
>
> "The Tx FIFO size of all selected Transmit channels is always same.
> Similarly, the Rx FIFO size of all selected Receive channels is same.
> These channels cannot be of different sizes."
>
Should I do this, right?

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 33d04243b4d8..9d4148daee68 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2371,8 +2371,13 @@ static void stmmac_dma_operation_mode(struct 
stmmac_priv *priv)
                 txfifosz = priv->dma_cap.tx_fifo_size;

         /* Adjust for real per queue fifo size */
-       rxfifosz /= rx_channels_count;
-       txfifosz /= tx_channels_count;
+       if ((priv->synopsys_id != DWMAC_CORE_3_40) ||
+           (priv->synopsys_id != DWMAC_CORE_3_50) ||
+           (priv->synopsys_id != DWMAC_CORE_3_70)) {
+               rxfifosz /= rx_channels_count;
+               txfifosz /= tx_channels_count;
+       }
+

         if (priv->plat->force_thresh_dma_mode) {
                 txmode = tc;


Thanks,

Yanteng

Re: [PATCH net-next v12 02/15] net: stmmac: Add multi-channel support

[Serge Semin]

On Fri, May 10, 2024 at 06:13:40PM +0800, Yanteng Si wrote:
> Hi Serge
> 
> 在 2024/5/3 06:02, Serge Semin 写道:
> > On Thu, Apr 25, 2024 at 09:01:55PM +0800, Yanteng Si wrote:
> > > DW GMAC v3.x multi-channels feature is implemented as multiple
> > > sets of the same CSRs. Here is only preliminary support, it will
> > > be useful for the driver further evolution and for the users
> > > having multi-channel DWGMAC v3.x devices.
> > Why do you call it "preliminary"? AFAICS it's a fully functional
> > support with no restrictions. Am I wrong?
> > 
> > I would reformulate the commit message as:
> > 
> > "DW GMAC v3.73 can be equipped with the Audio Video (AV) feature which
> > enables transmission of time-sensitive traffic over bridged local area
> > networks (DWC Ethernet QoS Product). In that case there can be up to two
> > additional DMA-channels available with no Tx COE support (unless there is
> > vendor-specific IP-core alterations). Each channel is implemented as a
> > separate Control and Status register (CSR) for managing the transmit and
> > receive functions, descriptor handling, and interrupt handling.
> > 
> > Add the multi-channels DW GMAC controllers support just by making sure the
> > already implemented DMA-configs are performed on the per-channel basis.
> > 
> > Note the only currently known instance of the multi-channel DW GMAC
> > IP-core is the LS2K2000 GNET controller, which has been released with the
> > vendor-specific feature extension of having eight DMA-channels. The device
> > support will be added in one of the following up commits."
> OK.
> > 
> > 
> > > @@ -153,7 +155,7 @@ static void dwmac1000_dma_operation_mode_rx(struct stmmac_priv *priv,
> > >   					    void __iomem *ioaddr, int mode,
> > >   					    u32 channel, int fifosz, u8 qmode)
> > >   {
> > > -	u32 csr6 = readl(ioaddr + DMA_CONTROL);
> > > +	u32 csr6 = readl(ioaddr + DMA_CHAN_CONTROL(channel));
> > >   	if (mode == SF_DMA_MODE) {
> > >   		pr_debug("GMAC: enable RX store and forward mode\n");
> > > @@ -175,14 +177,14 @@ static void dwmac1000_dma_operation_mode_rx(struct stmmac_priv *priv,
> > >   	/* Configure flow control based on rx fifo size */
> > >   	csr6 = dwmac1000_configure_fc(csr6, fifosz);
> > > -	writel(csr6, ioaddr + DMA_CONTROL);
> > > +	writel(csr6, ioaddr + DMA_CHAN_CONTROL(channel));
> > >   }
> > >   static void dwmac1000_dma_operation_mode_tx(struct stmmac_priv *priv,
> > >   					    void __iomem *ioaddr, int mode,
> > >   					    u32 channel, int fifosz, u8 qmode)
> > >   {
> > > -	u32 csr6 = readl(ioaddr + DMA_CONTROL);
> > > +	u32 csr6 = readl(ioaddr + DMA_CHAN_CONTROL(channel));
> > >   	if (mode == SF_DMA_MODE) {
> > >   		pr_debug("GMAC: enable TX store and forward mode\n");
> > > @@ -209,7 +211,7 @@ static void dwmac1000_dma_operation_mode_tx(struct stmmac_priv *priv,
> > >   			csr6 |= DMA_CONTROL_TTC_256;
> > >   	}
> > > -	writel(csr6, ioaddr + DMA_CONTROL);
> > > +	writel(csr6, ioaddr + DMA_CHAN_CONTROL(channel));
> > >   }
> > Just figured out that besides of the channel-related changes you also need
> > to have the stmmac_dma_operation_mode() method fixed. So one wouldn't
> > redistribute the detected Tx/Rx FIFO between the channels. Each DW GMAC
> > channel has separate FIFO of the same size. The databook explicitly says
> > about that:
> > 
> > "The Tx FIFO size of all selected Transmit channels is always same.
> > Similarly, the Rx FIFO size of all selected Receive channels is same.
> > These channels cannot be of different sizes."
> > 

> Should I do this, right?
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 33d04243b4d8..9d4148daee68 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2371,8 +2371,13 @@ static void stmmac_dma_operation_mode(struct
> stmmac_priv *priv)
>                 txfifosz = priv->dma_cap.tx_fifo_size;
> 
>         /* Adjust for real per queue fifo size */
> -       rxfifosz /= rx_channels_count;
> -       txfifosz /= tx_channels_count;
> +       if ((priv->synopsys_id != DWMAC_CORE_3_40) ||
> +           (priv->synopsys_id != DWMAC_CORE_3_50) ||
> +           (priv->synopsys_id != DWMAC_CORE_3_70)) {
> +               rxfifosz /= rx_channels_count;
> +               txfifosz /= tx_channels_count;
> +       }
> +
> 
>         if (priv->plat->force_thresh_dma_mode) {
>                 txmode = tc;

Seeing the shared FIFO memory is specific for the DW QoS Eth and DW
xGMAC IP-cores let's use the has_gmac4 and has_xgmac flags instead:

--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2371,8 +2371,13 @@ static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
 	if (txfifosz == 0)
 		txfifosz = priv->dma_cap.tx_fifo_size;
 
-	/* Adjust for real per queue fifo size */
-	rxfifosz /= rx_channels_count;
-	txfifosz /= tx_channels_count;
+	/* Split up the shared Tx/Rx FIFO memory on DW QoS Eth and DW XGMAC */
+	if (priv->plat->has_gmac4 || priv->plat->has_xgmac) {
+		rxfifosz /= rx_channels_count;
+		txfifosz /= tx_channels_count;
+	}
 
 	if (priv->plat->force_thresh_dma_mode) {
 		txmode = tc;

-Serge(y)
> 
> 
> Thanks,
> 
> Yanteng
> 

Re: [PATCH net-next v12 03/15] net: stmmac: Export dwmac1000_dma_ops

[Yanteng Si]

在 2024/5/3 18:27, Serge Semin 写道:
> On Thu, Apr 25, 2024 at 09:01:56PM +0800, Yanteng Si wrote:
>> The loongson gnet will call it in the future.
> More descriptive commit log:
>
> "Export the DW GMAC DMA-ops descriptor so one could be available in
> the low-level platform drivers. It will be utilized to override some
> callbacks in order to handle the LS2K2000 GNET device specifics. The
> GNET controller support is being added in one of the following up
> commits."
>
> Other than that the change looks good. Thanks.
>
> Reviewed-by: Serge Semin<fancer.lancer@gmail.com>

OK, Thanks!


Thanks,

Yanteng

Re: [PATCH net-next v12 04/15] net: stmmac: dwmac-loongson: Drop useless platform data

[Yanteng Si]

在 2024/5/3 18:55, Serge Semin 写道:
> On Thu, Apr 25, 2024 at 09:04:35PM +0800, Yanteng Si wrote:
>> The multicast_filter_bins is initialized twice, it should
>> be 256, let's drop the first useless assignment.
> Please drop the second plat_stmmacenet_data::multicast_filter_bins
> init statement and just change the first one to initializing the
> correct value - 256. Thus you'll have
> 1. the multicast and unicast filters size inits done in the same place;
> 2. the in-situ comments preserved (it's not like they're that much
> helpful, but seeing the rest of the lines have a comment above it
> would be nice to have the comment preserved here too);
> 3. dropped the statement closely attached to the return statement
> (in kernel it's a widespread practice to separate the return
> statement with an empty line).
>
> The unit 1. is the main reason of course.
>
> A bit more readable commit log would be:
>
> "The plat_stmmacenet_data::multicast_filter_bins  field is twice
> initialized in the loongson_default_data() method. Drop the redundant
> initialization, but for the readability sake keep the filters init
> statements defined in the same place of the method."

OK!


Thanks,

Yanteng

Re: [PATCH net-next v12 04/15] net: stmmac: dwmac-loongson: Drop useless platform data

[Yanteng Si]

在 2024/5/3 22:47, Serge Semin 写道:
> On Fri, May 03, 2024 at 01:55:38PM +0300, Serge Semin wrote:
>> On Thu, Apr 25, 2024 at 09:04:35PM +0800, Yanteng Si wrote:
>>> The multicast_filter_bins is initialized twice, it should
>>> be 256, let's drop the first useless assignment.
>> Please drop the second plat_stmmacenet_data::multicast_filter_bins
>> init statement and just change the first one to initializing the
>> correct value - 256. Thus you'll have
>> 1. the multicast and unicast filters size inits done in the same place;
>> 2. the in-situ comments preserved (it's not like they're that much
>> helpful, but seeing the rest of the lines have a comment above it
>> would be nice to have the comment preserved here too);
>> 3. dropped the statement closely attached to the return statement
>> (in kernel it's a widespread practice to separate the return
>> statement with an empty line).
>>
>> The unit 1. is the main reason of course.
>>
>> A bit more readable commit log would be:
>>
>> "The plat_stmmacenet_data::multicast_filter_bins  field is twice
>> initialized in the loongson_default_data() method. Drop the redundant
>> initialization, but for the readability sake keep the filters init
>> statements defined in the same place of the method."
> [PATCH net-next v12 04/15] net: stmmac: dwmac-loongson: Drop useless platform data
>
> The patch subject is too generic. Just make it:
>
> [PATCH net-next v12 04/15] net: stmmac: dwmac-loongson: Drop duplicated hash-based filter size init

OK, Thanks!


Thanks,

Yanteng

Re: [PATCH net-next v12 02/15] net: stmmac: Add multi-channel support

[Yanteng Si]

在 2024/5/13 17:45, Serge Semin 写道:
> On Fri, May 10, 2024 at 06:13:40PM +0800, Yanteng Si wrote:
>> Hi Serge
>>
>> 在 2024/5/3 06:02, Serge Semin 写道:
>>> On Thu, Apr 25, 2024 at 09:01:55PM +0800, Yanteng Si wrote:
>>>> DW GMAC v3.x multi-channels feature is implemented as multiple
>>>> sets of the same CSRs. Here is only preliminary support, it will
>>>> be useful for the driver further evolution and for the users
>>>> having multi-channel DWGMAC v3.x devices.
>>> Why do you call it "preliminary"? AFAICS it's a fully functional
>>> support with no restrictions. Am I wrong?
>>>
>>> I would reformulate the commit message as:
>>>
>>> "DW GMAC v3.73 can be equipped with the Audio Video (AV) feature which
>>> enables transmission of time-sensitive traffic over bridged local area
>>> networks (DWC Ethernet QoS Product). In that case there can be up to two
>>> additional DMA-channels available with no Tx COE support (unless there is
>>> vendor-specific IP-core alterations). Each channel is implemented as a
>>> separate Control and Status register (CSR) for managing the transmit and
>>> receive functions, descriptor handling, and interrupt handling.
>>>
>>> Add the multi-channels DW GMAC controllers support just by making sure the
>>> already implemented DMA-configs are performed on the per-channel basis.
>>>
>>> Note the only currently known instance of the multi-channel DW GMAC
>>> IP-core is the LS2K2000 GNET controller, which has been released with the
>>> vendor-specific feature extension of having eight DMA-channels. The device
>>> support will be added in one of the following up commits."
>> OK.
>>>> @@ -153,7 +155,7 @@ static void dwmac1000_dma_operation_mode_rx(struct stmmac_priv *priv,
>>>>    					    void __iomem *ioaddr, int mode,
>>>>    					    u32 channel, int fifosz, u8 qmode)
>>>>    {
>>>> -	u32 csr6 = readl(ioaddr + DMA_CONTROL);
>>>> +	u32 csr6 = readl(ioaddr + DMA_CHAN_CONTROL(channel));
>>>>    	if (mode == SF_DMA_MODE) {
>>>>    		pr_debug("GMAC: enable RX store and forward mode\n");
>>>> @@ -175,14 +177,14 @@ static void dwmac1000_dma_operation_mode_rx(struct stmmac_priv *priv,
>>>>    	/* Configure flow control based on rx fifo size */
>>>>    	csr6 = dwmac1000_configure_fc(csr6, fifosz);
>>>> -	writel(csr6, ioaddr + DMA_CONTROL);
>>>> +	writel(csr6, ioaddr + DMA_CHAN_CONTROL(channel));
>>>>    }
>>>>    static void dwmac1000_dma_operation_mode_tx(struct stmmac_priv *priv,
>>>>    					    void __iomem *ioaddr, int mode,
>>>>    					    u32 channel, int fifosz, u8 qmode)
>>>>    {
>>>> -	u32 csr6 = readl(ioaddr + DMA_CONTROL);
>>>> +	u32 csr6 = readl(ioaddr + DMA_CHAN_CONTROL(channel));
>>>>    	if (mode == SF_DMA_MODE) {
>>>>    		pr_debug("GMAC: enable TX store and forward mode\n");
>>>> @@ -209,7 +211,7 @@ static void dwmac1000_dma_operation_mode_tx(struct stmmac_priv *priv,
>>>>    			csr6 |= DMA_CONTROL_TTC_256;
>>>>    	}
>>>> -	writel(csr6, ioaddr + DMA_CONTROL);
>>>> +	writel(csr6, ioaddr + DMA_CHAN_CONTROL(channel));
>>>>    }
>>> Just figured out that besides of the channel-related changes you also need
>>> to have the stmmac_dma_operation_mode() method fixed. So one wouldn't
>>> redistribute the detected Tx/Rx FIFO between the channels. Each DW GMAC
>>> channel has separate FIFO of the same size. The databook explicitly says
>>> about that:
>>>
>>> "The Tx FIFO size of all selected Transmit channels is always same.
>>> Similarly, the Rx FIFO size of all selected Receive channels is same.
>>> These channels cannot be of different sizes."
>>>
>> Should I do this, right?
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 33d04243b4d8..9d4148daee68 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -2371,8 +2371,13 @@ static void stmmac_dma_operation_mode(struct
>> stmmac_priv *priv)
>>                  txfifosz = priv->dma_cap.tx_fifo_size;
>>
>>          /* Adjust for real per queue fifo size */
>> -       rxfifosz /= rx_channels_count;
>> -       txfifosz /= tx_channels_count;
>> +       if ((priv->synopsys_id != DWMAC_CORE_3_40) ||
>> +           (priv->synopsys_id != DWMAC_CORE_3_50) ||
>> +           (priv->synopsys_id != DWMAC_CORE_3_70)) {
>> +               rxfifosz /= rx_channels_count;
>> +               txfifosz /= tx_channels_count;
>> +       }
>> +
>>
>>          if (priv->plat->force_thresh_dma_mode) {
>>                  txmode = tc;
> Seeing the shared FIFO memory is specific for the DW QoS Eth and DW
> xGMAC IP-cores let's use the has_gmac4 and has_xgmac flags instead:
>
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2371,8 +2371,13 @@ static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
>   	if (txfifosz == 0)
>   		txfifosz = priv->dma_cap.tx_fifo_size;
>   
> -	/* Adjust for real per queue fifo size */
> -	rxfifosz /= rx_channels_count;
> -	txfifosz /= tx_channels_count;
> +	/* Split up the shared Tx/Rx FIFO memory on DW QoS Eth and DW XGMAC */
> +	if (priv->plat->has_gmac4 || priv->plat->has_xgmac) {
> +		rxfifosz /= rx_channels_count;
> +		txfifosz /= tx_channels_count;
> +	}
>   
>   	if (priv->plat->force_thresh_dma_mode) {
>   		txmode = tc;

OK.


Thanks,

Yanteng

Re: [PATCH net-next v12 05/15] net: stmmac: dwmac-loongson: Use PCI_DEVICE_DATA() macro for device identification

[Yanteng Si]

在 2024/5/3 21:43, Serge Semin 写道:
> On Thu, Apr 25, 2024 at 09:04:36PM +0800, Yanteng Si wrote:
>> Just use PCI_DEVICE_DATA() macro for device identification,
>> No changes to function functionality.
> Some more verbose commit log:
>
> "For the readability sake convert the hard-coded Loongson GMAC PCI ID to
> the respective macro and use the PCI_DEVICE_DATA() macro-function to
> create the pci_device_id array entry. The later change will be
> specifically useful in order to assign the device-specific data for the
> currently supported device and for about to be added Loongson GNET
> controller."
>
> Other than that the change looks good:
>
> Reviewed-by: Serge Semin<fancer.lancer@gmail.com>

OK, Thanks!


Thanks,

Yanteng

Re: [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy

[Yanteng Si]

在 2024/5/5 05:28, Serge Semin 写道:
> On Thu, Apr 25, 2024 at 09:10:36PM +0800, Yanteng Si wrote:
>> Move res._irq to loongson_dwmac_config_legacy().
>> No function changes.
> Since the code affected by this patch has just been touched by the
> previous patch
> [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> just merge this patch content into there. But add a note to the
> commit message of that patch like this:
>
> "While at it move the IRQ initialization procedure into a dedicated
> method. It will be useful in one of the subsequent commit adding the
> Loongson GNET device support."
OK.
>
>> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
>> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
>> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
>> ---
>>   .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 56 +++++++++++--------
>>   1 file changed, 34 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> index 1022bceaa680..df5899bec91a 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> @@ -68,6 +68,38 @@ static struct stmmac_pci_info loongson_gmac_pci_info = {
>>   	.setup = loongson_gmac_data,
>>   };
>>   
>> +static int loongson_dwmac_config_legacy(struct pci_dev *pdev,
>> +					struct plat_stmmacenet_data *plat,
>> +					struct stmmac_resources *res,
>> +					struct device_node *np)
>> +{
>> +	if (np) {
>> +		res->irq = of_irq_get_byname(np, "macirq");
>> +		if (res->irq < 0) {
>> +			dev_err(&pdev->dev, "IRQ macirq not found\n");
>> +			return -ENODEV;
>> +		}
>> +
>> +		res->wol_irq = of_irq_get_byname(np, "eth_wake_irq");
>> +		if (res->wol_irq < 0) {
>> +			dev_info(&pdev->dev,
>> +				 "IRQ eth_wake_irq not found, using macirq\n");
>> +			res->wol_irq = res->irq;
>> +		}
>> +
>> +		res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
>> +		if (res->lpi_irq < 0) {
>> +			dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
>> +			return -ENODEV;
>> +		}
>> +	} else {
>> +		res->irq = pdev->irq;
>> +		res->wol_irq = res->irq;
> Once again - drop this, unless you can justify it's required.
OK.
>
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>   static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>>   {
>>   	struct plat_stmmacenet_data *plat;
>> @@ -136,28 +168,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   			goto err_disable_device;
>>   		}
>>   		plat->phy_interface = phy_mode;
>> -
>> -		res.irq = of_irq_get_byname(np, "macirq");
>> -		if (res.irq < 0) {
>> -			dev_err(&pdev->dev, "IRQ macirq not found\n");
>> -			ret = -ENODEV;
>> -			goto err_disable_msi;
>> -		}
>> -
>> -		res.wol_irq = of_irq_get_byname(np, "eth_wake_irq");
>> -		if (res.wol_irq < 0) {
>> -			dev_info(&pdev->dev, "IRQ eth_wake_irq not found, using macirq\n");
>> -			res.wol_irq = res.irq;
>> -		}
>> -
>> -		res.lpi_irq = of_irq_get_byname(np, "eth_lpi");
>> -		if (res.lpi_irq < 0) {
>> -			dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
>> -			ret = -ENODEV;
>> -			goto err_disable_msi;
>> -		}
>> -	} else {
>> -		res.irq = pdev->irq;
>>   	}
>>   
>>   	pci_enable_msi(pdev);
>> @@ -167,6 +177,8 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   	plat->tx_queues_to_use = 1;
>>   	plat->rx_queues_to_use = 1;
>>   
>> +	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
>> +
> By not checking the return value the patch turns to in fact containing
> the functional change, which contradicts to what you say in the commit
> log. Besides it's just wrong in this case. So please add the return
> value check.

OK.


Thanks,

Yanteng

Re: [PATCH net-next v12 12/15] net: stmmac: dwmac-loongson: Fixed failure to set network speed to 1000.

[Yanteng Si]

在 2024/5/5 06:13, Serge Semin 写道:
> On Thu, Apr 25, 2024 at 09:10:37PM +0800, Yanteng Si wrote:
>> GNET devices with dev revision 0x00 do not support manually
>> setting the speed to 1000.
>>
>> Signed-off-by: Feiyang Chen<chenfeiyang@loongson.cn>
>> Signed-off-by: Yinggang Gu<guyinggang@loongson.cn>
>> Signed-off-by: Yanteng Si<siyanteng@loongson.cn>
>> ---
>>   drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 8 ++++++++
>>   drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 6 ++++++
>>   include/linux/stmmac.h                               | 1 +
>>   3 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> index df5899bec91a..a16bba389417 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> @@ -10,6 +10,7 @@
>>   #include "stmmac.h"
>>   
>>   #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
>> +#define PCI_DEVICE_ID_LOONGSON_GNET	0x7a13
>>   
>>   struct stmmac_pci_info {
>>   	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
>> @@ -179,6 +180,13 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   
>>   	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
>>   
>> +	/* GNET devices with dev revision 0x00 do not support manually
>> +	 * setting the speed to 1000.
>> +	 */
>> +	if (pdev->device == PCI_DEVICE_ID_LOONGSON_GNET &&
>> +	    pdev->revision == 0x00)
>> +		plat->flags |= STMMAC_FLAG_DISABLE_FORCE_1000;
>> +
> That's why it's important to wait for the discussions being finished.
> If you waited for some time I would have told you that the only part
> what was required to move to the separate patch was the changes in the
> files:
> drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> include/linux/stmmac.h
>
> So please move the changes above to the patch
> [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
> * with the flag setup being done in the loongson_gnet_data() method.
>
> Thus you'll be able to drop the patch 14
> [PATCH net-next v12 14/15] net: stmmac: dwmac-loongson: Move disable_force flag to _gnet_date

OK.


Thanks,

Yanteng

Re: [PATCH net-next v12 14/15] net: stmmac: dwmac-loongson: Move disable_force flag to _gnet_date

[Yanteng Si]

在 2024/5/6 05:53, Serge Semin 写道:
> On Thu, Apr 25, 2024 at 09:11:37PM +0800, Yanteng Si wrote:
>> We've already introduced loongson_gnet_data(), so the
>> STMMAC_FLAG_DISABLE_FORCE_1000 should be take away from
>> loongson_dwmac_probe().
>>
>> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
>> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
>> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
>> ---
>>   .../net/ethernet/stmicro/stmmac/dwmac-loongson.c    | 13 ++++++-------
>>   1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> index 68de90c44feb..dea02de030e6 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> @@ -286,6 +286,12 @@ static int loongson_gnet_data(struct pci_dev *pdev,
>>   	plat->mdio_bus_data->phy_mask = ~(u32)BIT(2);
>>   	plat->fix_mac_speed = loongson_gnet_fix_speed;
>>   
>> +	/* GNET devices with dev revision 0x00 do not support manually
>> +	 * setting the speed to 1000.
>> +	 */
>> +	if (pdev->revision == 0x00)
>> +		plat->flags |= STMMAC_FLAG_DISABLE_FORCE_1000;
>> +
> Just introduce the change above in the framework of the patch
> [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
> and ...
OK.
>
>>   	return 0;
>>   }
>>   
>> @@ -540,13 +546,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   		break;
>>   	}
>>   
>> -	/* GNET devices with dev revision 0x00 do not support manually
>> -	 * setting the speed to 1000.
>> -	 */
>> -	if (pdev->device == PCI_DEVICE_ID_LOONGSON_GNET &&
>> -	    pdev->revision == 0x00)
>> -		plat->flags |= STMMAC_FLAG_DISABLE_FORCE_1000;
>> -
> ... you won't to have this being undone. So this patch won't be even
> needed to be introduced.
>
> See my comment sent to
> [PATCH net-next v12 12/15] net: stmmac: dwmac-loongson: Fixed failure to set network speed to 1000.
>
OK.


Thanks,

Yanteng

Re: [PATCH net-next v12 08/15] net: stmmac: dwmac-loongson: Add phy mask for Loongson GMAC

[Yanteng Si]

在 2024/5/4 02:28, Serge Semin 写道:
> On Thu, Apr 25, 2024 at 09:06:11PM +0800, Yanteng Si wrote:
>> The phy mask of gmac(and gnet) is 0.
> First of all the GNET PHY mask won't be zero as you setting it up to
> ~BIT(2) in the patch 13 yourself. Secondly the stmmac_mdio_bus_data
> structure instance is Z-malloced, thus it will be zeroed anyway. So
> the only reason why the explicit stmmac_mdio_bus_data::phy_mask
> zeroing would be useful is to signify the difference between the GMAC
> and GNET devices. But that difference could be relatively easy
> inferred from the code. So to speak IMO the patch has a little value.
> I would drop it.

OK, drop it.


Thanks,

Yanteng

Re: [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support

[Yanteng Si]

在 2024/5/5 04:46, Serge Semin 写道:
>> [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> I would have changed the subject to:
>
> net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support
OK.
>
> On Thu, Apr 25, 2024 at 09:10:35PM +0800, Yanteng Si wrote:
>> Current dwmac-loongson only support LS2K in the "probed with PCI and
>> configured with DT" manner. Add LS7A support on which the devices are
>> fully PCI (non-DT).
>>
>> Others:
>> LS2K is a SoC and LS7A is a bridge chip.
> The text seems like misleading or just wrong. I see both of these
> platforms having the GMAC defined in the DT source:
>
> arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
> arch/mips/boot/dts/loongson/ls7a-pch.dtsi
>
> What do I miss in your description?
You are right.
>
> If nothing has been missed and it's just wrong I suggest to convert
> the commit log to something like this:
>
> "The Loongson GMAC driver currently supports the network controllers
> installed on the LS2K1000 SoC and LS7A1000 chipset, for which the GMAC
> devices are required to be defined in the platform device tree source.
> Let's extend the driver functionality with the case of having the
> Loongson GMAC probed on the PCI bus with no device tree node defined
> for it. That requires to make the device DT-node optional, to rely on
> the IRQ line detected by the PCI core and to have the MDIO bus ID
> calculated using the PCIe Domain+BDF numbers."

OK, Thanks!

>
>> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
>> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
>> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
>> ---
>>   .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 113 ++++++++++--------
>>   1 file changed, 65 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> index e989cb835340..1022bceaa680 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> @@ -11,8 +11,17 @@
>>   
>>   #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
>>   
>> -static void loongson_default_data(struct plat_stmmacenet_data *plat)
>> +struct stmmac_pci_info {
>> +	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
>> +};
> Please move this and the rest of the setup-callback introduction
> change into a separate patch. It' subject could be something like
> this:
> net: stmmac: dwmac-loongson: Introduce PCI device info data
OK.
>
>> +
>> +static void loongson_default_data(struct pci_dev *pdev,
>> +				  struct plat_stmmacenet_data *plat)
>>   {
>> +	/* Get bus_id, this can be overloaded later */
> s/overloaded/overwritten
OK
>
>> +	plat->bus_id = (pci_domain_nr(pdev->bus) << 16) |
>> +			PCI_DEVID(pdev->bus->number, pdev->devfn);
> Em, so you removed the code from the probe() function:
> -     plat->bus_id = of_alias_get_id(np, "ethernet");
> -     if (plat->bus_id < 0)
> -             plat->bus_id = pci_dev_id(pdev);
> and instead of using the pci_dev_id() method here just opencoded it'
> content. Nice. Why not to use pci_dev_id() instead of PCI_DEVID()?
OK, I will try it!
>
>> +
>>   	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
>>   	plat->has_gmac = 1;
>>   	plat->force_sf_dma_mode = 1;
>> @@ -44,9 +53,10 @@ static void loongson_default_data(struct plat_stmmacenet_data *plat)
>>   	plat->multicast_filter_bins = 256;
>>   }
>>   
>> -static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
>> +static int loongson_gmac_data(struct pci_dev *pdev,
>> +			      struct plat_stmmacenet_data *plat)
>>   {
>> -	loongson_default_data(plat);
>> +	loongson_default_data(pdev, plat);
>>   
>>   	plat->mdio_bus_data->phy_mask = 0;
>>   	plat->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
>> @@ -54,20 +64,20 @@ static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
>>   	return 0;
>>   }
>>   
>> +static struct stmmac_pci_info loongson_gmac_pci_info = {
>> +	.setup = loongson_gmac_data,
>> +};
>> +
> To the separate patch please.
OK.
>
>>   static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>>   {
>>   	struct plat_stmmacenet_data *plat;
>> +	int ret, i, bus_id, phy_mode;
>> +	struct stmmac_pci_info *info;
>>   	struct stmmac_resources res;
>>   	struct device_node *np;
>> -	int ret, i, phy_mode;
> You can drop the bus_id and phy_mode variables, and use ret in the
> respective statements instead.
OK, I will try it.
>
>>   
>>   	np = dev_of_node(&pdev->dev);
>>   
>> -	if (!np) {
>> -		pr_info("dwmac_loongson_pci: No OF node\n");
>> -		return -ENODEV;
>> -	}
>> -
>>   	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
>>   	if (!plat)
>>   		return -ENOMEM;
>> @@ -78,12 +88,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   	if (!plat->mdio_bus_data)
>>   		return -ENOMEM;
>>   
>> -	plat->mdio_node = of_get_child_by_name(np, "mdio");
>> -	if (plat->mdio_node) {
>> -		dev_info(&pdev->dev, "Found MDIO subnode\n");
>> -		plat->mdio_bus_data->needs_reset = true;
>> -	}
>> -
>>   	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
>>   	if (!plat->dma_cfg) {
>>   		ret = -ENOMEM;
>> @@ -107,46 +111,59 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   		break;
>>   	}
>>   
>> -	plat->bus_id = of_alias_get_id(np, "ethernet");
>> -	if (plat->bus_id < 0)
>> -		plat->bus_id = pci_dev_id(pdev);
>> +	pci_set_master(pdev);
>>   
>> -	phy_mode = device_get_phy_mode(&pdev->dev);
>> -	if (phy_mode < 0) {
>> -		dev_err(&pdev->dev, "phy_mode not found\n");
>> -		ret = phy_mode;
>> +	info = (struct stmmac_pci_info *)id->driver_data;
>> +	ret = info->setup(pdev, plat);
>> +	if (ret)
>>   		goto err_disable_device;
> To the separate patch please.
OK.
>
>> -	}
>>   
>> -	plat->phy_interface = phy_mode;
>> -
>> -	pci_set_master(pdev);
>> +	if (np) {
>> +		plat->mdio_node = of_get_child_by_name(np, "mdio");
>> +		if (plat->mdio_node) {
>> +			dev_info(&pdev->dev, "Found MDIO subnode\n");
>> +			plat->mdio_bus_data->needs_reset = true;
>> +		}
>> +
>> +		bus_id = of_alias_get_id(np, "ethernet");
>> +		if (bus_id >= 0)
>> +			plat->bus_id = bus_id;
> 		ret = of_alias_get_id(np, "ethernet");
> 		if (ret >= 0)
> 			plat->bus_id = ret;
>
>> +
>> +		phy_mode = device_get_phy_mode(&pdev->dev);
>> +		if (phy_mode < 0) {
>> +			dev_err(&pdev->dev, "phy_mode not found\n");
>> +			ret = phy_mode;
>> +			goto err_disable_device;
>> +		}
>> +		plat->phy_interface = phy_mode;
> 		ret = device_get_phy_mode(&pdev->dev);
> 		if (ret < 0) {
> 			dev_err(&pdev->dev, "phy_mode not found\n");
> 			goto err_disable_device;
> 		}
> 		
> 		plat->phy_interface = ret;
>
> * note empty line between the if-clause and the last statement.
OK.
>
>> +
>> +		res.irq = of_irq_get_byname(np, "macirq");
>> +		if (res.irq < 0) {
>> +			dev_err(&pdev->dev, "IRQ macirq not found\n");
>> +			ret = -ENODEV;
>> +			goto err_disable_msi;
>> +		}
>> +
>> +		res.wol_irq = of_irq_get_byname(np, "eth_wake_irq");
>> +		if (res.wol_irq < 0) {
>> +			dev_info(&pdev->dev, "IRQ eth_wake_irq not found, using macirq\n");
>> +			res.wol_irq = res.irq;
>> +		}
>> +
>> +		res.lpi_irq = of_irq_get_byname(np, "eth_lpi");
>> +		if (res.lpi_irq < 0) {
>> +			dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
>> +			ret = -ENODEV;
>> +			goto err_disable_msi;
>> +		}
>> +	} else {
>> +		res.irq = pdev->irq;
>> +	}
>>   
>> -	loongson_gmac_data(plat);
> To the separate patch please.
OK.
>
>>   	pci_enable_msi(pdev);
>>   	memset(&res, 0, sizeof(res));
>>   	res.addr = pcim_iomap_table(pdev)[0];
>>   
>> -	res.irq = of_irq_get_byname(np, "macirq");
>> -	if (res.irq < 0) {
>> -		dev_err(&pdev->dev, "IRQ macirq not found\n");
>> -		ret = -ENODEV;
>> -		goto err_disable_msi;
>> -	}
>> -
>> -	res.wol_irq = of_irq_get_byname(np, "eth_wake_irq");
>> -	if (res.wol_irq < 0) {
>> -		dev_info(&pdev->dev, "IRQ eth_wake_irq not found, using macirq\n");
>> -		res.wol_irq = res.irq;
>> -	}
>> -
>> -	res.lpi_irq = of_irq_get_byname(np, "eth_lpi");
>> -	if (res.lpi_irq < 0) {
>> -		dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
>> -		ret = -ENODEV;
>> -		goto err_disable_msi;
>> -	}
>> -
>>   	plat->tx_queues_to_use = 1;
>>   	plat->rx_queues_to_use = 1;
>>   
>> @@ -224,7 +241,7 @@ static SIMPLE_DEV_PM_OPS(loongson_dwmac_pm_ops, loongson_dwmac_suspend,
>>   			 loongson_dwmac_resume);
>>   
>>   static const struct pci_device_id loongson_dwmac_id_table[] = {
>> -	{ PCI_DEVICE_DATA(LOONGSON, GMAC, NULL) },
>> +	{ PCI_DEVICE_DATA(LOONGSON, GMAC, &loongson_gmac_pci_info) },
> To the separate patch please.
OK.



Thanks,

Yanteng

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Serge Semin]

On Thu, May 09, 2024 at 04:57:44PM +0800, Yanteng Si wrote:
> Hi Serge
> 
> 在 2024/5/8 23:10, Serge Semin 写道:
> > On Wed, May 08, 2024 at 10:58:16PM +0800, Huacai Chen wrote:
> > > Hi, Serge,
> > > 
> > > On Wed, May 8, 2024 at 10:38 PM Serge Semin<fancer.lancer@gmail.com>  wrote:
> > > > On Tue, May 07, 2024 at 09:35:24PM +0800, Yanteng Si wrote:
> > > > > Hi Serge,
> > > > > 
> > > > > 在 2024/5/6 18:39, Serge Semin 写道:
> > > > > > On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
> > > > > > > ...
> > > > > > > +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
> > > > > > > +                              struct plat_stmmacenet_data *plat,
> > > > > > > +                              struct stmmac_resources *res,
> > > > > > > +                              struct device_node *np)
> > > > > > > +{
> > > > > > > + int i, ret, vecs;
> > > > > > > +
> > > > > > > + vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
> > > > > > > + ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
> > > > > > > + if (ret < 0) {
> > > > > > > +         dev_info(&pdev->dev,
> > > > > > > +                  "MSI enable failed, Fallback to legacy interrupt\n");
> > > > > > > +         return loongson_dwmac_config_legacy(pdev, plat, res, np);
> > > > > > > + }
> > > > > > > +
> > > > > > > + res->irq = pci_irq_vector(pdev, 0);
> > > > > > > + res->wol_irq = 0;
> > > > > > > +
> > > > > > > + /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> > > > > > > +  * --------- ----- -------- --------  ...  -------- --------
> > > > > > > +  * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> > > > > > > +  */
> > > > > > > + for (i = 0; i < CHANNEL_NUM; i++) {
> > > > > > > +         res->rx_irq[CHANNEL_NUM - 1 - i] =
> > > > > > > +                 pci_irq_vector(pdev, 1 + i * 2);
> > > > > > > +         res->tx_irq[CHANNEL_NUM - 1 - i] =
> > > > > > > +                 pci_irq_vector(pdev, 2 + i * 2);
> > > > > > > + }
> > > > > > > +
> > > > > > > + plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > ...
> > > > > > >    static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > > > > > >    {
> > > > > > >            struct plat_stmmacenet_data *plat;
> > > > > > >            int ret, i, bus_id, phy_mode;
> > > > > > >            struct stmmac_pci_info *info;
> > > > > > >            struct stmmac_resources res;
> > > > > > > + struct loongson_data *ld;
> > > > > > >            struct device_node *np;
> > > > > > >            np = dev_of_node(&pdev->dev);
> > > > > > > @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > > > > >                    return -ENOMEM;
> > > > > > >            plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> > > > > > > - if (!plat->dma_cfg) {
> > > > > > > -         ret = -ENOMEM;
> > > > > > > -         goto err_put_node;
> > > > > > > - }
> > > > > > > + if (!plat->dma_cfg)
> > > > > > > +         return -ENOMEM;
> > > > > > > +
> > > > > > > + ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
> > > > > > > + if (!ld)
> > > > > > > +         return -ENOMEM;
> > > > > > >            /* Enable pci device */
> > > > > > >            ret = pci_enable_device(pdev);
> > > > > > > @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > > > > >                    plat->phy_interface = phy_mode;
> > > > > > >            }
> > > > > > > - pci_enable_msi(pdev);
> > > > > > > + plat->bsp_priv = ld;
> > > > > > > + plat->setup = loongson_dwmac_setup;
> > > > > > > + ld->dev = &pdev->dev;
> > > > > > > +
> > > > > > >            memset(&res, 0, sizeof(res));
> > > > > > >            res.addr = pcim_iomap_table(pdev)[0];
> > > > > > > + ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
> > > > > > > +
> > > > > > > + switch (ld->gmac_verion) {
> > > > > > > + case LOONGSON_DWMAC_CORE_1_00:
> > > > > > > +         plat->rx_queues_to_use = CHANNEL_NUM;
> > > > > > > +         plat->tx_queues_to_use = CHANNEL_NUM;
> > > > > > > +
> > > > > > > +         /* Only channel 0 supports checksum,
> > > > > > > +          * so turn off checksum to enable multiple channels.
> > > > > > > +          */
> > > > > > > +         for (i = 1; i < CHANNEL_NUM; i++)
> > > > > > > +                 plat->tx_queues_cfg[i].coe_unsupported = 1;
> > > > > > > - plat->tx_queues_to_use = 1;
> > > > > > > - plat->rx_queues_to_use = 1;
> > > > > > > +         ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
> > > > > > > +         break;
> > > > > > > + default:        /* 0x35 device and 0x37 device. */
> > > > > > > +         plat->tx_queues_to_use = 1;
> > > > > > > +         plat->rx_queues_to_use = 1;
> > > > > > > - ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > > > > +         ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > > > > +         break;
> > > > > > > + }
> > > > > > Let's now talk about this change.
> > > > > > 
> > > > > > First of all, one more time. You can't miss the return value check
> > > > > > because if any of the IRQ config method fails then the driver won't
> > > > > > work! The first change that introduces the problem is in the patch
> > > > > > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > > OK!
> > > > > > Second, as I already mentioned in another message sent to this patch
> > > > > > you are missing the PCI MSI IRQs freeing in the cleanup-on-error path
> > > > > > and in the device/driver remove() function. It's definitely wrong.
> > > > > You are right! I will do it.
> > > > > > Thirdly, you said that the node-pointer is now optional and introduced
> > > > > > the patch
> > > > > > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > > > If so and the DT-based setting up isn't mandatory then I would
> > > > > > suggest to proceed with the entire so called legacy setups only if the
> > > > > > node-pointer has been found, otherwise the pure PCI-based setup would
> > > > > > be performed. So the patches 10-13 (in your v12 order) would look
> > > > > In this case, MSI will not be enabled when the node-pointer is found.
> > > > > 
> > > > > .
> > > > > 
> > > > > 
> > > > > In fact, a large fraction of 2k devices are DT-based, of course, many are
> > > > > PCI-based.
> > > > Then please summarise which devices need the DT-node pointer which
> > > > don't? And most importantly if they do why do they need the DT-node?
> > > Whether we need DT-nodes doesn't depend on device type, but depends on
> > > the BIOS type. When we boot with UEFI+ACPI, we don't need DT-node,
> > > when we boot with PMON+FDT, we need DT-node. Loongson machines may
> > > have either BIOS types.
> > Thanks for the answer. Just to fully clarify. Does it mean that all
> > Loongson Ethernet controllers (Loongson GNET and GMAC) are able to
> > deliver both PCI MSI IRQs and direct GIC IRQs (so called legacy)?
> 

> No, only devices that support multiple channels can deliver both PCI MSI
> IRQs
> 
> and direct GIC IRQs, other devices can only deliver GIC IRQs.
> 
> Furthermore, multiple channel features are bundled with MSI. If we want to
> 
> enable multiple channels, we must enable MSI.

Sadly to say but this information changes a lot. Based on that the
only platform with optional DT-node is the LS2K2000 GNET device. The
rest of the devices (GMACs and LS7A2000 GNET) must be equipped with a
node-pointer otherwise they won't work. Due to that the logic of the
patches
[PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
[PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
is incorrect.

1. [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
So this patch doesn't add a pure PCI-based probe procedure after all
because the Loongson GMACs are required to have a DT-node. AFAICS
pdev->irq is actually the IRQ retrieved from the DT-node. So the "if
(np) {} else {}" clause doesn't really make sense.

2. [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
First of all the function name is incorrect. The IRQ signal isn't legacy
(INTx-based), but is retrieved from the DT-node. Secondly the
"if (np) {} else {}" statement is very much redundant because if no
DT-node found the pdev->irq won't be initialized at all, and the
driver won't work with no error printed.

All of that also affects the patch/commit logs. Glad we figured that
out at this stage. Seeing there have been tons of another comments
let's postpone the discussion around this problem for v13 then. I'll
keep in mind the info you shared in this thread and think of the way
to fix the patches after v13 is submitted for review.

Thanks
-Serge(y)

> 
> Thanks,
> 
> Yanteng
> 

Re: [PATCH net-next v12 06/15] net: stmmac: dwmac-loongson: Split up the platform data initialization

[Yanteng Si]

在 2024/5/4 02:08, Serge Semin 写道:
>> [PATCH net-next v12 06/15] net: stmmac: dwmac-loongson: Split up the platform data initialization
> Please convert the subject to being more specific, like this:
>
> net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init
>
> On Thu, Apr 25, 2024 at 09:04:37PM +0800, Yanteng Si wrote:
>> Based on IP core classification, loongson has two types of network
> What is the real company name? At least start the name with the
> capital letter.
> * everywhere
OK,  LOONGSON
>
>> devices: GMAC and GNET. GMAC's ip_core id is 0x35/0x37, while GNET's
>> ip_core id is 0x37/0x10.
> s/ip_core/IP-core
>
> Once again the IP-core ID isn't _hex_, but a number of the format:
> "v+Major.Minor"
> so use the _real_ IP-core version number everywhere. Note mentioning
> that some of your GNET device has the GMAC_VERSION.SNPSVER hardwired
> to 0x10 is completely redundant in this and many other context. The
> only place where it's relevant is the patch(es) where you have the
> Snps ID override.
OK.
>
>> Device tables:
>>
>> device    type    pci_id    snps_id    channel
>> ls2k1000  gmac    7a03      0x35/0x37   1
>> ls7a1000  gmac    7a03      0x35/0x37   1
>> ls2k2000  gnet    7a13      0x10        8
>> ls7a2000  gnet    7a13      0x37        1
> s/gmac/GMAC
> s/gnet/GNET
> s/pci_id/PCI Dev ID
> s/snsp_id/Synopys Version
> s/channels/DMA-channels
> s/ls2k/LS2K
> s/ls7a/LS7A
>
> * everywhere
OK.
>
>> The GMAC device only has a MAC chip inside and needs an
>> external PHY chip;
>>
>> To later distinguish 8-channel gnet devices from single-channel
>> gnet/gmac devices, move rx_queues_to_use loongson_default_data
>> to loongson_dwmac_probe(). Also move mac_interface to
>> loongson_default_data().
> Again. This is only a part of the reason why you need this change.
> The main reason is to provide the two-leveled platform data init
> functions: fist one is the common method initializing the data common
> for both GMAC and GNET, second one is the device-specific data
> initializer.
>
> To sum up I would change the commit log to something like this:
>
> "Loongson delivers two types of the network devices: Loongson GMAC and
> Loongson GNET in the framework of four CPU/Chipsets revisions:
>
>     Chip             Network  PCI Dev ID   Synopys Version   DMA-channel
> LS2K1000 CPU         GMAC      0x7a03       v3.50a/v3.73a        1
> LS7A1000 Chipset     GMAC      0x7a03       v3.50a/v3.73a        1
> LS2K2000 CPU         GNET      0x7a13          v3.73a            8
> LS7A2000 Chipset     GNET      0x7a13          v3.73a            1
>
> The driver currently supports the chips with the Loongson GMAC network
> device. As a preparation before adding the Loongson GNET support
> detach the Loongson GMAC-specific platform data initializations to the
> loongson_gmac_data() method and preserve the common settings in the
> loongson_default_data().
>
> While at it drop the return value statement from the
> loongson_default_data() method as redundant."
OK, Thanks!
>
>> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
>> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
>> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
>> ---
>>   .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 20 ++++++++++++-------
>>   1 file changed, 13 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> index 4e0838db4259..904e288d0be0 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> @@ -11,22 +11,20 @@
>>   
>>   #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
>>   
>> -static int loongson_default_data(struct plat_stmmacenet_data *plat)
>> +static void loongson_default_data(struct plat_stmmacenet_data *plat)
>>   {
>>   	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
>>   	plat->has_gmac = 1;
>>   	plat->force_sf_dma_mode = 1;
>>   
>> +	plat->mac_interface = PHY_INTERFACE_MODE_GMII;
>> +
> I double-checked this part in my HW and in the databooks. DW GMAC with
> _RGMII_ PHY-interfaces can't be equipped with a PCS (STMMAC driver is
> wrong in considering otherwise at least in the Auto-negotiation part).
> PCS is only available for the RTI, RTBI and SGMII interfaces.
>
> You can double-check that by checking out the DMA_HW_FEATURE.PCSSEL
> flag state. I'll be surprised if it's set in your case. If it isn't
> then either drop the plat_stmmacenet_data::mac_interface
> initialization or (as Russell suggested) initialize it with
> PHY_INTERFACE_MODE_NA. But do that in a separate pre-requisite patch!
OK.
>
>>   	/* Set default value for unicast filter entries */
>>   	plat->unicast_filter_entries = 1;
>>   
>>   	/* Set the maxmtu to a default of JUMBO_LEN */
>>   	plat->maxmtu = JUMBO_LEN;
>>   
>> -	/* Set default number of RX and TX queues to use */
>> -	plat->tx_queues_to_use = 1;
>> -	plat->rx_queues_to_use = 1;
>> -
>>   	/* Disable Priority config by default */
>>   	plat->tx_queues_cfg[0].use_prio = false;
>>   	plat->rx_queues_cfg[0].use_prio = false;
>> @@ -41,6 +39,12 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>>   	plat->dma_cfg->pblx8 = true;
>>   
>>   	plat->multicast_filter_bins = 256;
>> +}
>> +
>> +static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
>> +{
>> +	loongson_default_data(plat);
>> +
>>   	return 0;
>>   }
>>   
>> @@ -109,11 +113,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   	}
>>   
>>   	plat->phy_interface = phy_mode;
>> -	plat->mac_interface = PHY_INTERFACE_MODE_GMII;
>>   
>>   	pci_set_master(pdev);
>>   
>> -	loongson_default_data(plat);
>> +	loongson_gmac_data(plat);
>>   	pci_enable_msi(pdev);
>>   	memset(&res, 0, sizeof(res));
>>   	res.addr = pcim_iomap_table(pdev)[0];
>> @@ -138,6 +141,9 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   		goto err_disable_msi;
>>   	}
>>   
>> +	plat->tx_queues_to_use = 1;
>> +	plat->rx_queues_to_use = 1;
>> +
> You can freely move this to loongson_gmac_data() method. And then, in
> the patch adding the GNET-support, you'll be able to provide these fields
> initialization in the loongson_gnet_data() method together with the
> plat->tx_queues_cfg[*].coe_unsupported flag init. Thus the probe()
> method will get to be smaller and easier to read, and the
> loongson_*_data() method will be more coherent.

As you said, at first glance, putting them in loongson_gnet_data() 
method is fine,

but in LS2K2000:

         plat->rx_queues_to_use = CHANNEL_NUM;    // CHANNEL_NUM = 8;
         plat->tx_queues_to_use = CHANNEL_NUM;

So we need to distinguish between them. At the same time, we have to 
distinguish

between LS2K2000 in probe() method. Why not put them inside probe, which 
will

save a lot of duplicate code, like this:

     struct stmmac_resources res;
     struct loongson_data *ld;

...

     memset(&res, 0, sizeof(res));
     res.addr = pcim_iomap_table(pdev)[0];
     ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;

     switch (ld->gmac_verion) {
     case LOONGSON_DWMAC_CORE_1_00:
         plat->rx_queues_to_use = CHANNEL_NUM;
         plat->tx_queues_to_use = CHANNEL_NUM;

         /* Only channel 0 supports checksum,
          * so turn off checksum to enable multiple channels.
          */
         for (i = 1; i < CHANNEL_NUM; i++)
             plat->tx_queues_cfg[i].coe_unsupported = 1;

         ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
         break;
     default:    /* 0x35 device and 0x37 device. */
         plat->tx_queues_to_use = 1;
         plat->rx_queues_to_use = 1;

         ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
         break;
     }
     if (ret)
         goto err_disable_device;


What do you think?


Of course, if you insist, I'm willing to repeat this in the

loongson_gnet_data() method.



Thanks,

Yanteng

Re: [PATCH net-next v12 06/15] net: stmmac: dwmac-loongson: Split up the platform data initialization

[Huacai Chen]

On Mon, May 13, 2024 at 7:07 PM Yanteng Si <siyanteng@loongson.cn> wrote:
>
>
> 在 2024/5/4 02:08, Serge Semin 写道:
> >> [PATCH net-next v12 06/15] net: stmmac: dwmac-loongson: Split up the platform data initialization
> > Please convert the subject to being more specific, like this:
> >
> > net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init
> >
> > On Thu, Apr 25, 2024 at 09:04:37PM +0800, Yanteng Si wrote:
> >> Based on IP core classification, loongson has two types of network
> > What is the real company name? At least start the name with the
> > capital letter.
> > * everywhere
> OK,  LOONGSON
> >
> >> devices: GMAC and GNET. GMAC's ip_core id is 0x35/0x37, while GNET's
> >> ip_core id is 0x37/0x10.
> > s/ip_core/IP-core
> >
> > Once again the IP-core ID isn't _hex_, but a number of the format:
> > "v+Major.Minor"
> > so use the _real_ IP-core version number everywhere. Note mentioning
> > that some of your GNET device has the GMAC_VERSION.SNPSVER hardwired
> > to 0x10 is completely redundant in this and many other context. The
> > only place where it's relevant is the patch(es) where you have the
> > Snps ID override.
> OK.
> >
> >> Device tables:
> >>
> >> device    type    pci_id    snps_id    channel
> >> ls2k1000  gmac    7a03      0x35/0x37   1
> >> ls7a1000  gmac    7a03      0x35/0x37   1
> >> ls2k2000  gnet    7a13      0x10        8
> >> ls7a2000  gnet    7a13      0x37        1
> > s/gmac/GMAC
> > s/gnet/GNET
> > s/pci_id/PCI Dev ID
> > s/snsp_id/Synopys Version
> > s/channels/DMA-channels
> > s/ls2k/LS2K
> > s/ls7a/LS7A
> >
> > * everywhere
> OK.
> >
> >> The GMAC device only has a MAC chip inside and needs an
> >> external PHY chip;
> >>
> >> To later distinguish 8-channel gnet devices from single-channel
> >> gnet/gmac devices, move rx_queues_to_use loongson_default_data
> >> to loongson_dwmac_probe(). Also move mac_interface to
> >> loongson_default_data().
> > Again. This is only a part of the reason why you need this change.
> > The main reason is to provide the two-leveled platform data init
> > functions: fist one is the common method initializing the data common
> > for both GMAC and GNET, second one is the device-specific data
> > initializer.
> >
> > To sum up I would change the commit log to something like this:
> >
> > "Loongson delivers two types of the network devices: Loongson GMAC and
> > Loongson GNET in the framework of four CPU/Chipsets revisions:
> >
> >     Chip             Network  PCI Dev ID   Synopys Version   DMA-channel
> > LS2K1000 CPU         GMAC      0x7a03       v3.50a/v3.73a        1
> > LS7A1000 Chipset     GMAC      0x7a03       v3.50a/v3.73a        1
> > LS2K2000 CPU         GNET      0x7a13          v3.73a            8
> > LS7A2000 Chipset     GNET      0x7a13          v3.73a            1
> >
> > The driver currently supports the chips with the Loongson GMAC network
> > device. As a preparation before adding the Loongson GNET support
> > detach the Loongson GMAC-specific platform data initializations to the
> > loongson_gmac_data() method and preserve the common settings in the
> > loongson_default_data().
> >
> > While at it drop the return value statement from the
> > loongson_default_data() method as redundant."
> OK, Thanks!
> >
> >> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> >> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> >> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> >> ---
> >>   .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 20 ++++++++++++-------
> >>   1 file changed, 13 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> >> index 4e0838db4259..904e288d0be0 100644
> >> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> >> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> >> @@ -11,22 +11,20 @@
> >>
> >>   #define PCI_DEVICE_ID_LOONGSON_GMAC        0x7a03
> >>
> >> -static int loongson_default_data(struct plat_stmmacenet_data *plat)
> >> +static void loongson_default_data(struct plat_stmmacenet_data *plat)
> >>   {
> >>      plat->clk_csr = 2;      /* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
> >>      plat->has_gmac = 1;
> >>      plat->force_sf_dma_mode = 1;
> >>
> >> +    plat->mac_interface = PHY_INTERFACE_MODE_GMII;
> >> +
> > I double-checked this part in my HW and in the databooks. DW GMAC with
> > _RGMII_ PHY-interfaces can't be equipped with a PCS (STMMAC driver is
> > wrong in considering otherwise at least in the Auto-negotiation part).
> > PCS is only available for the RTI, RTBI and SGMII interfaces.
> >
> > You can double-check that by checking out the DMA_HW_FEATURE.PCSSEL
> > flag state. I'll be surprised if it's set in your case. If it isn't
> > then either drop the plat_stmmacenet_data::mac_interface
> > initialization or (as Russell suggested) initialize it with
> > PHY_INTERFACE_MODE_NA. But do that in a separate pre-requisite patch!
> OK.
> >
> >>      /* Set default value for unicast filter entries */
> >>      plat->unicast_filter_entries = 1;
> >>
> >>      /* Set the maxmtu to a default of JUMBO_LEN */
> >>      plat->maxmtu = JUMBO_LEN;
> >>
> >> -    /* Set default number of RX and TX queues to use */
> >> -    plat->tx_queues_to_use = 1;
> >> -    plat->rx_queues_to_use = 1;
> >> -
> >>      /* Disable Priority config by default */
> >>      plat->tx_queues_cfg[0].use_prio = false;
> >>      plat->rx_queues_cfg[0].use_prio = false;
> >> @@ -41,6 +39,12 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
> >>      plat->dma_cfg->pblx8 = true;
> >>
> >>      plat->multicast_filter_bins = 256;
> >> +}
> >> +
> >> +static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
> >> +{
> >> +    loongson_default_data(plat);
> >> +
> >>      return 0;
> >>   }
> >>
> >> @@ -109,11 +113,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> >>      }
> >>
> >>      plat->phy_interface = phy_mode;
> >> -    plat->mac_interface = PHY_INTERFACE_MODE_GMII;
> >>
> >>      pci_set_master(pdev);
> >>
> >> -    loongson_default_data(plat);
> >> +    loongson_gmac_data(plat);
> >>      pci_enable_msi(pdev);
> >>      memset(&res, 0, sizeof(res));
> >>      res.addr = pcim_iomap_table(pdev)[0];
> >> @@ -138,6 +141,9 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> >>              goto err_disable_msi;
> >>      }
> >>
> >> +    plat->tx_queues_to_use = 1;
> >> +    plat->rx_queues_to_use = 1;
> >> +
> > You can freely move this to loongson_gmac_data() method. And then, in
> > the patch adding the GNET-support, you'll be able to provide these fields
> > initialization in the loongson_gnet_data() method together with the
> > plat->tx_queues_cfg[*].coe_unsupported flag init. Thus the probe()
> > method will get to be smaller and easier to read, and the
> > loongson_*_data() method will be more coherent.
>
> As you said, at first glance, putting them in loongson_gnet_data()
> method is fine,
>
> but in LS2K2000:
>
>          plat->rx_queues_to_use = CHANNEL_NUM;    // CHANNEL_NUM = 8;
>          plat->tx_queues_to_use = CHANNEL_NUM;
>
> So we need to distinguish between them. At the same time, we have to
> distinguish
>
> between LS2K2000 in probe() method. Why not put them inside probe, which
> will
>
> save a lot of duplicate code, like this:
>
>      struct stmmac_resources res;
>      struct loongson_data *ld;
>
> ...
>
>      memset(&res, 0, sizeof(res));
>      res.addr = pcim_iomap_table(pdev)[0];
>      ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
>
>      switch (ld->gmac_verion) {
>      case LOONGSON_DWMAC_CORE_1_00:
>          plat->rx_queues_to_use = CHANNEL_NUM;
>          plat->tx_queues_to_use = CHANNEL_NUM;
>
>          /* Only channel 0 supports checksum,
>           * so turn off checksum to enable multiple channels.
>           */
>          for (i = 1; i < CHANNEL_NUM; i++)
>              plat->tx_queues_cfg[i].coe_unsupported = 1;
>
>          ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
>          break;
>      default:    /* 0x35 device and 0x37 device. */
>          plat->tx_queues_to_use = 1;
>          plat->rx_queues_to_use = 1;
>
>          ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
>          break;
>      }
>      if (ret)
>          goto err_disable_device;
>
>
> What do you think?
>
>
> Of course, if you insist, I'm willing to repeat this in the
>
> loongson_gnet_data() method.
In my opinion, it is the most elegant method by reading gmac_version
only once in the probe function, and save it in loongson_data for
other functions to use. So, it is good for me to put the switch-case
in the probe function.

Huacai
>
>
>
> Thanks,
>
> Yanteng
>

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Huacai Chen]

Hi, Serge,

On Mon, May 13, 2024 at 6:57 PM Serge Semin <fancer.lancer@gmail.com> wrote:
>
> On Thu, May 09, 2024 at 04:57:44PM +0800, Yanteng Si wrote:
> > Hi Serge
> >
> > 在 2024/5/8 23:10, Serge Semin 写道:
> > > On Wed, May 08, 2024 at 10:58:16PM +0800, Huacai Chen wrote:
> > > > Hi, Serge,
> > > >
> > > > On Wed, May 8, 2024 at 10:38 PM Serge Semin<fancer.lancer@gmail.com>  wrote:
> > > > > On Tue, May 07, 2024 at 09:35:24PM +0800, Yanteng Si wrote:
> > > > > > Hi Serge,
> > > > > >
> > > > > > 在 2024/5/6 18:39, Serge Semin 写道:
> > > > > > > On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
> > > > > > > > ...
> > > > > > > > +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
> > > > > > > > +                              struct plat_stmmacenet_data *plat,
> > > > > > > > +                              struct stmmac_resources *res,
> > > > > > > > +                              struct device_node *np)
> > > > > > > > +{
> > > > > > > > + int i, ret, vecs;
> > > > > > > > +
> > > > > > > > + vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
> > > > > > > > + ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
> > > > > > > > + if (ret < 0) {
> > > > > > > > +         dev_info(&pdev->dev,
> > > > > > > > +                  "MSI enable failed, Fallback to legacy interrupt\n");
> > > > > > > > +         return loongson_dwmac_config_legacy(pdev, plat, res, np);
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + res->irq = pci_irq_vector(pdev, 0);
> > > > > > > > + res->wol_irq = 0;
> > > > > > > > +
> > > > > > > > + /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> > > > > > > > +  * --------- ----- -------- --------  ...  -------- --------
> > > > > > > > +  * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> > > > > > > > +  */
> > > > > > > > + for (i = 0; i < CHANNEL_NUM; i++) {
> > > > > > > > +         res->rx_irq[CHANNEL_NUM - 1 - i] =
> > > > > > > > +                 pci_irq_vector(pdev, 1 + i * 2);
> > > > > > > > +         res->tx_irq[CHANNEL_NUM - 1 - i] =
> > > > > > > > +                 pci_irq_vector(pdev, 2 + i * 2);
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> > > > > > > > +
> > > > > > > > + return 0;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > ...
> > > > > > > >    static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > > > > > > >    {
> > > > > > > >            struct plat_stmmacenet_data *plat;
> > > > > > > >            int ret, i, bus_id, phy_mode;
> > > > > > > >            struct stmmac_pci_info *info;
> > > > > > > >            struct stmmac_resources res;
> > > > > > > > + struct loongson_data *ld;
> > > > > > > >            struct device_node *np;
> > > > > > > >            np = dev_of_node(&pdev->dev);
> > > > > > > > @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > > > > > >                    return -ENOMEM;
> > > > > > > >            plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> > > > > > > > - if (!plat->dma_cfg) {
> > > > > > > > -         ret = -ENOMEM;
> > > > > > > > -         goto err_put_node;
> > > > > > > > - }
> > > > > > > > + if (!plat->dma_cfg)
> > > > > > > > +         return -ENOMEM;
> > > > > > > > +
> > > > > > > > + ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
> > > > > > > > + if (!ld)
> > > > > > > > +         return -ENOMEM;
> > > > > > > >            /* Enable pci device */
> > > > > > > >            ret = pci_enable_device(pdev);
> > > > > > > > @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > > > > > >                    plat->phy_interface = phy_mode;
> > > > > > > >            }
> > > > > > > > - pci_enable_msi(pdev);
> > > > > > > > + plat->bsp_priv = ld;
> > > > > > > > + plat->setup = loongson_dwmac_setup;
> > > > > > > > + ld->dev = &pdev->dev;
> > > > > > > > +
> > > > > > > >            memset(&res, 0, sizeof(res));
> > > > > > > >            res.addr = pcim_iomap_table(pdev)[0];
> > > > > > > > + ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
> > > > > > > > +
> > > > > > > > + switch (ld->gmac_verion) {
> > > > > > > > + case LOONGSON_DWMAC_CORE_1_00:
> > > > > > > > +         plat->rx_queues_to_use = CHANNEL_NUM;
> > > > > > > > +         plat->tx_queues_to_use = CHANNEL_NUM;
> > > > > > > > +
> > > > > > > > +         /* Only channel 0 supports checksum,
> > > > > > > > +          * so turn off checksum to enable multiple channels.
> > > > > > > > +          */
> > > > > > > > +         for (i = 1; i < CHANNEL_NUM; i++)
> > > > > > > > +                 plat->tx_queues_cfg[i].coe_unsupported = 1;
> > > > > > > > - plat->tx_queues_to_use = 1;
> > > > > > > > - plat->rx_queues_to_use = 1;
> > > > > > > > +         ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
> > > > > > > > +         break;
> > > > > > > > + default:        /* 0x35 device and 0x37 device. */
> > > > > > > > +         plat->tx_queues_to_use = 1;
> > > > > > > > +         plat->rx_queues_to_use = 1;
> > > > > > > > - ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > > > > > +         ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > > > > > +         break;
> > > > > > > > + }
> > > > > > > Let's now talk about this change.
> > > > > > >
> > > > > > > First of all, one more time. You can't miss the return value check
> > > > > > > because if any of the IRQ config method fails then the driver won't
> > > > > > > work! The first change that introduces the problem is in the patch
> > > > > > > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > > > OK!
> > > > > > > Second, as I already mentioned in another message sent to this patch
> > > > > > > you are missing the PCI MSI IRQs freeing in the cleanup-on-error path
> > > > > > > and in the device/driver remove() function. It's definitely wrong.
> > > > > > You are right! I will do it.
> > > > > > > Thirdly, you said that the node-pointer is now optional and introduced
> > > > > > > the patch
> > > > > > > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > > > > If so and the DT-based setting up isn't mandatory then I would
> > > > > > > suggest to proceed with the entire so called legacy setups only if the
> > > > > > > node-pointer has been found, otherwise the pure PCI-based setup would
> > > > > > > be performed. So the patches 10-13 (in your v12 order) would look
> > > > > > In this case, MSI will not be enabled when the node-pointer is found.
> > > > > >
> > > > > > .
> > > > > >
> > > > > >
> > > > > > In fact, a large fraction of 2k devices are DT-based, of course, many are
> > > > > > PCI-based.
> > > > > Then please summarise which devices need the DT-node pointer which
> > > > > don't? And most importantly if they do why do they need the DT-node?
> > > > Whether we need DT-nodes doesn't depend on device type, but depends on
> > > > the BIOS type. When we boot with UEFI+ACPI, we don't need DT-node,
> > > > when we boot with PMON+FDT, we need DT-node. Loongson machines may
> > > > have either BIOS types.
> > > Thanks for the answer. Just to fully clarify. Does it mean that all
> > > Loongson Ethernet controllers (Loongson GNET and GMAC) are able to
> > > deliver both PCI MSI IRQs and direct GIC IRQs (so called legacy)?
> >
>
> > No, only devices that support multiple channels can deliver both PCI MSI
> > IRQs
> >
> > and direct GIC IRQs, other devices can only deliver GIC IRQs.
> >
> > Furthermore, multiple channel features are bundled with MSI. If we want to
> >
> > enable multiple channels, we must enable MSI.
>
> Sadly to say but this information changes a lot. Based on that the
> only platform with optional DT-node is the LS2K2000 GNET device. The
> rest of the devices (GMACs and LS7A2000 GNET) must be equipped with a
> node-pointer otherwise they won't work. Due to that the logic of the
> patches
> [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> is incorrect.
>
> 1. [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> So this patch doesn't add a pure PCI-based probe procedure after all
> because the Loongson GMACs are required to have a DT-node. AFAICS
> pdev->irq is actually the IRQ retrieved from the DT-node. So the "if
> (np) {} else {}" clause doesn't really make sense.
>
> 2. [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> First of all the function name is incorrect. The IRQ signal isn't legacy
> (INTx-based), but is retrieved from the DT-node. Secondly the
> "if (np) {} else {}" statement is very much redundant because if no
> DT-node found the pdev->irq won't be initialized at all, and the
> driver won't work with no error printed.
>
> All of that also affects the patch/commit logs. Glad we figured that
> out at this stage. Seeing there have been tons of another comments
> let's postpone the discussion around this problem for v13 then. I'll
> keep in mind the info you shared in this thread and think of the way
> to fix the patches after v13 is submitted for review.
Let me clarify the interrupt information, hope that can help you to
understand better:
1, Loongson machines may use UEFI (implies ACPI) or PMON/UBOOT
(implies FDT) as the BIOS.
2, The BIOS type has no relationship with device types, which means:
machines with GMAC can be either ACPI-based or FDT-based, machines
with GNET can also be either ACPI-based or FDT-based.
3, The existing Loongson driver can only support FDT, which means the
device should be PCI-probed and DT-configured. Though the existing
driver only supports GMAC, it doesn't mean that GMAC is bound to FDT.
GMAC can also work with ACPI, in that case we say it is "full PCI",
which means we don't need "np".
4, At present, multi-channel devices support MSI, currently only GNET
support MSI, but in future there may also GMAC support MSI.
5, So, in Yanteng's patches, a device firstly request MSI, and since
MSI is dynamically allocated, it doesn't care about the BIOS type
(ACPI or FDT). However, if MSI fails (either because MSI is exhausted
or the device doesn't support it), it fallback to "legacy" interrupt,
which means irq lines mapped to INT-A/B/C/D of PCI.
6. In the legacy case, the irq is get from DT-node (FDT case), or
already in pdev->irq (ACPI case). So Yanteng use a "if (np) { } else {
}", which is reasonable from my point of view.

So Yanteng's interrupt code is good for me, but I also agree to
improve that after v13, if needed.

Huacai

>
> Thanks
> -Serge(y)
>
> >
> > Thanks,
> >
> > Yanteng
> >

Re: [PATCH net-next v12 06/15] net: stmmac: dwmac-loongson: Split up the platform data initialization

[Serge Semin]

On Mon, May 13, 2024 at 07:07:38PM +0800, Yanteng Si wrote:
> 
> 在 2024/5/4 02:08, Serge Semin 写道:
> > > [PATCH net-next v12 06/15] net: stmmac: dwmac-loongson: Split up the platform data initialization
> > Please convert the subject to being more specific, like this:
> > 
> > net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init
> > 
> > On Thu, Apr 25, 2024 at 09:04:37PM +0800, Yanteng Si wrote:
> > > Based on IP core classification, loongson has two types of network
> > What is the real company name? At least start the name with the
> > capital letter.
> > * everywhere
> OK,  LOONGSON
> > 
> > > devices: GMAC and GNET. GMAC's ip_core id is 0x35/0x37, while GNET's
> > > ip_core id is 0x37/0x10.
> > s/ip_core/IP-core
> > 
> > Once again the IP-core ID isn't _hex_, but a number of the format:
> > "v+Major.Minor"
> > so use the _real_ IP-core version number everywhere. Note mentioning
> > that some of your GNET device has the GMAC_VERSION.SNPSVER hardwired
> > to 0x10 is completely redundant in this and many other context. The
> > only place where it's relevant is the patch(es) where you have the
> > Snps ID override.
> OK.
> > 
> > > Device tables:
> > > 
> > > device    type    pci_id    snps_id    channel
> > > ls2k1000  gmac    7a03      0x35/0x37   1
> > > ls7a1000  gmac    7a03      0x35/0x37   1
> > > ls2k2000  gnet    7a13      0x10        8
> > > ls7a2000  gnet    7a13      0x37        1
> > s/gmac/GMAC
> > s/gnet/GNET
> > s/pci_id/PCI Dev ID
> > s/snsp_id/Synopys Version
> > s/channels/DMA-channels
> > s/ls2k/LS2K
> > s/ls7a/LS7A
> > 
> > * everywhere
> OK.
> > 
> > > The GMAC device only has a MAC chip inside and needs an
> > > external PHY chip;
> > > 
> > > To later distinguish 8-channel gnet devices from single-channel
> > > gnet/gmac devices, move rx_queues_to_use loongson_default_data
> > > to loongson_dwmac_probe(). Also move mac_interface to
> > > loongson_default_data().
> > Again. This is only a part of the reason why you need this change.
> > The main reason is to provide the two-leveled platform data init
> > functions: fist one is the common method initializing the data common
> > for both GMAC and GNET, second one is the device-specific data
> > initializer.
> > 
> > To sum up I would change the commit log to something like this:
> > 
> > "Loongson delivers two types of the network devices: Loongson GMAC and
> > Loongson GNET in the framework of four CPU/Chipsets revisions:
> > 
> >     Chip             Network  PCI Dev ID   Synopys Version   DMA-channel
> > LS2K1000 CPU         GMAC      0x7a03       v3.50a/v3.73a        1
> > LS7A1000 Chipset     GMAC      0x7a03       v3.50a/v3.73a        1
> > LS2K2000 CPU         GNET      0x7a13          v3.73a            8
> > LS7A2000 Chipset     GNET      0x7a13          v3.73a            1
> > 
> > The driver currently supports the chips with the Loongson GMAC network
> > device. As a preparation before adding the Loongson GNET support
> > detach the Loongson GMAC-specific platform data initializations to the
> > loongson_gmac_data() method and preserve the common settings in the
> > loongson_default_data().
> > 
> > While at it drop the return value statement from the
> > loongson_default_data() method as redundant."
> OK, Thanks!
> > 
> > > Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> > > Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> > > Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> > > ---
> > >   .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 20 ++++++++++++-------
> > >   1 file changed, 13 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > > index 4e0838db4259..904e288d0be0 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > > @@ -11,22 +11,20 @@
> > >   #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
> > > -static int loongson_default_data(struct plat_stmmacenet_data *plat)
> > > +static void loongson_default_data(struct plat_stmmacenet_data *plat)
> > >   {
> > >   	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
> > >   	plat->has_gmac = 1;
> > >   	plat->force_sf_dma_mode = 1;
> > > +	plat->mac_interface = PHY_INTERFACE_MODE_GMII;
> > > +
> > I double-checked this part in my HW and in the databooks. DW GMAC with
> > _RGMII_ PHY-interfaces can't be equipped with a PCS (STMMAC driver is
> > wrong in considering otherwise at least in the Auto-negotiation part).
> > PCS is only available for the RTI, RTBI and SGMII interfaces.
> > 
> > You can double-check that by checking out the DMA_HW_FEATURE.PCSSEL
> > flag state. I'll be surprised if it's set in your case. If it isn't
> > then either drop the plat_stmmacenet_data::mac_interface
> > initialization or (as Russell suggested) initialize it with
> > PHY_INTERFACE_MODE_NA. But do that in a separate pre-requisite patch!
> OK.
> > 
> > >   	/* Set default value for unicast filter entries */
> > >   	plat->unicast_filter_entries = 1;
> > >   	/* Set the maxmtu to a default of JUMBO_LEN */
> > >   	plat->maxmtu = JUMBO_LEN;
> > > -	/* Set default number of RX and TX queues to use */
> > > -	plat->tx_queues_to_use = 1;
> > > -	plat->rx_queues_to_use = 1;
> > > -
> > >   	/* Disable Priority config by default */
> > >   	plat->tx_queues_cfg[0].use_prio = false;
> > >   	plat->rx_queues_cfg[0].use_prio = false;
> > > @@ -41,6 +39,12 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
> > >   	plat->dma_cfg->pblx8 = true;
> > >   	plat->multicast_filter_bins = 256;
> > > +}
> > > +
> > > +static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
> > > +{
> > > +	loongson_default_data(plat);
> > > +
> > >   	return 0;
> > >   }
> > > @@ -109,11 +113,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > >   	}
> > >   	plat->phy_interface = phy_mode;
> > > -	plat->mac_interface = PHY_INTERFACE_MODE_GMII;
> > >   	pci_set_master(pdev);
> > > -	loongson_default_data(plat);
> > > +	loongson_gmac_data(plat);
> > >   	pci_enable_msi(pdev);
> > >   	memset(&res, 0, sizeof(res));
> > >   	res.addr = pcim_iomap_table(pdev)[0];
> > > @@ -138,6 +141,9 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > >   		goto err_disable_msi;
> > >   	}
> > > +	plat->tx_queues_to_use = 1;
> > > +	plat->rx_queues_to_use = 1;
> > > +
> > You can freely move this to loongson_gmac_data() method. And then, in
> > the patch adding the GNET-support, you'll be able to provide these fields
> > initialization in the loongson_gnet_data() method together with the
> > plat->tx_queues_cfg[*].coe_unsupported flag init. Thus the probe()
> > method will get to be smaller and easier to read, and the
> > loongson_*_data() method will be more coherent.
> 
> As you said, at first glance, putting them in loongson_gnet_data() method is
> fine,
> 
> but in LS2K2000:
> 
>         plat->rx_queues_to_use = CHANNEL_NUM;    // CHANNEL_NUM = 8;
>         plat->tx_queues_to_use = CHANNEL_NUM;
> 
> So we need to distinguish between them. At the same time, we have to
> distinguish
> 
> between LS2K2000 in probe() method. Why not put them inside probe, which
> will
> 
> save a lot of duplicate code, like this:
> 
>     struct stmmac_resources res;
>     struct loongson_data *ld;
> 
> ...
> 
>     memset(&res, 0, sizeof(res));
>     res.addr = pcim_iomap_table(pdev)[0];
>     ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
> 
>     switch (ld->gmac_verion) {
>     case LOONGSON_DWMAC_CORE_1_00:
>         plat->rx_queues_to_use = CHANNEL_NUM;
>         plat->tx_queues_to_use = CHANNEL_NUM;
> 
>         /* Only channel 0 supports checksum,
>          * so turn off checksum to enable multiple channels.
>          */
>         for (i = 1; i < CHANNEL_NUM; i++)
>             plat->tx_queues_cfg[i].coe_unsupported = 1;
> 
>         ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
>         break;
>     default:    /* 0x35 device and 0x37 device. */
>         plat->tx_queues_to_use = 1;
>         plat->rx_queues_to_use = 1;
> 
>         ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
>         break;
>     }
>     if (ret)
>         goto err_disable_device;
> 
> 
> What do you think?
> 
> 
> Of course, if you insist, I'm willing to repeat this in the
> 
> loongson_gnet_data() method.

Not necessarily. As Huacai earlier suggested you can keep the Loongson
ID in the platform private data and have it utilized in the local
sub-functions/routines. Like this:

struct loongson_data {
	u32 loongson_id;
};

static int loongson_gmac_data(struct pci_dev *pdev,
			      struct plat_stmmacenet_data *plat)
{
	struct loongson_data *ld = plat->bsp_priv;

	...

	plat->rx_queues_to_use = 1;
	plat->tx_queues_to_use = 1;

	return 0;
}

static int loongson_gnet_data(struct pci_dev *pdev,
			      struct plat_stmmacenet_data *plat)
{
	struct loongson_data *ld = plat->bsp_priv;

	...

	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
		plat->rx_queues_to_use = 8;
		plat->tx_queues_to_use = 8;

		/* Tx COE is supported by the channel 0 only */
		for (i = 1; i < 8; i++)
			plat->tx_queues_cfg[i].coe_unsupported = 1;
	} else {
		plat->rx_queues_to_use = 1;
		plat->tx_queues_to_use = 1;
	}

	return 0;
}

static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
	struct loongson_data *ld;
	...

	ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
	if (!ld)
		return -ENOMEM;
	...
	ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
	plat->bsp_priv = ld;
	...
	if (ld->loongson_id == DWMAC_CORE_LS2K2000)
		ret = loongson_dwmac_config_msi(pdev, plat, &res);
	else
		ret = loongson_dwmac_config_plat(pdev, plat, &res);

	if (ret)
		return ret;
	...
}

It's not "a lot" duplication code. Just two if-else statements, which
is fine. But the data-init methods will get to be fully coherent. It's
much more important.

* Note switch-case is redundant since you have a single case in there,
so if-else would be more than enough.

-Serge(y)

> 
> 
> 
> Thanks,
> 
> Yanteng
> 

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Serge Semin]

On Mon, May 13, 2024 at 09:26:11PM +0800, Huacai Chen wrote:
> Hi, Serge,
> 
> On Mon, May 13, 2024 at 6:57 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> >
> > On Thu, May 09, 2024 at 04:57:44PM +0800, Yanteng Si wrote:
> > > Hi Serge
> > >
> > > 在 2024/5/8 23:10, Serge Semin 写道:
> > > > On Wed, May 08, 2024 at 10:58:16PM +0800, Huacai Chen wrote:
> > > > > Hi, Serge,
> > > > >
> > > > > On Wed, May 8, 2024 at 10:38 PM Serge Semin<fancer.lancer@gmail.com>  wrote:
> > > > > > On Tue, May 07, 2024 at 09:35:24PM +0800, Yanteng Si wrote:
> > > > > > > Hi Serge,
> > > > > > >
> > > > > > > 在 2024/5/6 18:39, Serge Semin 写道:
> > > > > > > > On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
> > > > > > > > > ...
> > > > > > > > > +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
> > > > > > > > > +                              struct plat_stmmacenet_data *plat,
> > > > > > > > > +                              struct stmmac_resources *res,
> > > > > > > > > +                              struct device_node *np)
> > > > > > > > > +{
> > > > > > > > > + int i, ret, vecs;
> > > > > > > > > +
> > > > > > > > > + vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
> > > > > > > > > + ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
> > > > > > > > > + if (ret < 0) {
> > > > > > > > > +         dev_info(&pdev->dev,
> > > > > > > > > +                  "MSI enable failed, Fallback to legacy interrupt\n");
> > > > > > > > > +         return loongson_dwmac_config_legacy(pdev, plat, res, np);
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + res->irq = pci_irq_vector(pdev, 0);
> > > > > > > > > + res->wol_irq = 0;
> > > > > > > > > +
> > > > > > > > > + /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> > > > > > > > > +  * --------- ----- -------- --------  ...  -------- --------
> > > > > > > > > +  * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> > > > > > > > > +  */
> > > > > > > > > + for (i = 0; i < CHANNEL_NUM; i++) {
> > > > > > > > > +         res->rx_irq[CHANNEL_NUM - 1 - i] =
> > > > > > > > > +                 pci_irq_vector(pdev, 1 + i * 2);
> > > > > > > > > +         res->tx_irq[CHANNEL_NUM - 1 - i] =
> > > > > > > > > +                 pci_irq_vector(pdev, 2 + i * 2);
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> > > > > > > > > +
> > > > > > > > > + return 0;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > ...
> > > > > > > > >    static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > > > > > > > >    {
> > > > > > > > >            struct plat_stmmacenet_data *plat;
> > > > > > > > >            int ret, i, bus_id, phy_mode;
> > > > > > > > >            struct stmmac_pci_info *info;
> > > > > > > > >            struct stmmac_resources res;
> > > > > > > > > + struct loongson_data *ld;
> > > > > > > > >            struct device_node *np;
> > > > > > > > >            np = dev_of_node(&pdev->dev);
> > > > > > > > > @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > > > > > > >                    return -ENOMEM;
> > > > > > > > >            plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> > > > > > > > > - if (!plat->dma_cfg) {
> > > > > > > > > -         ret = -ENOMEM;
> > > > > > > > > -         goto err_put_node;
> > > > > > > > > - }
> > > > > > > > > + if (!plat->dma_cfg)
> > > > > > > > > +         return -ENOMEM;
> > > > > > > > > +
> > > > > > > > > + ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
> > > > > > > > > + if (!ld)
> > > > > > > > > +         return -ENOMEM;
> > > > > > > > >            /* Enable pci device */
> > > > > > > > >            ret = pci_enable_device(pdev);
> > > > > > > > > @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > > > > > > >                    plat->phy_interface = phy_mode;
> > > > > > > > >            }
> > > > > > > > > - pci_enable_msi(pdev);
> > > > > > > > > + plat->bsp_priv = ld;
> > > > > > > > > + plat->setup = loongson_dwmac_setup;
> > > > > > > > > + ld->dev = &pdev->dev;
> > > > > > > > > +
> > > > > > > > >            memset(&res, 0, sizeof(res));
> > > > > > > > >            res.addr = pcim_iomap_table(pdev)[0];
> > > > > > > > > + ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
> > > > > > > > > +
> > > > > > > > > + switch (ld->gmac_verion) {
> > > > > > > > > + case LOONGSON_DWMAC_CORE_1_00:
> > > > > > > > > +         plat->rx_queues_to_use = CHANNEL_NUM;
> > > > > > > > > +         plat->tx_queues_to_use = CHANNEL_NUM;
> > > > > > > > > +
> > > > > > > > > +         /* Only channel 0 supports checksum,
> > > > > > > > > +          * so turn off checksum to enable multiple channels.
> > > > > > > > > +          */
> > > > > > > > > +         for (i = 1; i < CHANNEL_NUM; i++)
> > > > > > > > > +                 plat->tx_queues_cfg[i].coe_unsupported = 1;
> > > > > > > > > - plat->tx_queues_to_use = 1;
> > > > > > > > > - plat->rx_queues_to_use = 1;
> > > > > > > > > +         ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
> > > > > > > > > +         break;
> > > > > > > > > + default:        /* 0x35 device and 0x37 device. */
> > > > > > > > > +         plat->tx_queues_to_use = 1;
> > > > > > > > > +         plat->rx_queues_to_use = 1;
> > > > > > > > > - ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > > > > > > +         ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > > > > > > +         break;
> > > > > > > > > + }
> > > > > > > > Let's now talk about this change.
> > > > > > > >
> > > > > > > > First of all, one more time. You can't miss the return value check
> > > > > > > > because if any of the IRQ config method fails then the driver won't
> > > > > > > > work! The first change that introduces the problem is in the patch
> > > > > > > > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > > > > OK!
> > > > > > > > Second, as I already mentioned in another message sent to this patch
> > > > > > > > you are missing the PCI MSI IRQs freeing in the cleanup-on-error path
> > > > > > > > and in the device/driver remove() function. It's definitely wrong.
> > > > > > > You are right! I will do it.
> > > > > > > > Thirdly, you said that the node-pointer is now optional and introduced
> > > > > > > > the patch
> > > > > > > > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > > > > > If so and the DT-based setting up isn't mandatory then I would
> > > > > > > > suggest to proceed with the entire so called legacy setups only if the
> > > > > > > > node-pointer has been found, otherwise the pure PCI-based setup would
> > > > > > > > be performed. So the patches 10-13 (in your v12 order) would look
> > > > > > > In this case, MSI will not be enabled when the node-pointer is found.
> > > > > > >
> > > > > > > .
> > > > > > >
> > > > > > >
> > > > > > > In fact, a large fraction of 2k devices are DT-based, of course, many are
> > > > > > > PCI-based.
> > > > > > Then please summarise which devices need the DT-node pointer which
> > > > > > don't? And most importantly if they do why do they need the DT-node?
> > > > > Whether we need DT-nodes doesn't depend on device type, but depends on
> > > > > the BIOS type. When we boot with UEFI+ACPI, we don't need DT-node,
> > > > > when we boot with PMON+FDT, we need DT-node. Loongson machines may
> > > > > have either BIOS types.
> > > > Thanks for the answer. Just to fully clarify. Does it mean that all
> > > > Loongson Ethernet controllers (Loongson GNET and GMAC) are able to
> > > > deliver both PCI MSI IRQs and direct GIC IRQs (so called legacy)?
> > >
> >
> > > No, only devices that support multiple channels can deliver both PCI MSI
> > > IRQs
> > >
> > > and direct GIC IRQs, other devices can only deliver GIC IRQs.
> > >
> > > Furthermore, multiple channel features are bundled with MSI. If we want to
> > >
> > > enable multiple channels, we must enable MSI.
> >
> > Sadly to say but this information changes a lot. Based on that the
> > only platform with optional DT-node is the LS2K2000 GNET device. The
> > rest of the devices (GMACs and LS7A2000 GNET) must be equipped with a
> > node-pointer otherwise they won't work. Due to that the logic of the
> > patches
> > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > is incorrect.
> >
> > 1. [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > So this patch doesn't add a pure PCI-based probe procedure after all
> > because the Loongson GMACs are required to have a DT-node. AFAICS
> > pdev->irq is actually the IRQ retrieved from the DT-node. So the "if
> > (np) {} else {}" clause doesn't really make sense.
> >
> > 2. [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > First of all the function name is incorrect. The IRQ signal isn't legacy
> > (INTx-based), but is retrieved from the DT-node. Secondly the
> > "if (np) {} else {}" statement is very much redundant because if no
> > DT-node found the pdev->irq won't be initialized at all, and the
> > driver won't work with no error printed.
> >
> > All of that also affects the patch/commit logs. Glad we figured that
> > out at this stage. Seeing there have been tons of another comments
> > let's postpone the discussion around this problem for v13 then. I'll
> > keep in mind the info you shared in this thread and think of the way
> > to fix the patches after v13 is submitted for review.
> Let me clarify the interrupt information, hope that can help you to
> understand better:

> 1, Loongson machines may use UEFI (implies ACPI) or PMON/UBOOT
> (implies FDT) as the BIOS.

Ok. Aside with the OF-based platform there is an ACPI case.

> 2, The BIOS type has no relationship with device types, which means:
> machines with GMAC can be either ACPI-based or FDT-based, machines
> with GNET can also be either ACPI-based or FDT-based.

Ok. It's either-or. Got it.

> 3, The existing Loongson driver can only support FDT, which means the
> device should be PCI-probed and DT-configured. Though the existing
> driver only supports GMAC, it doesn't mean that GMAC is bound to FDT.
> GMAC can also work with ACPI, in that case we say it is "full PCI",
> which means we don't need "np".

"full PCI" statement can't be utilized for the case of the ACPI-based
IRQ assignment. "full PCI" is the way the GNET probe procedure works -
everything required for the device handling is detected in runtime
with no ACPI/DT stuff.

So the patch 10 with the "full PCI"-related subject doesn't actually
adds the PCIe-only-based device probe support, but actually converts
the driver to supporting the ACPI-case.)

> 4, At present, multi-channel devices support MSI, currently only GNET
> support MSI, but in future there may also GMAC support MSI.

It's better to avoid adding a support for hypothetical devices and
prohibit all the currently unreal cases. It will simplify the code,
ease it' maintenance, reduce the bugs probability.

> 5, So, in Yanteng's patches, a device firstly request MSI, and since
> MSI is dynamically allocated, it doesn't care about the BIOS type
> (ACPI or FDT). However, if MSI fails (either because MSI is exhausted
> or the device doesn't support it), it fallback to "legacy" interrupt,
> which means irq lines mapped to INT-A/B/C/D of PCI.

Unless we are talking about the actual PCI devices (not PCI express)
or the cases where the INT-x is emulated by means the specific PCIe
TLPs, I wouldn't mentioned the INTx or "legacy" names in the current
context. It's just a platform ACPI/DT IRQs.

> 6. In the legacy case, the irq is get from DT-node (FDT case), or
> already in pdev->irq (ACPI case).

It will be in the pdev->irq in any case whether it's DT or ACPI. See:

ACPI:
pci_device_probe():
+-> arch/loongarch/pci/pci.c:pcibios_alloc_irq()

DT:
pci_device_probe():
+-> pci_assign_irq();
    +-> pci_host_bridge::map_irq()
        +-> of_irq_parse_and_map_pci()
        or in case of Loongson PCIe host controller:
        +-> drivers/pci/controller/pci-loongson.c::loongson_map_irq()

Moreover unless the MSI IRQs are enabled, the platform IRQ (and the
legacy IRQ) can be retrieved by means of the pci_irq_vector() method.
The only reason of having the direct OF-based IRQs getting in the
Loongson DWMAC driver I see is that the LPI IRQ will be missing in
case of the pci_irq_vector() method utilization. In the rest of the
cases the pci_irq_vector() function could be freely used.

>  So Yanteng use a "if (np) { } else {
> }", which is reasonable from my point of view.
> 

At least one problem is there. What if pdev->irq isn't initialized
(initialized with zero)?..

> So Yanteng's interrupt code is good for me, but I also agree to
> improve that after v13, if needed.

Ok. I've got much better picture about what is going on under the
hood. Thanks. In anyway I'll get back to this topic in details in v13.

-Serge(y)

> 
> Huacai
> 
> >
> > Thanks
> > -Serge(y)
> >
> > >
> > > Thanks,
> > >
> > > Yanteng
> > >

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Huacai Chen]

On Tue, May 14, 2024 at 12:11 AM Serge Semin <fancer.lancer@gmail.com> wrote:
>
> On Mon, May 13, 2024 at 09:26:11PM +0800, Huacai Chen wrote:
> > Hi, Serge,
> >
> > On Mon, May 13, 2024 at 6:57 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> > >
> > > On Thu, May 09, 2024 at 04:57:44PM +0800, Yanteng Si wrote:
> > > > Hi Serge
> > > >
> > > > 在 2024/5/8 23:10, Serge Semin 写道:
> > > > > On Wed, May 08, 2024 at 10:58:16PM +0800, Huacai Chen wrote:
> > > > > > Hi, Serge,
> > > > > >
> > > > > > On Wed, May 8, 2024 at 10:38 PM Serge Semin<fancer.lancer@gmail.com>  wrote:
> > > > > > > On Tue, May 07, 2024 at 09:35:24PM +0800, Yanteng Si wrote:
> > > > > > > > Hi Serge,
> > > > > > > >
> > > > > > > > 在 2024/5/6 18:39, Serge Semin 写道:
> > > > > > > > > On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
> > > > > > > > > > ...
> > > > > > > > > > +static int loongson_dwmac_config_msi(struct pci_dev *pdev,
> > > > > > > > > > +                              struct plat_stmmacenet_data *plat,
> > > > > > > > > > +                              struct stmmac_resources *res,
> > > > > > > > > > +                              struct device_node *np)
> > > > > > > > > > +{
> > > > > > > > > > + int i, ret, vecs;
> > > > > > > > > > +
> > > > > > > > > > + vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 1);
> > > > > > > > > > + ret = pci_alloc_irq_vectors(pdev, vecs, vecs, PCI_IRQ_MSI);
> > > > > > > > > > + if (ret < 0) {
> > > > > > > > > > +         dev_info(&pdev->dev,
> > > > > > > > > > +                  "MSI enable failed, Fallback to legacy interrupt\n");
> > > > > > > > > > +         return loongson_dwmac_config_legacy(pdev, plat, res, np);
> > > > > > > > > > + }
> > > > > > > > > > +
> > > > > > > > > > + res->irq = pci_irq_vector(pdev, 0);
> > > > > > > > > > + res->wol_irq = 0;
> > > > > > > > > > +
> > > > > > > > > > + /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> > > > > > > > > > +  * --------- ----- -------- --------  ...  -------- --------
> > > > > > > > > > +  * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> > > > > > > > > > +  */
> > > > > > > > > > + for (i = 0; i < CHANNEL_NUM; i++) {
> > > > > > > > > > +         res->rx_irq[CHANNEL_NUM - 1 - i] =
> > > > > > > > > > +                 pci_irq_vector(pdev, 1 + i * 2);
> > > > > > > > > > +         res->tx_irq[CHANNEL_NUM - 1 - i] =
> > > > > > > > > > +                 pci_irq_vector(pdev, 2 + i * 2);
> > > > > > > > > > + }
> > > > > > > > > > +
> > > > > > > > > > + plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> > > > > > > > > > +
> > > > > > > > > > + return 0;
> > > > > > > > > > +}
> > > > > > > > > > +
> > > > > > > > > > ...
> > > > > > > > > >    static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > > > > > > > > >    {
> > > > > > > > > >            struct plat_stmmacenet_data *plat;
> > > > > > > > > >            int ret, i, bus_id, phy_mode;
> > > > > > > > > >            struct stmmac_pci_info *info;
> > > > > > > > > >            struct stmmac_resources res;
> > > > > > > > > > + struct loongson_data *ld;
> > > > > > > > > >            struct device_node *np;
> > > > > > > > > >            np = dev_of_node(&pdev->dev);
> > > > > > > > > > @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > > > > > > > >                    return -ENOMEM;
> > > > > > > > > >            plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> > > > > > > > > > - if (!plat->dma_cfg) {
> > > > > > > > > > -         ret = -ENOMEM;
> > > > > > > > > > -         goto err_put_node;
> > > > > > > > > > - }
> > > > > > > > > > + if (!plat->dma_cfg)
> > > > > > > > > > +         return -ENOMEM;
> > > > > > > > > > +
> > > > > > > > > > + ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
> > > > > > > > > > + if (!ld)
> > > > > > > > > > +         return -ENOMEM;
> > > > > > > > > >            /* Enable pci device */
> > > > > > > > > >            ret = pci_enable_device(pdev);
> > > > > > > > > > @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > > > > > > > > >                    plat->phy_interface = phy_mode;
> > > > > > > > > >            }
> > > > > > > > > > - pci_enable_msi(pdev);
> > > > > > > > > > + plat->bsp_priv = ld;
> > > > > > > > > > + plat->setup = loongson_dwmac_setup;
> > > > > > > > > > + ld->dev = &pdev->dev;
> > > > > > > > > > +
> > > > > > > > > >            memset(&res, 0, sizeof(res));
> > > > > > > > > >            res.addr = pcim_iomap_table(pdev)[0];
> > > > > > > > > > + ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
> > > > > > > > > > +
> > > > > > > > > > + switch (ld->gmac_verion) {
> > > > > > > > > > + case LOONGSON_DWMAC_CORE_1_00:
> > > > > > > > > > +         plat->rx_queues_to_use = CHANNEL_NUM;
> > > > > > > > > > +         plat->tx_queues_to_use = CHANNEL_NUM;
> > > > > > > > > > +
> > > > > > > > > > +         /* Only channel 0 supports checksum,
> > > > > > > > > > +          * so turn off checksum to enable multiple channels.
> > > > > > > > > > +          */
> > > > > > > > > > +         for (i = 1; i < CHANNEL_NUM; i++)
> > > > > > > > > > +                 plat->tx_queues_cfg[i].coe_unsupported = 1;
> > > > > > > > > > - plat->tx_queues_to_use = 1;
> > > > > > > > > > - plat->rx_queues_to_use = 1;
> > > > > > > > > > +         ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
> > > > > > > > > > +         break;
> > > > > > > > > > + default:        /* 0x35 device and 0x37 device. */
> > > > > > > > > > +         plat->tx_queues_to_use = 1;
> > > > > > > > > > +         plat->rx_queues_to_use = 1;
> > > > > > > > > > - ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > > > > > > > +         ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > > > > > > > > +         break;
> > > > > > > > > > + }
> > > > > > > > > Let's now talk about this change.
> > > > > > > > >
> > > > > > > > > First of all, one more time. You can't miss the return value check
> > > > > > > > > because if any of the IRQ config method fails then the driver won't
> > > > > > > > > work! The first change that introduces the problem is in the patch
> > > > > > > > > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > > > > > OK!
> > > > > > > > > Second, as I already mentioned in another message sent to this patch
> > > > > > > > > you are missing the PCI MSI IRQs freeing in the cleanup-on-error path
> > > > > > > > > and in the device/driver remove() function. It's definitely wrong.
> > > > > > > > You are right! I will do it.
> > > > > > > > > Thirdly, you said that the node-pointer is now optional and introduced
> > > > > > > > > the patch
> > > > > > > > > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > > > > > > If so and the DT-based setting up isn't mandatory then I would
> > > > > > > > > suggest to proceed with the entire so called legacy setups only if the
> > > > > > > > > node-pointer has been found, otherwise the pure PCI-based setup would
> > > > > > > > > be performed. So the patches 10-13 (in your v12 order) would look
> > > > > > > > In this case, MSI will not be enabled when the node-pointer is found.
> > > > > > > >
> > > > > > > > .
> > > > > > > >
> > > > > > > >
> > > > > > > > In fact, a large fraction of 2k devices are DT-based, of course, many are
> > > > > > > > PCI-based.
> > > > > > > Then please summarise which devices need the DT-node pointer which
> > > > > > > don't? And most importantly if they do why do they need the DT-node?
> > > > > > Whether we need DT-nodes doesn't depend on device type, but depends on
> > > > > > the BIOS type. When we boot with UEFI+ACPI, we don't need DT-node,
> > > > > > when we boot with PMON+FDT, we need DT-node. Loongson machines may
> > > > > > have either BIOS types.
> > > > > Thanks for the answer. Just to fully clarify. Does it mean that all
> > > > > Loongson Ethernet controllers (Loongson GNET and GMAC) are able to
> > > > > deliver both PCI MSI IRQs and direct GIC IRQs (so called legacy)?
> > > >
> > >
> > > > No, only devices that support multiple channels can deliver both PCI MSI
> > > > IRQs
> > > >
> > > > and direct GIC IRQs, other devices can only deliver GIC IRQs.
> > > >
> > > > Furthermore, multiple channel features are bundled with MSI. If we want to
> > > >
> > > > enable multiple channels, we must enable MSI.
> > >
> > > Sadly to say but this information changes a lot. Based on that the
> > > only platform with optional DT-node is the LS2K2000 GNET device. The
> > > rest of the devices (GMACs and LS7A2000 GNET) must be equipped with a
> > > node-pointer otherwise they won't work. Due to that the logic of the
> > > patches
> > > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > is incorrect.
> > >
> > > 1. [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > So this patch doesn't add a pure PCI-based probe procedure after all
> > > because the Loongson GMACs are required to have a DT-node. AFAICS
> > > pdev->irq is actually the IRQ retrieved from the DT-node. So the "if
> > > (np) {} else {}" clause doesn't really make sense.
> > >
> > > 2. [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > First of all the function name is incorrect. The IRQ signal isn't legacy
> > > (INTx-based), but is retrieved from the DT-node. Secondly the
> > > "if (np) {} else {}" statement is very much redundant because if no
> > > DT-node found the pdev->irq won't be initialized at all, and the
> > > driver won't work with no error printed.
> > >
> > > All of that also affects the patch/commit logs. Glad we figured that
> > > out at this stage. Seeing there have been tons of another comments
> > > let's postpone the discussion around this problem for v13 then. I'll
> > > keep in mind the info you shared in this thread and think of the way
> > > to fix the patches after v13 is submitted for review.
> > Let me clarify the interrupt information, hope that can help you to
> > understand better:
>
> > 1, Loongson machines may use UEFI (implies ACPI) or PMON/UBOOT
> > (implies FDT) as the BIOS.
>
> Ok. Aside with the OF-based platform there is an ACPI case.
>
> > 2, The BIOS type has no relationship with device types, which means:
> > machines with GMAC can be either ACPI-based or FDT-based, machines
> > with GNET can also be either ACPI-based or FDT-based.
>
> Ok. It's either-or. Got it.
>
> > 3, The existing Loongson driver can only support FDT, which means the
> > device should be PCI-probed and DT-configured. Though the existing
> > driver only supports GMAC, it doesn't mean that GMAC is bound to FDT.
> > GMAC can also work with ACPI, in that case we say it is "full PCI",
> > which means we don't need "np".
>
> "full PCI" statement can't be utilized for the case of the ACPI-based
> IRQ assignment. "full PCI" is the way the GNET probe procedure works -
> everything required for the device handling is detected in runtime
> with no ACPI/DT stuff.
>
> So the patch 10 with the "full PCI"-related subject doesn't actually
> adds the PCIe-only-based device probe support, but actually converts
> the driver to supporting the ACPI-case.)
Yes, the commit message can be improved.

>
> > 4, At present, multi-channel devices support MSI, currently only GNET
> > support MSI, but in future there may also GMAC support MSI.
>
> It's better to avoid adding a support for hypothetical devices and
> prohibit all the currently unreal cases. It will simplify the code,
> ease it' maintenance, reduce the bugs probability.
>
> > 5, So, in Yanteng's patches, a device firstly request MSI, and since
> > MSI is dynamically allocated, it doesn't care about the BIOS type
> > (ACPI or FDT). However, if MSI fails (either because MSI is exhausted
> > or the device doesn't support it), it fallback to "legacy" interrupt,
> > which means irq lines mapped to INT-A/B/C/D of PCI.
>
> Unless we are talking about the actual PCI devices (not PCI express)
> or the cases where the INT-x is emulated by means the specific PCIe
> TLPs, I wouldn't mentioned the INTx or "legacy" names in the current
> context. It's just a platform ACPI/DT IRQs.
Yes, it is probably a platform ACPI/DT IRQ, but I think the "legacy"
name is still reasonable in this case. Otherwise, what does "legacy"
stand for in "PCI_IRQ_LEGACY/PCI_IRQ_MSI/PCI_IRQ_MSIX"?

>
> > 6. In the legacy case, the irq is get from DT-node (FDT case), or
> > already in pdev->irq (ACPI case).
>
> It will be in the pdev->irq in any case whether it's DT or ACPI. See:
>
> ACPI:
> pci_device_probe():
> +-> arch/loongarch/pci/pci.c:pcibios_alloc_irq()
>
> DT:
> pci_device_probe():
> +-> pci_assign_irq();
>     +-> pci_host_bridge::map_irq()
>         +-> of_irq_parse_and_map_pci()
>         or in case of Loongson PCIe host controller:
>         +-> drivers/pci/controller/pci-loongson.c::loongson_map_irq()
>
> Moreover unless the MSI IRQs are enabled, the platform IRQ (and the
> legacy IRQ) can be retrieved by means of the pci_irq_vector() method.
> The only reason of having the direct OF-based IRQs getting in the
> Loongson DWMAC driver I see is that the LPI IRQ will be missing in
> case of the pci_irq_vector() method utilization. In the rest of the
> cases the pci_irq_vector() function could be freely used.
Yes, in the DT case, they may be macirq, eth_wake_irq and eth_lpi,
rather than a single irq, so we need an if-else here.

>
> >  So Yanteng use a "if (np) { } else {
> > }", which is reasonable from my point of view.
> >
>
> At least one problem is there. What if pdev->irq isn't initialized
> (initialized with zero)?..
As you said above, both ACPI and DT initialized pdev->irq, unless
there is a bug in BIOS.


Huacai

>
> > So Yanteng's interrupt code is good for me, but I also agree to
> > improve that after v13, if needed.
>
> Ok. I've got much better picture about what is going on under the
> hood. Thanks. In anyway I'll get back to this topic in details in v13.
>
> -Serge(y)
>
> >
> > Huacai
> >
> > >
> > > Thanks
> > > -Serge(y)
> > >
> > > >
> > > > Thanks,
> > > >
> > > > Yanteng
> > > >

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Serge Semin]

On Tue, May 14, 2024 at 12:58:33PM +0800, Huacai Chen wrote:
> On Tue, May 14, 2024 at 12:11 AM Serge Semin <fancer.lancer@gmail.com> wrote:
> >
> > On Mon, May 13, 2024 at 09:26:11PM +0800, Huacai Chen wrote:
> > > Hi, Serge,
> > >
> > > On Mon, May 13, 2024 at 6:57 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> > > >
> > > > On Thu, May 09, 2024 at 04:57:44PM +0800, Yanteng Si wrote:
> > > > > Hi Serge
> > > > >
...
> > > >
> > > > > No, only devices that support multiple channels can deliver both PCI MSI
> > > > > IRQs
> > > > >
> > > > > and direct GIC IRQs, other devices can only deliver GIC IRQs.
> > > > >
> > > > > Furthermore, multiple channel features are bundled with MSI. If we want to
> > > > >
> > > > > enable multiple channels, we must enable MSI.
> > > >
> > > > Sadly to say but this information changes a lot. Based on that the
> > > > only platform with optional DT-node is the LS2K2000 GNET device. The
> > > > rest of the devices (GMACs and LS7A2000 GNET) must be equipped with a
> > > > node-pointer otherwise they won't work. Due to that the logic of the
> > > > patches
> > > > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > is incorrect.
> > > >
> > > > 1. [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > So this patch doesn't add a pure PCI-based probe procedure after all
> > > > because the Loongson GMACs are required to have a DT-node. AFAICS
> > > > pdev->irq is actually the IRQ retrieved from the DT-node. So the "if
> > > > (np) {} else {}" clause doesn't really make sense.
> > > >
> > > > 2. [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > First of all the function name is incorrect. The IRQ signal isn't legacy
> > > > (INTx-based), but is retrieved from the DT-node. Secondly the
> > > > "if (np) {} else {}" statement is very much redundant because if no
> > > > DT-node found the pdev->irq won't be initialized at all, and the
> > > > driver won't work with no error printed.
> > > >
> > > > All of that also affects the patch/commit logs. Glad we figured that
> > > > out at this stage. Seeing there have been tons of another comments
> > > > let's postpone the discussion around this problem for v13 then. I'll
> > > > keep in mind the info you shared in this thread and think of the way
> > > > to fix the patches after v13 is submitted for review.
> > > Let me clarify the interrupt information, hope that can help you to
> > > understand better:
> >
> > > 1, Loongson machines may use UEFI (implies ACPI) or PMON/UBOOT
> > > (implies FDT) as the BIOS.
> >
> > Ok. Aside with the OF-based platform there is an ACPI case.
> >
> > > 2, The BIOS type has no relationship with device types, which means:
> > > machines with GMAC can be either ACPI-based or FDT-based, machines
> > > with GNET can also be either ACPI-based or FDT-based.
> >
> > Ok. It's either-or. Got it.
> >
> > > 3, The existing Loongson driver can only support FDT, which means the
> > > device should be PCI-probed and DT-configured. Though the existing
> > > driver only supports GMAC, it doesn't mean that GMAC is bound to FDT.
> > > GMAC can also work with ACPI, in that case we say it is "full PCI",
> > > which means we don't need "np".
> >
> > "full PCI" statement can't be utilized for the case of the ACPI-based
> > IRQ assignment. "full PCI" is the way the GNET probe procedure works -
> > everything required for the device handling is detected in runtime
> > with no ACPI/DT stuff.
> >
> > So the patch 10 with the "full PCI"-related subject doesn't actually
> > adds the PCIe-only-based device probe support, but actually converts
> > the driver to supporting the ACPI-case.)

> Yes, the commit message can be improved.

Can be? It must be changed, because at the very least it's misleading,
but frankly speaking it now sounds just wrong.

> 
> >
> > > 4, At present, multi-channel devices support MSI, currently only GNET
> > > support MSI, but in future there may also GMAC support MSI.
> >
> > It's better to avoid adding a support for hypothetical devices and
> > prohibit all the currently unreal cases. It will simplify the code,
> > ease it' maintenance, reduce the bugs probability.
> >
> > > 5, So, in Yanteng's patches, a device firstly request MSI, and since
> > > MSI is dynamically allocated, it doesn't care about the BIOS type
> > > (ACPI or FDT). However, if MSI fails (either because MSI is exhausted
> > > or the device doesn't support it), it fallback to "legacy" interrupt,
> > > which means irq lines mapped to INT-A/B/C/D of PCI.
> >
> > Unless we are talking about the actual PCI devices (not PCI express)
> > or the cases where the INT-x is emulated by means the specific PCIe
> > TLPs, I wouldn't mentioned the INTx or "legacy" names in the current
> > context. It's just a platform ACPI/DT IRQs.

> Yes, it is probably a platform ACPI/DT IRQ, but I think the "legacy"
> name is still reasonable in this case.

Probably? These _are_ pure platform IRQs.

> Otherwise, what does "legacy"
> stand for in "PCI_IRQ_LEGACY/PCI_IRQ_MSI/PCI_IRQ_MSIX"?

It means that the platform IRQs has just been implemented via the
already available old-school API, which has been in the kernel since
the plain PCI devices. The platform IRQs and the traditional PCI INTx
are normally mutually exclusive, so I guess that's why they have been
implemented in framework of the same interface. Another reason could
be to have less troubles with adopting the PCI drivers for both type
of the IRQs delivery.

Moreover just recently the so called _legacy_ flag name has been
deprecated in favor of the more generic INTx one:
https://lore.kernel.org/linux-pci/20231122060406.14695-1-dlemoal@kernel.org/

Once again about the naming. From the retrospective point of view the
so called legacy PCI IRQs (in fact PCI INTx) and the platform IRQs
look similar because these are just the level-type signals connected
to the system IRQ controller. But when it comes to the PCI _Express_,
the implementation is completely different. The PCIe INTx is just the
PCIe TLPs of special type, like MSI. Upon receiving these special
messages the PCIe host controller delivers the IRQ up to the
respective system IRQ controller. So in order to avoid the confusion
between the actual legacy PCI INTx, PCI Express INTx and the just
platform IRQs, it's better to emphasize the actual way of the IRQs
delivery. In this case it's the later method.

> 
> >
> > > 6. In the legacy case, the irq is get from DT-node (FDT case), or
> > > already in pdev->irq (ACPI case).
> >
> > It will be in the pdev->irq in any case whether it's DT or ACPI. See:
> >
> > ACPI:
> > pci_device_probe():
> > +-> arch/loongarch/pci/pci.c:pcibios_alloc_irq()
> >
> > DT:
> > pci_device_probe():
> > +-> pci_assign_irq();
> >     +-> pci_host_bridge::map_irq()
> >         +-> of_irq_parse_and_map_pci()
> >         or in case of Loongson PCIe host controller:
> >         +-> drivers/pci/controller/pci-loongson.c::loongson_map_irq()
> >
> > Moreover unless the MSI IRQs are enabled, the platform IRQ (and the
> > legacy IRQ) can be retrieved by means of the pci_irq_vector() method.
> > The only reason of having the direct OF-based IRQs getting in the
> > Loongson DWMAC driver I see is that the LPI IRQ will be missing in
> > case of the pci_irq_vector() method utilization. In the rest of the
> > cases the pci_irq_vector() function could be freely used.
> Yes, in the DT case, they may be macirq, eth_wake_irq and eth_lpi,
> rather than a single irq, so we need an if-else here.
> 
> >
> > >  So Yanteng use a "if (np) { } else {
> > > }", which is reasonable from my point of view.
> > >
> >
> > At least one problem is there. What if pdev->irq isn't initialized
> > (initialized with zero)?..

> As you said above, both ACPI and DT initialized pdev->irq, unless
> there is a bug in BIOS.

I meant that based on the platform firmware nature the pdev->irq field
shall be initialized with an IRQ number in accordance with the DT or
ACPI logic. I never said it was impossible to have the field
uninitialized (that is being left zero). It's absolutely possible.
There are much more reasons to have that than just a firmware bug. On
the top of my mind: MSI being enabled, kernel misconfiguration, kernel
bug, DT/ACPI lacking the IRQ property, ...

-Serge(y)

> 
> 
> Huacai
> 
> >
> > > So Yanteng's interrupt code is good for me, but I also agree to
> > > improve that after v13, if needed.
> >
> > Ok. I've got much better picture about what is going on under the
> > hood. Thanks. In anyway I'll get back to this topic in details in v13.
> >
> > -Serge(y)
> >
> > >
> > > Huacai
> > >
> > > >
> > > > Thanks
> > > > -Serge(y)
> > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Yanteng
> > > > >

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Huacai Chen]

Hi, Serge,

On Tue, May 14, 2024 at 7:33 PM Serge Semin <fancer.lancer@gmail.com> wrote:
>
> On Tue, May 14, 2024 at 12:58:33PM +0800, Huacai Chen wrote:
> > On Tue, May 14, 2024 at 12:11 AM Serge Semin <fancer.lancer@gmail.com> wrote:
> > >
> > > On Mon, May 13, 2024 at 09:26:11PM +0800, Huacai Chen wrote:
> > > > Hi, Serge,
> > > >
> > > > On Mon, May 13, 2024 at 6:57 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> > > > >
> > > > > On Thu, May 09, 2024 at 04:57:44PM +0800, Yanteng Si wrote:
> > > > > > Hi Serge
> > > > > >
> ...
> > > > >
> > > > > > No, only devices that support multiple channels can deliver both PCI MSI
> > > > > > IRQs
> > > > > >
> > > > > > and direct GIC IRQs, other devices can only deliver GIC IRQs.
> > > > > >
> > > > > > Furthermore, multiple channel features are bundled with MSI. If we want to
> > > > > >
> > > > > > enable multiple channels, we must enable MSI.
> > > > >
> > > > > Sadly to say but this information changes a lot. Based on that the
> > > > > only platform with optional DT-node is the LS2K2000 GNET device. The
> > > > > rest of the devices (GMACs and LS7A2000 GNET) must be equipped with a
> > > > > node-pointer otherwise they won't work. Due to that the logic of the
> > > > > patches
> > > > > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > > is incorrect.
> > > > >
> > > > > 1. [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > > So this patch doesn't add a pure PCI-based probe procedure after all
> > > > > because the Loongson GMACs are required to have a DT-node. AFAICS
> > > > > pdev->irq is actually the IRQ retrieved from the DT-node. So the "if
> > > > > (np) {} else {}" clause doesn't really make sense.
> > > > >
> > > > > 2. [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > > First of all the function name is incorrect. The IRQ signal isn't legacy
> > > > > (INTx-based), but is retrieved from the DT-node. Secondly the
> > > > > "if (np) {} else {}" statement is very much redundant because if no
> > > > > DT-node found the pdev->irq won't be initialized at all, and the
> > > > > driver won't work with no error printed.
> > > > >
> > > > > All of that also affects the patch/commit logs. Glad we figured that
> > > > > out at this stage. Seeing there have been tons of another comments
> > > > > let's postpone the discussion around this problem for v13 then. I'll
> > > > > keep in mind the info you shared in this thread and think of the way
> > > > > to fix the patches after v13 is submitted for review.
> > > > Let me clarify the interrupt information, hope that can help you to
> > > > understand better:
> > >
> > > > 1, Loongson machines may use UEFI (implies ACPI) or PMON/UBOOT
> > > > (implies FDT) as the BIOS.
> > >
> > > Ok. Aside with the OF-based platform there is an ACPI case.
> > >
> > > > 2, The BIOS type has no relationship with device types, which means:
> > > > machines with GMAC can be either ACPI-based or FDT-based, machines
> > > > with GNET can also be either ACPI-based or FDT-based.
> > >
> > > Ok. It's either-or. Got it.
> > >
> > > > 3, The existing Loongson driver can only support FDT, which means the
> > > > device should be PCI-probed and DT-configured. Though the existing
> > > > driver only supports GMAC, it doesn't mean that GMAC is bound to FDT.
> > > > GMAC can also work with ACPI, in that case we say it is "full PCI",
> > > > which means we don't need "np".
> > >
> > > "full PCI" statement can't be utilized for the case of the ACPI-based
> > > IRQ assignment. "full PCI" is the way the GNET probe procedure works -
> > > everything required for the device handling is detected in runtime
> > > with no ACPI/DT stuff.
> > >
> > > So the patch 10 with the "full PCI"-related subject doesn't actually
> > > adds the PCIe-only-based device probe support, but actually converts
> > > the driver to supporting the ACPI-case.)
>
> > Yes, the commit message can be improved.
>
> Can be? It must be changed, because at the very least it's misleading,
> but frankly speaking it now sounds just wrong.
Sit back and relax. :)
I agree with your opinion, but we don't need to so abolute, yes?

>
> >
> > >
> > > > 4, At present, multi-channel devices support MSI, currently only GNET
> > > > support MSI, but in future there may also GMAC support MSI.
> > >
> > > It's better to avoid adding a support for hypothetical devices and
> > > prohibit all the currently unreal cases. It will simplify the code,
> > > ease it' maintenance, reduce the bugs probability.
> > >
> > > > 5, So, in Yanteng's patches, a device firstly request MSI, and since
> > > > MSI is dynamically allocated, it doesn't care about the BIOS type
> > > > (ACPI or FDT). However, if MSI fails (either because MSI is exhausted
> > > > or the device doesn't support it), it fallback to "legacy" interrupt,
> > > > which means irq lines mapped to INT-A/B/C/D of PCI.
> > >
> > > Unless we are talking about the actual PCI devices (not PCI express)
> > > or the cases where the INT-x is emulated by means the specific PCIe
> > > TLPs, I wouldn't mentioned the INTx or "legacy" names in the current
> > > context. It's just a platform ACPI/DT IRQs.
>
> > Yes, it is probably a platform ACPI/DT IRQ, but I think the "legacy"
> > name is still reasonable in this case.
>
> Probably? These _are_ pure platform IRQs.
>
> > Otherwise, what does "legacy"
> > stand for in "PCI_IRQ_LEGACY/PCI_IRQ_MSI/PCI_IRQ_MSIX"?
>
> It means that the platform IRQs has just been implemented via the
> already available old-school API, which has been in the kernel since
> the plain PCI devices. The platform IRQs and the traditional PCI INTx
> are normally mutually exclusive, so I guess that's why they have been
> implemented in framework of the same interface. Another reason could
> be to have less troubles with adopting the PCI drivers for both type
> of the IRQs delivery.
>
> Moreover just recently the so called _legacy_ flag name has been
> deprecated in favor of the more generic INTx one:
> https://lore.kernel.org/linux-pci/20231122060406.14695-1-dlemoal@kernel.org/
This info is important, but your last suggestion for Yanteng still use
PCI_IRQ_LEGACY. :)

>
> Once again about the naming. From the retrospective point of view the
> so called legacy PCI IRQs (in fact PCI INTx) and the platform IRQs
> look similar because these are just the level-type signals connected
> to the system IRQ controller. But when it comes to the PCI _Express_,
> the implementation is completely different. The PCIe INTx is just the
> PCIe TLPs of special type, like MSI. Upon receiving these special
> messages the PCIe host controller delivers the IRQ up to the
> respective system IRQ controller. So in order to avoid the confusion
> between the actual legacy PCI INTx, PCI Express INTx and the just
> platform IRQs, it's better to emphasize the actual way of the IRQs
> delivery. In this case it's the later method.
You are absolutely right, and I think I found a method to use your
framework to solve our problems:

   static int loongson_dwmac_config_irqs(struct pci_dev *pdev,
                                          struct plat_stmmacenet_data *plat,
                                          struct stmmac_resources *res)
   {
       int i, ret, vecs;

       /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
        * --------- ----- -------- --------  ...  -------- --------
        * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
        */
       vecs = plat->rx_queues_to_use + plat->tx_queues_to_use + 1;
       ret = pci_alloc_irq_vectors(pdev, 1, vecs, PCI_IRQ_MSI | PCI_IRQ_INTX);
       if (ret < 0) {
               dev_err(&pdev->dev, "Failed to allocate PCI IRQs\n");
               return ret;
       }
      if (ret >= vecs) {
               for (i = 0; i < plat->rx_queues_to_use; i++) {
                       res->rx_irq[CHANNELS_NUM - 1 - i] =
                               pci_irq_vector(pdev, 1 + i * 2);
               }
               for (i = 0; i < plat->tx_queues_to_use; i++) {
                       res->tx_irq[CHANNELS_NUM - 1 - i] =
                               pci_irq_vector(pdev, 2 + i * 2);
               }

               plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
       }

       res->irq = pci_irq_vector(pdev, 0);

     if (np) {
         res->irq = of_irq_get_byname(np, "macirq");
         if (res->irq < 0) {
            dev_err(&pdev->dev, "IRQ macirq not found\n");
            return -ENODEV;
         }

         res->wol_irq = of_irq_get_byname(np, "eth_wake_irq");
         if (res->wol_irq < 0) {
            dev_info(&pdev->dev,
                 "IRQ eth_wake_irq not found, using macirq\n");
            res->wol_irq = res->irq;
         }

         res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
         if (res->lpi_irq < 0) {
            dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
            return -ENODEV;
         }
     }
       return 0;
   }

If your agree, Yanteng can use this method in V13, then avoid furthur changes.

Huacai

>
> >
> > >
> > > > 6. In the legacy case, the irq is get from DT-node (FDT case), or
> > > > already in pdev->irq (ACPI case).
> > >
> > > It will be in the pdev->irq in any case whether it's DT or ACPI. See:
> > >
> > > ACPI:
> > > pci_device_probe():
> > > +-> arch/loongarch/pci/pci.c:pcibios_alloc_irq()
> > >
> > > DT:
> > > pci_device_probe():
> > > +-> pci_assign_irq();
> > >     +-> pci_host_bridge::map_irq()
> > >         +-> of_irq_parse_and_map_pci()
> > >         or in case of Loongson PCIe host controller:
> > >         +-> drivers/pci/controller/pci-loongson.c::loongson_map_irq()
> > >
> > > Moreover unless the MSI IRQs are enabled, the platform IRQ (and the
> > > legacy IRQ) can be retrieved by means of the pci_irq_vector() method.
> > > The only reason of having the direct OF-based IRQs getting in the
> > > Loongson DWMAC driver I see is that the LPI IRQ will be missing in
> > > case of the pci_irq_vector() method utilization. In the rest of the
> > > cases the pci_irq_vector() function could be freely used.
> > Yes, in the DT case, they may be macirq, eth_wake_irq and eth_lpi,
> > rather than a single irq, so we need an if-else here.
> >
> > >
> > > >  So Yanteng use a "if (np) { } else {
> > > > }", which is reasonable from my point of view.
> > > >
> > >
> > > At least one problem is there. What if pdev->irq isn't initialized
> > > (initialized with zero)?..
>
> > As you said above, both ACPI and DT initialized pdev->irq, unless
> > there is a bug in BIOS.
>
> I meant that based on the platform firmware nature the pdev->irq field
> shall be initialized with an IRQ number in accordance with the DT or
> ACPI logic. I never said it was impossible to have the field
> uninitialized (that is being left zero). It's absolutely possible.
> There are much more reasons to have that than just a firmware bug. On
> the top of my mind: MSI being enabled, kernel misconfiguration, kernel
> bug, DT/ACPI lacking the IRQ property, ...
>
> -Serge(y)
>
> >
> >
> > Huacai
> >
> > >
> > > > So Yanteng's interrupt code is good for me, but I also agree to
> > > > improve that after v13, if needed.
> > >
> > > Ok. I've got much better picture about what is going on under the
> > > hood. Thanks. In anyway I'll get back to this topic in details in v13.
> > >
> > > -Serge(y)
> > >
> > > >
> > > > Huacai
> > > >
> > > > >
> > > > > Thanks
> > > > > -Serge(y)
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Yanteng
> > > > > >

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Serge Semin]

On Tue, May 14, 2024 at 08:53:46PM +0800, Huacai Chen wrote:
> Hi, Serge,
> 
> On Tue, May 14, 2024 at 7:33 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> >
> > On Tue, May 14, 2024 at 12:58:33PM +0800, Huacai Chen wrote:
> > > On Tue, May 14, 2024 at 12:11 AM Serge Semin <fancer.lancer@gmail.com> wrote:
> > > >
> > > > On Mon, May 13, 2024 at 09:26:11PM +0800, Huacai Chen wrote:
> > > > > Hi, Serge,
> > > > >
> > > > > On Mon, May 13, 2024 at 6:57 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> > > > > >
> > > > > > On Thu, May 09, 2024 at 04:57:44PM +0800, Yanteng Si wrote:
> > > > > > > Hi Serge
> > > > > > >
> > ...
> > > > > >
> > > > > > > No, only devices that support multiple channels can deliver both PCI MSI
> > > > > > > IRQs
> > > > > > >
> > > > > > > and direct GIC IRQs, other devices can only deliver GIC IRQs.
> > > > > > >
> > > > > > > Furthermore, multiple channel features are bundled with MSI. If we want to
> > > > > > >
> > > > > > > enable multiple channels, we must enable MSI.
> > > > > >
> > > > > > Sadly to say but this information changes a lot. Based on that the
> > > > > > only platform with optional DT-node is the LS2K2000 GNET device. The
> > > > > > rest of the devices (GMACs and LS7A2000 GNET) must be equipped with a
> > > > > > node-pointer otherwise they won't work. Due to that the logic of the
> > > > > > patches
> > > > > > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > > > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > > > is incorrect.
> > > > > >
> > > > > > 1. [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > > > So this patch doesn't add a pure PCI-based probe procedure after all
> > > > > > because the Loongson GMACs are required to have a DT-node. AFAICS
> > > > > > pdev->irq is actually the IRQ retrieved from the DT-node. So the "if
> > > > > > (np) {} else {}" clause doesn't really make sense.
> > > > > >
> > > > > > 2. [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > > > First of all the function name is incorrect. The IRQ signal isn't legacy
> > > > > > (INTx-based), but is retrieved from the DT-node. Secondly the
> > > > > > "if (np) {} else {}" statement is very much redundant because if no
> > > > > > DT-node found the pdev->irq won't be initialized at all, and the
> > > > > > driver won't work with no error printed.
> > > > > >
> > > > > > All of that also affects the patch/commit logs. Glad we figured that
> > > > > > out at this stage. Seeing there have been tons of another comments
> > > > > > let's postpone the discussion around this problem for v13 then. I'll
> > > > > > keep in mind the info you shared in this thread and think of the way
> > > > > > to fix the patches after v13 is submitted for review.
> > > > > Let me clarify the interrupt information, hope that can help you to
> > > > > understand better:
> > > >
> > > > > 1, Loongson machines may use UEFI (implies ACPI) or PMON/UBOOT
> > > > > (implies FDT) as the BIOS.
> > > >
> > > > Ok. Aside with the OF-based platform there is an ACPI case.
> > > >
> > > > > 2, The BIOS type has no relationship with device types, which means:
> > > > > machines with GMAC can be either ACPI-based or FDT-based, machines
> > > > > with GNET can also be either ACPI-based or FDT-based.
> > > >
> > > > Ok. It's either-or. Got it.
> > > >
> > > > > 3, The existing Loongson driver can only support FDT, which means the
> > > > > device should be PCI-probed and DT-configured. Though the existing
> > > > > driver only supports GMAC, it doesn't mean that GMAC is bound to FDT.
> > > > > GMAC can also work with ACPI, in that case we say it is "full PCI",
> > > > > which means we don't need "np".
> > > >
> > > > "full PCI" statement can't be utilized for the case of the ACPI-based
> > > > IRQ assignment. "full PCI" is the way the GNET probe procedure works -
> > > > everything required for the device handling is detected in runtime
> > > > with no ACPI/DT stuff.
> > > >
> > > > So the patch 10 with the "full PCI"-related subject doesn't actually
> > > > adds the PCIe-only-based device probe support, but actually converts
> > > > the driver to supporting the ACPI-case.)
> >
> > > Yes, the commit message can be improved.
> >
> > Can be? It must be changed, because at the very least it's misleading,
> > but frankly speaking it now sounds just wrong.

> Sit back and relax. :)

The smiley enclosing your epigram doesn't make it appropriate. Please
refrain from familiarity in our future discussions.

> I agree with your opinion, but we don't need to so abolute, yes?
> 
> >
> > >
> > > >
> > > > > 4, At present, multi-channel devices support MSI, currently only GNET
> > > > > support MSI, but in future there may also GMAC support MSI.
> > > >
> > > > It's better to avoid adding a support for hypothetical devices and
> > > > prohibit all the currently unreal cases. It will simplify the code,
> > > > ease it' maintenance, reduce the bugs probability.
> > > >
> > > > > 5, So, in Yanteng's patches, a device firstly request MSI, and since
> > > > > MSI is dynamically allocated, it doesn't care about the BIOS type
> > > > > (ACPI or FDT). However, if MSI fails (either because MSI is exhausted
> > > > > or the device doesn't support it), it fallback to "legacy" interrupt,
> > > > > which means irq lines mapped to INT-A/B/C/D of PCI.
> > > >
> > > > Unless we are talking about the actual PCI devices (not PCI express)
> > > > or the cases where the INT-x is emulated by means the specific PCIe
> > > > TLPs, I wouldn't mentioned the INTx or "legacy" names in the current
> > > > context. It's just a platform ACPI/DT IRQs.
> >
> > > Yes, it is probably a platform ACPI/DT IRQ, but I think the "legacy"
> > > name is still reasonable in this case.
> >
> > Probably? These _are_ pure platform IRQs.
> >
> > > Otherwise, what does "legacy"
> > > stand for in "PCI_IRQ_LEGACY/PCI_IRQ_MSI/PCI_IRQ_MSIX"?
> >
> > It means that the platform IRQs has just been implemented via the
> > already available old-school API, which has been in the kernel since
> > the plain PCI devices. The platform IRQs and the traditional PCI INTx
> > are normally mutually exclusive, so I guess that's why they have been
> > implemented in framework of the same interface. Another reason could
> > be to have less troubles with adopting the PCI drivers for both type
> > of the IRQs delivery.
> >
> > Moreover just recently the so called _legacy_ flag name has been
> > deprecated in favor of the more generic INTx one:
> > https://lore.kernel.org/linux-pci/20231122060406.14695-1-dlemoal@kernel.org/

> This info is important, but your last suggestion for Yanteng still use
> PCI_IRQ_LEGACY. :)

Yes, my mistake. It should be replaced with PCI_IRQ_INTX.

> 
> >
> > Once again about the naming. From the retrospective point of view the
> > so called legacy PCI IRQs (in fact PCI INTx) and the platform IRQs
> > look similar because these are just the level-type signals connected
> > to the system IRQ controller. But when it comes to the PCI _Express_,
> > the implementation is completely different. The PCIe INTx is just the
> > PCIe TLPs of special type, like MSI. Upon receiving these special
> > messages the PCIe host controller delivers the IRQ up to the
> > respective system IRQ controller. So in order to avoid the confusion
> > between the actual legacy PCI INTx, PCI Express INTx and the just
> > platform IRQs, it's better to emphasize the actual way of the IRQs
> > delivery. In this case it's the later method.
> You are absolutely right, and I think I found a method to use your
> framework to solve our problems:
> 
>    static int loongson_dwmac_config_irqs(struct pci_dev *pdev,
>                                           struct plat_stmmacenet_data *plat,
>                                           struct stmmac_resources *res)
>    {
>        int i, ret, vecs;
> 
>        /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
>         * --------- ----- -------- --------  ...  -------- --------
>         * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
>         */
>        vecs = plat->rx_queues_to_use + plat->tx_queues_to_use + 1;
>        ret = pci_alloc_irq_vectors(pdev, 1, vecs, PCI_IRQ_MSI | PCI_IRQ_INTX);
>        if (ret < 0) {
>                dev_err(&pdev->dev, "Failed to allocate PCI IRQs\n");
>                return ret;
>        }
>       if (ret >= vecs) {
>                for (i = 0; i < plat->rx_queues_to_use; i++) {
>                        res->rx_irq[CHANNELS_NUM - 1 - i] =
>                                pci_irq_vector(pdev, 1 + i * 2);
>                }
>                for (i = 0; i < plat->tx_queues_to_use; i++) {
>                        res->tx_irq[CHANNELS_NUM - 1 - i] =
>                                pci_irq_vector(pdev, 2 + i * 2);
>                }
> 
>                plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
>        }
> 
>        res->irq = pci_irq_vector(pdev, 0);
> 
>      if (np) {
>          res->irq = of_irq_get_byname(np, "macirq");
>          if (res->irq < 0) {
>             dev_err(&pdev->dev, "IRQ macirq not found\n");
>             return -ENODEV;
>          }
> 
>          res->wol_irq = of_irq_get_byname(np, "eth_wake_irq");
>          if (res->wol_irq < 0) {
>             dev_info(&pdev->dev,
>                  "IRQ eth_wake_irq not found, using macirq\n");
>             res->wol_irq = res->irq;
>          }
> 
>          res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
>          if (res->lpi_irq < 0) {
>             dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
>             return -ENODEV;
>          }
>      }
>        return 0;
>    }
> 
> If your agree, Yanteng can use this method in V13, then avoid furthur changes.

Since yesterday I have been too relaxed sitting back to explain in
detail the problems with the code above. Shortly speaking, no to the
method designed as above.

-Serge(y)

> 
> Huacai
> 
> >
> > >
> > > >
> > > > > 6. In the legacy case, the irq is get from DT-node (FDT case), or
> > > > > already in pdev->irq (ACPI case).
> > > >
> > > > It will be in the pdev->irq in any case whether it's DT or ACPI. See:
> > > >
> > > > ACPI:
> > > > pci_device_probe():
> > > > +-> arch/loongarch/pci/pci.c:pcibios_alloc_irq()
> > > >
> > > > DT:
> > > > pci_device_probe():
> > > > +-> pci_assign_irq();
> > > >     +-> pci_host_bridge::map_irq()
> > > >         +-> of_irq_parse_and_map_pci()
> > > >         or in case of Loongson PCIe host controller:
> > > >         +-> drivers/pci/controller/pci-loongson.c::loongson_map_irq()
> > > >
> > > > Moreover unless the MSI IRQs are enabled, the platform IRQ (and the
> > > > legacy IRQ) can be retrieved by means of the pci_irq_vector() method.
> > > > The only reason of having the direct OF-based IRQs getting in the
> > > > Loongson DWMAC driver I see is that the LPI IRQ will be missing in
> > > > case of the pci_irq_vector() method utilization. In the rest of the
> > > > cases the pci_irq_vector() function could be freely used.
> > > Yes, in the DT case, they may be macirq, eth_wake_irq and eth_lpi,
> > > rather than a single irq, so we need an if-else here.
> > >
> > > >
> > > > >  So Yanteng use a "if (np) { } else {
> > > > > }", which is reasonable from my point of view.
> > > > >
> > > >
> > > > At least one problem is there. What if pdev->irq isn't initialized
> > > > (initialized with zero)?..
> >
> > > As you said above, both ACPI and DT initialized pdev->irq, unless
> > > there is a bug in BIOS.
> >
> > I meant that based on the platform firmware nature the pdev->irq field
> > shall be initialized with an IRQ number in accordance with the DT or
> > ACPI logic. I never said it was impossible to have the field
> > uninitialized (that is being left zero). It's absolutely possible.
> > There are much more reasons to have that than just a firmware bug. On
> > the top of my mind: MSI being enabled, kernel misconfiguration, kernel
> > bug, DT/ACPI lacking the IRQ property, ...
> >
> > -Serge(y)
> >
> > >
> > >
> > > Huacai
> > >
> > > >
> > > > > So Yanteng's interrupt code is good for me, but I also agree to
> > > > > improve that after v13, if needed.
> > > >
> > > > Ok. I've got much better picture about what is going on under the
> > > > hood. Thanks. In anyway I'll get back to this topic in details in v13.
> > > >
> > > > -Serge(y)
> > > >
> > > > >
> > > > > Huacai
> > > > >
> > > > > >
> > > > > > Thanks
> > > > > > -Serge(y)
> > > > > >
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Yanteng
> > > > > > >

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Huacai Chen]

On Wed, May 15, 2024 at 4:40 PM Serge Semin <fancer.lancer@gmail.com> wrote:
>
> On Tue, May 14, 2024 at 08:53:46PM +0800, Huacai Chen wrote:
> > Hi, Serge,
> >
> > On Tue, May 14, 2024 at 7:33 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> > >
> > > On Tue, May 14, 2024 at 12:58:33PM +0800, Huacai Chen wrote:
> > > > On Tue, May 14, 2024 at 12:11 AM Serge Semin <fancer.lancer@gmail.com> wrote:
> > > > >
> > > > > On Mon, May 13, 2024 at 09:26:11PM +0800, Huacai Chen wrote:
> > > > > > Hi, Serge,
> > > > > >
> > > > > > On Mon, May 13, 2024 at 6:57 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> > > > > > >
> > > > > > > On Thu, May 09, 2024 at 04:57:44PM +0800, Yanteng Si wrote:
> > > > > > > > Hi Serge
> > > > > > > >
> > > ...
> > > > > > >
> > > > > > > > No, only devices that support multiple channels can deliver both PCI MSI
> > > > > > > > IRQs
> > > > > > > >
> > > > > > > > and direct GIC IRQs, other devices can only deliver GIC IRQs.
> > > > > > > >
> > > > > > > > Furthermore, multiple channel features are bundled with MSI. If we want to
> > > > > > > >
> > > > > > > > enable multiple channels, we must enable MSI.
> > > > > > >
> > > > > > > Sadly to say but this information changes a lot. Based on that the
> > > > > > > only platform with optional DT-node is the LS2K2000 GNET device. The
> > > > > > > rest of the devices (GMACs and LS7A2000 GNET) must be equipped with a
> > > > > > > node-pointer otherwise they won't work. Due to that the logic of the
> > > > > > > patches
> > > > > > > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > > > > [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > > > > is incorrect.
> > > > > > >
> > > > > > > 1. [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > > > > > > So this patch doesn't add a pure PCI-based probe procedure after all
> > > > > > > because the Loongson GMACs are required to have a DT-node. AFAICS
> > > > > > > pdev->irq is actually the IRQ retrieved from the DT-node. So the "if
> > > > > > > (np) {} else {}" clause doesn't really make sense.
> > > > > > >
> > > > > > > 2. [PATCH net-next v12 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_config_legacy
> > > > > > > First of all the function name is incorrect. The IRQ signal isn't legacy
> > > > > > > (INTx-based), but is retrieved from the DT-node. Secondly the
> > > > > > > "if (np) {} else {}" statement is very much redundant because if no
> > > > > > > DT-node found the pdev->irq won't be initialized at all, and the
> > > > > > > driver won't work with no error printed.
> > > > > > >
> > > > > > > All of that also affects the patch/commit logs. Glad we figured that
> > > > > > > out at this stage. Seeing there have been tons of another comments
> > > > > > > let's postpone the discussion around this problem for v13 then. I'll
> > > > > > > keep in mind the info you shared in this thread and think of the way
> > > > > > > to fix the patches after v13 is submitted for review.
> > > > > > Let me clarify the interrupt information, hope that can help you to
> > > > > > understand better:
> > > > >
> > > > > > 1, Loongson machines may use UEFI (implies ACPI) or PMON/UBOOT
> > > > > > (implies FDT) as the BIOS.
> > > > >
> > > > > Ok. Aside with the OF-based platform there is an ACPI case.
> > > > >
> > > > > > 2, The BIOS type has no relationship with device types, which means:
> > > > > > machines with GMAC can be either ACPI-based or FDT-based, machines
> > > > > > with GNET can also be either ACPI-based or FDT-based.
> > > > >
> > > > > Ok. It's either-or. Got it.
> > > > >
> > > > > > 3, The existing Loongson driver can only support FDT, which means the
> > > > > > device should be PCI-probed and DT-configured. Though the existing
> > > > > > driver only supports GMAC, it doesn't mean that GMAC is bound to FDT.
> > > > > > GMAC can also work with ACPI, in that case we say it is "full PCI",
> > > > > > which means we don't need "np".
> > > > >
> > > > > "full PCI" statement can't be utilized for the case of the ACPI-based
> > > > > IRQ assignment. "full PCI" is the way the GNET probe procedure works -
> > > > > everything required for the device handling is detected in runtime
> > > > > with no ACPI/DT stuff.
> > > > >
> > > > > So the patch 10 with the "full PCI"-related subject doesn't actually
> > > > > adds the PCIe-only-based device probe support, but actually converts
> > > > > the driver to supporting the ACPI-case.)
> > >
> > > > Yes, the commit message can be improved.
> > >
> > > Can be? It must be changed, because at the very least it's misleading,
> > > but frankly speaking it now sounds just wrong.
>
> > Sit back and relax. :)
>
> The smiley enclosing your epigram doesn't make it appropriate. Please
> refrain from familiarity in our future discussions.
>
> > I agree with your opinion, but we don't need to so abolute, yes?
> >
> > >
> > > >
> > > > >
> > > > > > 4, At present, multi-channel devices support MSI, currently only GNET
> > > > > > support MSI, but in future there may also GMAC support MSI.
> > > > >
> > > > > It's better to avoid adding a support for hypothetical devices and
> > > > > prohibit all the currently unreal cases. It will simplify the code,
> > > > > ease it' maintenance, reduce the bugs probability.
> > > > >
> > > > > > 5, So, in Yanteng's patches, a device firstly request MSI, and since
> > > > > > MSI is dynamically allocated, it doesn't care about the BIOS type
> > > > > > (ACPI or FDT). However, if MSI fails (either because MSI is exhausted
> > > > > > or the device doesn't support it), it fallback to "legacy" interrupt,
> > > > > > which means irq lines mapped to INT-A/B/C/D of PCI.
> > > > >
> > > > > Unless we are talking about the actual PCI devices (not PCI express)
> > > > > or the cases where the INT-x is emulated by means the specific PCIe
> > > > > TLPs, I wouldn't mentioned the INTx or "legacy" names in the current
> > > > > context. It's just a platform ACPI/DT IRQs.
> > >
> > > > Yes, it is probably a platform ACPI/DT IRQ, but I think the "legacy"
> > > > name is still reasonable in this case.
> > >
> > > Probably? These _are_ pure platform IRQs.
> > >
> > > > Otherwise, what does "legacy"
> > > > stand for in "PCI_IRQ_LEGACY/PCI_IRQ_MSI/PCI_IRQ_MSIX"?
> > >
> > > It means that the platform IRQs has just been implemented via the
> > > already available old-school API, which has been in the kernel since
> > > the plain PCI devices. The platform IRQs and the traditional PCI INTx
> > > are normally mutually exclusive, so I guess that's why they have been
> > > implemented in framework of the same interface. Another reason could
> > > be to have less troubles with adopting the PCI drivers for both type
> > > of the IRQs delivery.
> > >
> > > Moreover just recently the so called _legacy_ flag name has been
> > > deprecated in favor of the more generic INTx one:
> > > https://lore.kernel.org/linux-pci/20231122060406.14695-1-dlemoal@kernel.org/
>
> > This info is important, but your last suggestion for Yanteng still use
> > PCI_IRQ_LEGACY. :)
>
> Yes, my mistake. It should be replaced with PCI_IRQ_INTX.
>
> >
> > >
> > > Once again about the naming. From the retrospective point of view the
> > > so called legacy PCI IRQs (in fact PCI INTx) and the platform IRQs
> > > look similar because these are just the level-type signals connected
> > > to the system IRQ controller. But when it comes to the PCI _Express_,
> > > the implementation is completely different. The PCIe INTx is just the
> > > PCIe TLPs of special type, like MSI. Upon receiving these special
> > > messages the PCIe host controller delivers the IRQ up to the
> > > respective system IRQ controller. So in order to avoid the confusion
> > > between the actual legacy PCI INTx, PCI Express INTx and the just
> > > platform IRQs, it's better to emphasize the actual way of the IRQs
> > > delivery. In this case it's the later method.
> > You are absolutely right, and I think I found a method to use your
> > framework to solve our problems:
> >
> >    static int loongson_dwmac_config_irqs(struct pci_dev *pdev,
> >                                           struct plat_stmmacenet_data *plat,
> >                                           struct stmmac_resources *res)
> >    {
> >        int i, ret, vecs;
> >
> >        /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> >         * --------- ----- -------- --------  ...  -------- --------
> >         * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> >         */
> >        vecs = plat->rx_queues_to_use + plat->tx_queues_to_use + 1;
> >        ret = pci_alloc_irq_vectors(pdev, 1, vecs, PCI_IRQ_MSI | PCI_IRQ_INTX);
> >        if (ret < 0) {
> >                dev_err(&pdev->dev, "Failed to allocate PCI IRQs\n");
> >                return ret;
> >        }
> >       if (ret >= vecs) {
> >                for (i = 0; i < plat->rx_queues_to_use; i++) {
> >                        res->rx_irq[CHANNELS_NUM - 1 - i] =
> >                                pci_irq_vector(pdev, 1 + i * 2);
> >                }
> >                for (i = 0; i < plat->tx_queues_to_use; i++) {
> >                        res->tx_irq[CHANNELS_NUM - 1 - i] =
> >                                pci_irq_vector(pdev, 2 + i * 2);
> >                }
> >
> >                plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> >        }
> >
> >        res->irq = pci_irq_vector(pdev, 0);
> >
> >      if (np) {
> >          res->irq = of_irq_get_byname(np, "macirq");
> >          if (res->irq < 0) {
> >             dev_err(&pdev->dev, "IRQ macirq not found\n");
> >             return -ENODEV;
> >          }
> >
> >          res->wol_irq = of_irq_get_byname(np, "eth_wake_irq");
> >          if (res->wol_irq < 0) {
> >             dev_info(&pdev->dev,
> >                  "IRQ eth_wake_irq not found, using macirq\n");
> >             res->wol_irq = res->irq;
> >          }
> >
> >          res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
> >          if (res->lpi_irq < 0) {
> >             dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
> >             return -ENODEV;
> >          }
> >      }
> >        return 0;
> >    }
> >
> > If your agree, Yanteng can use this method in V13, then avoid furthur changes.
>
> Since yesterday I have been too relaxed sitting back to explain in
> detail the problems with the code above. Shortly speaking, no to the
> method designed as above.
This function is copy-paste from your version which you suggest to
Yanteng, and plus the fallback parts for DT. If you don't want to
discuss it any more, we can discuss after V13.

BTW, we cannot remove "res->wol_irq = res->irq", because Loongson
GMAC/GNET indeed supports WoL.

Huacai

>
> -Serge(y)
>
> >
> > Huacai
> >
> > >
> > > >
> > > > >
> > > > > > 6. In the legacy case, the irq is get from DT-node (FDT case), or
> > > > > > already in pdev->irq (ACPI case).
> > > > >
> > > > > It will be in the pdev->irq in any case whether it's DT or ACPI. See:
> > > > >
> > > > > ACPI:
> > > > > pci_device_probe():
> > > > > +-> arch/loongarch/pci/pci.c:pcibios_alloc_irq()
> > > > >
> > > > > DT:
> > > > > pci_device_probe():
> > > > > +-> pci_assign_irq();
> > > > >     +-> pci_host_bridge::map_irq()
> > > > >         +-> of_irq_parse_and_map_pci()
> > > > >         or in case of Loongson PCIe host controller:
> > > > >         +-> drivers/pci/controller/pci-loongson.c::loongson_map_irq()
> > > > >
> > > > > Moreover unless the MSI IRQs are enabled, the platform IRQ (and the
> > > > > legacy IRQ) can be retrieved by means of the pci_irq_vector() method.
> > > > > The only reason of having the direct OF-based IRQs getting in the
> > > > > Loongson DWMAC driver I see is that the LPI IRQ will be missing in
> > > > > case of the pci_irq_vector() method utilization. In the rest of the
> > > > > cases the pci_irq_vector() function could be freely used.
> > > > Yes, in the DT case, they may be macirq, eth_wake_irq and eth_lpi,
> > > > rather than a single irq, so we need an if-else here.
> > > >
> > > > >
> > > > > >  So Yanteng use a "if (np) { } else {
> > > > > > }", which is reasonable from my point of view.
> > > > > >
> > > > >
> > > > > At least one problem is there. What if pdev->irq isn't initialized
> > > > > (initialized with zero)?..
> > >
> > > > As you said above, both ACPI and DT initialized pdev->irq, unless
> > > > there is a bug in BIOS.
> > >
> > > I meant that based on the platform firmware nature the pdev->irq field
> > > shall be initialized with an IRQ number in accordance with the DT or
> > > ACPI logic. I never said it was impossible to have the field
> > > uninitialized (that is being left zero). It's absolutely possible.
> > > There are much more reasons to have that than just a firmware bug. On
> > > the top of my mind: MSI being enabled, kernel misconfiguration, kernel
> > > bug, DT/ACPI lacking the IRQ property, ...
> > >
> > > -Serge(y)
> > >
> > > >
> > > >
> > > > Huacai
> > > >
> > > > >
> > > > > > So Yanteng's interrupt code is good for me, but I also agree to
> > > > > > improve that after v13, if needed.
> > > > >
> > > > > Ok. I've got much better picture about what is going on under the
> > > > > hood. Thanks. In anyway I'll get back to this topic in details in v13.
> > > > >
> > > > > -Serge(y)
> > > > >
> > > > > >
> > > > > > Huacai
> > > > > >
> > > > > > >
> > > > > > > Thanks
> > > > > > > -Serge(y)
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Yanteng
> > > > > > > >

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Yanteng Si]

Well, let's modify the biggest patch。

在 2024/5/6 05:50, Serge Semin 写道:
> On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
>> There are two types of Loongson DWGMAC. The first type shares the same
> s/Loongson DWGMAC/Loongson GNET controllers
OK,
>
>> register definitions and has similar logic as dwmac1000. The second type
>> uses several different register definitions, we think it is necessary to
>> distinguish rx and tx, so we split these bits into two.
> s/rx/Rx
> s/tx/Tx

OK.

>> Simply put, we split some single bit fields into double bits fileds:
>>
>>       Name              Tx          Rx
>>
>> DMA_INTR_ENA_NIE = 0x00040000 | 0x00020000;
>> DMA_INTR_ENA_AIE = 0x00010000 | 0x00008000;
>> DMA_STATUS_NIS   = 0x00040000 | 0x00020000;
>> DMA_STATUS_AIS   = 0x00010000 | 0x00008000;
>> DMA_STATUS_FBI   = 0x00002000 | 0x00001000;
>>
>> Therefore, when using, TX and RX must be set at the same time.
>>
>> How to use them:
>>   1. Create the Loongson GNET-specific
>>   stmmac_dma_ops.dma_interrupt()
>>   stmmac_dma_ops.init_chan()
>>   methods in the dwmac-loongson.c driver. Adding all the
>>   Loongson-specific macros
>>
>>   2. Create a Loongson GNET-specific platform setup method with the next
>>   semantics:
>>      + allocate stmmac_dma_ops instance and initialize it with
>>        dwmac1000_dma_ops.
>>      + override the stmmac_dma_ops.{dma_interrupt, init_chan} with
>>        the pointers to the methods defined in 2.
>>      + allocate mac_device_info instance and initialize the
>>        mac_device_info.dma field with a pointer to the new
>>        stmmac_dma_ops instance.
>>      + initialize mac_device_info in a way it's done in
>>        dwmac1000_setup().
>>
>>   3. Initialize plat_stmmacenet_data.setup() with the pointer to the
>>   method created in 2.
>>
>> GNET features:
>>
>>   Speeds: 10/100/1000Mbps
>>   DMA-descriptors type: enhanced
>>   L3/L4 filters availability: support
>>   VLAN hash table filter: support
>>   PHY-interface: GMII
>>   Remote Wake-up support: support
>>   Mac Management Counters (MMC): support
>>   Number of additional MAC addresses: 5
>>   MAC Hash-based filter: support
>>   Number of ash table size: 256
>>   DMA chennel number: 0x10 device is 8 and 0x37 device is 1
>>
>> Others:
>>
>>   GNET integrates both MAC and PHY chips inside.
>>   GNET device: LS2K2000, LS7A2000, the chip connection between the mac and
>>               phy of these devices is not normal and requires two rounds of
>>               negotiation; LS7A2000 does not support half-duplex and
>>               multi-channel;
>>
>>               To enable multi-channel on LS2K2000, you need to turn off
>>               hardware checksum.
>>
>> **Note**: Currently, only the LS2K2000's synopsys_id is 0x10, while the
>> synopsys_id of other devices are 0x37.
> The entire commit log looks as a set of information and doesn't
> explicitly explain what is going on in the patch body. Let's make it a
> bit more coherent:
>
> "Aside with the Loongson GMAC controllers which can be normally found
> on the LS2K1000 SoC and LS7A1000 chipset, Loongson released a new
> version of the network controllers called Loongson GNET. It has
> been synthesized into the new generation LS2K2000 SoC and LS7A2000
> chipset with the next DW GMAC features enabled:
>
>    DW GMAC IP-core: v3.73a
>    Speeds: 10/100/1000Mbps
>    Duplex: Full (both versions), Half (LS2K2000 SoC only)
>    DMA-descriptors type: enhanced
>    L3/L4 filters availability: Y
>    VLAN hash table filter: Y
>    PHY-interface: GMII (PHY is integrated into the chips)
>    Remote Wake-up support: Y
>    Mac Management Counters (MMC): Y
>    Number of additional MAC addresses: 5
>    MAC Hash-based filter: Y
>    Hash Table Size: 256
>    AV feature: Y (LS2K2000 SoC only)
>    DMA channels: 8 (LS2K2000 SoC), 1 (LS7A2000 chipset)
>
> The integrated PHY has a weird problem with switching from the low
> speeds to 1000Mbps mode. The speedup procedure requires the PHY-link
> re-negotiation. Besides the LS2K2000 GNET controller the next
> peculiarities:
> 1. Split up Tx and Rx DMA IRQ status/mask bits:
>         Name              Tx          Rx
>    DMA_INTR_ENA_NIE = 0x00040000 | 0x00020000;
>    DMA_INTR_ENA_AIE = 0x00010000 | 0x00008000;
>    DMA_STATUS_NIS   = 0x00040000 | 0x00020000;
>    DMA_STATUS_AIS   = 0x00010000 | 0x00008000;
>    DMA_STATUS_FBI   = 0x00002000 | 0x00001000;
> 2. Custom Synopsys ID hardwired into the GMAC_VERSION.SNPSVER field.
> It's 0x10 while it should have been 0x37 in accordance with the actual
> DW GMAC IP-core version.
>
> Thus in order to have the Loongson GNET controllers supported let's
> modify the Loongson DWMAC driver in accordance with all the
> peculiarities described above:
>
> 1. Create the Loongson GNET-specific
>     stmmac_dma_ops::dma_interrupt()
>     stmmac_dma_ops::init_chan()
>     callbacks due to the non-standard DMA IRQ CSR flags layout.
> 2. Create the Loongson GNET-specific platform setup() method which
> gets to initialize the DMA-ops with the dwmac1000_dma_ops instance
> and overrides the callbacks described in 1, and overrides the custom
> Synopsys ID with the real one in order to have the rest of the
> HW-specific callbacks correctly detected by the driver core.
> 3. Make sure the Loongson GNET-specific platform setup() method
> enables the duplex modes supported by the controller.
> 4. Provide the plat_stmmacenet_data::fix_mac_speed() callback which
> will restart the link Auto-negotiation in case of the speed change."
>
>
> See, you don't need to mention the 0x10 ID all the time. Just once and
> in the place where it's actually relevant.
OK, Thanks a lot!
>
>> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
>> Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
>> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
>> ---
>>   drivers/net/ethernet/stmicro/stmmac/common.h  |   1 +
>>   .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 381 +++++++++++++++++-
>>   2 files changed, 371 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
>> index 9cd62b2110a1..aed6ae80cc7c 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
>> @@ -29,6 +29,7 @@
>>   /* Synopsys Core versions */
>>   #define	DWMAC_CORE_3_40		0x34
>>   #define	DWMAC_CORE_3_50		0x35
>> +#define	DWMAC_CORE_3_70		0x37
>>   #define	DWMAC_CORE_4_00		0x40
>>   #define DWMAC_CORE_4_10		0x41
>>   #define DWMAC_CORE_5_00		0x50
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> index a16bba389417..68de90c44feb 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> @@ -8,9 +8,71 @@
>>   #include <linux/device.h>
>>   #include <linux/of_irq.h>
>>   #include "stmmac.h"
>> +#include "dwmac_dma.h"
>> +#include "dwmac1000.h"
>> +
>>
>> +#define LOONGSON_DWMAC_CORE_1_00	0x10	/* Loongson custom IP */
> What about using the name like calling as:
> +#define DWMAC_CORE_LS2K2000		0x10
> Thus you'll have the name similar to the rest of the DWMAC_CORE_*
> macros and which would emphasize what the device for which the custom
> ID is specific.
OK.
>
>> +#define CHANNEL_NUM			8
>> +
>> +struct loongson_data {
>> +	u32 gmac_verion;
> Let's call it loongson_id thus referring to the
> stmmac_priv::synopsys_id field.
OK.
>
>> +
>> +static int loongson_gnet_dma_interrupt(struct stmmac_priv *priv,
>> +				       void __iomem *ioaddr,
>> +				       struct stmmac_extra_stats *x,
>> +				       u32 chan, u32 dir)
>> +{
>> +	struct stmmac_pcpu_stats *stats =
> ...
>> +	/* Clear the interrupt by writing a logic 1 to the CSR5[15-0] */
> 0x7ffff != CSR5[15-0]

Hmmm, It should be CSR5[19-0]?

BTW, 0x1ffff != CSR5[15-0], too.

It should be CSR5[16-0], right?


>
>> +	writel((intr_status & 0x7ffff), ioaddr + DMA_CHAN_STATUS(chan));
>> +
>> +	return ret;
>> +}
>> +
>> +static void loongson_gnet_fix_speed(void *priv, unsigned int speed,
>> +				    unsigned int mode)
>> +{
>> +	struct loongson_data *ld = (struct loongson_data *)priv;
>> +	struct net_device *ndev = dev_get_drvdata(ld->dev);
>> +	struct stmmac_priv *ptr = netdev_priv(ndev);
>> +
>> +	/* The controller and PHY don't work well together.
>> +	 * We need to use the PS bit to check if the controller's status
>> +	 * is correct and reset PHY if necessary.
> This doesn't correspond to what you're actually doing. Please align
> the comment with what is done below (if what I provided in the commit
> log regarding this problem is correct, use the description here).
OK, you are right.
>> +	 * MAC_CTRL_REG.15 is defined by the GMAC_CONTROL_PS macro.
> useless. please drop
OK.
>
>> +	 */
>> +	if (speed == SPEED_1000) {
>>
>> +
>> +static struct mac_device_info *loongson_dwmac_setup(void *apriv)
>> +{
>> +	struct stmmac_priv *priv = apriv;
>> +	struct mac_device_info *mac;
> seems unused. See my next comment.
No, We're using it. See my next reply.
>
>> +	struct stmmac_dma_ops *dma;
>> +	struct loongson_data *ld;
>> +	struct pci_dev *pdev;
>> +
>> +	ld = priv->plat->bsp_priv;
>> +	pdev = to_pci_dev(priv->device);
>> +
>> +	mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
>> +	if (!mac)
>> +		return NULL;
> I see you no longer override the ops in dwmac1000_ops. If so this can
> be dropped.
No,

Because I pre-initialize the respective "mac" fields as it's done
in dwmac1000_setup().

>
>> +
>> +	dma = devm_kzalloc(priv->device, sizeof(*dma), GFP_KERNEL);
>> +	if (!dma)
>> +		return NULL;
>> +
>> +	/* The original IP-core version is 0x37 in all Loongson GNET
> s/0x37/v3.73a
Yeah!
>
>> +	 * (ls2k2000 and ls7a2000), but the GNET HW designers have changed the
>> +	 * GMAC_VERSION.SNPSVER field to the custom 0x10 value on the Loongson
>> +	 * ls2k2000 MAC to emphasize the differences: multiple DMA-channels,
> s/ls2k2000/LS2K2000
> s/ls7a2000/LS7A2000
OK.
>
>> +	 * AV feature and GMAC_INT_STATUS CSR flags layout. Get back the
>> +	 * original value so the correct HW-interface would be selected.
>> +	 */
>> +	if (ld->gmac_verion == LOONGSON_DWMAC_CORE_1_00) {
>> +		priv->synopsys_id = DWMAC_CORE_3_70;
>> +		*dma = dwmac1000_dma_ops;
>> +		dma->init_chan = loongson_gnet_dma_init_channel;
>> +		dma->dma_interrupt = loongson_gnet_dma_interrupt;
>> +		mac->dma = dma;
>> +	}
>> +
>> +	mac->mac = &dwmac1000_ops;
> Unused?
Yeah, will be droped!
>
>> +	priv->dev->priv_flags |= IFF_UNICAST_FLT;
>> +
>> +	/* Pre-initialize the respective "mac" fields as it's done in
>> +	 * dwmac1000_setup()
>> +	 */
>> +	mac->pcsr = priv->ioaddr;
>> +	mac->multicast_filter_bins = priv->plat->multicast_filter_bins;
>> +	mac->unicast_filter_entries = priv->plat->unicast_filter_entries;
>> +	mac->mcast_bits_log2 = 0;
>> +
>> +	if (mac->multicast_filter_bins)
>> +		mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
>> +
>> +	/* The GMAC devices with PCI ID 0x7a03 does not support any pause mode.
>> +	 * The GNET devices without CORE ID 0x10 does not support half-duplex.
>> +	 */
> No need to mention the IDs but just the actual devices:
> 	/* Loongson GMAC doesn't support the flow control. LS2K2000
> 	 * GNET doesn't support the half-duplex link mode.
> 	 */
>
OK, Thanks.
>> +	if (pdev->device == PCI_DEVICE_ID_LOONGSON_GMAC) {
>> +		mac->link.caps = MAC_10 | MAC_100 | MAC_1000;
>> +	} else {
>> +		if (ld->gmac_verion == LOONGSON_DWMAC_CORE_1_00)
>> +			mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
>> +					 MAC_10 | MAC_100 | MAC_1000;
>> +		else
>> +			mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
>> +					 MAC_10FD | MAC_100FD | MAC_1000FD;
>> +	}
>> +
>> +	mac->link.duplex = GMAC_CONTROL_DM;
>> +	mac->link.speed10 = GMAC_CONTROL_PS;
>> +	mac->link.speed100 = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
>> +	mac->link.speed1000 = 0;
>> +	mac->link.speed_mask = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
>> +	mac->mii.addr = GMAC_MII_ADDR;
>> +	mac->mii.data = GMAC_MII_DATA;
>> +	mac->mii.addr_shift = 11;
>> +	mac->mii.addr_mask = 0x0000F800;
>> +	mac->mii.reg_shift = 6;
>> +	mac->mii.reg_mask = 0x000007C0;
>> +	mac->mii.clk_csr_shift = 2;
>> +	mac->mii.clk_csr_mask = GENMASK(5, 2);
>> +
>> +	return mac;
>> +}
>> +
>>   static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>>   {
>>   	struct plat_stmmacenet_data *plat;
>>   	int ret, i, bus_id, phy_mode;
>>   	struct stmmac_pci_info *info;
>>   	struct stmmac_resources res;
>> +	struct loongson_data *ld;
>>   	struct device_node *np;
>>   
>>   	np = dev_of_node(&pdev->dev);
>> @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   		return -ENOMEM;
>>   
>>   	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
>> -	if (!plat->dma_cfg) {
>> -		ret = -ENOMEM;
>> -		goto err_put_node;
>> -	}
>> +	if (!plat->dma_cfg)
>> +		return -ENOMEM;
> This change must have been introduced in the patch
> [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> which moves the mdio_node pointer initialization to under the if-clause.
OK.
>
>> +
>> +	ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
>> +	if (!ld)
>> +		return -ENOMEM;
>>   
>>   	/* Enable pci device */
>>   	ret = pci_enable_device(pdev);
>> @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   		plat->phy_interface = phy_mode;
>>   	}
>>   
>> -	pci_enable_msi(pdev);
> Hm, this must be justified and better being done in a separate patch.
OK.
>
>> +	plat->bsp_priv = ld;
>> +	plat->setup = loongson_dwmac_setup;
>> +	ld->dev = &pdev->dev;
>> +
>>   	memset(&res, 0, sizeof(res));
>>   	res.addr = pcim_iomap_table(pdev)[0];
>> +	ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
>> +
>> +	switch (ld->gmac_verion) {
>> +	case LOONGSON_DWMAC_CORE_1_00:
>> +		plat->rx_queues_to_use = CHANNEL_NUM;
>> +		plat->tx_queues_to_use = CHANNEL_NUM;
>> +
>> +		/* Only channel 0 supports checksum,
>> +		 * so turn off checksum to enable multiple channels.
>> +		 */
>> +		for (i = 1; i < CHANNEL_NUM; i++)
>> +			plat->tx_queues_cfg[i].coe_unsupported = 1;
>>   
>> -	plat->tx_queues_to_use = 1;
>> -	plat->rx_queues_to_use = 1;
>> +		ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
>> +		break;
>> +	default:	/* 0x35 device and 0x37 device. */
>> +		plat->tx_queues_to_use = 1;
>> +		plat->rx_queues_to_use = 1;
>>   
> Move the NoF queues (and coe flag) initializations to the respective
> loongson_*_data() methods.
OK.
>
> Besides I don't see you freeing the IRQ vectors allocated in the
> loongson_dwmac_config_msi() method neither in probe(), nor in remove()
> functions. That's definitely wrong. What you need is to have a
> method antagonistic to loongson_dwmac_config_msi() (like
> loongson_dwmac_clear_msi()) which would execute the cleanup procedure.

Hmmm, We can free it in struct pci_driver ->remove method.

Just in loongson_dwmac_remove() call

pci_free_irq_vectors(pdev);


>
>> -	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
>> +		ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
>> +		break;
>> +	}
>>   
>>   	/* GNET devices with dev revision 0x00 do not support manually
>>   	 * setting the speed to 1000.
>> @@ -189,12 +549,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   
>>   	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>>   	if (ret)
>> -		goto err_disable_msi;
>> +		goto err_disable_device;
>>   
>>   	return ret;
>>   
>> -err_disable_msi:
>> -	pci_disable_msi(pdev);
> Once again. Justify the change. Moreover I don't see you dropping the
> pci_disable_msi() from the remove() method.

Since we need to check the return value of the allocated msi, we will

restore this change in v13.


Thanks,

Yanteng

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Yanteng Si]

Hi Huacai, Serge,

在 2024/5/15 21:55, Huacai Chen 写道:
>>>> Once again about the naming. From the retrospective point of view the
>>>> so called legacy PCI IRQs (in fact PCI INTx) and the platform IRQs
>>>> look similar because these are just the level-type signals connected
>>>> to the system IRQ controller. But when it comes to the PCI_Express_,
>>>> the implementation is completely different. The PCIe INTx is just the
>>>> PCIe TLPs of special type, like MSI. Upon receiving these special
>>>> messages the PCIe host controller delivers the IRQ up to the
>>>> respective system IRQ controller. So in order to avoid the confusion
>>>> between the actual legacy PCI INTx, PCI Express INTx and the just
>>>> platform IRQs, it's better to emphasize the actual way of the IRQs
>>>> delivery. In this case it's the later method.
>>> You are absolutely right, and I think I found a method to use your
>>> framework to solve our problems:
>>>
>>>     static int loongson_dwmac_config_irqs(struct pci_dev *pdev,
>>>                                            struct plat_stmmacenet_data *plat,
>>>                                            struct stmmac_resources *res)
>>>     {
>>>         int i, ret, vecs;
>>>
>>>         /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
>>>          * --------- ----- -------- --------  ...  -------- --------
>>>          * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
>>>          */
>>>         vecs = plat->rx_queues_to_use + plat->tx_queues_to_use + 1;
>>>         ret = pci_alloc_irq_vectors(pdev, 1, vecs, PCI_IRQ_MSI | PCI_IRQ_INTX);
>>>         if (ret < 0) {
>>>                 dev_err(&pdev->dev, "Failed to allocate PCI IRQs\n");
>>>                 return ret;
>>>         }
>>>        if (ret >= vecs) {
>>>                 for (i = 0; i < plat->rx_queues_to_use; i++) {
>>>                         res->rx_irq[CHANNELS_NUM - 1 - i] =
>>>                                 pci_irq_vector(pdev, 1 + i * 2);
>>>                 }
>>>                 for (i = 0; i < plat->tx_queues_to_use; i++) {
>>>                         res->tx_irq[CHANNELS_NUM - 1 - i] =
>>>                                 pci_irq_vector(pdev, 2 + i * 2);
>>>                 }
>>>
>>>                 plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
>>>         }
>>>
>>>         res->irq = pci_irq_vector(pdev, 0);
>>>
>>>       if (np) {
>>>           res->irq = of_irq_get_byname(np, "macirq");
>>>           if (res->irq < 0) {
>>>              dev_err(&pdev->dev, "IRQ macirq not found\n");
>>>              return -ENODEV;
>>>           }
>>>
>>>           res->wol_irq = of_irq_get_byname(np, "eth_wake_irq");
>>>           if (res->wol_irq < 0) {
>>>              dev_info(&pdev->dev,
>>>                   "IRQ eth_wake_irq not found, using macirq\n");
>>>              res->wol_irq = res->irq;
>>>           }
>>>
>>>           res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
>>>           if (res->lpi_irq < 0) {
>>>              dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
>>>              return -ENODEV;
>>>           }
>>>       }
>>>         return 0;
>>>     }
>>>
>>> If your agree, Yanteng can use this method in V13, then avoid furthur changes.
>> Since yesterday I have been too relaxed sitting back to explain in
>> detail the problems with the code above. Shortly speaking, no to the
>> method designed as above.
> This function is copy-paste from your version which you suggest to
> Yanteng, and plus the fallback parts for DT. If you don't want to
> discuss it any more, we can discuss after V13.

All right. I have been preparing v13 and will send it as soon as possible.

Let's continue the discussion in v13. Of course, I will copy the part 
that has

not received a clear reply to v13.

>
> BTW, we cannot remove "res->wol_irq = res->irq", because Loongson
> GMAC/GNET indeed supports WoL.

Okay, I will not drop it in v13.


Thanks,

Yanteng

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Serge Semin]

On Fri, May 17, 2024 at 04:42:51PM +0800, Yanteng Si wrote:
> Hi Huacai, Serge,
> 
> 在 2024/5/15 21:55, Huacai Chen 写道:
> > > > > Once again about the naming. From the retrospective point of view the
> > > > > so called legacy PCI IRQs (in fact PCI INTx) and the platform IRQs
> > > > > look similar because these are just the level-type signals connected
> > > > > to the system IRQ controller. But when it comes to the PCI_Express_,
> > > > > the implementation is completely different. The PCIe INTx is just the
> > > > > PCIe TLPs of special type, like MSI. Upon receiving these special
> > > > > messages the PCIe host controller delivers the IRQ up to the
> > > > > respective system IRQ controller. So in order to avoid the confusion
> > > > > between the actual legacy PCI INTx, PCI Express INTx and the just
> > > > > platform IRQs, it's better to emphasize the actual way of the IRQs
> > > > > delivery. In this case it's the later method.
> > > > You are absolutely right, and I think I found a method to use your
> > > > framework to solve our problems:
> > > > 
> > > >     static int loongson_dwmac_config_irqs(struct pci_dev *pdev,
> > > >                                            struct plat_stmmacenet_data *plat,
> > > >                                            struct stmmac_resources *res)
> > > >     {
> > > >         int i, ret, vecs;
> > > > 
> > > >         /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
> > > >          * --------- ----- -------- --------  ...  -------- --------
> > > >          * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
> > > >          */
> > > >         vecs = plat->rx_queues_to_use + plat->tx_queues_to_use + 1;
> > > >         ret = pci_alloc_irq_vectors(pdev, 1, vecs, PCI_IRQ_MSI | PCI_IRQ_INTX);
> > > >         if (ret < 0) {
> > > >                 dev_err(&pdev->dev, "Failed to allocate PCI IRQs\n");
> > > >                 return ret;
> > > >         }
> > > >        if (ret >= vecs) {
> > > >                 for (i = 0; i < plat->rx_queues_to_use; i++) {
> > > >                         res->rx_irq[CHANNELS_NUM - 1 - i] =
> > > >                                 pci_irq_vector(pdev, 1 + i * 2);
> > > >                 }
> > > >                 for (i = 0; i < plat->tx_queues_to_use; i++) {
> > > >                         res->tx_irq[CHANNELS_NUM - 1 - i] =
> > > >                                 pci_irq_vector(pdev, 2 + i * 2);
> > > >                 }
> > > > 
> > > >                 plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> > > >         }
> > > > 
> > > >         res->irq = pci_irq_vector(pdev, 0);
> > > > 
> > > >       if (np) {
> > > >           res->irq = of_irq_get_byname(np, "macirq");
> > > >           if (res->irq < 0) {
> > > >              dev_err(&pdev->dev, "IRQ macirq not found\n");
> > > >              return -ENODEV;
> > > >           }
> > > > 
> > > >           res->wol_irq = of_irq_get_byname(np, "eth_wake_irq");
> > > >           if (res->wol_irq < 0) {
> > > >              dev_info(&pdev->dev,
> > > >                   "IRQ eth_wake_irq not found, using macirq\n");
> > > >              res->wol_irq = res->irq;
> > > >           }
> > > > 
> > > >           res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
> > > >           if (res->lpi_irq < 0) {
> > > >              dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
> > > >              return -ENODEV;
> > > >           }
> > > >       }
> > > >         return 0;
> > > >     }
> > > > 
> > > > If your agree, Yanteng can use this method in V13, then avoid furthur changes.
> > > Since yesterday I have been too relaxed sitting back to explain in
> > > detail the problems with the code above. Shortly speaking, no to the
> > > method designed as above.

> > This function is copy-paste from your version which you suggest to
> > Yanteng, and plus the fallback parts for DT. If you don't want to
> > discuss it any more, we can discuss after V13.

My conclusion is the same. no to _your_ (Huacai) version of the code.
I suggest to Huacai dig dipper in the function semantic and find out
the problems it has. Meanwhile I'll keep relaxing...

> > 
> > BTW, we cannot remove "res->wol_irq = res->irq", because Loongson
> > GMAC/GNET indeed supports WoL.
> 
> Okay, I will not drop it in v13.

Apparently Huacai isn't well familiar with what he is reviewing. Once
again the initialization is useless. Drop it.

> 
> All right. I have been preparing v13 and will send it as soon as possible.
> 
> Let's continue the discussion in v13. Of course, I will copy the part that
> has
> 
> not received a clear reply to v13.
> 

Note the merge window has been opened and the 'net-next' tree is now
closed. So either you submit your series as RFC or wait for the window
being closed.

-Serge(y)

> 
> 
> Thanks,
> 
> Yanteng
> 

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Serge Semin]

On Fri, May 17, 2024 at 04:12:20PM +0800, Yanteng Si wrote:
> Well, let's modify the biggest patch。
> 
> 在 2024/5/6 05:50, Serge Semin 写道:
> > On Thu, Apr 25, 2024 at 09:11:36PM +0800, Yanteng Si wrote:
> > > There are two types of Loongson DWGMAC. The first type shares the same
> > s/Loongson DWGMAC/Loongson GNET controllers
> OK,
> > 
> > > register definitions and has similar logic as dwmac1000. The second type
> > > uses several different register definitions, we think it is necessary to
> > > distinguish rx and tx, so we split these bits into two.
> > s/rx/Rx
> > s/tx/Tx
> 
> OK.
> 
> > > Simply put, we split some single bit fields into double bits fileds:
> > > 
> > >       Name              Tx          Rx
> > > 
> > > DMA_INTR_ENA_NIE = 0x00040000 | 0x00020000;
> > > DMA_INTR_ENA_AIE = 0x00010000 | 0x00008000;
> > > DMA_STATUS_NIS   = 0x00040000 | 0x00020000;
> > > DMA_STATUS_AIS   = 0x00010000 | 0x00008000;
> > > DMA_STATUS_FBI   = 0x00002000 | 0x00001000;
> > > 
> > > Therefore, when using, TX and RX must be set at the same time.
> > > 
> > > How to use them:
> > >   1. Create the Loongson GNET-specific
> > >   stmmac_dma_ops.dma_interrupt()
> > >   stmmac_dma_ops.init_chan()
> > >   methods in the dwmac-loongson.c driver. Adding all the
> > >   Loongson-specific macros
> > > 
> > >   2. Create a Loongson GNET-specific platform setup method with the next
> > >   semantics:
> > >      + allocate stmmac_dma_ops instance and initialize it with
> > >        dwmac1000_dma_ops.
> > >      + override the stmmac_dma_ops.{dma_interrupt, init_chan} with
> > >        the pointers to the methods defined in 2.
> > >      + allocate mac_device_info instance and initialize the
> > >        mac_device_info.dma field with a pointer to the new
> > >        stmmac_dma_ops instance.
> > >      + initialize mac_device_info in a way it's done in
> > >        dwmac1000_setup().
> > > 
> > >   3. Initialize plat_stmmacenet_data.setup() with the pointer to the
> > >   method created in 2.
> > > 
> > > GNET features:
> > > 
> > >   Speeds: 10/100/1000Mbps
> > >   DMA-descriptors type: enhanced
> > >   L3/L4 filters availability: support
> > >   VLAN hash table filter: support
> > >   PHY-interface: GMII
> > >   Remote Wake-up support: support
> > >   Mac Management Counters (MMC): support
> > >   Number of additional MAC addresses: 5
> > >   MAC Hash-based filter: support
> > >   Number of ash table size: 256
> > >   DMA chennel number: 0x10 device is 8 and 0x37 device is 1
> > > 
> > > Others:
> > > 
> > >   GNET integrates both MAC and PHY chips inside.
> > >   GNET device: LS2K2000, LS7A2000, the chip connection between the mac and
> > >               phy of these devices is not normal and requires two rounds of
> > >               negotiation; LS7A2000 does not support half-duplex and
> > >               multi-channel;
> > > 
> > >               To enable multi-channel on LS2K2000, you need to turn off
> > >               hardware checksum.
> > > 
> > > **Note**: Currently, only the LS2K2000's synopsys_id is 0x10, while the
> > > synopsys_id of other devices are 0x37.
> > The entire commit log looks as a set of information and doesn't
> > explicitly explain what is going on in the patch body. Let's make it a
> > bit more coherent:
> > 
> > "Aside with the Loongson GMAC controllers which can be normally found
> > on the LS2K1000 SoC and LS7A1000 chipset, Loongson released a new
> > version of the network controllers called Loongson GNET. It has
> > been synthesized into the new generation LS2K2000 SoC and LS7A2000
> > chipset with the next DW GMAC features enabled:
> > 
> >    DW GMAC IP-core: v3.73a
> >    Speeds: 10/100/1000Mbps
> >    Duplex: Full (both versions), Half (LS2K2000 SoC only)
> >    DMA-descriptors type: enhanced
> >    L3/L4 filters availability: Y
> >    VLAN hash table filter: Y
> >    PHY-interface: GMII (PHY is integrated into the chips)
> >    Remote Wake-up support: Y
> >    Mac Management Counters (MMC): Y
> >    Number of additional MAC addresses: 5
> >    MAC Hash-based filter: Y
> >    Hash Table Size: 256
> >    AV feature: Y (LS2K2000 SoC only)
> >    DMA channels: 8 (LS2K2000 SoC), 1 (LS7A2000 chipset)
> > 
> > The integrated PHY has a weird problem with switching from the low
> > speeds to 1000Mbps mode. The speedup procedure requires the PHY-link
> > re-negotiation. Besides the LS2K2000 GNET controller the next
> > peculiarities:
> > 1. Split up Tx and Rx DMA IRQ status/mask bits:
> >         Name              Tx          Rx
> >    DMA_INTR_ENA_NIE = 0x00040000 | 0x00020000;
> >    DMA_INTR_ENA_AIE = 0x00010000 | 0x00008000;
> >    DMA_STATUS_NIS   = 0x00040000 | 0x00020000;
> >    DMA_STATUS_AIS   = 0x00010000 | 0x00008000;
> >    DMA_STATUS_FBI   = 0x00002000 | 0x00001000;
> > 2. Custom Synopsys ID hardwired into the GMAC_VERSION.SNPSVER field.
> > It's 0x10 while it should have been 0x37 in accordance with the actual
> > DW GMAC IP-core version.
> > 
> > Thus in order to have the Loongson GNET controllers supported let's
> > modify the Loongson DWMAC driver in accordance with all the
> > peculiarities described above:
> > 
> > 1. Create the Loongson GNET-specific
> >     stmmac_dma_ops::dma_interrupt()
> >     stmmac_dma_ops::init_chan()
> >     callbacks due to the non-standard DMA IRQ CSR flags layout.
> > 2. Create the Loongson GNET-specific platform setup() method which
> > gets to initialize the DMA-ops with the dwmac1000_dma_ops instance
> > and overrides the callbacks described in 1, and overrides the custom
> > Synopsys ID with the real one in order to have the rest of the
> > HW-specific callbacks correctly detected by the driver core.
> > 3. Make sure the Loongson GNET-specific platform setup() method
> > enables the duplex modes supported by the controller.
> > 4. Provide the plat_stmmacenet_data::fix_mac_speed() callback which
> > will restart the link Auto-negotiation in case of the speed change."
> > 
> > 
> > See, you don't need to mention the 0x10 ID all the time. Just once and
> > in the place where it's actually relevant.
> OK, Thanks a lot!
> > 
> > > Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> > > Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
> > > Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> > > ---
> > >   drivers/net/ethernet/stmicro/stmmac/common.h  |   1 +
> > >   .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 381 +++++++++++++++++-
> > >   2 files changed, 371 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
> > > index 9cd62b2110a1..aed6ae80cc7c 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> > > @@ -29,6 +29,7 @@
> > >   /* Synopsys Core versions */
> > >   #define	DWMAC_CORE_3_40		0x34
> > >   #define	DWMAC_CORE_3_50		0x35
> > > +#define	DWMAC_CORE_3_70		0x37
> > >   #define	DWMAC_CORE_4_00		0x40
> > >   #define DWMAC_CORE_4_10		0x41
> > >   #define DWMAC_CORE_5_00		0x50
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > > index a16bba389417..68de90c44feb 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > > @@ -8,9 +8,71 @@
> > >   #include <linux/device.h>
> > >   #include <linux/of_irq.h>
> > >   #include "stmmac.h"
> > > +#include "dwmac_dma.h"
> > > +#include "dwmac1000.h"
> > > +
> > > 
> > > +#define LOONGSON_DWMAC_CORE_1_00	0x10	/* Loongson custom IP */
> > What about using the name like calling as:
> > +#define DWMAC_CORE_LS2K2000		0x10
> > Thus you'll have the name similar to the rest of the DWMAC_CORE_*
> > macros and which would emphasize what the device for which the custom
> > ID is specific.
> OK.
> > 
> > > +#define CHANNEL_NUM			8
> > > +
> > > +struct loongson_data {
> > > +	u32 gmac_verion;
> > Let's call it loongson_id thus referring to the
> > stmmac_priv::synopsys_id field.
> OK.
> > 
> > > +
> > > +static int loongson_gnet_dma_interrupt(struct stmmac_priv *priv,
> > > +				       void __iomem *ioaddr,
> > > +				       struct stmmac_extra_stats *x,
> > > +				       u32 chan, u32 dir)
> > > +{
> > > +	struct stmmac_pcpu_stats *stats =
> > ...
> > > +	/* Clear the interrupt by writing a logic 1 to the CSR5[15-0] */
> > 0x7ffff != CSR5[15-0]
> 

> Hmmm, It should be CSR5[19-0]?

0x7ffff = [18-0]
0xfffff = [19-0]

> 
> BTW, 0x1ffff != CSR5[15-0], too.
> 
> It should be CSR5[16-0], right?

Right. If you wish to fix that in the original code, that has to be
done in a dedicated patch.

> 
> 
> > 
> > > +	writel((intr_status & 0x7ffff), ioaddr + DMA_CHAN_STATUS(chan));
> > > +
> > > +	return ret;
> > > +}
> > > +
> > > +static void loongson_gnet_fix_speed(void *priv, unsigned int speed,
> > > +				    unsigned int mode)
> > > +{
> > > +	struct loongson_data *ld = (struct loongson_data *)priv;
> > > +	struct net_device *ndev = dev_get_drvdata(ld->dev);
> > > +	struct stmmac_priv *ptr = netdev_priv(ndev);
> > > +
> > > +	/* The controller and PHY don't work well together.
> > > +	 * We need to use the PS bit to check if the controller's status
> > > +	 * is correct and reset PHY if necessary.
> > This doesn't correspond to what you're actually doing. Please align
> > the comment with what is done below (if what I provided in the commit
> > log regarding this problem is correct, use the description here).
> OK, you are right.
> > > +	 * MAC_CTRL_REG.15 is defined by the GMAC_CONTROL_PS macro.
> > useless. please drop
> OK.
> > 
> > > +	 */
> > > +	if (speed == SPEED_1000) {
> > > 
> > > +
> > > +static struct mac_device_info *loongson_dwmac_setup(void *apriv)
> > > +{
> > > +	struct stmmac_priv *priv = apriv;
> > > +	struct mac_device_info *mac;

> > seems unused. See my next comment.
> No, We're using it. See my next reply.

Right. Sorry for the misleading comment. Got confused the mac and the
mac->mac parts. Of course I meant the usage and initialization of the
"mac_device_info::mac" field.

> > 
> > > +	struct stmmac_dma_ops *dma;
> > > +	struct loongson_data *ld;
> > > +	struct pci_dev *pdev;
> > > +
> > > +	ld = priv->plat->bsp_priv;
> > > +	pdev = to_pci_dev(priv->device);
> > > +
> > > +	mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
> > > +	if (!mac)
> > > +		return NULL;
> > I see you no longer override the ops in dwmac1000_ops. If so this can
> > be dropped.

> No,
> 
> Because I pre-initialize the respective "mac" fields as it's done
> in dwmac1000_setup().

You are right.

> 
> > 
> > > +
> > > +	dma = devm_kzalloc(priv->device, sizeof(*dma), GFP_KERNEL);
> > > +	if (!dma)
> > > +		return NULL;
> > > +
> > > +	/* The original IP-core version is 0x37 in all Loongson GNET
> > s/0x37/v3.73a
> Yeah!
> > 
> > > +	 * (ls2k2000 and ls7a2000), but the GNET HW designers have changed the
> > > +	 * GMAC_VERSION.SNPSVER field to the custom 0x10 value on the Loongson
> > > +	 * ls2k2000 MAC to emphasize the differences: multiple DMA-channels,
> > s/ls2k2000/LS2K2000
> > s/ls7a2000/LS7A2000
> OK.
> > 
> > > +	 * AV feature and GMAC_INT_STATUS CSR flags layout. Get back the
> > > +	 * original value so the correct HW-interface would be selected.
> > > +	 */
> > > +	if (ld->gmac_verion == LOONGSON_DWMAC_CORE_1_00) {
> > > +		priv->synopsys_id = DWMAC_CORE_3_70;
> > > +		*dma = dwmac1000_dma_ops;
> > > +		dma->init_chan = loongson_gnet_dma_init_channel;
> > > +		dma->dma_interrupt = loongson_gnet_dma_interrupt;
> > > +		mac->dma = dma;
> > > +	}
> > > +

> > > +	mac->mac = &dwmac1000_ops;
> > Unused?
> Yeah, will be droped!

That's what I meant.

> > 
> > > +	priv->dev->priv_flags |= IFF_UNICAST_FLT;
> > > +
> > > +	/* Pre-initialize the respective "mac" fields as it's done in
> > > +	 * dwmac1000_setup()
> > > +	 */
> > > +	mac->pcsr = priv->ioaddr;
> > > +	mac->multicast_filter_bins = priv->plat->multicast_filter_bins;
> > > +	mac->unicast_filter_entries = priv->plat->unicast_filter_entries;
> > > +	mac->mcast_bits_log2 = 0;
> > > +
> > > +	if (mac->multicast_filter_bins)
> > > +		mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
> > > +
> > > +	/* The GMAC devices with PCI ID 0x7a03 does not support any pause mode.
> > > +	 * The GNET devices without CORE ID 0x10 does not support half-duplex.
> > > +	 */
> > No need to mention the IDs but just the actual devices:
> > 	/* Loongson GMAC doesn't support the flow control. LS2K2000
> > 	 * GNET doesn't support the half-duplex link mode.
> > 	 */
> > 
> OK, Thanks.
> > > +	if (pdev->device == PCI_DEVICE_ID_LOONGSON_GMAC) {
> > > +		mac->link.caps = MAC_10 | MAC_100 | MAC_1000;
> > > +	} else {
> > > +		if (ld->gmac_verion == LOONGSON_DWMAC_CORE_1_00)
> > > +			mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
> > > +					 MAC_10 | MAC_100 | MAC_1000;
> > > +		else
> > > +			mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
> > > +					 MAC_10FD | MAC_100FD | MAC_1000FD;
> > > +	}
> > > +
> > > +	mac->link.duplex = GMAC_CONTROL_DM;
> > > +	mac->link.speed10 = GMAC_CONTROL_PS;
> > > +	mac->link.speed100 = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
> > > +	mac->link.speed1000 = 0;
> > > +	mac->link.speed_mask = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
> > > +	mac->mii.addr = GMAC_MII_ADDR;
> > > +	mac->mii.data = GMAC_MII_DATA;
> > > +	mac->mii.addr_shift = 11;
> > > +	mac->mii.addr_mask = 0x0000F800;
> > > +	mac->mii.reg_shift = 6;
> > > +	mac->mii.reg_mask = 0x000007C0;
> > > +	mac->mii.clk_csr_shift = 2;
> > > +	mac->mii.clk_csr_mask = GENMASK(5, 2);
> > > +
> > > +	return mac;
> > > +}
> > > +
> > >   static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > >   {
> > >   	struct plat_stmmacenet_data *plat;
> > >   	int ret, i, bus_id, phy_mode;
> > >   	struct stmmac_pci_info *info;
> > >   	struct stmmac_resources res;
> > > +	struct loongson_data *ld;
> > >   	struct device_node *np;
> > >   	np = dev_of_node(&pdev->dev);
> > > @@ -122,10 +460,12 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > >   		return -ENOMEM;
> > >   	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> > > -	if (!plat->dma_cfg) {
> > > -		ret = -ENOMEM;
> > > -		goto err_put_node;
> > > -	}
> > > +	if (!plat->dma_cfg)
> > > +		return -ENOMEM;
> > This change must have been introduced in the patch
> > [PATCH net-next v12 10/15] net: stmmac: dwmac-loongson: Add full PCI support
> > which moves the mdio_node pointer initialization to under the if-clause.
> OK.
> > 
> > > +
> > > +	ld = devm_kzalloc(&pdev->dev, sizeof(*ld), GFP_KERNEL);
> > > +	if (!ld)
> > > +		return -ENOMEM;
> > >   	/* Enable pci device */
> > >   	ret = pci_enable_device(pdev);
> > > @@ -171,14 +511,34 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > >   		plat->phy_interface = phy_mode;
> > >   	}
> > > -	pci_enable_msi(pdev);

> > Hm, this must be justified and better being done in a separate patch.
> OK.

AFAICS the pci_enable_msi()/pci_disable_msi() calls can be dropped due
to the Loongson GMAC not having the MSI IRQs delivered (at least
that's what I got from the discussion and from the original driver,
please correct my if I am wrong). Thus no need in the MSI capability
being enabled. Meanwhile the multi-channels Loongson GNET will use the
pci_alloc_irq_vectors()/pci_free_irq_vectors() functions for the IRQ
vectors allocation and freeing which already perform the MSIs
enable/disable by design.
* But once again, please drop the functions call in a separate patch
submitted with the proper commit log justifying the removal.

> > 
> > > +	plat->bsp_priv = ld;
> > > +	plat->setup = loongson_dwmac_setup;
> > > +	ld->dev = &pdev->dev;
> > > +
> > >   	memset(&res, 0, sizeof(res));
> > >   	res.addr = pcim_iomap_table(pdev)[0];
> > > +	ld->gmac_verion = readl(res.addr + GMAC_VERSION) & 0xff;
> > > +
> > > +	switch (ld->gmac_verion) {
> > > +	case LOONGSON_DWMAC_CORE_1_00:
> > > +		plat->rx_queues_to_use = CHANNEL_NUM;
> > > +		plat->tx_queues_to_use = CHANNEL_NUM;
> > > +
> > > +		/* Only channel 0 supports checksum,
> > > +		 * so turn off checksum to enable multiple channels.
> > > +		 */
> > > +		for (i = 1; i < CHANNEL_NUM; i++)
> > > +			plat->tx_queues_cfg[i].coe_unsupported = 1;
> > > -	plat->tx_queues_to_use = 1;
> > > -	plat->rx_queues_to_use = 1;
> > > +		ret = loongson_dwmac_config_msi(pdev, plat, &res, np);
> > > +		break;
> > > +	default:	/* 0x35 device and 0x37 device. */
> > > +		plat->tx_queues_to_use = 1;
> > > +		plat->rx_queues_to_use = 1;
> > Move the NoF queues (and coe flag) initializations to the respective
> > loongson_*_data() methods.
> OK.
> > 
> > Besides I don't see you freeing the IRQ vectors allocated in the
> > loongson_dwmac_config_msi() method neither in probe(), nor in remove()
> > functions. That's definitely wrong. What you need is to have a
> > method antagonistic to loongson_dwmac_config_msi() (like
> > loongson_dwmac_clear_msi()) which would execute the cleanup procedure.
> 

> Hmmm, We can free it in struct pci_driver ->remove method.
> 
> Just in loongson_dwmac_remove() call
> 
> pci_free_irq_vectors(pdev);

Sounds good. Although I would have implemented that in a more
maintainable way:

loongson_dwmac_config_msi()
{
	...
}

loongson_dwmac_clear_msi()
{
	pci_free_irq_vectors(pdev)
}

...

loongson_dwmac_remove()
{
	...
	if (ld->loongson_id == DWMAC_CORE_LS2K2000)
		loongson_dwmac_clear_msi();
	...
}

-Serge(y)

> 
> 
> > 
> > > -	ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > +		ret = loongson_dwmac_config_legacy(pdev, plat, &res, np);
> > > +		break;
> > > +	}
> > >   	/* GNET devices with dev revision 0x00 do not support manually
> > >   	 * setting the speed to 1000.
> > > @@ -189,12 +549,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> > >   	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
> > >   	if (ret)
> > > -		goto err_disable_msi;
> > > +		goto err_disable_device;
> > >   	return ret;
> > > -err_disable_msi:
> > > -	pci_disable_msi(pdev);
> > Once again. Justify the change. Moreover I don't see you dropping the
> > pci_disable_msi() from the remove() method.
> 
> Since we need to check the return value of the allocated msi, we will
> 
> restore this change in v13.
> 
> 
> Thanks,
> 
> Yanteng
> 

Re: [PATCH net-next v12 13/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Yanteng Si]

Hi Serge,

在 2024/5/17 17:07, Serge Semin 写道:
> On Fri, May 17, 2024 at 04:42:51PM +0800, Yanteng Si wrote:
>> Hi Huacai, Serge,
>>
>> 在 2024/5/15 21:55, Huacai Chen 写道:
>>>>>> Once again about the naming. From the retrospective point of view the
>>>>>> so called legacy PCI IRQs (in fact PCI INTx) and the platform IRQs
>>>>>> look similar because these are just the level-type signals connected
>>>>>> to the system IRQ controller. But when it comes to the PCI_Express_,
>>>>>> the implementation is completely different. The PCIe INTx is just the
>>>>>> PCIe TLPs of special type, like MSI. Upon receiving these special
>>>>>> messages the PCIe host controller delivers the IRQ up to the
>>>>>> respective system IRQ controller. So in order to avoid the confusion
>>>>>> between the actual legacy PCI INTx, PCI Express INTx and the just
>>>>>> platform IRQs, it's better to emphasize the actual way of the IRQs
>>>>>> delivery. In this case it's the later method.
>>>>> You are absolutely right, and I think I found a method to use your
>>>>> framework to solve our problems:
>>>>>
>>>>>      static int loongson_dwmac_config_irqs(struct pci_dev *pdev,
>>>>>                                             struct plat_stmmacenet_data *plat,
>>>>>                                             struct stmmac_resources *res)
>>>>>      {
>>>>>          int i, ret, vecs;
>>>>>
>>>>>          /* INT NAME | MAC | CH7 rx | CH7 tx | ... | CH0 rx | CH0 tx |
>>>>>           * --------- ----- -------- --------  ...  -------- --------
>>>>>           * IRQ NUM  |  0  |   1    |   2    | ... |   15   |   16   |
>>>>>           */
>>>>>          vecs = plat->rx_queues_to_use + plat->tx_queues_to_use + 1;
>>>>>          ret = pci_alloc_irq_vectors(pdev, 1, vecs, PCI_IRQ_MSI | PCI_IRQ_INTX);
>>>>>          if (ret < 0) {
>>>>>                  dev_err(&pdev->dev, "Failed to allocate PCI IRQs\n");
>>>>>                  return ret;
>>>>>          }
>>>>>         if (ret >= vecs) {
>>>>>                  for (i = 0; i < plat->rx_queues_to_use; i++) {
>>>>>                          res->rx_irq[CHANNELS_NUM - 1 - i] =
>>>>>                                  pci_irq_vector(pdev, 1 + i * 2);
>>>>>                  }
>>>>>                  for (i = 0; i < plat->tx_queues_to_use; i++) {
>>>>>                          res->tx_irq[CHANNELS_NUM - 1 - i] =
>>>>>                                  pci_irq_vector(pdev, 2 + i * 2);
>>>>>                  }
>>>>>
>>>>>                  plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
>>>>>          }
>>>>>
>>>>>          res->irq = pci_irq_vector(pdev, 0);
>>>>>
>>>>>        if (np) {
>>>>>            res->irq = of_irq_get_byname(np, "macirq");
>>>>>            if (res->irq < 0) {
>>>>>               dev_err(&pdev->dev, "IRQ macirq not found\n");
>>>>>               return -ENODEV;
>>>>>            }
>>>>>
>>>>>            res->wol_irq = of_irq_get_byname(np, "eth_wake_irq");
>>>>>            if (res->wol_irq < 0) {
>>>>>               dev_info(&pdev->dev,
>>>>>                    "IRQ eth_wake_irq not found, using macirq\n");
>>>>>               res->wol_irq = res->irq;
>>>>>            }
>>>>>
>>>>>            res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
>>>>>            if (res->lpi_irq < 0) {
>>>>>               dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
>>>>>               return -ENODEV;
>>>>>            }
>>>>>        }
>>>>>          return 0;
>>>>>      }
>>>>>
>>>>> If your agree, Yanteng can use this method in V13, then avoid furthur changes.
>>>> Since yesterday I have been too relaxed sitting back to explain in
>>>> detail the problems with the code above. Shortly speaking, no to the
>>>> method designed as above.
>>> This function is copy-paste from your version which you suggest to
>>> Yanteng, and plus the fallback parts for DT. If you don't want to
>>> discuss it any more, we can discuss after V13.
> My conclusion is the same. no to _your_ (Huacai) version of the code.
> I suggest to Huacai dig dipper in the function semantic and find out
> the problems it has. Meanwhile I'll keep relaxing...
>
>>> BTW, we cannot remove "res->wol_irq = res->irq", because Loongson
>>> GMAC/GNET indeed supports WoL.
>> Okay, I will not drop it in v13.
> Apparently Huacai isn't well familiar with what he is reviewing. Once
> again the initialization is useless. Drop it.

Hmm, to be honest, I'm still a little confused about this.

When we first designed the driver, we looked at intel,See:

$: vim drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c +953

static int stmmac_config_single_msi(struct pci_dev *pdev,
                     struct plat_stmmacenet_data *plat,
                     struct stmmac_resources *res)
{
     int ret;

     ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
     if (ret < 0) {
         dev_info(&pdev->dev, "%s: Single IRQ enablement failed\n",
              __func__);
         return ret;
     }

     res->irq = pci_irq_vector(pdev, 0);
     res->wol_irq = res->irq;

Why can't we do this?

Intel Patch thread link 
<https://lore.kernel.org/netdev/20210316121823.18659-5-weifeng.voon@intel.com/>


>
>> All right. I have been preparing v13 and will send it as soon as possible.
>>
>> Let's continue the discussion in v13. Of course, I will copy the part that
>> has
>>
>> not received a clear reply to v13.
>>
> Note the merge window has been opened and the 'net-next' tree is now
> closed. So either you submit your series as RFC or wait for the window
> being closed.
>
Ok, if I'm fast enough, I'll send an RFC to talk about msi and legacy.


Thanks,

Yanteng