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

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

[Yanteng Si]

v13:

* Sorry, we have clarified some things in the past 10 days. I did not
 give you a clear reply to the following questions in v12, so I need
 to reply again:

 1. The current LS2K2000 also have a GMAC(and two GNET) that supports 8
    channels, so we have to reconsider the initialization of
    tx/rx_queues_to_use into probe();

 2. In v12, we disagreed on the loongson_dwmac_msi_config method, but I changed
    it based on Serge's comments(If I understand correctly):
	if (dev_of_node(&pdev->dev)) {
		ret = loongson_dwmac_dt_config(pdev, plat, &res);
	}

	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
		ret = loongson_dwmac_msi_config(pdev, plat, &res);
	} else {
		ret = loongson_dwmac_intx_config(pdev, plat, &res);
	}

 3. Our priv->dma_cap.pcs is false, so let's use PHY_INTERFACE_MODE_NA;

 4. Our GMAC does not support Delay, so let's use PHY_INTERFACE_MODE_RGMII_ID,
    the current dts is wrong, a fix patch will be sent to the LoongArch list
    later.

Others:
* Re-split a part of the patch (it seems we do this with every version);
* Copied Serge's comments into the commit message of patch;
* Fixed the stmmac_dma_operation_mode() method;
* Changed some code comments.

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 duplicated hash-based filter size
    init
  net: stmmac: dwmac-loongson: Use PCI_DEVICE_DATA() macro for device
    identification
  net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init
  net: stmmac: dwmac-loongson: Init ref and PTP clocks rate
  net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC
  net: stmmac: dwmac-loongson: Introduce PCI device info data
  net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support
  net: stmmac: dwmac-loongson: Add loongson_dwmac_dt_config
  net: stmmac: Fixed failure to set network speed to 1000.
  net: stmmac: dwmac-loongson: Drop pci_enable/disable_msi temporarily
  net: stmmac: dwmac-loongson: Add Loongson GNET support
  net: stmmac: dwmac-loongson: Add loongson module author

 drivers/net/ethernet/stmicro/stmmac/common.h  |   1 +
 .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 534 ++++++++++++++++--
 .../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 |  19 +-
 include/linux/stmmac.h                        |   2 +
 13 files changed, 552 insertions(+), 110 deletions(-)

-- 
2.31.4

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

[Yanteng Si]

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.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
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 b3afc7cb7d72..99da314508c3 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 f92c195c76ed..1536455f9052 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 v13 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 | 14 ++++----
 6 files changed, 60 insertions(+), 40 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 99da314508c3..0eef95c15cd0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2370,9 +2370,11 @@ 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;
@@ -2556,7 +2558,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 +4754,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 +4981,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 v13 03/15] net: stmmac: Export dwmac1000_dma_ops

[Yanteng Si]

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.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
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 v13 04/15] net: stmmac: dwmac-loongson: Drop duplicated hash-based filter size init

[Yanteng Si]

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.

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, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 9e40c28d453a..9dbd11766364 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -16,7 +16,7 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
 	plat->force_sf_dma_mode = 1;
 
 	/* Set default value for multicast hash bins */
-	plat->multicast_filter_bins = HASH_TABLE_SIZE;
+	plat->multicast_filter_bins = 256;
 
 	/* Set default value for unicast filter entries */
 	plat->unicast_filter_entries = 1;
@@ -41,7 +41,6 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
 	plat->dma_cfg->pbl = 32;
 	plat->dma_cfg->pblx8 = true;
 
-	plat->multicast_filter_bins = 256;
 	return 0;
 }
 
-- 
2.31.4

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

[Yanteng Si]

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.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
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 9dbd11766364..739b73f4fc35 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 */
@@ -212,7 +214,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 v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Yanteng Si]

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  | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 739b73f4fc35..ad3f44440963 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -11,7 +11,7 @@
 
 #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;
@@ -20,16 +20,14 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
 	/* Set default value for multicast hash bins */
 	plat->multicast_filter_bins = 256;
 
+	plat->mac_interface = PHY_INTERFACE_MODE_NA;
+
 	/* 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;
@@ -42,6 +40,11 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
 
 	plat->dma_cfg->pbl = 32;
 	plat->dma_cfg->pblx8 = true;
+}
+
+static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
+{
+	loongson_default_data(plat);
 
 	return 0;
 }
@@ -111,11 +114,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];
@@ -140,6 +142,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 v13 07/15] net: stmmac: dwmac-loongson: Init ref and PTP clocks rate

[Yanteng Si]

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.

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 ad3f44440963..e725c59c6c98 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -35,6 +35,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 v13 08/15] net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC

[Yanteng Si]

The phy_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 | 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 e725c59c6c98..0289956e274b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -49,6 +49,8 @@ static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
 {
 	loongson_default_data(plat);
 
+	plat->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
+
 	return 0;
 }
 
-- 
2.31.4

[PATCH net-next v13 09/15] net: stmmac: dwmac-loongson: Introduce PCI device info data

[Yanteng Si]

Just introduce PCI device info data to prepare for later
ACPI-base support. Loongson machines may use UEFI (implies
ACPI) or PMON/UBOOT (implies FDT) as the BIOS.

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

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    | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 0289956e274b..fec2aa0607d4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -11,6 +11,10 @@
 
 #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
 
+struct stmmac_pci_info {
+	int (*setup)(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 */
@@ -54,9 +58,14 @@ 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;
+	struct stmmac_pci_info *info;
 	struct stmmac_resources res;
 	struct device_node *np;
 	int ret, i, phy_mode;
@@ -107,6 +116,11 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 		break;
 	}
 
+	info = (struct stmmac_pci_info *)id->driver_data;
+	ret = info->setup(plat);
+	if (ret)
+		goto err_disable_device;
+
 	plat->bus_id = of_alias_get_id(np, "ethernet");
 	if (plat->bus_id < 0)
 		plat->bus_id = pci_dev_id(pdev);
@@ -122,7 +136,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 
 	pci_set_master(pdev);
 
-	loongson_gmac_data(plat);
 	pci_enable_msi(pdev);
 	memset(&res, 0, sizeof(res));
 	res.addr = pcim_iomap_table(pdev)[0];
@@ -224,7 +237,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 v13 10/15] net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support

[Yanteng Si]

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  | 105 +++++++++---------
 1 file changed, 53 insertions(+), 52 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index fec2aa0607d4..8bcf9d522781 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -12,11 +12,15 @@
 #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
 
 struct stmmac_pci_info {
-	int (*setup)(struct plat_stmmacenet_data *plat);
+	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
 };
 
-static void loongson_default_data(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 overwritten later */
+	plat->bus_id = pci_dev_id(pdev);
+
 	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
 	plat->has_gmac = 1;
 	plat->force_sf_dma_mode = 1;
@@ -49,9 +53,10 @@ static void loongson_default_data(struct plat_stmmacenet_data *plat)
 	plat->dma_cfg->pblx8 = true;
 }
 
-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->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
 
@@ -68,15 +73,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 	struct stmmac_pci_info *info;
 	struct stmmac_resources res;
 	struct device_node *np;
-	int ret, i, phy_mode;
+	int ret, i;
 
 	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;
@@ -87,17 +87,9 @@ 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;
-		goto err_put_node;
-	}
+	if (!plat->dma_cfg)
+		return -ENOMEM;
 
 	/* Enable pci device */
 	ret = pci_enable_device(pdev);
@@ -117,49 +109,58 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 	}
 
 	info = (struct stmmac_pci_info *)id->driver_data;
-	ret = info->setup(plat);
+	ret = info->setup(pdev, plat);
 	if (ret)
 		goto err_disable_device;
 
-	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;
-		goto err_disable_device;
-	}
+	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;
+		}
 
-	plat->phy_interface = phy_mode;
+		ret = of_alias_get_id(np, "ethernet");
+		if (ret >= 0)
+			plat->bus_id = ret;
 
-	pci_set_master(pdev);
+		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;
+
+		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);
 	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;
 
-- 
2.31.4

[PATCH net-next v13 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_dt_config

[Yanteng Si]

While at it move the np 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  | 90 ++++++++++---------
 1 file changed, 50 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 8bcf9d522781..fdd25ff33d02 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -67,16 +67,60 @@ static struct stmmac_pci_info loongson_gmac_pci_info = {
 	.setup = loongson_gmac_data,
 };
 
+static int loongson_dwmac_dt_config(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;
+	}
+
+	ret = device_get_phy_mode(&pdev->dev);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "phy_mode not found\n");
+		return -ENODEV;
+	}
+
+	plat->phy_interface = ret;
+
+	return 0;
+}
+
 static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
 	struct plat_stmmacenet_data *plat;
 	struct stmmac_pci_info *info;
 	struct stmmac_resources res;
-	struct device_node *np;
 	int ret, i;
 
-	np = dev_of_node(&pdev->dev);
-
 	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
 	if (!plat)
 		return -ENOMEM;
@@ -115,44 +159,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 
 	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;
-		}
-
-		ret = of_alias_get_id(np, "ethernet");
-		if (ret >= 0)
-			plat->bus_id = ret;
-
-		ret = device_get_phy_mode(&pdev->dev);
-		if (ret < 0) {
-			dev_err(&pdev->dev, "phy_mode not found\n");
+	if (dev_of_node(&pdev->dev)) {
+		ret = loongson_dwmac_dt_config(pdev, plat, &res);
+		if (ret)
 			goto err_disable_device;
-		}
-
-		plat->phy_interface = ret;
-
-		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;
 	}
-- 
2.31.4

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

[Yanteng Si]

Loongson GNET devices with dev revision 0x00 do not
support manually setting the speed to 1000, When the
bug is triggered, let's return -EOPNOTSUPP, which
will be flag in later gnet support patches.

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/stmmac_ethtool.c | 6 ++++++
 include/linux/stmmac.h                               | 1 +
 2 files changed, 7 insertions(+)

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 1536455f9052..3e4f7e8d73fb 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -208,6 +208,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 v13 13/15] net: stmmac: dwmac-loongson: Drop pci_enable/disable_msi temporarily

[Yanteng Si]

The LS2K2000 patch added later will alloc vectors, so let's
remove pci_enable/disable_msi temporarily to prepare for later
calls to pci_alloc_irq_vectors/pci_free_irq_vectors. This does
not affect the work of gmac devices, as they actually use intx.

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 | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index fdd25ff33d02..45dcc35b7955 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -167,7 +167,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 		res.irq = pdev->irq;
 	}
 
-	pci_enable_msi(pdev);
 	memset(&res, 0, sizeof(res));
 	res.addr = pcim_iomap_table(pdev)[0];
 
@@ -176,12 +175,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:
@@ -205,7 +202,6 @@ static void loongson_dwmac_remove(struct pci_dev *pdev)
 		break;
 	}
 
-	pci_disable_msi(pdev);
 	pci_disable_device(pdev);
 }
 
-- 
2.31.4

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

[Yanteng Si]

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.

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  | 390 +++++++++++++++++-
 2 files changed, 387 insertions(+), 4 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 45dcc35b7955..559215e3fe41 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -8,8 +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 DWMAC_CORE_LS2K2000		0x10	/* Loongson custom IP */
+#define CHANNEL_NUM			8
+
+struct loongson_data {
+	u32 loongson_id;
+	struct device *dev;
+};
 
 struct stmmac_pci_info {
 	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
@@ -67,6 +130,298 @@ 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[19-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 integrated PHY has a weird problem with switching from the low
+	 * speeds to 1000Mbps mode. The speedup procedure requires the PHY-link
+	 * re-negotiation.
+	 */
+	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;
+
+	/* 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;
+}
+
+static struct stmmac_pci_info loongson_gnet_pci_info = {
+	.setup = loongson_gnet_data,
+};
+
+static int loongson_dwmac_intx_config(struct pci_dev *pdev,
+				      struct plat_stmmacenet_data *plat,
+				      struct stmmac_resources *res)
+{
+	res->irq = pdev->irq;
+
+	return 0;
+}
+
+static int loongson_dwmac_msi_config(struct pci_dev *pdev,
+				     struct plat_stmmacenet_data *plat,
+				     struct stmmac_resources *res)
+{
+	int i, ret, vecs;
+
+	vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 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[CHANNEL_NUM - 1 - i] =
+				pci_irq_vector(pdev, 1 + i * 2);
+		}
+		for (i = 0; i < plat->tx_queues_to_use; i++) {
+			res->tx_irq[CHANNEL_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;
+}
+
+static int loongson_dwmac_msi_clear(struct pci_dev *pdev)
+{
+	pci_free_irq_vectors(pdev);
+
+	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 v3.73a 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->loongson_id == DWMAC_CORE_LS2K2000) {
+		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;
+	}
+
+	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);
+
+	/* 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->loongson_id == DWMAC_CORE_LS2K2000)
+			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_dt_config(struct pci_dev *pdev,
 				    struct plat_stmmacenet_data *plat,
 				    struct stmmac_resources *res)
@@ -119,6 +474,7 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 	struct plat_stmmacenet_data *plat;
 	struct stmmac_pci_info *info;
 	struct stmmac_resources res;
+	struct loongson_data *ld;
 	int ret, i;
 
 	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
@@ -135,6 +491,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 	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);
 	if (ret) {
@@ -159,19 +519,39 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 
 	pci_set_master(pdev);
 
+	plat->bsp_priv = ld;
+	plat->setup = loongson_dwmac_setup;
+	ld->dev = &pdev->dev;
+
 	if (dev_of_node(&pdev->dev)) {
 		ret = loongson_dwmac_dt_config(pdev, plat, &res);
 		if (ret)
 			goto err_disable_device;
-	} else {
-		res.irq = pdev->irq;
 	}
 
 	memset(&res, 0, sizeof(res));
 	res.addr = pcim_iomap_table(pdev)[0];
+	ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
+
+	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
+		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_msi_config(pdev, plat, &res);
+	} else {
+		plat->tx_queues_to_use = 1;
+		plat->rx_queues_to_use = 1;
+
+		ret = loongson_dwmac_intx_config(pdev, plat, &res);
+	}
+	if (ret)
+		goto err_disable_device;
 
 	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
 	if (ret)
@@ -202,6 +582,7 @@ static void loongson_dwmac_remove(struct pci_dev *pdev)
 		break;
 	}
 
+	loongson_dwmac_msi_clear(pdev);
 	pci_disable_device(pdev);
 }
 
@@ -245,6 +626,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 v13 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 559215e3fe41..9f39657f71f3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -645,4 +645,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 v13 12/15] net: stmmac: Fixed failure to set network speed to 1000.

[Huacai Chen]

Hi, Yanteng,

The title should be "Fix ....." rather than "Fixed .....", and it is
better to move this patch earlier since it is a preparation for later
Loongson-related patches.

Huacai

On Wed, May 29, 2024 at 6:20 PM Yanteng Si <siyanteng@loongson.cn> wrote:
>
> Loongson GNET devices with dev revision 0x00 do not
> support manually setting the speed to 1000, When the
> bug is triggered, let's return -EOPNOTSUPP, which
> will be flag in later gnet support patches.
>
> 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/stmmac_ethtool.c | 6 ++++++
>  include/linux/stmmac.h                               | 1 +
>  2 files changed, 7 insertions(+)
>
> 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 1536455f9052..3e4f7e8d73fb 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -208,6 +208,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 v13 14/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Huacai Chen]

Hi, Yanteng,

On Wed, May 29, 2024 at 6:21 PM Yanteng Si <siyanteng@loongson.cn> wrote:
>
> 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.
>
> 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  | 390 +++++++++++++++++-
>  2 files changed, 387 insertions(+), 4 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 45dcc35b7955..559215e3fe41 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -8,8 +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 DWMAC_CORE_LS2K2000            0x10    /* Loongson custom IP */
It is not suitable to call 0x10 "LS2K2000", because LS2K2000 is the
name of the whole SOC, not the NIC IP. As an example, ThinkPad is the
name of a whole computer series, you cannot call its CPU "ThinkPad
CPU". Right?
From my point of view, the name "LOONGSON_DWMAC_CORE_1_00" in V12 is
much better.

If any macro name for 0x10 is unacceptable, and open-code 0x10 is also
unaccpetable, then there is an alternative way, apply the below patch
on top of this one:

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index b41ffdc6d3d0..81293e2570e8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -66,11 +66,10 @@

 #define PCI_DEVICE_ID_LOONGSON_GMAC    0x7a03
 #define PCI_DEVICE_ID_LOONGSON_GNET    0x7a13
-#define DWMAC_CORE_LS2K2000            0x10    /* Loongson custom IP */
 #define CHANNEL_NUM                    8

 struct loongson_data {
-       u32 loongson_id;
+       int has_multichan;
        struct device *dev;
 };

@@ -370,7 +369,7 @@ static struct mac_device_info
*loongson_dwmac_setup(void *apriv)
         * AV feature and GMAC_INT_STATUS CSR flags layout. Get back the
         * original value so the correct HW-interface would be selected.
         */
-       if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
+       if (ld->has_multichan) {
                priv->synopsys_id = DWMAC_CORE_3_70;
                *dma = dwmac1000_dma_ops;
                dma->init_chan = loongson_gnet_dma_init_channel;
@@ -397,7 +396,7 @@ static struct mac_device_info
*loongson_dwmac_setup(void *apriv)
        if (pdev->device == PCI_DEVICE_ID_LOONGSON_GMAC) {
                mac->link.caps = MAC_10 | MAC_100 | MAC_1000;
        } else {
-               if (ld->loongson_id == DWMAC_CORE_LS2K2000)
+               if (ld->has_multichan)
                        mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
                                         MAC_10 | MAC_100 | MAC_1000;
                else
@@ -474,6 +473,7 @@ static int loongson_dwmac_probe(struct pci_dev
*pdev, const struct pci_device_id
        struct stmmac_pci_info *info;
        struct stmmac_resources res;
        struct loongson_data *ld;
+      u32 gmac_version;
        int ret, i;

        plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
@@ -530,9 +530,19 @@ static int loongson_dwmac_probe(struct pci_dev
*pdev, const struct pci_device_id

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

-       if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
+      switch (gmac_version) {
+      case DWMAC_CORE_3_50:
+      case DWMAC_CORE_3_70:
+           ld->has_multichan = 0;
+                  plat->tx_queues_to_use = 1;
+                  plat->rx_queues_to_use = 1;
+                  ret = loongson_dwmac_intx_config(pdev, plat, &res);
+           break;
+
+        default:
+             ld->has_multichan = 1;
                plat->rx_queues_to_use = CHANNEL_NUM;
                plat->tx_queues_to_use = CHANNEL_NUM;
@@ -543,12 +553,8 @@ static int loongson_dwmac_probe(struct pci_dev
*pdev, const struct pci_device_id
                        plat->tx_queues_cfg[i].coe_unsupported = 1;

                ret = loongson_dwmac_msi_config(pdev, plat, &res);
-       } else {
-               plat->tx_queues_to_use = 1;
-               plat->rx_queues_to_use = 1;
+    }

-               ret = loongson_dwmac_intx_config(pdev, plat, &res);
-       }
        if (ret)
                goto err_disable_device;


Huacai

> +#define CHANNEL_NUM                    8
> +
> +struct loongson_data {
> +       u32 loongson_id;
> +       struct device *dev;
> +};
>
>  struct stmmac_pci_info {
>         int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
> @@ -67,6 +130,298 @@ 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[19-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 integrated PHY has a weird problem with switching from the low
> +        * speeds to 1000Mbps mode. The speedup procedure requires the PHY-link
> +        * re-negotiation.
> +        */
> +       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;
> +
> +       /* 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;
> +}
> +
> +static struct stmmac_pci_info loongson_gnet_pci_info = {
> +       .setup = loongson_gnet_data,
> +};
> +
> +static int loongson_dwmac_intx_config(struct pci_dev *pdev,
> +                                     struct plat_stmmacenet_data *plat,
> +                                     struct stmmac_resources *res)
> +{
> +       res->irq = pdev->irq;
> +
> +       return 0;
> +}
> +
> +static int loongson_dwmac_msi_config(struct pci_dev *pdev,
> +                                    struct plat_stmmacenet_data *plat,
> +                                    struct stmmac_resources *res)
> +{
> +       int i, ret, vecs;
> +
> +       vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 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[CHANNEL_NUM - 1 - i] =
> +                               pci_irq_vector(pdev, 1 + i * 2);
> +               }
> +               for (i = 0; i < plat->tx_queues_to_use; i++) {
> +                       res->tx_irq[CHANNEL_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;
> +}
> +
> +static int loongson_dwmac_msi_clear(struct pci_dev *pdev)
> +{
> +       pci_free_irq_vectors(pdev);
> +
> +       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 v3.73a 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->loongson_id == DWMAC_CORE_LS2K2000) {
> +               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;
> +       }
> +
> +       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);
> +
> +       /* 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->loongson_id == DWMAC_CORE_LS2K2000)
> +                       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_dt_config(struct pci_dev *pdev,
>                                     struct plat_stmmacenet_data *plat,
>                                     struct stmmac_resources *res)
> @@ -119,6 +474,7 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>         struct plat_stmmacenet_data *plat;
>         struct stmmac_pci_info *info;
>         struct stmmac_resources res;
> +       struct loongson_data *ld;
>         int ret, i;
>
>         plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
> @@ -135,6 +491,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>         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);
>         if (ret) {
> @@ -159,19 +519,39 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>
>         pci_set_master(pdev);
>
> +       plat->bsp_priv = ld;
> +       plat->setup = loongson_dwmac_setup;
> +       ld->dev = &pdev->dev;
> +
>         if (dev_of_node(&pdev->dev)) {
>                 ret = loongson_dwmac_dt_config(pdev, plat, &res);
>                 if (ret)
>                         goto err_disable_device;
> -       } else {
> -               res.irq = pdev->irq;
>         }
>
>         memset(&res, 0, sizeof(res));
>         res.addr = pcim_iomap_table(pdev)[0];
> +       ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
> +
> +       if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
> +               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_msi_config(pdev, plat, &res);
> +       } else {
> +               plat->tx_queues_to_use = 1;
> +               plat->rx_queues_to_use = 1;
> +
> +               ret = loongson_dwmac_intx_config(pdev, plat, &res);
> +       }
> +       if (ret)
> +               goto err_disable_device;
>
>         ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>         if (ret)
> @@ -202,6 +582,7 @@ static void loongson_dwmac_remove(struct pci_dev *pdev)
>                 break;
>         }
>
> +       loongson_dwmac_msi_clear(pdev);
>         pci_disable_device(pdev);
>  }
>
> @@ -245,6 +626,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 v13 12/15] net: stmmac: Fixed failure to set network speed to 1000.

[Russell King (Oracle)]

On Thu, May 30, 2024 at 10:25:01AM +0800, Huacai Chen wrote:
> Hi, Yanteng,
> 
> The title should be "Fix ....." rather than "Fixed .....", and it is

I would avoid the ambiguous "Fix" which for stable folk imply that this
is a bug fix - but it isn't. It's adding support for requiring 1G
speeds to always be negotiated.

I would like this patch to be held off until more thought can be put
into how to handle this without having a hack in the driver (stmmac
has too many hacks and we're going to have to start saying no to
these.)

However, I'm completely overloaded right now to have any bandwidth
to think about 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 v13 12/15] net: stmmac: Fixed failure to set network speed to 1000.

[si.yanteng]

2024年5月30日 15:22, "Russell King (Oracle)" <linux@armlinux.org.uk> 写到:

Hi, Russell, Serge,

> 
> On Thu, May 30, 2024 at 10:25:01AM +0800, Huacai Chen wrote:
> 
> > 
> > Hi, Yanteng,
> > 
> >  
> > 
> >  The title should be "Fix ....." rather than "Fixed .....", and it is
> > 
> 
> I would avoid the ambiguous "Fix" which for stable folk imply that this
> 
> is a bug fix - but it isn't. It's adding support for requiring 1G
> 
> speeds to always be negotiated.
Oh, I get it now. Thanks!

> 
> I would like this patch to be held off until more thought can be put
> 
> into how to handle this without having a hack in the driver (stmmac
> 
> has too many hacks and we're going to have to start saying no to
> 
> these.)
Yeah, you have a point there, but I would also like to hear Serge's opinion.



Thanks,
Yanteng

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

[Yanteng Si]

在 2024/5/30 10:46, Huacai Chen 写道:
>>   #define PCI_DEVICE_ID_LOONGSON_GMAC    0x7a03
>> +#define PCI_DEVICE_ID_LOONGSON_GNET    0x7a13
>> +#define DWMAC_CORE_LS2K2000            0x10    /* Loongson custom IP */
> It is not suitable to call 0x10 "LS2K2000", because LS2K2000 is the
> name of the whole SOC, not the NIC IP. As an example, ThinkPad is the
> name of a whole computer series, you cannot call its CPU "ThinkPad
> CPU". Right?
>  From my point of view, the name "LOONGSON_DWMAC_CORE_1_00" in V12 is
> much better.
>
> If any macro name for 0x10 is unacceptable, and open-code 0x10 is also
> unaccpetable, then there is an alternative way, apply the below patch
> on top of this one:
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index b41ffdc6d3d0..81293e2570e8 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -66,11 +66,10 @@
>
>   #define PCI_DEVICE_ID_LOONGSON_GMAC    0x7a03
>   #define PCI_DEVICE_ID_LOONGSON_GNET    0x7a13
> -#define DWMAC_CORE_LS2K2000            0x10    /* Loongson custom IP */
>   #define CHANNEL_NUM                    8
>
>   struct loongson_data {
> -       u32 loongson_id;
> +       int has_multichan;
>          struct device *dev;
>   };
>
> @@ -370,7 +369,7 @@ static struct mac_device_info
> *loongson_dwmac_setup(void *apriv)
>           * AV feature and GMAC_INT_STATUS CSR flags layout. Get back the
>           * original value so the correct HW-interface would be selected.
>           */
> -       if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
> +       if (ld->has_multichan) {
>                  priv->synopsys_id = DWMAC_CORE_3_70;
>                  *dma = dwmac1000_dma_ops;
>                  dma->init_chan = loongson_gnet_dma_init_channel;
> @@ -397,7 +396,7 @@ static struct mac_device_info
> *loongson_dwmac_setup(void *apriv)
>          if (pdev->device == PCI_DEVICE_ID_LOONGSON_GMAC) {
>                  mac->link.caps = MAC_10 | MAC_100 | MAC_1000;
>          } else {
> -               if (ld->loongson_id == DWMAC_CORE_LS2K2000)
> +               if (ld->has_multichan)
>                          mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
>                                           MAC_10 | MAC_100 | MAC_1000;
>                  else
> @@ -474,6 +473,7 @@ static int loongson_dwmac_probe(struct pci_dev
> *pdev, const struct pci_device_id
>          struct stmmac_pci_info *info;
>          struct stmmac_resources res;
>          struct loongson_data *ld;
> +      u32 gmac_version;
>          int ret, i;
>
>          plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
> @@ -530,9 +530,19 @@ static int loongson_dwmac_probe(struct pci_dev
> *pdev, const struct pci_device_id
>
>          memset(&res, 0, sizeof(res));
>          res.addr = pcim_iomap_table(pdev)[0];
> -       ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
> +       gmac_version = readl(res.addr + GMAC_VERSION) & 0xff;
>
> -       if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
> +      switch (gmac_version) {
> +      case DWMAC_CORE_3_50:
> +      case DWMAC_CORE_3_70:
> +           ld->has_multichan = 0;
> +                  plat->tx_queues_to_use = 1;
> +                  plat->rx_queues_to_use = 1;
> +                  ret = loongson_dwmac_intx_config(pdev, plat, &res);
> +           break;
> +
> +        default:
> +             ld->has_multichan = 1;
>                  plat->rx_queues_to_use = CHANNEL_NUM;
>                  plat->tx_queues_to_use = CHANNEL_NUM;
> @@ -543,12 +553,8 @@ static int loongson_dwmac_probe(struct pci_dev
> *pdev, const struct pci_device_id
>                          plat->tx_queues_cfg[i].coe_unsupported = 1;
>
>                  ret = loongson_dwmac_msi_config(pdev, plat, &res);
> -       } else {
> -               plat->tx_queues_to_use = 1;
> -               plat->rx_queues_to_use = 1;
> +    }
>
> -               ret = loongson_dwmac_intx_config(pdev, plat, &res);
> -       }
>          if (ret)
>                  goto err_disable_device;

I think it's great. What about everyone else?


Thanks,

Yanteng

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

[Serge Semin]

Hi Yanteng

On Wed, May 29, 2024 at 06:17:22PM +0800, Yanteng Si wrote:
> v13:
> 
> * Sorry, we have clarified some things in the past 10 days. I did not
>  give you a clear reply to the following questions in v12, so I need
>  to reply again:
> 
>  1. The current LS2K2000 also have a GMAC(and two GNET) that supports 8
>     channels, so we have to reconsider the initialization of
>     tx/rx_queues_to_use into probe();
> 
>  2. In v12, we disagreed on the loongson_dwmac_msi_config method, but I changed
>     it based on Serge's comments(If I understand correctly):
> 	if (dev_of_node(&pdev->dev)) {
> 		ret = loongson_dwmac_dt_config(pdev, plat, &res);
> 	}
> 
> 	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
> 		ret = loongson_dwmac_msi_config(pdev, plat, &res);
> 	} else {
> 		ret = loongson_dwmac_intx_config(pdev, plat, &res);
> 	}
> 
>  3. Our priv->dma_cap.pcs is false, so let's use PHY_INTERFACE_MODE_NA;
> 
>  4. Our GMAC does not support Delay, so let's use PHY_INTERFACE_MODE_RGMII_ID,
>     the current dts is wrong, a fix patch will be sent to the LoongArch list
>     later.
> 
> Others:
> * Re-split a part of the patch (it seems we do this with every version);
> * Copied Serge's comments into the commit message of patch;
> * Fixed the stmmac_dma_operation_mode() method;
> * Changed some code comments.

Thanks for the new version of the series submitted. I've received the
copy and all the currently posted comments. Alas I'll be busy on this
week to join the discussions and start reviewing the bits. I'll be
able to do that early next week. Sorry for making you and the rest of
reviewers wait.

-Serge(y)

> 
> 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 duplicated hash-based filter size
>     init
>   net: stmmac: dwmac-loongson: Use PCI_DEVICE_DATA() macro for device
>     identification
>   net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init
>   net: stmmac: dwmac-loongson: Init ref and PTP clocks rate
>   net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC
>   net: stmmac: dwmac-loongson: Introduce PCI device info data
>   net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support
>   net: stmmac: dwmac-loongson: Add loongson_dwmac_dt_config
>   net: stmmac: Fixed failure to set network speed to 1000.
>   net: stmmac: dwmac-loongson: Drop pci_enable/disable_msi temporarily
>   net: stmmac: dwmac-loongson: Add Loongson GNET support
>   net: stmmac: dwmac-loongson: Add loongson module author
> 
>  drivers/net/ethernet/stmicro/stmmac/common.h  |   1 +
>  .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 534 ++++++++++++++++--
>  .../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 |  19 +-
>  include/linux/stmmac.h                        |   2 +
>  13 files changed, 552 insertions(+), 110 deletions(-)
> 
> -- 
> 2.31.4
> 

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

[Yanteng Si]

Hi Serge,

在 2024/6/5 19:30, Serge Semin 写道:
> On Wed, May 29, 2024 at 06:17:22PM +0800, Yanteng Si wrote:
>> v13:
>>
>> * Sorry, we have clarified some things in the past 10 days. I did not
>>   give you a clear reply to the following questions in v12, so I need
>>   to reply again:
>>
>>   1. The current LS2K2000 also have a GMAC(and two GNET) that supports 8
>>      channels, so we have to reconsider the initialization of
>>      tx/rx_queues_to_use into probe();
>>
>>   2. In v12, we disagreed on the loongson_dwmac_msi_config method, but I changed
>>      it based on Serge's comments(If I understand correctly):
>> 	if (dev_of_node(&pdev->dev)) {
>> 		ret = loongson_dwmac_dt_config(pdev, plat, &res);
>> 	}
>>
>> 	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
>> 		ret = loongson_dwmac_msi_config(pdev, plat, &res);
>> 	} else {
>> 		ret = loongson_dwmac_intx_config(pdev, plat, &res);
>> 	}
>>
>>   3. Our priv->dma_cap.pcs is false, so let's use PHY_INTERFACE_MODE_NA;
>>
>>   4. Our GMAC does not support Delay, so let's use PHY_INTERFACE_MODE_RGMII_ID,
>>      the current dts is wrong, a fix patch will be sent to the LoongArch list
>>      later.
>>
>> Others:
>> * Re-split a part of the patch (it seems we do this with every version);
>> * Copied Serge's comments into the commit message of patch;
>> * Fixed the stmmac_dma_operation_mode() method;
>> * Changed some code comments.
> Thanks for the new version of the series submitted. I've received the
> copy and all the currently posted comments. Alas I'll be busy on this
> week to join the discussions and start reviewing the bits. I'll be
> able to do that early next week. Sorry for making you and the rest of
> reviewers wait.

Thanks for your reply.

Ok, I just had time to test Huacai's method.


Thanks,

Yanteng

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

[Russell King (Oracle)]

On Wed, May 29, 2024 at 06:17:22PM +0800, Yanteng Si wrote:
>  3. Our priv->dma_cap.pcs is false, so let's use PHY_INTERFACE_MODE_NA;

Useful to note.

>  4. Our GMAC does not support Delay, so let's use PHY_INTERFACE_MODE_RGMII_ID,
>     the current dts is wrong, a fix patch will be sent to the LoongArch list
>     later.

RGMII requires a delay somewhere in the system, and there are three
options: at the MAC, in the board traces, or at the PHY. The
PHY_INTERFACE_MODE_RGMII* passed to the PHY determines what delays the
PHY uses, and thus what the GMAC uses has no bearing on this - if the
board traces are adding the required delay, then
PHY_INTERFACE_MODE_RGMII is sufficient.

If the board traces do not add the required delay, and the GMAC doesn't
add a delay, then it is necessary to add the delay at the PHY, so
using PHY_INTERFACE_MODE_RGMII_ID is appropriate.

It's all detailed in Documentation/networking/phy.rst

What isn't documented there (and arguably should be) is if the MAC
adjusts its delays according to the PHY interface mode, then the MAC
should pass PHY_INTERFACE_MODE_RGMII to the PHY _irrespective_ of
which _ID/_TXID/ _RXID has been selected by firmware (since we don't
want the PHY to be adding its own delays if they've already been taken
care of by the MAC.)

-- 
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 v13 00/15] stmmac: Add Loongson platform support

[Andrew Lunn]

On Thu, Jun 06, 2024 at 07:27:52PM +0100, Russell King (Oracle) wrote:
> On Wed, May 29, 2024 at 06:17:22PM +0800, Yanteng Si wrote:
> >  3. Our priv->dma_cap.pcs is false, so let's use PHY_INTERFACE_MODE_NA;
> 
> Useful to note.
> 
> >  4. Our GMAC does not support Delay, so let's use PHY_INTERFACE_MODE_RGMII_ID,
> >     the current dts is wrong, a fix patch will be sent to the LoongArch list
> >     later.
> 
> RGMII requires a delay somewhere in the system, and there are three
> options: at the MAC, in the board traces, or at the PHY. The
> PHY_INTERFACE_MODE_RGMII* passed to the PHY determines what delays the
> PHY uses, and thus what the GMAC uses has no bearing on this - if the
> board traces are adding the required delay, then
> PHY_INTERFACE_MODE_RGMII is sufficient.
> 
> If the board traces do not add the required delay, and the GMAC doesn't
> add a delay, then it is necessary to add the delay at the PHY, so
> using PHY_INTERFACE_MODE_RGMII_ID is appropriate.
> 
> It's all detailed in Documentation/networking/phy.rst
> 
> What isn't documented there (and arguably should be) is if the MAC
> adjusts its delays according to the PHY interface mode, then the MAC
> should pass PHY_INTERFACE_MODE_RGMII to the PHY _irrespective_ of
> which _ID/_TXID/ _RXID has been selected by firmware (since we don't
> want the PHY to be adding its own delays if they've already been taken
> care of by the MAC.)

Just adding to this, the vast majority of systems default to the PHY
adding the delays. There are only a small number of systems with the
MAC adding the delays, even if many MACs have hardware to allow the
MAC to add the delays. Keeping things uniform just avoids problems, so
i always suggest the PHY should add the delay.

    Andrew

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

[Yanteng Si]

Hi all,

在 2024/5/30 10:46, Huacai Chen 写道:
>>   #define PCI_DEVICE_ID_LOONGSON_GMAC    0x7a03
>> +#define PCI_DEVICE_ID_LOONGSON_GNET    0x7a13
>> +#define DWMAC_CORE_LS2K2000            0x10    /* Loongson custom IP */
> It is not suitable to call 0x10 "LS2K2000", because LS2K2000 is the
> name of the whole SOC, not the NIC IP. As an example, ThinkPad is the
> name of a whole computer series, you cannot call its CPU "ThinkPad
> CPU". Right?
>  From my point of view, the name "LOONGSON_DWMAC_CORE_1_00" in V12 is
> much better.
>
> If any macro name for 0x10 is unacceptable, and open-code 0x10 is also
> unaccpetable, then there is an alternative way, apply the below patch
> on top of this one:
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index b41ffdc6d3d0..81293e2570e8 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -66,11 +66,10 @@
>
>   #define PCI_DEVICE_ID_LOONGSON_GMAC    0x7a03
>   #define PCI_DEVICE_ID_LOONGSON_GNET    0x7a13
> -#define DWMAC_CORE_LS2K2000            0x10    /* Loongson custom IP */
>   #define CHANNEL_NUM                    8
>
>   struct loongson_data {
> -       u32 loongson_id;
> +       int has_multichan;
>          struct device *dev;
>   };
>
> @@ -370,7 +369,7 @@ static struct mac_device_info
> *loongson_dwmac_setup(void *apriv)
>           * AV feature and GMAC_INT_STATUS CSR flags layout. Get back the
>           * original value so the correct HW-interface would be selected.
>           */
> -       if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
> +       if (ld->has_multichan) {
>                  priv->synopsys_id = DWMAC_CORE_3_70;
>                  *dma = dwmac1000_dma_ops;
>                  dma->init_chan = loongson_gnet_dma_init_channel;
> @@ -397,7 +396,7 @@ static struct mac_device_info
> *loongson_dwmac_setup(void *apriv)
>          if (pdev->device == PCI_DEVICE_ID_LOONGSON_GMAC) {
>                  mac->link.caps = MAC_10 | MAC_100 | MAC_1000;
>          } else {
> -               if (ld->loongson_id == DWMAC_CORE_LS2K2000)
> +               if (ld->has_multichan)
>                          mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
>                                           MAC_10 | MAC_100 | MAC_1000;
>                  else
> @@ -474,6 +473,7 @@ static int loongson_dwmac_probe(struct pci_dev
> *pdev, const struct pci_device_id
>          struct stmmac_pci_info *info;
>          struct stmmac_resources res;
>          struct loongson_data *ld;
> +      u32 gmac_version;
>          int ret, i;
>
>          plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
> @@ -530,9 +530,19 @@ static int loongson_dwmac_probe(struct pci_dev
> *pdev, const struct pci_device_id
>
>          memset(&res, 0, sizeof(res));
>          res.addr = pcim_iomap_table(pdev)[0];
> -       ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
> +       gmac_version = readl(res.addr + GMAC_VERSION) & 0xff;
>
> -       if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
> +      switch (gmac_version) {
> +      case DWMAC_CORE_3_50:
> +      case DWMAC_CORE_3_70:
> +           ld->has_multichan = 0;
> +                  plat->tx_queues_to_use = 1;
> +                  plat->rx_queues_to_use = 1;
> +                  ret = loongson_dwmac_intx_config(pdev, plat, &res);
> +           break;
> +
> +        default:
> +             ld->has_multichan = 1;
>                  plat->rx_queues_to_use = CHANNEL_NUM;
>                  plat->tx_queues_to_use = CHANNEL_NUM;
> @@ -543,12 +553,8 @@ static int loongson_dwmac_probe(struct pci_dev
> *pdev, const struct pci_device_id
>                          plat->tx_queues_cfg[i].coe_unsupported = 1;
>
>                  ret = loongson_dwmac_msi_config(pdev, plat, &res);
> -       } else {
> -               plat->tx_queues_to_use = 1;
> -               plat->rx_queues_to_use = 1;
> +    }
>
> -               ret = loongson_dwmac_intx_config(pdev, plat, &res);
> -       }
>          if (ret)
>                  goto err_disable_device;
>
Huacai's method works.


Thanks,

Yanteng

> Huacai

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

[Serge Semin]

Hi Yanteng

On Wed, May 29, 2024 at 06:18:18PM +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 haven't you picked up the commit log suggested on v12? It has more
details about the feature and the change context. Please use it:

"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 | 14 ++++----
>  6 files changed, 60 insertions(+), 40 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)
> +

Please re-define the macros in the address ascending order:
DMA_CHAN_BUS_MODE()
DMA_CHAN_XMT_POLL_DEMAND()
DMA_CHAN_RCV_POLL_DEMAND()
DMA_CHAN_RCV_BASE_ADDR()
DMA_CHAN_TX_BASE_ADDR()
DMA_CHAN_STATUS()
DMA_CHAN_CONTROL()
DMA_CHAN_INTR_ENA()
DMA_CHAN_MISSED_FRAME_CTR()
DMA_CHAN_RX_WATCHDOG()

* Please don't forget DMA_CHAN_RCV_POLL_DEMAND() and
DMA_CHAN_MISSED_FRAME_CTR() macros you've missed in your patch.

>  /* 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);

> -

What has been wrong with this empty line so you decided to remove it?)

-Serge(y) 

>  #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 99da314508c3..0eef95c15cd0 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2370,9 +2370,11 @@ 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;
> @@ -2556,7 +2558,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 +4754,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 +4981,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
> 

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

[Serge Semin]

On Wed, May 29, 2024 at 06:19:01PM +0800, Yanteng Si wrote:
> 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.

Looking 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-loongson.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 9e40c28d453a..9dbd11766364 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -16,7 +16,7 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>  	plat->force_sf_dma_mode = 1;
>  
>  	/* Set default value for multicast hash bins */
> -	plat->multicast_filter_bins = HASH_TABLE_SIZE;
> +	plat->multicast_filter_bins = 256;
>  
>  	/* Set default value for unicast filter entries */
>  	plat->unicast_filter_entries = 1;
> @@ -41,7 +41,6 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>  	plat->dma_cfg->pbl = 32;
>  	plat->dma_cfg->pblx8 = true;
>  
> -	plat->multicast_filter_bins = 256;
>  	return 0;
>  }
>  
> -- 
> 2.31.4
> 

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Serge Semin]

On Wed, May 29, 2024 at 06:19:03PM +0800, Yanteng Si wrote:
> 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

You mentioned in the cover-letter
https://lore.kernel.org/netdev/cover.1716973237.git.siyanteng@loongson.cn/
that LS2K now have GMAC NICs too:
" 1. The current LS2K2000 also have a GMAC(and two GNET) that supports 8
    channels, so we have to reconsider the initialization of
    tx/rx_queues_to_use into probe();"

But I don't see much changes in the series which would indicate that
new data. Please clarify what does it mean:

Does it mean LS2K2000 has two types of the DW GMACs, right?

Are both of them based on the DW GMAC v3.73a IP-core with AV-feature
enabled and 8 DMA-channels? 

Seeing you called the new device as GMAC it doesn't have an
integrated PHY as GNETs do, does it? If so, then neither
STMMAC_FLAG_DISABLE_FORCE_1000 nor loongson_gnet_fix_speed() relevant
for the new device, right?

Why haven't you changed the sheet in the commit log? Shall the sheet
be updated like this:

    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         GMAC      0x7a13          v3.73a            8
 LS2K2000 CPU         GNET      0x7a13          v3.73a            8
 LS7A2000 Chipset     GNET      0x7a13          v3.73a            1

?

I'll continue reviewing the series after the questions above are
clarified.

-Serge(y)

> 
> 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  | 19 ++++++++++++-------
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 739b73f4fc35..ad3f44440963 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -11,7 +11,7 @@
>  
>  #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;
> @@ -20,16 +20,14 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>  	/* Set default value for multicast hash bins */
>  	plat->multicast_filter_bins = 256;
>  
> +	plat->mac_interface = PHY_INTERFACE_MODE_NA;
> +
>  	/* 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;
> @@ -42,6 +40,11 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>  
>  	plat->dma_cfg->pbl = 32;
>  	plat->dma_cfg->pblx8 = true;
> +}
> +
> +static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
> +{
> +	loongson_default_data(plat);
>  
>  	return 0;
>  }
> @@ -111,11 +114,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];
> @@ -140,6 +142,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
> 

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

[Yanteng Si]

在 2024/6/14 21:31, Serge Semin 写道:
> Hi Yanteng
>
> On Wed, May 29, 2024 at 06:18:18PM +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 haven't you picked up the commit log suggested on v12? It has more
> details about the feature and the change context. Please use it:
>
> "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."
Oops! I will pick up in v14.
>
>> 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 ++++++++++---------
>>
>>   	.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)
>> +
> Please re-define the macros in the address ascending order:
> DMA_CHAN_BUS_MODE()
> DMA_CHAN_XMT_POLL_DEMAND()
> DMA_CHAN_RCV_POLL_DEMAND()
> DMA_CHAN_RCV_BASE_ADDR()
> DMA_CHAN_TX_BASE_ADDR()
> DMA_CHAN_STATUS()
> DMA_CHAN_CONTROL()
> DMA_CHAN_INTR_ENA()
> DMA_CHAN_MISSED_FRAME_CTR()
> DMA_CHAN_RX_WATCHDOG()
>
> * Please don't forget DMA_CHAN_RCV_POLL_DEMAND() and
> DMA_CHAN_MISSED_FRAME_CTR() macros you've missed in your patch.
OK.
>>   /* 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);
>> -
> What has been wrong with this empty line so you decided to remove it?)

OK, will restore it.


Thanks,

Yanteng

>
> -Serge(y)
>

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Yanteng Si]

Hi Serge,

在 2024/6/15 00:19, Serge Semin 写道:
> On Wed, May 29, 2024 at 06:19:03PM +0800, Yanteng Si wrote:
>> 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
> You mentioned in the cover-letter
> https://lore.kernel.org/netdev/cover.1716973237.git.siyanteng@loongson.cn/
> that LS2K now have GMAC NICs too:
> " 1. The current LS2K2000 also have a GMAC(and two GNET) that supports 8
>      channels, so we have to reconsider the initialization of
>      tx/rx_queues_to_use into probe();"
>
> But I don't see much changes in the series which would indicate that
> new data. Please clarify what does it mean:
>
> Does it mean LS2K2000 has two types of the DW GMACs, right?
Yes!
>
> Are both of them based on the DW GMAC v3.73a IP-core with AV-feature
> enabled and 8 DMA-channels?
Yes!
>
> Seeing you called the new device as GMAC it doesn't have an
> integrated PHY as GNETs do, does it? If so, then neither
> STMMAC_FLAG_DISABLE_FORCE_1000 nor loongson_gnet_fix_speed() relevant
> for the new device, right?
YES!
>
> Why haven't you changed the sheet in the commit log? Shall the sheet
> be updated like this:
>
>      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         GMAC      0x7a13          v3.73a            8
>   LS2K2000 CPU         GNET      0x7a13          v3.73a            8
>   LS7A2000 Chipset     GNET      0x7a13          v3.73a            1
>
> ?

No! PCI Dev ID of GMAC is 0x7a03. So:

  LS2K1000 CPU         GMAC      0x7a03       v3.50a/v3.73a 1
  LS7A1000 Chipset     GMAC      0x7a03       v3.50a/v3.73a 1
+LS2K2000 CPU         GMAC      0x7a03          v3.73a 8
  LS2K2000 CPU         GNET      0x7a13          v3.73a 8
  LS7A2000 Chipset     GNET      0x7a13          v3.73a 1

>
> I'll continue reviewing the series after the questions above are
> clarified.

OK, If anything else is unclear, please let me know.


Thanks,

Yanteng


>
> -Serge(y)
>
>> 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  | 19 ++++++++++++-------
>>   1 file changed, 12 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> index 739b73f4fc35..ad3f44440963 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> @@ -11,7 +11,7 @@
>>   
>>   #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;
>> @@ -20,16 +20,14 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>>   	/* Set default value for multicast hash bins */
>>   	plat->multicast_filter_bins = 256;
>>   
>> +	plat->mac_interface = PHY_INTERFACE_MODE_NA;
>> +
>>   	/* 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;
>> @@ -42,6 +40,11 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>>   
>>   	plat->dma_cfg->pbl = 32;
>>   	plat->dma_cfg->pblx8 = true;
>> +}
>> +
>> +static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
>> +{
>> +	loongson_default_data(plat);
>>   
>>   	return 0;
>>   }
>> @@ -111,11 +114,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];
>> @@ -140,6 +142,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
>>

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Serge Semin]

On Mon, Jun 17, 2024 at 06:00:19PM +0800, Yanteng Si wrote:
> Hi Serge,
> 
> 在 2024/6/15 00:19, Serge Semin 写道:
> > On Wed, May 29, 2024 at 06:19:03PM +0800, Yanteng Si wrote:
> > > 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
> > You mentioned in the cover-letter
> > https://lore.kernel.org/netdev/cover.1716973237.git.siyanteng@loongson.cn/
> > that LS2K now have GMAC NICs too:
> > " 1. The current LS2K2000 also have a GMAC(and two GNET) that supports 8
> >      channels, so we have to reconsider the initialization of
> >      tx/rx_queues_to_use into probe();"
> > 
> > But I don't see much changes in the series which would indicate that
> > new data. Please clarify what does it mean:
> > 
> > Does it mean LS2K2000 has two types of the DW GMACs, right?
> Yes!
> > 
> > Are both of them based on the DW GMAC v3.73a IP-core with AV-feature
> > enabled and 8 DMA-channels?
> Yes!
> > 
> > Seeing you called the new device as GMAC it doesn't have an
> > integrated PHY as GNETs do, does it? If so, then neither
> > STMMAC_FLAG_DISABLE_FORCE_1000 nor loongson_gnet_fix_speed() relevant
> > for the new device, right?
> YES!
> > 
> > Why haven't you changed the sheet in the commit log? Shall the sheet
> > be updated like this:
> > 
> >      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         GMAC      0x7a13          v3.73a            8
> >   LS2K2000 CPU         GNET      0x7a13          v3.73a            8
> >   LS7A2000 Chipset     GNET      0x7a13          v3.73a            1
> > 
> > ?
> 
> No! PCI Dev ID of GMAC is 0x7a03. So:
> 
>  LS2K1000 CPU         GMAC      0x7a03       v3.50a/v3.73a 1
>  LS7A1000 Chipset     GMAC      0x7a03       v3.50a/v3.73a 1
> +LS2K2000 CPU         GMAC      0x7a03          v3.73a 8
>  LS2K2000 CPU         GNET      0x7a13          v3.73a 8
>  LS7A2000 Chipset     GNET      0x7a13          v3.73a 1
> 
> > 
> > I'll continue reviewing the series after the questions above are
> > clarified.
> 

> OK, If anything else is unclear, please let me know.

Got it. Thanks for clarifying. I'll get back to reviewing the series
tomorrow. Sorry for the timebreak.

-Serge(y)

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Yanteng Si]

在 2024/6/24 09:47, Serge Semin 写道:
> On Mon, Jun 17, 2024 at 06:00:19PM +0800, Yanteng Si wrote:
>> Hi Serge,
>>
>> 在 2024/6/15 00:19, Serge Semin 写道:
>>> On Wed, May 29, 2024 at 06:19:03PM +0800, Yanteng Si wrote:
>>>> 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
>>> You mentioned in the cover-letter
>>> https://lore.kernel.org/netdev/cover.1716973237.git.siyanteng@loongson.cn/
>>> that LS2K now have GMAC NICs too:
>>> " 1. The current LS2K2000 also have a GMAC(and two GNET) that supports 8
>>>       channels, so we have to reconsider the initialization of
>>>       tx/rx_queues_to_use into probe();"
>>>
>>> But I don't see much changes in the series which would indicate that
>>> new data. Please clarify what does it mean:
>>>
>>> Does it mean LS2K2000 has two types of the DW GMACs, right?
>> Yes!
>>> Are both of them based on the DW GMAC v3.73a IP-core with AV-feature
>>> enabled and 8 DMA-channels?
>> Yes!
>>> Seeing you called the new device as GMAC it doesn't have an
>>> integrated PHY as GNETs do, does it? If so, then neither
>>> STMMAC_FLAG_DISABLE_FORCE_1000 nor loongson_gnet_fix_speed() relevant
>>> for the new device, right?
>> YES!
>>> Why haven't you changed the sheet in the commit log? Shall the sheet
>>> be updated like this:
>>>
>>>       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         GMAC      0x7a13          v3.73a            8
>>>    LS2K2000 CPU         GNET      0x7a13          v3.73a            8
>>>    LS7A2000 Chipset     GNET      0x7a13          v3.73a            1
>>>
>>> ?
>> No! PCI Dev ID of GMAC is 0x7a03. So:
>>
>>   LS2K1000 CPU         GMAC      0x7a03       v3.50a/v3.73a 1
>>   LS7A1000 Chipset     GMAC      0x7a03       v3.50a/v3.73a 1
>> +LS2K2000 CPU         GMAC      0x7a03          v3.73a 8
>>   LS2K2000 CPU         GNET      0x7a13          v3.73a 8
>>   LS7A2000 Chipset     GNET      0x7a13          v3.73a 1
>>
>>> I'll continue reviewing the series after the questions above are
>>> clarified.
>> OK, If anything else is unclear, please let me know.
> Got it. Thanks for clarifying. I'll get back to reviewing the series
> tomorrow. Sorry for the timebreak.

OK. No worries.


Thanks,

Yanteng


>
> -Serge(y)

Re: [PATCH net-next v13 13/15] net: stmmac: dwmac-loongson: Drop pci_enable/disable_msi temporarily

[Serge Semin]

> [PATCH net-next v13 13/15] net: stmmac: dwmac-loongson: Drop pci_enable/disable_msi temporarily

You don't drop the methods call "temporarily" but forever. So fix
the subject like this please:
[PATCH net-next v13 13/15] net: stmmac: dwmac-loongson: Drop pci_enable_msi/disable_msi methods call

I understand that you meant that the MSI IRQs support will be
added later in framework of another commit and for the multi-channel
device case. But mentioning that in a way you did makes the commit log
more confusing than better explaining the change.

On Wed, May 29, 2024 at 06:21:08PM +0800, Yanteng Si wrote:
> The LS2K2000 patch added later will alloc vectors, so let's
> remove pci_enable/disable_msi temporarily to prepare for later
> calls to pci_alloc_irq_vectors/pci_free_irq_vectors. This does
> not affect the work of gmac devices, as they actually use intx.

As I mentioned in v12 AFAICS the MSI IRQs haven't been utilized on the
Loongseon GMAC devices so far since the IRQ numbers have been retrieved
directly from device DT-node. That's what you should have mentioned in
the log. Like this:
"The Loongson GMAC driver currently doesn't utilize the MSI IRQs, but
retrieves the IRQs specified in the device DT-node. Let's drop the
direct pci_enable_msi()/pci_disable_msi() calls then as redundant."

If what I said was correct and MSIs enable wasn't required for the
platform IRQs to work, then please use the log and move this patch to
being submitted between
[PATCH net-next v13 04/15] net: stmmac: dwmac-loongson: Drop duplicated hash-based filter size init
and
[PATCH net-next v13 05/15] net: stmmac: dwmac-loongson: Use PCI_DEVICE_DATA() macro for device identification

so the redundant pci_enable_msi()/pci_disable_msi() code wouldn't be
getting on a way of the subsequent preparation changes.

I'll get back to reviewing the rest of the patches tomorrow. That new
LS2K2000 + LS GMAC info made things much harder to comprehend than I
thought. But I think I finally managed to come up with what should be
done with the commit logs and the changes, to make it being taken into
account.

-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 | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index fdd25ff33d02..45dcc35b7955 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -167,7 +167,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  		res.irq = pdev->irq;
>  	}
>  
> -	pci_enable_msi(pdev);
>  	memset(&res, 0, sizeof(res));
>  	res.addr = pcim_iomap_table(pdev)[0];
>  
> @@ -176,12 +175,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:
> @@ -205,7 +202,6 @@ static void loongson_dwmac_remove(struct pci_dev *pdev)
>  		break;
>  	}
>  
> -	pci_disable_msi(pdev);
>  	pci_disable_device(pdev);
>  }
>  
> -- 
> 2.31.4
> 

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Serge Semin]

On Tue, Jun 25, 2024 at 08:31:32PM +0800, Yanteng Si wrote:
> 
> 在 2024/6/24 09:47, Serge Semin 写道:
> > On Mon, Jun 17, 2024 at 06:00:19PM +0800, Yanteng Si wrote:
> > > Hi Serge,
> > > 
> > > 在 2024/6/15 00:19, Serge Semin 写道:
> > > > On Wed, May 29, 2024 at 06:19:03PM +0800, Yanteng Si wrote:
> > > > > 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
> > > > You mentioned in the cover-letter
> > > > https://lore.kernel.org/netdev/cover.1716973237.git.siyanteng@loongson.cn/
> > > > that LS2K now have GMAC NICs too:
> > > > " 1. The current LS2K2000 also have a GMAC(and two GNET) that supports 8
> > > >       channels, so we have to reconsider the initialization of
> > > >       tx/rx_queues_to_use into probe();"
> > > > 
> > > > But I don't see much changes in the series which would indicate that
> > > > new data. Please clarify what does it mean:
> > > > 
> > > > Does it mean LS2K2000 has two types of the DW GMACs, right?
> > > Yes!
> > > > Are both of them based on the DW GMAC v3.73a IP-core with AV-feature
> > > > enabled and 8 DMA-channels?
> > > Yes!
> > > > Seeing you called the new device as GMAC it doesn't have an
> > > > integrated PHY as GNETs do, does it? If so, then neither
> > > > STMMAC_FLAG_DISABLE_FORCE_1000 nor loongson_gnet_fix_speed() relevant
> > > > for the new device, right?
> > > YES!
> > > > Why haven't you changed the sheet in the commit log? Shall the sheet
> > > > be updated like this:
> > > > 
> > > >       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         GMAC      0x7a13          v3.73a            8
> > > >    LS2K2000 CPU         GNET      0x7a13          v3.73a            8
> > > >    LS7A2000 Chipset     GNET      0x7a13          v3.73a            1
> > > > 
> > > > ?
> > > No! PCI Dev ID of GMAC is 0x7a03. So:
> > > 
> > >   LS2K1000 CPU         GMAC      0x7a03       v3.50a/v3.73a 1
> > >   LS7A1000 Chipset     GMAC      0x7a03       v3.50a/v3.73a 1
> > > +LS2K2000 CPU         GMAC      0x7a03          v3.73a 8
> > >   LS2K2000 CPU         GNET      0x7a13          v3.73a 8
> > >   LS7A2000 Chipset     GNET      0x7a13          v3.73a 1
> > > 
> > > > I'll continue reviewing the series after the questions above are
> > > > clarified.
> > > OK, If anything else is unclear, please let me know.
> > Got it. Thanks for clarifying. I'll get back to reviewing the series
> > tomorrow. Sorry for the timebreak.
> 
> OK. No worries.

Seeing Loongson GMAC can be also found with the 8-channels AV feature 
enabled, we'll need to reconsider the patches logic and thus the 
commit logs too. I'll try to thoroughly describe the changes in the
respective parts of the series. But in general, if what I've come up
with is implemented, the patchset will turn to look as follows:

[PATCH net-next v14 01/15] net: stmmac: Move the atds flag to the stmmac_dma_cfg structure
[PATCH net-next v14 02/15] net: stmmac: Add multi-channel support
[PATCH net-next v14 03/15] net: stmmac: Export dwmac1000_dma_ops
[PATCH net-next v14 04/15] net: stmmac: dwmac-loongson: Drop duplicated hash-based filter size init
[PATCH net-next v14 05/15] net: stmmac: dwmac-loongson: Drop pci_enable/disable_msi calls
[PATCH net-next v14 06/15] net: stmmac: dwmac-loongson: Use PCI_DEVICE_DATA() macro for device identification

[PATCH net-next v14 07/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init
+-> Init the plat_stmmacenet_data::{tx_queues_to_use,rx_queues_to_use}
    in the loongson_gmac_data() method.

[PATCH net-next v14 08/15] net: stmmac: dwmac-loongson: Init ref and PTP clocks rate
[PATCH net-next v14 09/15] net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC

[PATCH net-next v14 10/15] net: stmmac: dwmac-loongson: Introduce PCI device info data
+-> Make sure the setup() method is called after the pci_enable_device()
    invocation.

[PATCH net-next v14 11/15] net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support
+-> Introduce the loongson_dwmac_dt_config() method here instead of
    doing that in a separate patch.
+-> Add loongson_dwmac_acpi_config() which would just get the IRQ from
    the pdev->irq field and make sure it is valid.

[PATCH net-next v14 12/15] net: stmmac: Fixed failure to set network speed to 1000.
+-> ... not sure what to do with this ...

[PATCH net-next v14 13/15] net: stmmac: dwmac-loongson: Add Loongson Multi-channels GMAC support
+-> This is former "net: stmmac: dwmac-loongson: Add Loongson GNET
    support" patch, but which adds the support of the Loongson GMAC with the
    8-channels AV-feature available.
+-> loongson_dwmac_intx_config() shall be dropped due to the
    loongson_dwmac_acpi_config() method added in the PATCH 11/15.
+-> Make sure loongson_data::loongson_id is initialized before the
    stmmac_pci_info::setup() is called.
+-> Move the rx_queues_to_use/tx_queues_to_use and coe_unsupported
    fields initialization to the loongson_gmac_data() method.
+-> As before, call the loongson_dwmac_msi_config() method if the multi-channels
    Loongson MAC has been detected.
+-> Move everything GNET-specific to the next patch.

[PATCH net-next v14 14/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
+-> Everything Loonsgson GNET-specific is supposed to be added in the
    framework of this patch:
    + PCI_DEVICE_ID_LOONGSON_GNET macro
    + loongson_gnet_fix_speed() method
    + loongson_gnet_data() method
    + loongson_gnet_pci_info data
    + The GNET-specific part of the loongson_dwmac_setup() method.
    + ...

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

Hopefully I didn't forget anything. I'll give more details in the
comments to the respective patches.

-Serge(y)

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

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Serge Semin]

On Wed, May 29, 2024 at 06:19:03PM +0800, Yanteng Si wrote:
> 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.

Based on the last hardware setup insight Loongson GMAC with AV-feature
can be found on the LS2K2000 CPU. Thus the commit log should be:

"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         GMAC      0x7a03          v3.73a            8
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 synthesized with a single DMA-channel available. 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  | 19 ++++++++++++-------
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 739b73f4fc35..ad3f44440963 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -11,7 +11,7 @@
>  
>  #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;
> @@ -20,16 +20,14 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>  	/* Set default value for multicast hash bins */
>  	plat->multicast_filter_bins = 256;
>  
> +	plat->mac_interface = PHY_INTERFACE_MODE_NA;
> +
>  	/* 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;
> @@ -42,6 +40,11 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>  
>  	plat->dma_cfg->pbl = 32;
>  	plat->dma_cfg->pblx8 = true;
> +}
> +
> +static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
> +{
> +	loongson_default_data(plat);
>  
>  	return 0;
>  }
> @@ -111,11 +114,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];
> @@ -140,6 +142,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;
> +

Please move this to the loongson_gmac_data(). Thus all the
platform-data initializations would be collected in two coherent
methods: loongson_default_data() and loongson_gmac_data(). It will be
positive from the readability and maintainability points of view.

In the patch adding the Loongson multi-channel GMAC support make sure
the loongson_data::loongson_id field is initialized before the
stmmac_pci_info::setup() method is called.

-Serge(y)

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

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

[Serge Semin]

On Wed, May 29, 2024 at 06:19:47PM +0800, Yanteng Si wrote:
> The phy_interface of gmac is PHY_INTERFACE_MODE_RGMII_ID.

It's better to translate this to a normal sentence:
"PHY-interface of the Loongson GMAC device is RGMII with no internal
delays added to the data lines signal. So to comply with that let's
pre-initialize the platform-data field with the respective enum
constant."

-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 e725c59c6c98..0289956e274b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -49,6 +49,8 @@ static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
>  {
>  	loongson_default_data(plat);
>  
> +	plat->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
> +
>  	return 0;
>  }
>  
> -- 
> 2.31.4
> 

Re: [PATCH net-next v13 09/15] net: stmmac: dwmac-loongson: Introduce PCI device info data

[Serge Semin]

On Wed, May 29, 2024 at 06:19:48PM +0800, Yanteng Si wrote:
> Just introduce PCI device info data to prepare for later
> ACPI-base support. Loongson machines may use UEFI (implies
> ACPI) or PMON/UBOOT (implies FDT) as the BIOS.
> 
> The BIOS type has no relationship with device types, which
> means: machines can be either ACPI-based or FDT-based.

AFAICS the commit log is misleading because the DT-less (ACPI-based)
setups is being added in the next commit and it's implemented by using
the if-else statement with no setup() callback infrastructure
utilized.

But this change is still needed for adding the Loongson GNET support
later in the series. The setup() callback will be pre-initialized with
the network controller specific method based on the PCIe Device ID. So
to speak, please alter the commit log with the correct justification.
Like this:

"The Loongson GNET device support is about to be added in one of the
next commits. As another preparation for that introduce the PCI device
info data with a setup() callback performing the device-specific
platform data initializations. Currently it is utilized for the
already supported Loongson GMAC device only."

-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>
> ---
>  .../ethernet/stmicro/stmmac/dwmac-loongson.c    | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 0289956e274b..fec2aa0607d4 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -11,6 +11,10 @@
>  
>  #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
>  
> +struct stmmac_pci_info {
> +	int (*setup)(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 */
> @@ -54,9 +58,14 @@ 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;
> +	struct stmmac_pci_info *info;
>  	struct stmmac_resources res;
>  	struct device_node *np;
>  	int ret, i, phy_mode;
> @@ -107,6 +116,11 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  		break;
>  	}
>  
> +	info = (struct stmmac_pci_info *)id->driver_data;
> +	ret = info->setup(plat);
> +	if (ret)
> +		goto err_disable_device;
> +
>  	plat->bus_id = of_alias_get_id(np, "ethernet");
>  	if (plat->bus_id < 0)
>  		plat->bus_id = pci_dev_id(pdev);
> @@ -122,7 +136,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  
>  	pci_set_master(pdev);
>  
> -	loongson_gmac_data(plat);
>  	pci_enable_msi(pdev);
>  	memset(&res, 0, sizeof(res));
>  	res.addr = pcim_iomap_table(pdev)[0];
> @@ -224,7 +237,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
> 

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Yanteng Si]

在 2024/7/2 06:57, Serge Semin 写道:
> On Tue, Jun 25, 2024 at 08:31:32PM +0800, Yanteng Si wrote:
>> 在 2024/6/24 09:47, Serge Semin 写道:
>>> On Mon, Jun 17, 2024 at 06:00:19PM +0800, Yanteng Si wrote:
>>>> Hi Serge,
>>>>
>>>> 在 2024/6/15 00:19, Serge Semin 写道:
>>>>> On Wed, May 29, 2024 at 06:19:03PM +0800, Yanteng Si wrote:
>>>>>> 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
>>>>> You mentioned in the cover-letter
>>>>> https://lore.kernel.org/netdev/cover.1716973237.git.siyanteng@loongson.cn/
>>>>> that LS2K now have GMAC NICs too:
>>>>> " 1. The current LS2K2000 also have a GMAC(and two GNET) that supports 8
>>>>>        channels, so we have to reconsider the initialization of
>>>>>        tx/rx_queues_to_use into probe();"
>>>>>
>>>>> But I don't see much changes in the series which would indicate that
>>>>> new data. Please clarify what does it mean:
>>>>>
>>>>> Does it mean LS2K2000 has two types of the DW GMACs, right?
>>>> Yes!
>>>>> Are both of them based on the DW GMAC v3.73a IP-core with AV-feature
>>>>> enabled and 8 DMA-channels?
>>>> Yes!
>>>>> Seeing you called the new device as GMAC it doesn't have an
>>>>> integrated PHY as GNETs do, does it? If so, then neither
>>>>> STMMAC_FLAG_DISABLE_FORCE_1000 nor loongson_gnet_fix_speed() relevant
>>>>> for the new device, right?
>>>> YES!
>>>>> Why haven't you changed the sheet in the commit log? Shall the sheet
>>>>> be updated like this:
>>>>>
>>>>>        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         GMAC      0x7a13          v3.73a            8
>>>>>     LS2K2000 CPU         GNET      0x7a13          v3.73a            8
>>>>>     LS7A2000 Chipset     GNET      0x7a13          v3.73a            1
>>>>>
>>>>> ?
>>>> No! PCI Dev ID of GMAC is 0x7a03. So:
>>>>
>>>>    LS2K1000 CPU         GMAC      0x7a03       v3.50a/v3.73a 1
>>>>    LS7A1000 Chipset     GMAC      0x7a03       v3.50a/v3.73a 1
>>>> +LS2K2000 CPU         GMAC      0x7a03          v3.73a 8
>>>>    LS2K2000 CPU         GNET      0x7a13          v3.73a 8
>>>>    LS7A2000 Chipset     GNET      0x7a13          v3.73a 1
>>>>
>>>>> I'll continue reviewing the series after the questions above are
>>>>> clarified.
>>>> OK, If anything else is unclear, please let me know.
>>> Got it. Thanks for clarifying. I'll get back to reviewing the series
>>> tomorrow. Sorry for the timebreak.
>> OK. No worries.
> Seeing Loongson GMAC can be also found with the 8-channels AV feature
> enabled, we'll need to reconsider the patches logic and thus the
> commit logs too. I'll try to thoroughly describe the changes in the
> respective parts of the series. But in general, if what I've come up
> with is implemented, the patchset will turn to look as follows:
>
> [PATCH net-next v14 01/15] net: stmmac: Move the atds flag to the stmmac_dma_cfg structure
> [PATCH net-next v14 02/15] net: stmmac: Add multi-channel support
> [PATCH net-next v14 03/15] net: stmmac: Export dwmac1000_dma_ops
> [PATCH net-next v14 04/15] net: stmmac: dwmac-loongson: Drop duplicated hash-based filter size init
> [PATCH net-next v14 05/15] net: stmmac: dwmac-loongson: Drop pci_enable/disable_msi calls
> [PATCH net-next v14 06/15] net: stmmac: dwmac-loongson: Use PCI_DEVICE_DATA() macro for device identification
>
> [PATCH net-next v14 07/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init
> +-> Init the plat_stmmacenet_data::{tx_queues_to_use,rx_queues_to_use}
>      in the loongson_gmac_data() method.
>
> [PATCH net-next v14 08/15] net: stmmac: dwmac-loongson: Init ref and PTP clocks rate
> [PATCH net-next v14 09/15] net: stmmac: dwmac-loongson: Add phy_interface for Loongson GMAC
>
> [PATCH net-next v14 10/15] net: stmmac: dwmac-loongson: Introduce PCI device info data
> +-> Make sure the setup() method is called after the pci_enable_device()
>      invocation.
>
> [PATCH net-next v14 11/15] net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support
> +-> Introduce the loongson_dwmac_dt_config() method here instead of
>      doing that in a separate patch.
> +-> Add loongson_dwmac_acpi_config() which would just get the IRQ from
>      the pdev->irq field and make sure it is valid.
>
> [PATCH net-next v14 12/15] net: stmmac: Fixed failure to set network speed to 1000.
> +-> ... not sure what to do with this ...
>
> [PATCH net-next v14 13/15] net: stmmac: dwmac-loongson: Add Loongson Multi-channels GMAC support
> +-> This is former "net: stmmac: dwmac-loongson: Add Loongson GNET
>      support" patch, but which adds the support of the Loongson GMAC with the
>      8-channels AV-feature available.
> +-> loongson_dwmac_intx_config() shall be dropped due to the
>      loongson_dwmac_acpi_config() method added in the PATCH 11/15.
> +-> Make sure loongson_data::loongson_id is initialized before the
>      stmmac_pci_info::setup() is called.
> +-> Move the rx_queues_to_use/tx_queues_to_use and coe_unsupported
>      fields initialization to the loongson_gmac_data() method.
> +-> As before, call the loongson_dwmac_msi_config() method if the multi-channels
>      Loongson MAC has been detected.
> +-> Move everything GNET-specific to the next patch.
>
> [PATCH net-next v14 14/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
> +-> Everything Loonsgson GNET-specific is supposed to be added in the
>      framework of this patch:
>      + PCI_DEVICE_ID_LOONGSON_GNET macro
>      + loongson_gnet_fix_speed() method
>      + loongson_gnet_data() method
>      + loongson_gnet_pci_info data
>      + The GNET-specific part of the loongson_dwmac_setup() method.
>      + ...
>
> [PATCH net-next v14 15/15] net: stmmac: dwmac-loongson: Add loongson module author
>
> Hopefully I didn't forget anything. I'll give more details in the
> comments to the respective patches.

OK.  Thanks!


Thanks,

Yanteng

> -Serge(y)
>

Re: [PATCH net-next v13 10/15] net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support

[Serge Semin]

On Wed, May 29, 2024 at 06:20:26PM +0800, Yanteng Si wrote:
> 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.

We need to mention the ACPI-part here. 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.
But Loongson machines may have UEFI (implies ACPI) or PMON/UBOOT
(implies FDT) as the system bootloaders. In order to have both system
configurations support 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."

This shall well justify the change introduced in this patch and in the
patch "net: stmmac: dwmac-loongson: Add loongson_dwmac_dt_config"
which content I suggest to merge in into this one.

> 
> 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  | 105 +++++++++---------
>  1 file changed, 53 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index fec2aa0607d4..8bcf9d522781 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -12,11 +12,15 @@
>  #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
>  
>  struct stmmac_pci_info {
> -	int (*setup)(struct plat_stmmacenet_data *plat);
> +	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
>  };
>  
> -static void loongson_default_data(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 overwritten later */
> +	plat->bus_id = pci_dev_id(pdev);
> +
>  	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
>  	plat->has_gmac = 1;
>  	plat->force_sf_dma_mode = 1;
> @@ -49,9 +53,10 @@ static void loongson_default_data(struct plat_stmmacenet_data *plat)
>  	plat->dma_cfg->pblx8 = true;
>  }
>  
> -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->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
>  
> @@ -68,15 +73,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  	struct stmmac_pci_info *info;
>  	struct stmmac_resources res;
>  	struct device_node *np;
> -	int ret, i, phy_mode;
> +	int ret, i;
>  
>  	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;
> @@ -87,17 +87,9 @@ 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;
> -		goto err_put_node;
> -	}
> +	if (!plat->dma_cfg)
> +		return -ENOMEM;
>  
>  	/* Enable pci device */
>  	ret = pci_enable_device(pdev);
> @@ -117,49 +109,58 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  	}
>  
>  	info = (struct stmmac_pci_info *)id->driver_data;
> -	ret = info->setup(plat);
> +	ret = info->setup(pdev, plat);
>  	if (ret)
>  		goto err_disable_device;
>  
> -	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;
> -		goto err_disable_device;
> -	}
> +	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;
> +		}
>  
> -	plat->phy_interface = phy_mode;
> +		ret = of_alias_get_id(np, "ethernet");
> +		if (ret >= 0)
> +			plat->bus_id = ret;
>  
> -	pci_set_master(pdev);
> +		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;
> +
> +		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;
> +	}

Please merge in the patch:
[PATCH net-next v13 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_dt_config
content into this one and introduce the method:

static int loongson_dwmac_acpi_config(struct pci_dev *pdev,
				      struct plat_stmmacenet_data *plat,
				      struct stmmac_resources *res)
{
	if (!pdev->irq)
		return -EINVAL;

	res->irq = pdev->irq;

	return 0;
}

just below the loongson_dwmac_dt_config() function. Thus the only code
left in the probe() method would be:

	if (dev_of_node(&pdev->dev))
		ret = loongson_dwmac_dt_config(pdev, plat, &res);
	else
		ret = loongson_dwmac_acpi_config(pdev, plat, &res);

	if (ret)
		goto err_disable_device;

As a result this patch will look simpler and more coherent. So will
the probe() method with no additional change required for that.

-Serge(y)

>  
>  	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;
>  
> -- 
> 2.31.4
> 

Re: [PATCH net-next v13 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_dt_config

[Serge Semin]

On Wed, May 29, 2024 at 06:20:27PM +0800, Yanteng Si wrote:
> While at it move the np initialization procedure into a dedicated
> method. It will be useful in one of the subsequent commit adding the
> Loongson GNET device support.

As I just mentioned please merge in this patch content into the
previous patch:
[PATCH net-next v13 10/15] net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support

-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>
> ---
>  .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 90 ++++++++++---------
>  1 file changed, 50 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 8bcf9d522781..fdd25ff33d02 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -67,16 +67,60 @@ static struct stmmac_pci_info loongson_gmac_pci_info = {
>  	.setup = loongson_gmac_data,
>  };
>  
> +static int loongson_dwmac_dt_config(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;
> +	}
> +
> +	ret = device_get_phy_mode(&pdev->dev);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "phy_mode not found\n");
> +		return -ENODEV;
> +	}
> +
> +	plat->phy_interface = ret;
> +
> +	return 0;
> +}
> +
>  static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  {
>  	struct plat_stmmacenet_data *plat;
>  	struct stmmac_pci_info *info;
>  	struct stmmac_resources res;
> -	struct device_node *np;
>  	int ret, i;
>  
> -	np = dev_of_node(&pdev->dev);
> -
>  	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
>  	if (!plat)
>  		return -ENOMEM;
> @@ -115,44 +159,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  
>  	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;
> -		}
> -
> -		ret = of_alias_get_id(np, "ethernet");
> -		if (ret >= 0)
> -			plat->bus_id = ret;
> -
> -		ret = device_get_phy_mode(&pdev->dev);
> -		if (ret < 0) {
> -			dev_err(&pdev->dev, "phy_mode not found\n");
> +	if (dev_of_node(&pdev->dev)) {
> +		ret = loongson_dwmac_dt_config(pdev, plat, &res);
> +		if (ret)
>  			goto err_disable_device;
> -		}
> -
> -		plat->phy_interface = ret;
> -
> -		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;
>  	}
> -- 
> 2.31.4
> 

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

[Serge Semin]

On Tue, Jun 04, 2024 at 11:29:43AM +0000, si.yanteng@linux.dev wrote:
> 2024年5月30日 15:22, "Russell King (Oracle)" <linux@armlinux.org.uk> 写到:
> 
> Hi, Russell, Serge,
> 
> > 
> > On Thu, May 30, 2024 at 10:25:01AM +0800, Huacai Chen wrote:
> > 
> > > 
> > > Hi, Yanteng,
> > > 
> > >  
> > > 
> > >  The title should be "Fix ....." rather than "Fixed .....", and it is
> > > 
> > 
> > I would avoid the ambiguous "Fix" which for stable folk imply that this
> > 
> > is a bug fix - but it isn't. It's adding support for requiring 1G
> > 
> > speeds to always be negotiated.
> Oh, I get it now. Thanks!
> 
> > 
> > I would like this patch to be held off until more thought can be put
> > 
> > into how to handle this without having a hack in the driver (stmmac
> > 
> > has too many hacks and we're going to have to start saying no to
> > 
> > these.)
> Yeah, you have a point there, but I would also like to hear Serge's opinion.

I would be really glad not to have so many hacks in the STMMAC driver.
It would have been awesome if we are able to find a solution without
introducing one more quirk in the common driver code.

I started digging into this sometime ago, but failed to come up with
any decent hypothesis about the problem nature. One of the glimpse
idea was that the loongson_gnet_fix_speed() method code might be somehow
connected with the problem. But I didn't have much time to go further
than that.

Anyway I guess we'll need to have at least two more patchset
re-spins to settle all the found issues. Until then we can keep
discussing the problem Yanteng experience on his device. Russell, do
you have any suggestion of what info Yanteng should provide to better
understand the problem and get closer to it' cause?

-Serge(y)

> 
> 
> 
> Thanks,
> Yanteng

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Yanteng Si]

在 2024/7/2 16:28, Serge Semin 写道:
> On Wed, May 29, 2024 at 06:19:03PM +0800, Yanteng Si wrote:
>> 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.
> Based on the last hardware setup insight Loongson GMAC with AV-feature
> can be found on the LS2K2000 CPU. Thus the commit log should be:
>
> "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         GMAC      0x7a03          v3.73a            8
> 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 synthesized with a single DMA-channel available. 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, Thank you very much!
>
>> 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  | 19 ++++++++++++-------
>>   1 file changed, 12 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> index 739b73f4fc35..ad3f44440963 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> @@ -11,7 +11,7 @@
>>   
>>   #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;
>> @@ -20,16 +20,14 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>>   	/* Set default value for multicast hash bins */
>>   	plat->multicast_filter_bins = 256;
>>   
>> +	plat->mac_interface = PHY_INTERFACE_MODE_NA;
>> +
>>   	/* 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;
>> @@ -42,6 +40,11 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
>>   
>>   	plat->dma_cfg->pbl = 32;
>>   	plat->dma_cfg->pblx8 = true;
>> +}
>> +
>> +static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
>> +{
>> +	loongson_default_data(plat);
>>   
>>   	return 0;
>>   }
>> @@ -111,11 +114,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];
>> @@ -140,6 +142,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;
>> +
> Please move this to the loongson_gmac_data(). Thus all the
> platform-data initializations would be collected in two coherent
> methods: loongson_default_data() and loongson_gmac_data(). It will be
> positive from the readability and maintainability points of view.

OK, I will move this to the  loongson_default_data(),

Because loongson_gmac/gnet_data() call it.


>
> In the patch adding the Loongson multi-channel GMAC support make sure
> the loongson_data::loongson_id field is initialized before the
> stmmac_pci_info::setup() method is called.

I've tried. It's almost impossible.


The only way to do this is to initialize loongson_id again in 
loongson_default_data().

But that will add a lot of code.


Hmm, how about:


loongson_default_data() {

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

     ...

}


loongson_dwmac_probe() {

     ...

     if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
         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_msi_config(pdev, plat, &res);
     } else {
         ret = loongson_dwmac_intx_config(pdev, plat, &res);
     }

     ...

}



Thanks,

Yanteng

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

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

[Serge Semin]

> [PATCH net-next v13 14/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

Seeing the multi-channels AV-feature can be found on the Loongson
GMACs too we have to reconsider this patch logic by converting it to
adding the multi-channels support for the Loongson GMAC device only.
Everything Loongson GNET-specific should be moved to a new following
up patch.

So firstly please change this patch subject to:
[PATCH net-next v14 13/15] net: stmmac: dwmac-loongson: Add Loongson Multi-channels GMAC support

On Wed, May 29, 2024 at 06:21:09PM +0800, Yanteng Si wrote:
> 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.

Please convert the commit log of this patch to containing the
multi-channels feature description only. Like this (correct me if I am
wrong in understanding some of the Loongson network controllers
aspects):

"The Loongson DWMAC driver currently supports the Loongson GMAC
devices (based on the DW GMAC v3.50a/v3.73a IP-core) installed to the
LS2K1000 SoC and LS7A1000 chipset. But recently a new generation
LS2K2000 SoC was released with the new version of the Loongson GMAC
synthesized in. The new controller is based on the DW GMAC v3.73a
IP-core with the AV-feature enabled, which implies the multi
DMA-channels support. The multi DMA-channels feature has the next
vendor-specific 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 register
field. It's 0x10 while it should have been 0x37 in accordance with
the actual DW GMAC IP-core version.
3. There are eight DMA-channels available meanwhile the Synopsys DW
GMAC IP-core supports up to three DMA-channels.
4. It's possible to have each DMA-channel IRQ independently delivered.
The MSI IRQs must be utilized for that.

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

1. Create the multi-channels Loongson GMAC-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 DWMAC-specific platform setup() method
which gets to initialize the DMA-ops with the dwmac1000_dma_ops
instance and overrides the callbacks described in 1. The method also
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 platform setup() method enables the flow control and
duplex modes supported by the controller.
"

Once again, please correct the text if I was wrong in understanding
the way your devices work. Especially regarding the flow-control and
half-duplex mode.

---

The Loongson GNET-specific changes should be moved to the new patch
applied after this one. The subject of the new patch should be the same
as the former subject of this patch:
[PATCH net-next v14 14/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
but of course the commit log shall be different. Like this:

"The new generation Loongson LS2K2000 SoC and LS7A2000 chipset are
equipped with the network controllers called Loongson GNET. It's the
single and multi DMA-channels Loongson GMAC but with a PHY attached.
Here is the summary of the DW GMAC features the controller has:

   DW GMAC IP-core: v3.73a
   Speeds: 10/100/1000Mbps
   Duplex: Full (both versions), Half (LS2K2000 GNET 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 GNET only)
   DMA channels: 8 (LS2K2000 GNET), 1 (LS7A2000 GNET)

Let's update the Loongson DWMAC driver to supporting the new Loongson
GNET controller. The change is mainly trivial: the driver shall be
bound to the PCIe device with DID 0x7a13, and the device-specific
setup() method shall be called for it. The only peculiarity concerns
the integrated PHY speed change procedure. The PHY has a weird problem
with switching from the low speeds to 1000Mbps mode. The speedup
procedure requires the PHY-link re-negotiation. So the suggested
change provide the device-specific fix_mac_speed() method to overcome
the problem."

> 
> 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  | 390 +++++++++++++++++-
>  2 files changed, 387 insertions(+), 4 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 45dcc35b7955..559215e3fe41 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -8,8 +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

Please move this to the new patch adding the Loongson GNET support.

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

Note it's perfectly fine to have a device named after the SoC it's
equipped to. For example see the compatible strings defined for the
vendor-specific versions of the DW *MAC IP-cores:
Documentation/devicetree/bindings/net/snps,dwmac.yaml

But if you aren't comfortable with such naming we can change the
macro to something like:
#define DWMAC_CORE_LOONGSON_MULTI_CH	0x10

> +#define CHANNEL_NUM			8
> +
> +struct loongson_data {
> +	u32 loongson_id;

> +	struct device *dev;

Please add the "dev" field in the new patch adding the Loongson GNET support.

> +};
>  
>  struct stmmac_pci_info {
>  	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
> @@ -67,6 +130,298 @@ static struct stmmac_pci_info loongson_gmac_pci_info = {
>  	.setup = loongson_gmac_data,
>  };
>  

> +static void loongson_gnet_dma_init_channel(struct stmmac_priv *priv,

Since the multi-channel feature is no longer GNET-specific, please
rename the method prefix to loongson_dwmac_ .

> +					   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,

Similarly the loongson_dwmac_ prefix seems more appropriate now.

> +				       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[19-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 integrated PHY has a weird problem with switching from the low
> +	 * speeds to 1000Mbps mode. The speedup procedure requires the PHY-link
> +	 * re-negotiation.
> +	 */
> +	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;
> +
> +	/* 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;
> +}
> +
> +static struct stmmac_pci_info loongson_gnet_pci_info = {
> +	.setup = loongson_gnet_data,
> +};

Please move this to the new patch adding the Loongson GNET support.

> +
> +static int loongson_dwmac_intx_config(struct pci_dev *pdev,
> +				      struct plat_stmmacenet_data *plat,
> +				      struct stmmac_resources *res)
> +{
> +	res->irq = pdev->irq;
> +
> +	return 0;
> +}

If you get to implement what suggested here
https://lore.kernel.org/netdev/glm3jfqf36t5vnkmk4gsdqfx53ga7ohs3pxnsizqlogkbim7gg@a3dxav5siczn/
than the loongson_dwmac_intx_config() won't be needed.

> +
> +static int loongson_dwmac_msi_config(struct pci_dev *pdev,
> +				     struct plat_stmmacenet_data *plat,
> +				     struct stmmac_resources *res)
> +{
> +	int i, ret, vecs;
> +
> +	vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 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[CHANNEL_NUM - 1 - i] =
> +				pci_irq_vector(pdev, 1 + i * 2);
> +		}
> +		for (i = 0; i < plat->tx_queues_to_use; i++) {
> +			res->tx_irq[CHANNEL_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;
> +}

Could you please clarify whether the multi-channel feature will work
if the pci_alloc_irq_vectors() method failed to allocated as many MSI
vectors as there are channels?

> +
> +static int loongson_dwmac_msi_clear(struct pci_dev *pdev)
> +{
> +	pci_free_irq_vectors(pdev);
> +
> +	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 v3.73a 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.
> +	 */

The comment needs to be altered since the multi-channel feature is no
longer GNET-specific. Like this:

	/* The Loongson GMAC and GNET devices are based on the DW GMAC
	 * v3.50a and v3.73a IP-cores. But the HW designers have changed the
	 * GMAC_VERSION.SNPSVER field to the custom 0x10 value on the
	 * network controllers with the multi-channels feature
	 * available 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->loongson_id == DWMAC_CORE_LS2K2000) {
> +		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;
> +	}
> +
> +	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);
> +

> +	/* 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->loongson_id == DWMAC_CORE_LS2K2000)
> +			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;
> +	}

AFAIU The only part that is applicable for the multi-channels case of
the Loongson GMAC is:
+	/* Loongson GMAC doesn't support the flow control */
+	mac->link.caps = MAC_10 | MAC_100 | MAC_1000;

If so the rest of the changes in this chunk should be moved to the new
patch adding the Loongson GNET support.

> +
> +	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_dt_config(struct pci_dev *pdev,
>  				    struct plat_stmmacenet_data *plat,
>  				    struct stmmac_resources *res)
> @@ -119,6 +474,7 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  	struct plat_stmmacenet_data *plat;
>  	struct stmmac_pci_info *info;
>  	struct stmmac_resources res;
> +	struct loongson_data *ld;
>  	int ret, i;
>  
>  	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
> @@ -135,6 +491,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  	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);
>  	if (ret) {
> @@ -159,19 +519,39 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>  
>  	pci_set_master(pdev);
>  

> +	plat->bsp_priv = ld;
> +	plat->setup = loongson_dwmac_setup;
> +	ld->dev = &pdev->dev;
> +

Please make sure the chunk above and
+	ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
are performed before the stmmac_pci_info::setup() is called so the
callback could use the private platform data with the loongson_id
field initialized.

>  	if (dev_of_node(&pdev->dev)) {
>  		ret = loongson_dwmac_dt_config(pdev, plat, &res);
>  		if (ret)
>  			goto err_disable_device;
> -	} else {
> -		res.irq = pdev->irq;
>  	}
>  
>  	memset(&res, 0, sizeof(res));

I've just realised the memset() call will clear out everything
initialized in "res" by the loongson_dwmac_dt_config() method.

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


> +	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
> +		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;

Please move this part to the loongson_gmac_data() method (and to the
loongson_gnet_data() in the new patch). The only
code which would be left here is:
	if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
		ret = loongson_dwmac_msi_config(pdev, plat, &res);
		if (ret)
			goto err_disable_device;
	}

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

> +	} else {
> +		plat->tx_queues_to_use = 1;
> +		plat->rx_queues_to_use = 1;
> +
> +		ret = loongson_dwmac_intx_config(pdev, plat, &res);
> +	}
> +	if (ret)
> +		goto err_disable_device;

This won't be needed if you get to implement what is suggested here
https://lore.kernel.org/netdev/glm3jfqf36t5vnkmk4gsdqfx53ga7ohs3pxnsizqlogkbim7gg@a3dxav5siczn/

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

I don't see the MSI-configs being undone in case of the
stmmac_dvr_probe() failure. What should have been done:

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

	return 0;

err_clear_msi:
	if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH)
		loongson_dwmac_msi_clear(pdev);

err_disable_device:
	pci_disable_device(pdev);

	...

> @@ -202,6 +582,7 @@ static void loongson_dwmac_remove(struct pci_dev *pdev)
>  		break;
>  	}
>  

> +	loongson_dwmac_msi_clear(pdev);

Shouldn't this be done for the multi-channels device only? Like this
	if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH)
		loongson_dwmac_msi_clear(pdev);

>  	pci_disable_device(pdev);
>  }
>  
> @@ -245,6 +626,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) },

Please move this to the new patch adding the Loongson GNET support.



Sigh... The comments are brutal but if no more unexpected details get
to be revealed the respective alterations shall bring us to the
coherent set of changes. And hopefully there won't be need in such
comprehensive patchset refactoring anymore.(

-Serge(y)

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

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Serge Semin]

On Tue, Jul 02, 2024 at 09:14:07PM +0800, Yanteng Si wrote:
> 
> 在 2024/7/2 16:28, Serge Semin 写道:
> > On Wed, May 29, 2024 at 06:19:03PM +0800, Yanteng Si wrote:
> > > 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.
> > Based on the last hardware setup insight Loongson GMAC with AV-feature
> > can be found on the LS2K2000 CPU. Thus the commit log should be:
> > 
> > "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         GMAC      0x7a03          v3.73a            8
> > 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 synthesized with a single DMA-channel available. 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, Thank you very much!
> > 
> > > 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  | 19 ++++++++++++-------
> > >   1 file changed, 12 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > > index 739b73f4fc35..ad3f44440963 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > > @@ -11,7 +11,7 @@
> > >   #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;
> > > @@ -20,16 +20,14 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
> > >   	/* Set default value for multicast hash bins */
> > >   	plat->multicast_filter_bins = 256;
> > > +	plat->mac_interface = PHY_INTERFACE_MODE_NA;
> > > +
> > >   	/* 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;
> > > @@ -42,6 +40,11 @@ static int loongson_default_data(struct plat_stmmacenet_data *plat)
> > >   	plat->dma_cfg->pbl = 32;
> > >   	plat->dma_cfg->pblx8 = true;
> > > +}
> > > +
> > > +static int loongson_gmac_data(struct plat_stmmacenet_data *plat)
> > > +{
> > > +	loongson_default_data(plat);
> > >   	return 0;
> > >   }
> > > @@ -111,11 +114,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];
> > > @@ -140,6 +142,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;
> > > +
> > Please move this to the loongson_gmac_data(). Thus all the
> > platform-data initializations would be collected in two coherent
> > methods: loongson_default_data() and loongson_gmac_data(). It will be
> > positive from the readability and maintainability points of view.
> 

> OK, I will move this to the  loongson_default_data(),
> 
> Because loongson_gmac/gnet_data() call it.

It shall also work. But the fields will be overwritten in the
loongson_gmac_data()/loongson_gnet_data() methods for the
multi-channels case. I don't have a strong opinion against that. But
some maintainers may have.

> 
> 
> > 
> > In the patch adding the Loongson multi-channel GMAC support make sure
> > the loongson_data::loongson_id field is initialized before the
> > stmmac_pci_info::setup() method is called.
> 
> I've tried. It's almost impossible.

Emm, why is it impossible? I don't see any significant problem with
implementing that.

> 
> 
> The only way to do this is to initialize loongson_id again in
> loongson_default_data().
> 
> But that will add a lot of code.

Not sure, why? What about the next probe() code snippet:

	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
	if (!plat)
		return -ENOMEM;

	plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
					   sizeof(*plat->mdio_bus_data),
					   GFP_KERNEL);
        if (!plat->mdio_bus_data)
                return -ENOMEM;

	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
	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);
 	if (ret)
		return ret;

	// AFAIR the bus-mastering isn't required for the normal PCIe
	// IOs. So pci_set_master() can be called some place
	// afterwards.
	pci_set_master(pdev);

	for (i = 0; i < PCI_STD_NUM_BARS; i++) {
		if (pci_resource_len(pdev, i) == 0)
			continue;
		ret = pcim_iomap_regions(pdev, BIT(0), pci_name(pdev));
		if (ret)
			goto err_disable_device;
		break;
	}

	memset(&res, 0, sizeof(res));
	res.addr = pcim_iomap_table(pdev)[0];

	plat->bsp_priv = ld;
	plat->setup = loongson_dwmac_setup;
	ld->dev = &pdev->dev;
	ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;

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

	if (dev_of_node(&pdev->dev))
 		ret = loongson_dwmac_dt_config(pdev, plat, &res);
	else
		ret = loongson_dwmac_acpi_config(pdev, plat, &res);

	if (ret)
		goto err_disable_device;

	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
		ret = loongson_dwmac_msi_config(pdev, plat, &res);
		if (ret)
			goto err_disable_device;
	}

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

	return 0;

	...

The code allocates all the data, then enables the PCIe device
and maps the PCIe device resources. After that it calls all the setup
and config methods. Do I miss something?

-Serge(y)

> 
> 
> Hmm, how about:
> 
> 
> loongson_default_data() {
> 
>     plat->tx_queues_to_use = 1;
>     plat->rx_queues_to_use = 1;
> 
>     ...
> 
> }
> 
> 
> loongson_dwmac_probe() {
> 
>     ...
> 
>     if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
>         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_msi_config(pdev, plat, &res);
>     } else {
>         ret = loongson_dwmac_intx_config(pdev, plat, &res);
>     }
> 
>     ...
> 
> }
> 
> 
> 
> Thanks,
> 
> Yanteng
> 
> > 
> > -Serge(y)
> > 
> > >   	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
> > >   	if (ret)
> > >   		goto err_disable_msi;
> > > -- 
> > > 2.31.4
> > > 
> 

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

[Russell King (Oracle)]

On Tue, Jul 02, 2024 at 01:31:44PM +0300, Serge Semin wrote:
> On Tue, Jun 04, 2024 at 11:29:43AM +0000, si.yanteng@linux.dev wrote:
> > 2024年5月30日 15:22, "Russell King (Oracle)" <linux@armlinux.org.uk> 写到:
> > 
> > Hi, Russell, Serge,
> > 
> > > I would like this patch to be held off until more thought can be put
> > > 
> > > into how to handle this without having a hack in the driver (stmmac
> > > 
> > > has too many hacks and we're going to have to start saying no to
> > > 
> > > these.)
> > Yeah, you have a point there, but I would also like to hear Serge's opinion.
> 
> I would be really glad not to have so many hacks in the STMMAC driver.
> It would have been awesome if we are able to find a solution without
> introducing one more quirk in the common driver code.
> 
> I started digging into this sometime ago, but failed to come up with
> any decent hypothesis about the problem nature. One of the glimpse
> idea was that the loongson_gnet_fix_speed() method code might be somehow
> connected with the problem. But I didn't have much time to go further
> than that.
> 
> Anyway I guess we'll need to have at least two more patchset
> re-spins to settle all the found issues. Until then we can keep
> discussing the problem Yanteng experience on his device. Russell, do
> you have any suggestion of what info Yanteng should provide to better
> understand the problem and get closer to it' cause?

First question: is auto-negotiation required by 802.3 for 1000base-T?
By "required" I mean "required to be used" not "required to be
implemented". This is an important distinction, and 802.3 tends to be
a bit wooly about the exact meaning. However, I think on balance the
conclusion is that AN is mandatory _to be used_ for 1000base-T links.

Annex 40C's state diagrams seems to imply that mr_autoneg_enable
(BMCR AN ENABLE) doesn't affect whether or not the AN state machines
work for 1000base-T, and some PHY datasheets (e.g. Marvell Alaska)
state that disabling mr_autoneg_enable leaves AN enabled but forced
to 1G full duplex.

So, I'm thinking is that the ethtool interface should reject any
request where we have a PHY supporting *only* base-T for gigabit
speeds, where the user is requesting !AN && SPEED_1000 on the basis
that AN is part of the link setup of 1000base-T links.

Maybe this should be a property of the struct phy_device so we can
transition phylib and phylink to return an appropriate error to
userspace?

Alternatively, maybe just implement the Marvell Alaska solution
to this problem (if the user attempts to disable AN on a PHY
supporting only base-T at gigabit speeds, then we silently force
AN with SPEED_1000 and DUPLEX_FULL.

Andrew - seems to be an IEEE 802.3 requirement that's been missed
in phylib, any thoughts?

-- 
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 v13 14/15] net: stmmac: dwmac-loongson: Add Loongson GNET support

[Huacai Chen]

On Tue, Jul 2, 2024 at 9:43 PM Serge Semin <fancer.lancer@gmail.com> wrote:
>
> > [PATCH net-next v13 14/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
>
> Seeing the multi-channels AV-feature can be found on the Loongson
> GMACs too we have to reconsider this patch logic by converting it to
> adding the multi-channels support for the Loongson GMAC device only.
> Everything Loongson GNET-specific should be moved to a new following
> up patch.
>
> So firstly please change this patch subject to:
> [PATCH net-next v14 13/15] net: stmmac: dwmac-loongson: Add Loongson Multi-channels GMAC support
>
> On Wed, May 29, 2024 at 06:21:09PM +0800, Yanteng Si wrote:
> > 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.
>
> Please convert the commit log of this patch to containing the
> multi-channels feature description only. Like this (correct me if I am
> wrong in understanding some of the Loongson network controllers
> aspects):
>
> "The Loongson DWMAC driver currently supports the Loongson GMAC
> devices (based on the DW GMAC v3.50a/v3.73a IP-core) installed to the
> LS2K1000 SoC and LS7A1000 chipset. But recently a new generation
> LS2K2000 SoC was released with the new version of the Loongson GMAC
> synthesized in. The new controller is based on the DW GMAC v3.73a
> IP-core with the AV-feature enabled, which implies the multi
> DMA-channels support. The multi DMA-channels feature has the next
> vendor-specific 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 register
> field. It's 0x10 while it should have been 0x37 in accordance with
> the actual DW GMAC IP-core version.
> 3. There are eight DMA-channels available meanwhile the Synopsys DW
> GMAC IP-core supports up to three DMA-channels.
> 4. It's possible to have each DMA-channel IRQ independently delivered.
> The MSI IRQs must be utilized for that.
>
> Thus in order to have the multi-channels Loongson GMAC controllers
> supported let's modify the Loongson DWMAC driver in accordance with
> all the peculiarities described above:
>
> 1. Create the multi-channels Loongson GMAC-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 DWMAC-specific platform setup() method
> which gets to initialize the DMA-ops with the dwmac1000_dma_ops
> instance and overrides the callbacks described in 1. The method also
> 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 platform setup() method enables the flow control and
> duplex modes supported by the controller.
> "
>
> Once again, please correct the text if I was wrong in understanding
> the way your devices work. Especially regarding the flow-control and
> half-duplex mode.
>
> ---
>
> The Loongson GNET-specific changes should be moved to the new patch
> applied after this one. The subject of the new patch should be the same
> as the former subject of this patch:
> [PATCH net-next v14 14/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
> but of course the commit log shall be different. Like this:
>
> "The new generation Loongson LS2K2000 SoC and LS7A2000 chipset are
> equipped with the network controllers called Loongson GNET. It's the
> single and multi DMA-channels Loongson GMAC but with a PHY attached.
> Here is the summary of the DW GMAC features the controller has:
>
>    DW GMAC IP-core: v3.73a
>    Speeds: 10/100/1000Mbps
>    Duplex: Full (both versions), Half (LS2K2000 GNET 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 GNET only)
>    DMA channels: 8 (LS2K2000 GNET), 1 (LS7A2000 GNET)
>
> Let's update the Loongson DWMAC driver to supporting the new Loongson
> GNET controller. The change is mainly trivial: the driver shall be
> bound to the PCIe device with DID 0x7a13, and the device-specific
> setup() method shall be called for it. The only peculiarity concerns
> the integrated PHY speed change procedure. The PHY has a weird problem
> with switching from the low speeds to 1000Mbps mode. The speedup
> procedure requires the PHY-link re-negotiation. So the suggested
> change provide the device-specific fix_mac_speed() method to overcome
> the problem."
>
> >
> > 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  | 390 +++++++++++++++++-
> >  2 files changed, 387 insertions(+), 4 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 45dcc35b7955..559215e3fe41 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> > @@ -8,8 +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
>
> Please move this to the new patch adding the Loongson GNET support.
>
> > +#define DWMAC_CORE_LS2K2000          0x10    /* Loongson custom IP */
>
> Note it's perfectly fine to have a device named after the SoC it's
> equipped to. For example see the compatible strings defined for the
> vendor-specific versions of the DW *MAC IP-cores:
> Documentation/devicetree/bindings/net/snps,dwmac.yaml
>
> But if you aren't comfortable with such naming we can change the
> macro to something like:
> #define DWMAC_CORE_LOONGSON_MULTI_CH    0x10
Maybe DWMAC_CORE_LOONGSON_MULTICHAN or DWMAC_CORE_LOONGSON_MULTI_CHAN
is a little better?

Huacai
>
> > +#define CHANNEL_NUM                  8
> > +
> > +struct loongson_data {
> > +     u32 loongson_id;
>
> > +     struct device *dev;
>
> Please add the "dev" field in the new patch adding the Loongson GNET support.
>
> > +};
> >
> >  struct stmmac_pci_info {
> >       int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
> > @@ -67,6 +130,298 @@ static struct stmmac_pci_info loongson_gmac_pci_info = {
> >       .setup = loongson_gmac_data,
> >  };
> >
>
> > +static void loongson_gnet_dma_init_channel(struct stmmac_priv *priv,
>
> Since the multi-channel feature is no longer GNET-specific, please
> rename the method prefix to loongson_dwmac_ .
>
> > +                                        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,
>
> Similarly the loongson_dwmac_ prefix seems more appropriate now.
>
> > +                                    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[19-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 integrated PHY has a weird problem with switching from the low
> > +      * speeds to 1000Mbps mode. The speedup procedure requires the PHY-link
> > +      * re-negotiation.
> > +      */
> > +     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;
> > +
> > +     /* 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;
> > +}
> > +
> > +static struct stmmac_pci_info loongson_gnet_pci_info = {
> > +     .setup = loongson_gnet_data,
> > +};
>
> Please move this to the new patch adding the Loongson GNET support.
>
> > +
> > +static int loongson_dwmac_intx_config(struct pci_dev *pdev,
> > +                                   struct plat_stmmacenet_data *plat,
> > +                                   struct stmmac_resources *res)
> > +{
> > +     res->irq = pdev->irq;
> > +
> > +     return 0;
> > +}
>
> If you get to implement what suggested here
> https://lore.kernel.org/netdev/glm3jfqf36t5vnkmk4gsdqfx53ga7ohs3pxnsizqlogkbim7gg@a3dxav5siczn/
> than the loongson_dwmac_intx_config() won't be needed.
>
> > +
> > +static int loongson_dwmac_msi_config(struct pci_dev *pdev,
> > +                                  struct plat_stmmacenet_data *plat,
> > +                                  struct stmmac_resources *res)
> > +{
> > +     int i, ret, vecs;
> > +
> > +     vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 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[CHANNEL_NUM - 1 - i] =
> > +                             pci_irq_vector(pdev, 1 + i * 2);
> > +             }
> > +             for (i = 0; i < plat->tx_queues_to_use; i++) {
> > +                     res->tx_irq[CHANNEL_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;
> > +}
>
> Could you please clarify whether the multi-channel feature will work
> if the pci_alloc_irq_vectors() method failed to allocated as many MSI
> vectors as there are channels?
>
> > +
> > +static int loongson_dwmac_msi_clear(struct pci_dev *pdev)
> > +{
> > +     pci_free_irq_vectors(pdev);
> > +
> > +     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 v3.73a 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.
> > +      */
>
> The comment needs to be altered since the multi-channel feature is no
> longer GNET-specific. Like this:
>
>         /* The Loongson GMAC and GNET devices are based on the DW GMAC
>          * v3.50a and v3.73a IP-cores. But the HW designers have changed the
>          * GMAC_VERSION.SNPSVER field to the custom 0x10 value on the
>          * network controllers with the multi-channels feature
>          * available 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->loongson_id == DWMAC_CORE_LS2K2000) {
> > +             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;
> > +     }
> > +
> > +     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);
> > +
>
> > +     /* 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->loongson_id == DWMAC_CORE_LS2K2000)
> > +                     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;
> > +     }
>
> AFAIU The only part that is applicable for the multi-channels case of
> the Loongson GMAC is:
> +       /* Loongson GMAC doesn't support the flow control */
> +       mac->link.caps = MAC_10 | MAC_100 | MAC_1000;
>
> If so the rest of the changes in this chunk should be moved to the new
> patch adding the Loongson GNET support.
>
> > +
> > +     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_dt_config(struct pci_dev *pdev,
> >                                   struct plat_stmmacenet_data *plat,
> >                                   struct stmmac_resources *res)
> > @@ -119,6 +474,7 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> >       struct plat_stmmacenet_data *plat;
> >       struct stmmac_pci_info *info;
> >       struct stmmac_resources res;
> > +     struct loongson_data *ld;
> >       int ret, i;
> >
> >       plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
> > @@ -135,6 +491,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> >       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);
> >       if (ret) {
> > @@ -159,19 +519,39 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
> >
> >       pci_set_master(pdev);
> >
>
> > +     plat->bsp_priv = ld;
> > +     plat->setup = loongson_dwmac_setup;
> > +     ld->dev = &pdev->dev;
> > +
>
> Please make sure the chunk above and
> +       ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
> are performed before the stmmac_pci_info::setup() is called so the
> callback could use the private platform data with the loongson_id
> field initialized.
>
> >       if (dev_of_node(&pdev->dev)) {
> >               ret = loongson_dwmac_dt_config(pdev, plat, &res);
> >               if (ret)
> >                       goto err_disable_device;
> > -     } else {
> > -             res.irq = pdev->irq;
> >       }
> >
> >       memset(&res, 0, sizeof(res));
>
> I've just realised the memset() call will clear out everything
> initialized in "res" by the loongson_dwmac_dt_config() method.
>
> >       res.addr = pcim_iomap_table(pdev)[0];
> > +     ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
> > +
>
>
> > +     if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
> > +             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;
>
> Please move this part to the loongson_gmac_data() method (and to the
> loongson_gnet_data() in the new patch). The only
> code which would be left here is:
>         if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
>                 ret = loongson_dwmac_msi_config(pdev, plat, &res);
>                 if (ret)
>                         goto err_disable_device;
>         }
>
> > +             ret = loongson_dwmac_msi_config(pdev, plat, &res);
>
> > +     } else {
> > +             plat->tx_queues_to_use = 1;
> > +             plat->rx_queues_to_use = 1;
> > +
> > +             ret = loongson_dwmac_intx_config(pdev, plat, &res);
> > +     }
> > +     if (ret)
> > +             goto err_disable_device;
>
> This won't be needed if you get to implement what is suggested here
> https://lore.kernel.org/netdev/glm3jfqf36t5vnkmk4gsdqfx53ga7ohs3pxnsizqlogkbim7gg@a3dxav5siczn/
>
> >
> >       ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
> >       if (ret)
>
> I don't see the MSI-configs being undone in case of the
> stmmac_dvr_probe() failure. What should have been done:
>
>         ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>         if (ret)
>                 goto err_clear_msi;
>
>         return 0;
>
> err_clear_msi:
>         if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH)
>                 loongson_dwmac_msi_clear(pdev);
>
> err_disable_device:
>         pci_disable_device(pdev);
>
>         ...
>
> > @@ -202,6 +582,7 @@ static void loongson_dwmac_remove(struct pci_dev *pdev)
> >               break;
> >       }
> >
>
> > +     loongson_dwmac_msi_clear(pdev);
>
> Shouldn't this be done for the multi-channels device only? Like this
>         if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH)
>                 loongson_dwmac_msi_clear(pdev);
>
> >       pci_disable_device(pdev);
> >  }
> >
> > @@ -245,6 +626,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) },
>
> Please move this to the new patch adding the Loongson GNET support.
>
>
>
> Sigh... The comments are brutal but if no more unexpected details get
> to be revealed the respective alterations shall bring us to the
> coherent set of changes. And hopefully there won't be need in such
> comprehensive patchset refactoring anymore.(
>
> -Serge(y)
>
> >       {}
> >  };
> >  MODULE_DEVICE_TABLE(pci, loongson_dwmac_id_table);
> > --
> > 2.31.4
> >

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Yanteng Si]

>>>> -	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];
>>>> @@ -140,6 +142,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;
>>>> +
>>> Please move this to the loongson_gmac_data(). Thus all the
>>> platform-data initializations would be collected in two coherent
>>> methods: loongson_default_data() and loongson_gmac_data(). It will be
>>> positive from the readability and maintainability points of view.
>> OK, I will move this to the  loongson_default_data(),
>>
>> Because loongson_gmac/gnet_data() call it.
> It shall also work. But the fields will be overwritten in the
> loongson_gmac_data()/loongson_gnet_data() methods for the
> multi-channels case. I don't have a strong opinion against that. But
> some maintainers may have.
I see. I will move this to the loongson_gmac_data()/loongson_gnet_data().
>
>>
>>> In the patch adding the Loongson multi-channel GMAC support make sure
>>> the loongson_data::loongson_id field is initialized before the
>>> stmmac_pci_info::setup() method is called.
>> I've tried. It's almost impossible.
> Emm, why is it impossible? I don't see any significant problem with
> implementing that.
Sorry, I've to take back my words.
>
>>
>> The only way to do this is to initialize loongson_id again in
>> loongson_default_data().
>>
>> But that will add a lot of code.
> Not sure, why? What about the next probe() code snippet:
Full marks!
>
> 	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
> 	if (!plat)
> 		return -ENOMEM;
>
> 	plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
> 					   sizeof(*plat->mdio_bus_data),
> 					   GFP_KERNEL);
>          if (!plat->mdio_bus_data)
>                  return -ENOMEM;
>
> 	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> 	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);
>   	if (ret)
> 		return ret;
>
> 	// AFAIR the bus-mastering isn't required for the normal PCIe
> 	// IOs. So pci_set_master() can be called some place
> 	// afterwards.
> 	pci_set_master(pdev);
>
> 	for (i = 0; i < PCI_STD_NUM_BARS; i++) {
> 		if (pci_resource_len(pdev, i) == 0)
> 			continue;
> 		ret = pcim_iomap_regions(pdev, BIT(0), pci_name(pdev));
> 		if (ret)
> 			goto err_disable_device;
> 		break;
> 	}
>
> 	memset(&res, 0, sizeof(res));
> 	res.addr = pcim_iomap_table(pdev)[0];
>
> 	plat->bsp_priv = ld;
> 	plat->setup = loongson_dwmac_setup;
> 	ld->dev = &pdev->dev;
> 	ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
>
> 	info = (struct stmmac_pci_info *)id->driver_data;
> 	ret = info->setup(plat);
> 	if (ret)
> 		goto err_disable_device;
>
> 	if (dev_of_node(&pdev->dev))
>   		ret = loongson_dwmac_dt_config(pdev, plat, &res);
> 	else

> 		ret = loongson_dwmac_acpi_config(pdev, plat, &res);

I don't know how to write this function, it seems that there

is no obvious acpi code in the probe method.

>
> 	if (ret)
> 		goto err_disable_device;
>
> 	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
> 		ret = loongson_dwmac_msi_config(pdev, plat, &res);
> 		if (ret)
> 			goto err_disable_device;
> 	}

It seems that we don't need if else.

If failed to allocate msi,  it will fallback to intx.

so loongson_dwmac_msi_config also needs a new name. How about:

...

     ret = loongson_dwmac_irq_config(pdev, plat, &res);
     if (ret)
         goto err_disable_device;

     ret = stmmac_dvr_probe(&pdev->dev, plat, &res);

...



>
> 	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>   	if (ret)
> 		goto err_clear_msi;
>
> 	return 0;
>
> 	...
>
> The code allocates all the data, then enables the PCIe device
> and maps the PCIe device resources. After that it calls all the setup
> and config methods. Do I miss something?

You are right!



Thanks,

Yanteng

>
> -Serge(y)
>
>>>> 2.31.4
>>>>

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

[Yanteng Si]

在 2024/7/2 21:43, Serge Semin 写道:
>> [PATCH net-next v13 14/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
> Seeing the multi-channels AV-feature can be found on the Loongson
> GMACs too we have to reconsider this patch logic by converting it to
> adding the multi-channels support for the Loongson GMAC device only.
> Everything Loongson GNET-specific should be moved to a new following
> up patch.
>
> So firstly please change this patch subject to:
> [PATCH net-next v14 13/15] net: stmmac: dwmac-loongson: Add Loongson Multi-channels GMAC support
>
> On Wed, May 29, 2024 at 06:21:09PM +0800, Yanteng Si wrote:
>> 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.
> Please convert the commit log of this patch to containing the
> multi-channels feature description only. Like this (correct me if I am
> wrong in understanding some of the Loongson network controllers
> aspects):
>
> "The Loongson DWMAC driver currently supports the Loongson GMAC
> devices (based on the DW GMAC v3.50a/v3.73a IP-core) installed to the
> LS2K1000 SoC and LS7A1000 chipset. But recently a new generation
> LS2K2000 SoC was released with the new version of the Loongson GMAC
> synthesized in. The new controller is based on the DW GMAC v3.73a
> IP-core with the AV-feature enabled, which implies the multi
> DMA-channels support. The multi DMA-channels feature has the next
> vendor-specific 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 register
> field. It's 0x10 while it should have been 0x37 in accordance with
> the actual DW GMAC IP-core version.
> 3. There are eight DMA-channels available meanwhile the Synopsys DW
> GMAC IP-core supports up to three DMA-channels.
> 4. It's possible to have each DMA-channel IRQ independently delivered.
> The MSI IRQs must be utilized for that.
>
> Thus in order to have the multi-channels Loongson GMAC controllers
> supported let's modify the Loongson DWMAC driver in accordance with
> all the peculiarities described above:
>
> 1. Create the multi-channels Loongson GMAC-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 DWMAC-specific platform setup() method
> which gets to initialize the DMA-ops with the dwmac1000_dma_ops
> instance and overrides the callbacks described in 1. The method also
> 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 platform setup() method enables the flow control and
> duplex modes supported by the controller.
> "
>
> Once again, please correct the text if I was wrong in understanding
> the way your devices work. Especially regarding the flow-control and
> half-duplex mode.
>
> ---
>
> The Loongson GNET-specific changes should be moved to the new patch
> applied after this one. The subject of the new patch should be the same
> as the former subject of this patch:
> [PATCH net-next v14 14/15] net: stmmac: dwmac-loongson: Add Loongson GNET support
> but of course the commit log shall be different. Like this:
>
> "The new generation Loongson LS2K2000 SoC and LS7A2000 chipset are
> equipped with the network controllers called Loongson GNET. It's the
> single and multi DMA-channels Loongson GMAC but with a PHY attached.
> Here is the summary of the DW GMAC features the controller has:
>
>     DW GMAC IP-core: v3.73a
>     Speeds: 10/100/1000Mbps
>     Duplex: Full (both versions), Half (LS2K2000 GNET 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 GNET only)
>     DMA channels: 8 (LS2K2000 GNET), 1 (LS7A2000 GNET)
>
> Let's update the Loongson DWMAC driver to supporting the new Loongson
> GNET controller. The change is mainly trivial: the driver shall be
> bound to the PCIe device with DID 0x7a13, and the device-specific
> setup() method shall be called for it. The only peculiarity concerns
> the integrated PHY speed change procedure. The PHY has a weird problem
> with switching from the low speeds to 1000Mbps mode. The speedup
> procedure requires the PHY-link re-negotiation. So the suggested
> change provide the device-specific fix_mac_speed() method to overcome
> the problem."
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>
>> ---
>>   drivers/net/ethernet/stmicro/stmmac/common.h  |   1 +
>>   .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 390 +++++++++++++++++-
>>   2 files changed, 387 insertions(+), 4 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 45dcc35b7955..559215e3fe41 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> @@ -8,8 +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
> Please move this to the new patch adding the Loongson GNET support.
OK
>
>> +#define DWMAC_CORE_LS2K2000		0x10	/* Loongson custom IP */
> Note it's perfectly fine to have a device named after the SoC it's
> equipped to. For example see the compatible strings defined for the
> vendor-specific versions of the DW *MAC IP-cores:
> Documentation/devicetree/bindings/net/snps,dwmac.yaml
>
> But if you aren't comfortable with such naming we can change the
> macro to something like:
> #define DWMAC_CORE_LOONGSON_MULTI_CH	0x10
Hmmm, It's all okay. What about huacai's comment?
>
>> +#define CHANNEL_NUM			8
>> +
>> +struct loongson_data {
>> +	u32 loongson_id;
>> +	struct device *dev;
> Please add the "dev" field in the new patch adding the Loongson GNET support.
OK.
>
>> +};
>>   
>>   struct stmmac_pci_info {
>>   	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
>> @@ -67,6 +130,298 @@ static struct stmmac_pci_info loongson_gmac_pci_info = {
>>   	.setup = loongson_gmac_data,
>>   };
>>   
>> +static void loongson_gnet_dma_init_channel(struct stmmac_priv *priv,
> Since the multi-channel feature is no longer GNET-specific, please
> rename the method prefix to loongson_dwmac_ .
OK.
>
>> +					   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,
> Similarly the loongson_dwmac_ prefix seems more appropriate now.
OK.
>
>> +				       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[19-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 integrated PHY has a weird problem with switching from the low
>> +	 * speeds to 1000Mbps mode. The speedup procedure requires the PHY-link
>> +	 * re-negotiation.
>> +	 */
>> +	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;
>> +
>> +	/* 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;
>> +}
>> +
>> +static struct stmmac_pci_info loongson_gnet_pci_info = {
>> +	.setup = loongson_gnet_data,
>> +};
> Please move this to the new patch adding the Loongson GNET support.
OK.
>
>> +
>> +static int loongson_dwmac_intx_config(struct pci_dev *pdev,
>> +				      struct plat_stmmacenet_data *plat,
>> +				      struct stmmac_resources *res)
>> +{
>> +	res->irq = pdev->irq;
>> +
>> +	return 0;
>> +}
> If you get to implement what suggested here
> https://lore.kernel.org/netdev/glm3jfqf36t5vnkmk4gsdqfx53ga7ohs3pxnsizqlogkbim7gg@a3dxav5siczn/
> than the loongson_dwmac_intx_config() won't be needed.

Yeah! and loongson_dwmac_acpi_config() also won't be needed.

Because loongson_dwmac_msi_config() will do everything. I already reply 
in patch 6.


>
>> +
>> +static int loongson_dwmac_msi_config(struct pci_dev *pdev,
>> +				     struct plat_stmmacenet_data *plat,
>> +				     struct stmmac_resources *res)
>> +{
>> +	int i, ret, vecs;
>> +
>> +	vecs = roundup_pow_of_two(CHANNEL_NUM * 2 + 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[CHANNEL_NUM - 1 - i] =
>> +				pci_irq_vector(pdev, 1 + i * 2);
>> +		}
>> +		for (i = 0; i < plat->tx_queues_to_use; i++) {
>> +			res->tx_irq[CHANNEL_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;
>> +}
> Could you please clarify whether the multi-channel feature will work
> if the pci_alloc_irq_vectors() method failed to allocated as many MSI
> vectors as there are channels?

What I can confirm is that the multi-channel device can work in a single

channel, and as for the intermediate state, I still need to do experiments.

>
>> +
>> +static int loongson_dwmac_msi_clear(struct pci_dev *pdev)
>> +{
>> +	pci_free_irq_vectors(pdev);
>> +
>> +	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 v3.73a 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.
>> +	 */
> The comment needs to be altered since the multi-channel feature is no
> longer GNET-specific. Like this:
>
> 	/* The Loongson GMAC and GNET devices are based on the DW GMAC
> 	 * v3.50a and v3.73a IP-cores. But the HW designers have changed the
> 	 * GMAC_VERSION.SNPSVER field to the custom 0x10 value on the
> 	 * network controllers with the multi-channels feature
> 	 * available 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.
> 	 */
OK.
>> +	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
>> +		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;
>> +	}
>> +
>> +	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);
>> +
>> +	/* 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->loongson_id == DWMAC_CORE_LS2K2000)
>> +			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;
>> +	}
> AFAIU The only part that is applicable for the multi-channels case of
> the Loongson GMAC is:
> +	/* Loongson GMAC doesn't support the flow control */
> +	mac->link.caps = MAC_10 | MAC_100 | MAC_1000;
>
> If so the rest of the changes in this chunk should be moved to the new
> patch adding the Loongson GNET support.
OK.
>
>> +
>> +	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_dt_config(struct pci_dev *pdev,
>>   				    struct plat_stmmacenet_data *plat,
>>   				    struct stmmac_resources *res)
>> @@ -119,6 +474,7 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   	struct plat_stmmacenet_data *plat;
>>   	struct stmmac_pci_info *info;
>>   	struct stmmac_resources res;
>> +	struct loongson_data *ld;
>>   	int ret, i;
>>   
>>   	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
>> @@ -135,6 +491,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   	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);
>>   	if (ret) {
>> @@ -159,19 +519,39 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   
>>   	pci_set_master(pdev);
>>   
>> +	plat->bsp_priv = ld;
>> +	plat->setup = loongson_dwmac_setup;
>> +	ld->dev = &pdev->dev;
>> +
> Please make sure the chunk above and
> +	ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
> are performed before the stmmac_pci_info::setup() is called so the
> callback could use the private platform data with the loongson_id
> field initialized.
OK. I've used your method on patch 6 and it works.
>
>>   	if (dev_of_node(&pdev->dev)) {
>>   		ret = loongson_dwmac_dt_config(pdev, plat, &res);
>>   		if (ret)
>>   			goto err_disable_device;
>> -	} else {
>> -		res.irq = pdev->irq;
>>   	}
>>   
>>   	memset(&res, 0, sizeof(res));
> I've just realised the memset() call will clear out everything
> initialized in "res" by the loongson_dwmac_dt_config() method.

As your comments in patch 6:

     memset(&res, 0, sizeof(res));
     res.addr = pcim_iomap_table(pdev)[0];

     plat->bsp_priv = ld;
     plat->setup = loongson_dwmac_setup;
     ld->dev = &pdev->dev;
     ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;

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

     if (dev_of_node(&pdev->dev)) {
         ret = loongson_dwmac_dt_config(pdev, plat, &res);
         if (ret)
             goto err_disable_device;
     }

...

>
>>   	res.addr = pcim_iomap_table(pdev)[0];
>> +	ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
>> +
>
>> +	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
>> +		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;
> Please move this part to the loongson_gmac_data() method (and to the
> loongson_gnet_data() in the new patch). The only
> code which would be left here is:
> 	if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
> 		ret = loongson_dwmac_msi_config(pdev, plat, &res);
> 		if (ret)
> 			goto err_disable_device;
> 	}
OK. We don't need if else. I've explained this in patch 6.
>
>> +		ret = loongson_dwmac_msi_config(pdev, plat, &res);
>> +	} else {
>> +		plat->tx_queues_to_use = 1;
>> +		plat->rx_queues_to_use = 1;
>> +
>> +		ret = loongson_dwmac_intx_config(pdev, plat, &res);
>> +	}
>> +	if (ret)
>> +		goto err_disable_device;
> This won't be needed if you get to implement what is suggested here
> https://lore.kernel.org/netdev/glm3jfqf36t5vnkmk4gsdqfx53ga7ohs3pxnsizqlogkbim7gg@a3dxav5siczn/
I will drop it
>
>>   
>>   	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>>   	if (ret)
> I don't see the MSI-configs being undone in case of the
> stmmac_dvr_probe() failure. What should have been done:
>
> 	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
> 	if (ret)
> 		goto err_clear_msi;
>
> 	return 0;
>
> err_clear_msi:
> 	if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH)
> 		loongson_dwmac_msi_clear(pdev);
>
> err_disable_device:
> 	pci_disable_device(pdev);
>
> 	...
OK!
>
>> @@ -202,6 +582,7 @@ static void loongson_dwmac_remove(struct pci_dev *pdev)
>>   		break;
>>   	}
>>   
>> +	loongson_dwmac_msi_clear(pdev);
> Shouldn't this be done for the multi-channels device only? Like this
> 	if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH)
> 		loongson_dwmac_msi_clear(pdev);
Yeah!
>
>>   	pci_disable_device(pdev);
>>   }
>>   
>> @@ -245,6 +626,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) },
> Please move this to the new patch adding the Loongson GNET support.
OK.
>
>
>
> Sigh... The comments are brutal but if no more unexpected details get
> to be revealed the respective alterations shall bring us to the
> coherent set of changes. And hopefully there won't be need in such
> comprehensive patchset refactoring anymore.(

Sigh...


Thanks for you review!


Thanks,

Yanteng

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

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Serge Semin]

On Wed, Jul 03, 2024 at 05:41:55PM +0800, Yanteng Si wrote:
> > > > > -	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];
> > > > > @@ -140,6 +142,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;
> > > > > +
> > > > Please move this to the loongson_gmac_data(). Thus all the
> > > > platform-data initializations would be collected in two coherent
> > > > methods: loongson_default_data() and loongson_gmac_data(). It will be
> > > > positive from the readability and maintainability points of view.
> > > OK, I will move this to the  loongson_default_data(),
> > > 
> > > Because loongson_gmac/gnet_data() call it.
> > It shall also work. But the fields will be overwritten in the
> > loongson_gmac_data()/loongson_gnet_data() methods for the
> > multi-channels case. I don't have a strong opinion against that. But
> > some maintainers may have.
> I see. I will move this to the loongson_gmac_data()/loongson_gnet_data().
> > 
> > > 
> > > > In the patch adding the Loongson multi-channel GMAC support make sure
> > > > the loongson_data::loongson_id field is initialized before the
> > > > stmmac_pci_info::setup() method is called.
> > > I've tried. It's almost impossible.
> > Emm, why is it impossible? I don't see any significant problem with
> > implementing that.
> Sorry, I've to take back my words.
> > 
> > > 
> > > The only way to do this is to initialize loongson_id again in
> > > loongson_default_data().
> > > 
> > > But that will add a lot of code.
> > Not sure, why? What about the next probe() code snippet:
> Full marks!
> > 
> > 	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
> > 	if (!plat)
> > 		return -ENOMEM;
> > 
> > 	plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
> > 					   sizeof(*plat->mdio_bus_data),
> > 					   GFP_KERNEL);
> >          if (!plat->mdio_bus_data)
> >                  return -ENOMEM;
> > 
> > 	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
> > 	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);
> >   	if (ret)
> > 		return ret;
> > 
> > 	// AFAIR the bus-mastering isn't required for the normal PCIe
> > 	// IOs. So pci_set_master() can be called some place
> > 	// afterwards.
> > 	pci_set_master(pdev);
> > 
> > 	for (i = 0; i < PCI_STD_NUM_BARS; i++) {
> > 		if (pci_resource_len(pdev, i) == 0)
> > 			continue;
> > 		ret = pcim_iomap_regions(pdev, BIT(0), pci_name(pdev));
> > 		if (ret)
> > 			goto err_disable_device;
> > 		break;
> > 	}
> > 
> > 	memset(&res, 0, sizeof(res));
> > 	res.addr = pcim_iomap_table(pdev)[0];
> > 
> > 	plat->bsp_priv = ld;
> > 	plat->setup = loongson_dwmac_setup;
> > 	ld->dev = &pdev->dev;
> > 	ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
> > 
> > 	info = (struct stmmac_pci_info *)id->driver_data;
> > 	ret = info->setup(plat);
> > 	if (ret)
> > 		goto err_disable_device;
> > 
> > 	if (dev_of_node(&pdev->dev))
> >   		ret = loongson_dwmac_dt_config(pdev, plat, &res);
> > 	else
> 

> > 		ret = loongson_dwmac_acpi_config(pdev, plat, &res);
> 
> I don't know how to write this function, it seems that there
> 
> is no obvious acpi code in the probe method.

I've provided the method code here:
https://lore.kernel.org/netdev/glm3jfqf36t5vnkmk4gsdqfx53ga7ohs3pxnsizqlogkbim7gg@a3dxav5siczn/

It just gets the IRQ from the pci_device::irq field:

static int loongson_dwmac_acpi_config(struct pci_dev *pdev,
				      struct plat_stmmacenet_data *plat,
				      struct stmmac_resources *res)
{
	if (!pdev->irq)
		return -EINVAL;

	res->irq = pdev->irq;

	return 0;
}

It implies that if there is no DT found on the platform or no DT-node
assigned to the device, the IRQ line was supposed to be detected via
the ACPI interface by the PCIe subsystem core. Just recently you said
that the Loongson platforms are either UEFI or U-boot based. So at
least the loongson_dwmac_acpi_config() method would imply that the IRQ
number was supposed to be retrieved by means of the ACPI interface.

> 
> > 
> > 	if (ret)
> > 		goto err_disable_device;
> > 
> > 	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
> > 		ret = loongson_dwmac_msi_config(pdev, plat, &res);
> > 		if (ret)
> > 			goto err_disable_device;
> > 	}
> 

> It seems that we don't need if else.
> 
> If failed to allocate msi,  it will fallback to intx.
> 
> so loongson_dwmac_msi_config also needs a new name. How about:
> 
> ...
> 
>     ret = loongson_dwmac_irq_config(pdev, plat, &res);
>     if (ret)
>         goto err_disable_device;

Well, I've been thinking about that for quite some time. The problem
with your approach is that you _always_ override the res->irq field
with data retrieved from pci_irq_vector(pdev, 0). What's the point in
the res->irq initialization in the loongson_dwmac_dt_config() method
then?

Originally I suggested to use the PCI_IRQ_INTX flag in the
loongson_dwmac_msi_config() method because implied that eventually we
could come up to some generic IRQs initialization method with no
IRQ-related code performed in the rest of the driver. But after some
brainstorming I gave up that topic for now. Sending comments connected
with that would mean to cause a one more discussion. Seeing we already
at v13 it would have extended the review process for even longer than
it has already got to.

So since the MSI IRQs are required for the multi-channels device it
would be better to allocate MSIs for that case only. Thus I'd preserve
the conditional loongson_dwmac_msi_config() execution and would drop
the PCI_IRQ_INTX flag seeing we aren't going to implement the generic
IRQ setup method anymore. Like this:

+static int loongson_dwmac_msi_config(struct pci_dev *pdev,
+				     struct plat_stmmacenet_data *plat,
+				     struct stmmac_resources *res)
+{
+	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_err(&pdev->dev, "Failed to allocate per-channels IRQs\n");
+		return ret;
+	}
+
+	res->irq = pci_irq_vector(pdev, 0);
+
+	for (i = 0; i < plat->rx_queues_to_use; i++) {
+		res->rx_irq[CHANNEL_NUM - 1 - i] =
+			pci_irq_vector(pdev, 1 + i * 2);
+	}
+	for (i = 0; i < plat->tx_queues_to_use; i++) {
+		res->tx_irq[CHANNEL_NUM - 1 - i] =
+			pci_irq_vector(pdev, 2 + i * 2);
+	}
+
+	plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
+
+	return 0;
+}

* Please note the pci_alloc_irq_vectors(..., vecs, vecs, PCI_IRQ_MSI) arguments.

Seeing the discussion has started anyway, could you please find out
whether the multi-channel controller will still work if the MSI IRQs
allocation failed? Will the multi-channel-ness still work in that
case?

If the IRQ events from _all_ DMA-channels would still be delivered via
the main MAC IRQ (AFAICS from the DW GMAC v3.73a HW databook it works
like that by default), then we could ignore the errors returned from
the loongson_dwmac_msi_config() method, and simplify the probe()
method like this:

	/* Fallback to the common MAC IRQ if MSIs allocation failed */
	if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH)
		loongson_dwmac_msi_config(pdev, plat, &res);

-Serge(y)

> 
>     ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
> 
> ...
> 
> 
> 
> > 
> > 	ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
> >   	if (ret)
> > 		goto err_clear_msi;
> > 
> > 	return 0;
> > 
> > 	...
> > 
> > The code allocates all the data, then enables the PCIe device
> > and maps the PCIe device resources. After that it calls all the setup
> > and config methods. Do I miss something?
> 
> You are right!
> 
> 
> 
> Thanks,
> 
> Yanteng
> 
> > 
> > -Serge(y)
> > 
> > > > > 2.31.4
> > > > > 
> 

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

[Serge Semin]

On Tue, Jul 02, 2024 at 04:08:05PM +0100, Russell King (Oracle) wrote:
> On Tue, Jul 02, 2024 at 01:31:44PM +0300, Serge Semin wrote:
> > On Tue, Jun 04, 2024 at 11:29:43AM +0000, si.yanteng@linux.dev wrote:
> > > 2024年5月30日 15:22, "Russell King (Oracle)" <linux@armlinux.org.uk> 写到:
> > > 
> > > Hi, Russell, Serge,
> > > 
> > > > I would like this patch to be held off until more thought can be put
> > > > 
> > > > into how to handle this without having a hack in the driver (stmmac
> > > > 
> > > > has too many hacks and we're going to have to start saying no to
> > > > 
> > > > these.)
> > > Yeah, you have a point there, but I would also like to hear Serge's opinion.
> > 
> > I would be really glad not to have so many hacks in the STMMAC driver.
> > It would have been awesome if we are able to find a solution without
> > introducing one more quirk in the common driver code.
> > 
> > I started digging into this sometime ago, but failed to come up with
> > any decent hypothesis about the problem nature. One of the glimpse
> > idea was that the loongson_gnet_fix_speed() method code might be somehow
> > connected with the problem. But I didn't have much time to go further
> > than that.
> > 
> > Anyway I guess we'll need to have at least two more patchset
> > re-spins to settle all the found issues. Until then we can keep
> > discussing the problem Yanteng experience on his device. Russell, do
> > you have any suggestion of what info Yanteng should provide to better
> > understand the problem and get closer to it' cause?
> 
> First question: is auto-negotiation required by 802.3 for 1000base-T?
> By "required" I mean "required to be used" not "required to be
> implemented". This is an important distinction, and 802.3 tends to be
> a bit wooly about the exact meaning. However, I think on balance the
> conclusion is that AN is mandatory _to be used_ for 1000base-T links.

One another statement in IEEE 802.3 C40 that implies the AN being
mandatory is that 1000BASE-T PHYs determine their MASTER or SLAVE part
during the Auto-Negotiation process. The part determines the clock
source utilized by the PHYs: "The MASTER PHY uses a local clock to
determine the timing of transmitter operations. The SLAVE PHY recovers
the clock from the received signal and uses it to determine the timing
of transmitter operations, i.e.," (40.1.3 Operation of 1000BASE-T)

So I guess that without Auto-negotiation the link just won't be
established due to the clocks missconfiguration.

> 
> Annex 40C's state diagrams seems to imply that mr_autoneg_enable
> (BMCR AN ENABLE) doesn't affect whether or not the AN state machines
> work for 1000base-T, and some PHY datasheets (e.g. Marvell Alaska)
> state that disabling mr_autoneg_enable leaves AN enabled but forced
> to 1G full duplex.
> 
> So, I'm thinking is that the ethtool interface should reject any
> request where we have a PHY supporting *only* base-T for gigabit
> speeds, where the user is requesting !AN && SPEED_1000 on the basis
> that AN is part of the link setup of 1000base-T links.
> 
> Maybe this should be a property of the struct phy_device so we can
> transition phylib and phylink to return an appropriate error to
> userspace?
> 

> Alternatively, maybe just implement the Marvell Alaska solution
> to this problem (if the user attempts to disable AN on a PHY
> supporting only base-T at gigabit speeds, then we silently force
> AN with SPEED_1000 and DUPLEX_FULL.

I am not that much knowledgable about the PHY-lib and PHY-link
internals, but if we get to establish that the standard indeed
implies the AN being mandatory, then this sounds like the least
harmful solution from the user-space point of view.

-SergeY

> 
> Andrew - seems to be an IEEE 802.3 requirement that's been missed
> in phylib, any thoughts?
> 
> -- 
> 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 v13 12/15] net: stmmac: Fixed failure to set network speed to 1000.

[Russell King (Oracle)]

On Wed, Jul 03, 2024 at 07:56:31PM +0300, Serge Semin wrote:
> One another statement in IEEE 802.3 C40 that implies the AN being
> mandatory is that 1000BASE-T PHYs determine their MASTER or SLAVE part
> during the Auto-Negotiation process. The part determines the clock
> source utilized by the PHYs: "The MASTER PHY uses a local clock to
> determine the timing of transmitter operations. The SLAVE PHY recovers
> the clock from the received signal and uses it to determine the timing
> of transmitter operations, i.e.," (40.1.3 Operation of 1000BASE-T)
> 
> So I guess that without Auto-negotiation the link just won't be
> established due to the clocks missconfiguration.

Oh damn, I did a reply, then cocked up sending it (lost it instead!)
So, this is going to be a brief response now.

It seems AN is basically required for 1000base-T.

> > Alternatively, maybe just implement the Marvell Alaska solution
> > to this problem (if the user attempts to disable AN on a PHY
> > supporting only base-T at gigabit speeds, then we silently force
> > AN with SPEED_1000 and DUPLEX_FULL.
> 
> I am not that much knowledgable about the PHY-lib and PHY-link
> internals, but if we get to establish that the standard indeed
> implies the AN being mandatory, then this sounds like the least
> harmful solution from the user-space point of view.

The Atheros PHYs are another PHY where we should not be disabling
AN when wishing to use 1000base-T (so says the datasheet - I did
quote it in my original reply but lost that...)

As has already been mentioned, Marvell Alaska takes an interesting
approach - when BMCR AN enable is cleared but speed is forced to
1000, it internally keeps AN enabled and advertises the appropriate
1G speed + duplex capability bit depending on the BMCR duplex bit.

Rather than erroring out, I think it may be better to just adopt
the Marvell solution to this problem to give consistent behaviour
across all PHYs.

-- 
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 v13 12/15] net: stmmac: Fixed failure to set network speed to 1000.

[Andrew Lunn]

> Rather than erroring out, I think it may be better to just adopt
> the Marvell solution to this problem to give consistent behaviour
> across all PHYs.

Yes, expand phy_config_aneg() to look for this condition and enable
autoneg. But should we disable it when the condition is reverted? The
user swaps to 100Mbps forced?

What about other speeds? Is this limited to 1G? Since we have devices
without auto-neg for 2500BaseX i assume it is not an issue there.

	Andrew

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

[Russell King (Oracle)]

On Wed, Jul 03, 2024 at 09:09:53PM +0200, Andrew Lunn wrote:
> > Rather than erroring out, I think it may be better to just adopt
> > the Marvell solution to this problem to give consistent behaviour
> > across all PHYs.
> 
> Yes, expand phy_config_aneg() to look for this condition and enable
> autoneg. But should we disable it when the condition is reverted? The
> user swaps to 100Mbps forced?

I think we should "lie" to userspace rather than report how the
hardware was actually programmed - again, because that's what would
happen with Marvell Alaska.

> What about other speeds? Is this limited to 1G? Since we have devices
> without auto-neg for 2500BaseX i assume it is not an issue there.

1000base-X can have AN disabled - that's not an issue. Yes, there's
the ongoing issues with 2500base-X. 10Gbase-T wording is similar to
1000base-T, so we probably need to do similar there. Likely also the
case for 2500base-T and 5000base-T as well.

So I'm thinking of something like this (untested):

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 6c6ec9475709..197c4d5ab55b 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2094,22 +2094,20 @@ EXPORT_SYMBOL(phy_reset_after_clk_enable);
 /**
  * genphy_config_advert - sanitize and advertise auto-negotiation parameters
  * @phydev: target phy_device struct
+ * @advert: auto-negotiation parameters to advertise
  *
  * Description: Writes MII_ADVERTISE with the appropriate values,
  *   after sanitizing the values to make sure we only advertise
  *   what is supported.  Returns < 0 on error, 0 if the PHY's advertisement
  *   hasn't changed, and > 0 if it has changed.
  */
-static int genphy_config_advert(struct phy_device *phydev)
+static int genphy_config_advert(struct phy_device *phydev,
+				const unsigned long *advert)
 {
 	int err, bmsr, changed = 0;
 	u32 adv;
 
-	/* Only allow advertising what this PHY supports */
-	linkmode_and(phydev->advertising, phydev->advertising,
-		     phydev->supported);
-
-	adv = linkmode_adv_to_mii_adv_t(phydev->advertising);
+	adv = linkmode_adv_to_mii_adv_t(advert);
 
 	/* Setup standard advertisement */
 	err = phy_modify_changed(phydev, MII_ADVERTISE,
@@ -2132,7 +2130,7 @@ static int genphy_config_advert(struct phy_device *phydev)
 	if (!(bmsr & BMSR_ESTATEN))
 		return changed;
 
-	adv = linkmode_adv_to_mii_ctrl1000_t(phydev->advertising);
+	adv = linkmode_adv_to_mii_ctrl1000_t(advert);
 
 	err = phy_modify_changed(phydev, MII_CTRL1000,
 				 ADVERTISE_1000FULL | ADVERTISE_1000HALF,
@@ -2356,6 +2354,9 @@ EXPORT_SYMBOL(genphy_check_and_restart_aneg);
  */
 int __genphy_config_aneg(struct phy_device *phydev, bool changed)
 {
+	__ETHTOOL_DECLARE_LINK_MODE_MASK(fixed_advert);
+	const struct phy_setting *set;
+	unsigned long *advert;
 	int err;
 
 	err = genphy_c45_an_config_eee_aneg(phydev);
@@ -2370,10 +2371,25 @@ int __genphy_config_aneg(struct phy_device *phydev, bool changed)
 	else if (err)
 		changed = true;
 
-	if (AUTONEG_ENABLE != phydev->autoneg)
+	if (phydev->autoneg == AUTONEG_ENABLE) {
+		/* Only allow advertising what this PHY supports */
+		linkmode_and(phydev->advertising, phydev->advertising,
+			     phydev->supported);
+		advert = phydev->advertising;
+	} else if (phydev->speed < SPEED_1000) {
 		return genphy_setup_forced(phydev);
+	} else {
+		linkmode_zero(fixed_advert);
+
+		set = phy_lookup_setting(phydev->speed, phydev->duplex,
+					 phydev->supported, true);
+		if (set)
+			linkmode_set(set->bit, fixed_advert);
+
+		advert = fixed_advert;
+	}
 
-	err = genphy_config_advert(phydev);
+	err = genphy_config_advert(phydev, advert);
 	if (err < 0) /* error */
 		return err;
 	else if (err)

-- 
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 v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Yanteng Si]

在 2024/7/4 00:19, Serge Semin 写道:
> On Wed, Jul 03, 2024 at 05:41:55PM +0800, Yanteng Si wrote:
>>>>>> -	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];
>>>>>> @@ -140,6 +142,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;
>>>>>> +
>>>>> Please move this to the loongson_gmac_data(). Thus all the
>>>>> platform-data initializations would be collected in two coherent
>>>>> methods: loongson_default_data() and loongson_gmac_data(). It will be
>>>>> positive from the readability and maintainability points of view.
>>>> OK, I will move this to the  loongson_default_data(),
>>>>
>>>> Because loongson_gmac/gnet_data() call it.
>>> It shall also work. But the fields will be overwritten in the
>>> loongson_gmac_data()/loongson_gnet_data() methods for the
>>> multi-channels case. I don't have a strong opinion against that. But
>>> some maintainers may have.
>> I see. I will move this to the loongson_gmac_data()/loongson_gnet_data().
>>>>> In the patch adding the Loongson multi-channel GMAC support make sure
>>>>> the loongson_data::loongson_id field is initialized before the
>>>>> stmmac_pci_info::setup() method is called.
>>>> I've tried. It's almost impossible.
>>> Emm, why is it impossible? I don't see any significant problem with
>>> implementing that.
>> Sorry, I've to take back my words.
>>>> The only way to do this is to initialize loongson_id again in
>>>> loongson_default_data().
>>>>
>>>> But that will add a lot of code.
>>> Not sure, why? What about the next probe() code snippet:
>> Full marks!
>>> 	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
>>> 	if (!plat)
>>> 		return -ENOMEM;
>>>
>>> 	plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
>>> 					   sizeof(*plat->mdio_bus_data),
>>> 					   GFP_KERNEL);
>>>           if (!plat->mdio_bus_data)
>>>                   return -ENOMEM;
>>>
>>> 	plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
>>> 	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);
>>>    	if (ret)
>>> 		return ret;
>>>
>>> 	// AFAIR the bus-mastering isn't required for the normal PCIe
>>> 	// IOs. So pci_set_master() can be called some place
>>> 	// afterwards.
>>> 	pci_set_master(pdev);
>>>
>>> 	for (i = 0; i < PCI_STD_NUM_BARS; i++) {
>>> 		if (pci_resource_len(pdev, i) == 0)
>>> 			continue;
>>> 		ret = pcim_iomap_regions(pdev, BIT(0), pci_name(pdev));
>>> 		if (ret)
>>> 			goto err_disable_device;
>>> 		break;
>>> 	}
>>>
>>> 	memset(&res, 0, sizeof(res));
>>> 	res.addr = pcim_iomap_table(pdev)[0];
>>>
>>> 	plat->bsp_priv = ld;
>>> 	plat->setup = loongson_dwmac_setup;
>>> 	ld->dev = &pdev->dev;
>>> 	ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff;
>>>
>>> 	info = (struct stmmac_pci_info *)id->driver_data;
>>> 	ret = info->setup(plat);
>>> 	if (ret)
>>> 		goto err_disable_device;
>>>
>>> 	if (dev_of_node(&pdev->dev))
>>>    		ret = loongson_dwmac_dt_config(pdev, plat, &res);
>>> 	else
>>> 		ret = loongson_dwmac_acpi_config(pdev, plat, &res);
>> I don't know how to write this function, it seems that there
>>
>> is no obvious acpi code in the probe method.
> I've provided the method code here:
> https://lore.kernel.org/netdev/glm3jfqf36t5vnkmk4gsdqfx53ga7ohs3pxnsizqlogkbim7gg@a3dxav5siczn/
>
> It just gets the IRQ from the pci_device::irq field:
>
> static int loongson_dwmac_acpi_config(struct pci_dev *pdev,
> 				      struct plat_stmmacenet_data *plat,
> 				      struct stmmac_resources *res)
> {
> 	if (!pdev->irq)
> 		return -EINVAL;
>
> 	res->irq = pdev->irq;
>
> 	return 0;
> }
>
> It implies that if there is no DT found on the platform or no DT-node
> assigned to the device, the IRQ line was supposed to be detected via
> the ACPI interface by the PCIe subsystem core. Just recently you said
> that the Loongson platforms are either UEFI or U-boot based. So at
> least the loongson_dwmac_acpi_config() method would imply that the IRQ
> number was supposed to be retrieved by means of the ACPI interface.
Oh, I see!
>
>>> 	if (ret)
>>> 		goto err_disable_device;
>>>
>>> 	if (ld->loongson_id == DWMAC_CORE_LS2K2000) {
>>> 		ret = loongson_dwmac_msi_config(pdev, plat, &res);
>>> 		if (ret)
>>> 			goto err_disable_device;
>>> 	}
>> It seems that we don't need if else.
>>
>> If failed to allocate msi,  it will fallback to intx.
>>
>> so loongson_dwmac_msi_config also needs a new name. How about:
>>
>> ...
>>
>>      ret = loongson_dwmac_irq_config(pdev, plat, &res);
>>      if (ret)
>>          goto err_disable_device;
> Well, I've been thinking about that for quite some time. The problem
> with your approach is that you _always_ override the res->irq field
> with data retrieved from pci_irq_vector(pdev, 0). What's the point in
> the res->irq initialization in the loongson_dwmac_dt_config() method
> then?
>
> Originally I suggested to use the PCI_IRQ_INTX flag in the
> loongson_dwmac_msi_config() method because implied that eventually we
> could come up to some generic IRQs initialization method with no
> IRQ-related code performed in the rest of the driver. But after some
> brainstorming I gave up that topic for now. Sending comments connected
> with that would mean to cause a one more discussion. Seeing we already
> at v13 it would have extended the review process for even longer than
> it has already got to.
>
> So since the MSI IRQs are required for the multi-channels device it
> would be better to allocate MSIs for that case only. Thus I'd preserve
> the conditional loongson_dwmac_msi_config() execution and would drop
> the PCI_IRQ_INTX flag seeing we aren't going to implement the generic
> IRQ setup method anymore. Like this:
>
> +static int loongson_dwmac_msi_config(struct pci_dev *pdev,
> +				     struct plat_stmmacenet_data *plat,
> +				     struct stmmac_resources *res)
> +{
> +	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_err(&pdev->dev, "Failed to allocate per-channels IRQs\n");
> +		return ret;
> +	}
> +
> +	res->irq = pci_irq_vector(pdev, 0);
> +
> +	for (i = 0; i < plat->rx_queues_to_use; i++) {
> +		res->rx_irq[CHANNEL_NUM - 1 - i] =
> +			pci_irq_vector(pdev, 1 + i * 2);
> +	}
> +	for (i = 0; i < plat->tx_queues_to_use; i++) {
> +		res->tx_irq[CHANNEL_NUM - 1 - i] =
> +			pci_irq_vector(pdev, 2 + i * 2);
> +	}
> +
> +	plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> +
> +	return 0;
> +}
>
> * Please note the pci_alloc_irq_vectors(..., vecs, vecs, PCI_IRQ_MSI) arguments.
OK. I got you!
>
> Seeing the discussion has started anyway, could you please find out
> whether the multi-channel controller will still work if the MSI IRQs
> allocation failed? Will the multi-channel-ness still work in that
> case?

Based on my test results:

In this case, multi-channel controller don't work. If the MSI IRQs 
allocation

failed, NIC will work in single channel.


I will prepare v14 according to your comments,


Over the past year, with everyone's help, the drive has become better 
and better.

Thank you everyone. Thank you very much!


Thanks,

Yanteng

Re: [PATCH net-next v13 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_dt_config

[Yanteng Si]

在 2024/7/2 17:46, Serge Semin 写道:
> On Wed, May 29, 2024 at 06:20:27PM +0800, Yanteng Si wrote:
>> While at it move the np initialization procedure into a dedicated
>> method. It will be useful in one of the subsequent commit adding the
>> Loongson GNET device support.
> As I just mentioned please merge in this patch content into the
> previous patch:
> [PATCH net-next v13 10/15] net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support
>
OK.


Thanks,

Yanteng

Re: [PATCH net-next v13 10/15] net: stmmac: dwmac-loongson: Add DT-less GMAC PCI-device support

[Yanteng Si]

在 2024/7/2 17:35, Serge Semin 写道:
> On Wed, May 29, 2024 at 06:20:26PM +0800, Yanteng Si wrote:
>> 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.
> We need to mention the ACPI-part here. 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.
> But Loongson machines may have UEFI (implies ACPI) or PMON/UBOOT
> (implies FDT) as the system bootloaders. In order to have both system
> configurations support 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."
>
> This shall well justify the change introduced in this patch and in the
> patch "net: stmmac: dwmac-loongson: Add loongson_dwmac_dt_config"
> which content I suggest to merge in into this one.
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  | 105 +++++++++---------
>>   1 file changed, 53 insertions(+), 52 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> index fec2aa0607d4..8bcf9d522781 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> @@ -12,11 +12,15 @@
>>   #define PCI_DEVICE_ID_LOONGSON_GMAC	0x7a03
>>   
>>   struct stmmac_pci_info {
>> -	int (*setup)(struct plat_stmmacenet_data *plat);
>> +	int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
>>   };
>>   
>> -static void loongson_default_data(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 overwritten later */
>> +	plat->bus_id = pci_dev_id(pdev);
>> +
>>   	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
>>   	plat->has_gmac = 1;
>>   	plat->force_sf_dma_mode = 1;
>> @@ -49,9 +53,10 @@ static void loongson_default_data(struct plat_stmmacenet_data *plat)
>>   	plat->dma_cfg->pblx8 = true;
>>   }
>>   
>> -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->phy_interface = PHY_INTERFACE_MODE_RGMII_ID;
>>   
>> @@ -68,15 +73,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   	struct stmmac_pci_info *info;
>>   	struct stmmac_resources res;
>>   	struct device_node *np;
>> -	int ret, i, phy_mode;
>> +	int ret, i;
>>   
>>   	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;
>> @@ -87,17 +87,9 @@ 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;
>> -		goto err_put_node;
>> -	}
>> +	if (!plat->dma_cfg)
>> +		return -ENOMEM;
>>   
>>   	/* Enable pci device */
>>   	ret = pci_enable_device(pdev);
>> @@ -117,49 +109,58 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
>>   	}
>>   
>>   	info = (struct stmmac_pci_info *)id->driver_data;
>> -	ret = info->setup(plat);
>> +	ret = info->setup(pdev, plat);
>>   	if (ret)
>>   		goto err_disable_device;
>>   
>> -	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;
>> -		goto err_disable_device;
>> -	}
>> +	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;
>> +		}
>>   
>> -	plat->phy_interface = phy_mode;
>> +		ret = of_alias_get_id(np, "ethernet");
>> +		if (ret >= 0)
>> +			plat->bus_id = ret;
>>   
>> -	pci_set_master(pdev);
>> +		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;
>> +
>> +		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;
>> +	}
> Please merge in the patch:
> [PATCH net-next v13 11/15] net: stmmac: dwmac-loongson: Add loongson_dwmac_dt_config
> content into this one and introduce the method:
>
> static int loongson_dwmac_acpi_config(struct pci_dev *pdev,
> 				      struct plat_stmmacenet_data *plat,
> 				      struct stmmac_resources *res)
> {
> 	if (!pdev->irq)
> 		return -EINVAL;
>
> 	res->irq = pdev->irq;
>
> 	return 0;
> }
>
> just below the loongson_dwmac_dt_config() function. Thus the only code
> left in the probe() method would be:
>
> 	if (dev_of_node(&pdev->dev))
> 		ret = loongson_dwmac_dt_config(pdev, plat, &res);
> 	else
> 		ret = loongson_dwmac_acpi_config(pdev, plat, &res);
>
> 	if (ret)
> 		goto err_disable_device;
>
> As a result this patch will look simpler and more coherent. So will
> the probe() method with no additional change required for that.

OK!


Thanks,

Yanteng

Re: [PATCH net-next v13 09/15] net: stmmac: dwmac-loongson: Introduce PCI device info data

[Yanteng Si]

在 2024/7/2 17:18, Serge Semin 写道:
> On Wed, May 29, 2024 at 06:19:48PM +0800, Yanteng Si wrote:
>> Just introduce PCI device info data to prepare for later
>> ACPI-base support. Loongson machines may use UEFI (implies
>> ACPI) or PMON/UBOOT (implies FDT) as the BIOS.
>>
>> The BIOS type has no relationship with device types, which
>> means: machines can be either ACPI-based or FDT-based.
> AFAICS the commit log is misleading because the DT-less (ACPI-based)
> setups is being added in the next commit and it's implemented by using
> the if-else statement with no setup() callback infrastructure
> utilized.
>
> But this change is still needed for adding the Loongson GNET support
> later in the series. The setup() callback will be pre-initialized with
> the network controller specific method based on the PCIe Device ID. So
> to speak, please alter the commit log with the correct justification.
> Like this:
>
> "The Loongson GNET device support is about to be added in one of the
> next commits. As another preparation for that introduce the PCI device
> info data with a setup() callback performing the device-specific
> platform data initializations. Currently it is utilized for the
> already supported Loongson GMAC device only."
>
Ok, Thanks!


Thanks,

Yanteng

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

[Yanteng Si]

在 2024/7/2 16:43, Serge Semin 写道:
> On Wed, May 29, 2024 at 06:19:47PM +0800, Yanteng Si wrote:
>> The phy_interface of gmac is PHY_INTERFACE_MODE_RGMII_ID.
> It's better to translate this to a normal sentence:
> "PHY-interface of the Loongson GMAC device is RGMII with no internal
> delays added to the data lines signal. So to comply with that let's
> pre-initialize the platform-data field with the respective enum
> constant."
>
OK. Thanks!


Thanks,

Yanteng

Re: [PATCH net-next v13 13/15] net: stmmac: dwmac-loongson: Drop pci_enable/disable_msi temporarily

[Yanteng Si]

在 2024/7/1 09:17, Serge Semin 写道:
>> [PATCH net-next v13 13/15] net: stmmac: dwmac-loongson: Drop pci_enable/disable_msi temporarily
> You don't drop the methods call "temporarily" but forever. So fix
> the subject like this please:
> [PATCH net-next v13 13/15] net: stmmac: dwmac-loongson: Drop pci_enable_msi/disable_msi methods call
>
> I understand that you meant that the MSI IRQs support will be
> added later in framework of another commit and for the multi-channel
> device case. But mentioning that in a way you did makes the commit log
> more confusing than better explaining the change.
>
> On Wed, May 29, 2024 at 06:21:08PM +0800, Yanteng Si wrote:
>> The LS2K2000 patch added later will alloc vectors, so let's
>> remove pci_enable/disable_msi temporarily to prepare for later
>> calls to pci_alloc_irq_vectors/pci_free_irq_vectors. This does
>> not affect the work of gmac devices, as they actually use intx.
> As I mentioned in v12 AFAICS the MSI IRQs haven't been utilized on the
> Loongseon GMAC devices so far since the IRQ numbers have been retrieved
> directly from device DT-node. That's what you should have mentioned in
> the log. Like this:
> "The Loongson GMAC driver currently doesn't utilize the MSI IRQs, but
> retrieves the IRQs specified in the device DT-node. Let's drop the
> direct pci_enable_msi()/pci_disable_msi() calls then as redundant."
>
> If what I said was correct and MSIs enable wasn't required for the
> platform IRQs to work, then please use the log and move this patch to
> being submitted between
> [PATCH net-next v13 04/15] net: stmmac: dwmac-loongson: Drop duplicated hash-based filter size init
> and
> [PATCH net-next v13 05/15] net: stmmac: dwmac-loongson: Use PCI_DEVICE_DATA() macro for device identification
>
> so the redundant pci_enable_msi()/pci_disable_msi() code wouldn't be
> getting on a way of the subsequent preparation changes.

Ok, Thanks!


Thanks,

Yanteng

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Serge Semin]

On Thu, Jul 04, 2024 at 04:56:41PM +0800, Yanteng Si wrote:
> 
> 在 2024/7/4 00:19, Serge Semin 写道:
> ...
> > ...
> > 
> > Seeing the discussion has started anyway, could you please find out
> > whether the multi-channel controller will still work if the MSI IRQs
> > allocation failed? Will the multi-channel-ness still work in that
> > case?
> 
> Based on my test results:
> 
> In this case, multi-channel controller don't work. If the MSI IRQs
> allocation
> 
> failed, NIC will work in single channel.

What does "NIC will work in single channel" mean? Do the driver
(network traffic flow with a normal performance) still work even with
the plat->tx_queues_to_use and plat->rx_queues_to_use fields set to
eight? If it's then the multi-channel-ness still seems to be working
but the IRQs are delivered via the common MAC IRQ. If you get to
experience the data loss, or poor performance, or no traffic flowing
at all, then indeed the non-zero channels IRQs aren't delivered.

So the main question how did you find out that the controller work in
single channel?

> 
> 
> I will prepare v14 according to your comments,

Ok. Thanks.

> 
> 
> Over the past year, with everyone's help, the drive has become better and
> better.
> 
> Thank you everyone. Thank you very much!

Always welcome. I am glad we are finally advancing the series further.

-Serge(y)

> 
> 
> Thanks,
> 
> Yanteng
> 
> 

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

[Serge Semin]

Hi Huacai

On Wed, Jul 03, 2024 at 09:19:59AM +0800, Huacai Chen wrote:
> On Tue, Jul 2, 2024 at 9:43 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> > ...
> > On Wed, May 29, 2024 at 06:21:09PM +0800, Yanteng Si wrote:
> > > ...
> > ...
> > > +#define DWMAC_CORE_LS2K2000          0x10    /* Loongson custom IP */
> >
> > Note it's perfectly fine to have a device named after the SoC it's
> > equipped to. For example see the compatible strings defined for the
> > vendor-specific versions of the DW *MAC IP-cores:
> > Documentation/devicetree/bindings/net/snps,dwmac.yaml
> >
> > But if you aren't comfortable with such naming we can change the
> > macro to something like:
> > #define DWMAC_CORE_LOONGSON_MULTI_CH    0x10
> Maybe DWMAC_CORE_LOONGSON_MULTICHAN or DWMAC_CORE_LOONGSON_MULTI_CHAN
> is a little better?
> 

Well, I don't have a strong opinion about that in this case.
Personally I prefer to have the shortest and still readable version.
It decreases the probability of the lines splitting in case of the
long-line statements or highly indented code. From that perspective
something like DWMAC_CORE_LS_MULTI_CH would be even better. But seeing
the driver currently don't have such cases, we can use any of those
name. But it's better to be of such length so the code lines the name
is utilized in wouldn't exceed +80 chars.

-Serge(y)

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Yanteng Si]

在 2024/7/5 18:16, Serge Semin 写道:
>>> Seeing the discussion has started anyway, could you please find out
>>> whether the multi-channel controller will still work if the MSI IRQs
>>> allocation failed? Will the multi-channel-ness still work in that
>>> case?
>> Based on my test results:
>>
>> In this case, multi-channel controller don't work. If the MSI IRQs
>> allocation
>>
>> failed, NIC will work in single channel.
> What does "NIC will work in single channel" mean? Do the driver
> (network traffic flow with a normal performance) still work even with
> the plat->tx_queues_to_use and plat->rx_queues_to_use fields set to
> eight? If it's then the multi-channel-ness still seems to be working
> but the IRQs are delivered via the common MAC IRQ. If you get to
> experience the data loss, or poor performance, or no traffic flowing
> at all, then indeed the non-zero channels IRQs aren't delivered.
>
> So the main question how did you find out that the controller work in
> single channel?

sorry, I meant that if the MSI allocation failed, it will fallback to 
INTx, in which case

only the single channel works.  if the MSI allocation failed, the 
multi-channel-ness

don't work.


Thanks,

Yanteng

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Serge Semin]

On Fri, Jul 05, 2024 at 06:45:50PM +0800, Yanteng Si wrote:
> 
> 在 2024/7/5 18:16, Serge Semin 写道:
> > > > Seeing the discussion has started anyway, could you please find out
> > > > whether the multi-channel controller will still work if the MSI IRQs
> > > > allocation failed? Will the multi-channel-ness still work in that
> > > > case?
> > > Based on my test results:
> > > 
> > > In this case, multi-channel controller don't work. If the MSI IRQs
> > > allocation
> > > 
> > > failed, NIC will work in single channel.
> > What does "NIC will work in single channel" mean? Do the driver
> > (network traffic flow with a normal performance) still work even with
> > the plat->tx_queues_to_use and plat->rx_queues_to_use fields set to
> > eight? If it's then the multi-channel-ness still seems to be working
> > but the IRQs are delivered via the common MAC IRQ. If you get to
> > experience the data loss, or poor performance, or no traffic flowing
> > at all, then indeed the non-zero channels IRQs aren't delivered.
> > 
> > So the main question how did you find out that the controller work in
> > single channel?
> 
> sorry, I meant that if the MSI allocation failed, it will fallback to INTx,
> in which case
> 
> only the single channel works.  if the MSI allocation failed, the
> multi-channel-ness
> 
> don't work.

Could you please clarify what are the symptoms by which you figured
out that the "multi-channel-ness" didn't work?

Suppose you have an LS2K2000 SoC-based device, the
plat->tx_queues_to_use and plat->rx_queues_to_use to eight and the
loongson_dwmac_msi_config() function call is omitted. What is
happening with the activated network interface and with the traffic
flow then?

-Serge(y)

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

[Yanteng Si]

Hi all,


Thanks for your comments!


在 2024/7/4 04:33, Russell King (Oracle) 写道:
> On Wed, Jul 03, 2024 at 09:09:53PM +0200, Andrew Lunn wrote:
>>> Rather than erroring out, I think it may be better to just adopt
>>> the Marvell solution to this problem to give consistent behaviour
>>> across all PHYs.
>> Yes, expand phy_config_aneg() to look for this condition and enable
>> autoneg. But should we disable it when the condition is reverted? The
>> user swaps to 100Mbps forced?
> I think we should "lie" to userspace rather than report how the
> hardware was actually programmed - again, because that's what would
> happen with Marvell Alaska.
>
>> What about other speeds? Is this limited to 1G? Since we have devices
>> without auto-neg for 2500BaseX i assume it is not an issue there.
> 1000base-X can have AN disabled - that's not an issue. Yes, there's
> the ongoing issues with 2500base-X. 10Gbase-T wording is similar to
> 1000base-T, so we probably need to do similar there. Likely also the
> case for 2500base-T and 5000base-T as well.
>
> So I'm thinking of something like this (untested):
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 6c6ec9475709..197c4d5ab55b 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -2094,22 +2094,20 @@ EXPORT_SYMBOL(phy_reset_after_clk_enable);
>   /**
>    * genphy_config_advert - sanitize and advertise auto-negotiation parameters
>    * @phydev: target phy_device struct
> + * @advert: auto-negotiation parameters to advertise
>    *
>    * Description: Writes MII_ADVERTISE with the appropriate values,
>    *   after sanitizing the values to make sure we only advertise
>    *   what is supported.  Returns < 0 on error, 0 if the PHY's advertisement
>    *   hasn't changed, and > 0 if it has changed.
>    */
> -static int genphy_config_advert(struct phy_device *phydev)
> +static int genphy_config_advert(struct phy_device *phydev,
> +				const unsigned long *advert)
>   {
>   	int err, bmsr, changed = 0;
>   	u32 adv;
>   
> -	/* Only allow advertising what this PHY supports */
> -	linkmode_and(phydev->advertising, phydev->advertising,
> -		     phydev->supported);
> -
> -	adv = linkmode_adv_to_mii_adv_t(phydev->advertising);
> +	adv = linkmode_adv_to_mii_adv_t(advert);
>   
>   	/* Setup standard advertisement */
>   	err = phy_modify_changed(phydev, MII_ADVERTISE,
> @@ -2132,7 +2130,7 @@ static int genphy_config_advert(struct phy_device *phydev)
>   	if (!(bmsr & BMSR_ESTATEN))
>   		return changed;
>   
> -	adv = linkmode_adv_to_mii_ctrl1000_t(phydev->advertising);
> +	adv = linkmode_adv_to_mii_ctrl1000_t(advert);
>   
>   	err = phy_modify_changed(phydev, MII_CTRL1000,
>   				 ADVERTISE_1000FULL | ADVERTISE_1000HALF,
> @@ -2356,6 +2354,9 @@ EXPORT_SYMBOL(genphy_check_and_restart_aneg);
>    */
>   int __genphy_config_aneg(struct phy_device *phydev, bool changed)
>   {
> +	__ETHTOOL_DECLARE_LINK_MODE_MASK(fixed_advert);
> +	const struct phy_setting *set;
> +	unsigned long *advert;
>   	int err;
>   
>   	err = genphy_c45_an_config_eee_aneg(phydev);
> @@ -2370,10 +2371,25 @@ int __genphy_config_aneg(struct phy_device *phydev, bool changed)
>   	else if (err)
>   		changed = true;
>   
> -	if (AUTONEG_ENABLE != phydev->autoneg)
> +	if (phydev->autoneg == AUTONEG_ENABLE) {
> +		/* Only allow advertising what this PHY supports */
> +		linkmode_and(phydev->advertising, phydev->advertising,
> +			     phydev->supported);
> +		advert = phydev->advertising;
> +	} else if (phydev->speed < SPEED_1000) {
>   		return genphy_setup_forced(phydev);
> +	} else {
> +		linkmode_zero(fixed_advert);
> +
> +		set = phy_lookup_setting(phydev->speed, phydev->duplex,
> +					 phydev->supported, true);
> +		if (set)
> +			linkmode_set(set->bit, fixed_advert);
> +
> +		advert = fixed_advert;
> +	}
>   
> -	err = genphy_config_advert(phydev);
> +	err = genphy_config_advert(phydev, advert);
>   	if (err < 0) /* error */
>   		return err;
>   	else if (err)

It looks great, but I still want to follow Russell's earlier advice and 
drop this patch

from v14, then submit it separately with the above code.


Thanks,

Yanteng

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Yanteng Si]

在 2024/7/5 18:59, Serge Semin 写道:
> On Fri, Jul 05, 2024 at 06:45:50PM +0800, Yanteng Si wrote:
>> 在 2024/7/5 18:16, Serge Semin 写道:
>>>>> Seeing the discussion has started anyway, could you please find out
>>>>> whether the multi-channel controller will still work if the MSI IRQs
>>>>> allocation failed? Will the multi-channel-ness still work in that
>>>>> case?
>>>> Based on my test results:
>>>>
>>>> In this case, multi-channel controller don't work. If the MSI IRQs
>>>> allocation
>>>>
>>>> failed, NIC will work in single channel.
>>> What does "NIC will work in single channel" mean? Do the driver
>>> (network traffic flow with a normal performance) still work even with
>>> the plat->tx_queues_to_use and plat->rx_queues_to_use fields set to
>>> eight? If it's then the multi-channel-ness still seems to be working
>>> but the IRQs are delivered via the common MAC IRQ. If you get to
>>> experience the data loss, or poor performance, or no traffic flowing
>>> at all, then indeed the non-zero channels IRQs aren't delivered.
>>>
>>> So the main question how did you find out that the controller work in
>>> single channel?
>> sorry, I meant that if the MSI allocation failed, it will fallback to INTx,
>> in which case
>>
>> only the single channel works.  if the MSI allocation failed, the
>> multi-channel-ness
>>
>> don't work.
> Could you please clarify what are the symptoms by which you figured
> out that the "multi-channel-ness" didn't work?
>
> Suppose you have an LS2K2000 SoC-based device, the
> plat->tx_queues_to_use and plat->rx_queues_to_use to eight and the
> loongson_dwmac_msi_config() function call is omitted. What is
> happening with the activated network interface and with the traffic
> flow then?

Ok, here are the results of my test in LS2K2000:


v14 based.

$: git diff

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 25ddd99ae112..f05b600a19cf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -576,11 +576,11 @@ static int loongson_dwmac_probe(struct pci_dev 
*pdev, const struct pci_device_id
         if (ret)
                 goto err_disable_device;

-       if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
-               ret = loongson_dwmac_msi_config(pdev, plat, &res);
-               if (ret)
-                       goto err_disable_device;
-       }
+       // if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
+               // ret = loongson_dwmac_msi_config(pdev, plat, &res);
+               // if (ret)
+                       // goto err_disable_device;
+       // }

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


boot on LS2K2000.

dmesg:

[    0.000000] Linux version 6.10.0-rc5+ (siyanteng@kernelserver) 
(loongarch64-unknown-linux-gnu-gcc (GCC) 14.0.0 20231116 (experimental), 
GNU ld (GNU Binutils) 2.41.50.20231116) #56 SMP PREEMPT_DYNAMIC Fri Jul  
5 19:06:53 CST 2024
[    0.000000] 64-bit Loongson Processor probed (LA364 Core)
[    0.000000] CPU0 revision is: 0014b000 (Loongson-64bit)
[    0.000000] FPU0 revision is: 00000001
[    0.000000] efi: EFI v2.7 by EDK II
[    0.000000] efi: ACPI 2.0=0xf9c40000 SMBIOS 3.0=0xfdf20000 
INITRD=0xf9b60118 MEMRESERVE=0xf9b60198 MEMMAP=0xf3de0018
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000F9C40000 000024 (v02 LOONGS)
[    0.000000] ACPI: XSDT 0x00000000F9C30000 000064 (v01 LOONGS LOONGSON 
00000002      01000013)
[    0.000000] ACPI: FACP 0x00000000F9C00000 0000F4 (v03 LOONGS LOONGSON 
00000002 LIUX 01000013)
[    0.000000] ACPI: DSDT 0x00000000F9BD0000 001CE6 (v02 LOONGS LOONGSON 
00000002 INTL 20200925)
[    0.000000] ACPI: FACS 0x00000000F9C10000 000040
[    0.000000] ACPI: APIC 0x00000000F9C20000 0000A0 (v06 LOONGS LOONGSON 
00000002 LIUX 01000013)
[    0.000000] ACPI: IVRS 0x00000000F9BF0000 00004C (v01 LARCH LOONGSON 
00000001 LIUX 00000001)
[    0.000000] ACPI: MCFG 0x00000000F9BE0000 00003C (v01 LOONGS LOONGSON 
00000001 LIUX 01000013)
[    0.000000] ACPI: SRAT 0x00000000F9BC0000 0000A0 (v02 LOONGS LOONGSON 
00000002 LIUX 01000013)
[    0.000000] ACPI: SLIT 0x00000000F9BB0000 00002D (v01 LOONGS LOONGSON 
00000002 LIUX 01000013)
[    0.000000] ACPI: VIAT 0x00000000F9BA0000 00002C (v01 LOONGS LOONGSON 
00000002 LIUX 01000013)
[    0.000000] ACPI: PPTT 0x00000000F9B90000 0000D8 (v03 LOONGS LOONGSON 
00000002 LIUX 01000013)
[    0.000000] SRAT: PXM 0 -> CPU 0x00 -> Node 0
[    0.000000] SRAT: PXM 0 -> CPU 0x01 -> Node 0
[    0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x0fffffff]
[    0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x90000000-0x26fffffff]
[    0.000000] Node0: mem_type:2, mem_start:0x200000, mem_size:0x2b30000 
Bytes
[    0.000000]        start_pfn:0x80, end_pfn:0xb4c, num_physpages:0xacc
[    0.000000] Node0: mem_type:7, mem_start:0x2d30000, 
mem_size:0xc0d0000 Bytes
[    0.000000]        start_pfn:0xb4c, end_pfn:0x3b80, num_physpages:0x3b00
[    0.000000] Resvd: mem_type:6, mem_start:0x10000000, 
mem_size:0x10000000 Bytes
[    0.000000] Node0: mem_type:7, mem_start:0x90100000, 
mem_size:0x2ffc0000 Bytes
[    0.000000]        start_pfn:0x24040, end_pfn:0x30030, 
num_physpages:0xfaf0
[    0.000000] Node0: mem_type:4, mem_start:0xc00c0000, 
mem_size:0x2b0000 Bytes
[    0.000000]        start_pfn:0x30030, end_pfn:0x300dc, 
num_physpages:0xfb9c
[    0.000000] Node0: mem_type:7, mem_start:0xc0370000, 
mem_size:0x33a70000 Bytes
[    0.000000]        start_pfn:0x300dc, end_pfn:0x3cf78, 
num_physpages:0x1ca38
[    0.000000] Node0: mem_type:9, mem_start:0xf3de0000, mem_size:0x10000 
Bytes
[    0.000000]        start_pfn:0x3cf78, end_pfn:0x3cf7c, 
num_physpages:0x1ca3c
[    0.000000] Resvd: mem_type:9, mem_start:0xf3de0000, mem_size:0x10000 
Bytes
[    0.000000] Node0: mem_type:2, mem_start:0xf3df0000, 
mem_size:0x840000 Bytes
[    0.000000]        start_pfn:0x3cf7c, end_pfn:0x3d18c, 
num_physpages:0x1cc4c
[    0.000000] Node0: mem_type:1, mem_start:0xf4630000, 
mem_size:0x2b40000 Bytes
[    0.000000]        start_pfn:0x3d18c, end_pfn:0x3dc5c, 
num_physpages:0x1d71c
[    0.000000] Node0: mem_type:2, mem_start:0xf7170000, 
mem_size:0x29f1000 Bytes
[    0.000000]        start_pfn:0x3dc5c, end_pfn:0x3e6d8, 
num_physpages:0x1e198
[    0.000000] Node0: mem_type:7, mem_start:0xf9b61000, mem_size:0x4000 
Bytes
[    0.000000]        start_pfn:0x3e6d8, end_pfn:0x3e6d9, 
num_physpages:0x1e199
[    0.000000] Node0: mem_type:2, mem_start:0xf9b65000, mem_size:0x2000 
Bytes
[    0.000000]        start_pfn:0x3e6d9, end_pfn:0x3e6d9, 
num_physpages:0x1e199
[    0.000000] Node0: mem_type:1, mem_start:0xf9b67000, mem_size:0x29000 
Bytes
[    0.000000]        start_pfn:0x3e6d9, end_pfn:0x3e6e4, 
num_physpages:0x1e1a3
[    0.000000] Node0: mem_type:9, mem_start:0xf9b90000, mem_size:0x80000 
Bytes
[    0.000000]        start_pfn:0x3e6e4, end_pfn:0x3e704, 
num_physpages:0x1e1c3
[    0.000000] Resvd: mem_type:9, mem_start:0xf9b90000, mem_size:0x80000 
Bytes
[    0.000000] Node0: mem_type:9, mem_start:0xf9c20000, mem_size:0x30000 
Bytes
[    0.000000]        start_pfn:0x3e708, end_pfn:0x3e714, 
num_physpages:0x1e1cf
[    0.000000] Resvd: mem_type:9, mem_start:0xf9c20000, mem_size:0x30000 
Bytes
[    0.000000] Node0: mem_type:7, mem_start:0xf9c50000, 
mem_size:0x102d000 Bytes
[    0.000000]        start_pfn:0x3e714, end_pfn:0x3eb1f, 
num_physpages:0x1e5da
[    0.000000] Node0: mem_type:4, mem_start:0xfac7d000, mem_size:0xe2000 
Bytes
[    0.000000]        start_pfn:0x3eb1f, end_pfn:0x3eb57, 
num_physpages:0x1e612
[    0.000000] Node0: mem_type:7, mem_start:0xfad5f000, 
mem_size:0x1b3000 Bytes
[    0.000000]        start_pfn:0x3eb57, end_pfn:0x3ebc4, 
num_physpages:0x1e67e
[    0.000000] Node0: mem_type:4, mem_start:0xfaf12000, 
mem_size:0x1d3e000 Bytes
[    0.000000]        start_pfn:0x3ebc4, end_pfn:0x3f314, 
num_physpages:0x1edcd
[    0.000000] Node0: mem_type:7, mem_start:0xfcc50000, 
mem_size:0x507000 Bytes
[    0.000000]        start_pfn:0x3f314, end_pfn:0x3f455, 
num_physpages:0x1ef0e
[    0.000000] Node0: mem_type:3, mem_start:0xfd157000, 
mem_size:0x9f9000 Bytes
[    0.000000]        start_pfn:0x3f455, end_pfn:0x3f6d4, 
num_physpages:0x1f18c
[    0.000000] Resvd: mem_type:5, mem_start:0xfdb50000, 
mem_size:0x1c0000 Bytes
[    0.000000] Resvd: mem_type:6, mem_start:0xfdd10000, 
mem_size:0x400000 Bytes
[    0.000000] Node0: mem_type:7, mem_start:0xfe110000, mem_size:0x21000 
Bytes
[    0.000000]        start_pfn:0x3f844, end_pfn:0x3f84c, 
num_physpages:0x1f194
[    0.000000] Node0: mem_type:4, mem_start:0xfe131000, mem_size:0x21000 
Bytes
[    0.000000]        start_pfn:0x3f84c, end_pfn:0x3f854, 
num_physpages:0x1f19c
[    0.000000] Node0: mem_type:3, mem_start:0xfe152000, mem_size:0x39000 
Bytes
[    0.000000]        start_pfn:0x3f854, end_pfn:0x3f862, 
num_physpages:0x1f1aa
[    0.000000] Node0: mem_type:4, mem_start:0xfe18b000, 
mem_size:0xe51000 Bytes
[    0.000000]        start_pfn:0x3f862, end_pfn:0x3fbf7, 
num_physpages:0x1f53e
[    0.000000] Node0: mem_type:3, mem_start:0xfefdc000, mem_size:0x22000 
Bytes
[    0.000000]        start_pfn:0x3fbf7, end_pfn:0x3fbff, 
num_physpages:0x1f546
[    0.000000] Node0: mem_type:4, mem_start:0xfeffe000, mem_size:0x2000 
Bytes
[    0.000000]        start_pfn:0x3fbff, end_pfn:0x3fc00, 
num_physpages:0x1f546
[    0.000000] Node0: mem_type:7, mem_start:0xff000000, 
mem_size:0x16e200000 Bytes
[    0.000000]        start_pfn:0x3fc00, end_pfn:0x9b480, 
num_physpages:0x7adc6
[    0.000000] Node0: mem_type:1, mem_start:0x26d200000, 
mem_size:0x2e00000 Bytes
[    0.000000]        start_pfn:0x9b480, end_pfn:0x9c000, 
num_physpages:0x7b946
[    0.000000] Resvd: mem_type:0, mem_start:0xee00000, 
mem_size:0x1200000 Bytes
[    0.000000] Resvd: mem_type:0, mem_start:0x90000000, 
mem_size:0x100000 Bytes
[    0.000000] Node0's addrspace_offset is 0x0
[    0.000000] Node0: start_pfn=0x80, end_pfn=0x9c000
[    0.000000] SMBIOS 3.2.0 present.
[    0.000000] DMI: Loongson 
Loongson-2K2000-7A2000-1w-V0.1-EVB/Loongson-2K2000-7A2000-1w-EVB-V1.21, 
BIOS Loongson-UDK2018-V4.0.05692-stable202402
[    0.000000] DMI: Memory slots populated: 1/1
[    0.000000] CpuClock = 1400000000
[    0.000000] The BIOS Version: Loongson-UDK2018-V4.0.05692-stable202402
[    0.000000] software IO TLB: area num 2.
[    0.000000] software IO TLB: mapped [mem 
0x0000000006610000-0x000000000a610000] (64MB)
[    0.000000] PM: hibernation: Registered nosave memory: [mem 
0x05840000-0x05843fff]
[    0.000000] Detected 2 available CPU(s)
[    0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000000200000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x000000026fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000200000-0x000000000edfffff]
[    0.000000]   node   0: [mem 0x0000000090100000-0x00000000f9c0ffff]
[    0.000000]   node   0: [mem 0x00000000f9c20000-0x00000000fdb4ffff]
[    0.000000]   node   0: [mem 0x00000000fe110000-0x000000026fffffff]
[    0.000000] Initmem setup node 0 [mem 
0x0000000000200000-0x000000026fffffff]
[    0.000000] On node 0, zone DMA32: 128 pages in unavailable ranges
[    0.000000] On node 0, zone DMA32: 33984 pages in unavailable ranges
[    0.000000] On node 0, zone DMA32: 4 pages in unavailable ranges
[    0.000000] On node 0, zone DMA32: 368 pages in unavailable ranges
[    0.000000] On node 0, zone Normal: 16384 pages in unavailable ranges
[    0.000000] percpu: Embedded 6 pages/cpu s47056 r8192 d43056 u16777216
[    0.000000] pcpu-alloc: s47056 r8192 d43056 u16777216 alloc=1*33554432
[    0.000000] pcpu-alloc: [0] 0 1
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.x 
root=UUID=1ecbf33b-86de-4870-9171-9019c5ed78b3 rw console=ttyS0,115200
[    0.000000] Unknown kernel command line parameters 
"BOOT_IMAGE=/boot/vmlinuz-5.x", will be passed to user space.
[    0.000000] Dentry cache hash table entries: 1048576 (order: 9, 
8388608 bytes, linear)
[    0.000000] Inode-cache hash table entries: 524288 (order: 8, 4194304 
bytes, linear)
[    0.000000] Fallback order for Node 0: 0
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 506188
[    0.000000] Policy zone: Normal
[    0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[    0.000000] Memory: 7900832K/8099008K available (20736K kernel code, 
12889K rwdata, 8548K rodata, 640K init, 1231K bss, 198176K reserved, 0K 
cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Dynamic Preempt: full
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu:     RCU event tracing is enabled.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=256 to 
nr_cpu_ids=2.
[    0.000000]     Trampoline variant of Tasks RCU enabled.
[    0.000000]     Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay 
is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[    0.000000] RCU Tasks: Setting shift to 1 and lim to 1 
rcu_task_cb_adjust=1.
[    0.000000] RCU Tasks Trace: Setting shift to 1 and lim to 1 
rcu_task_cb_adjust=1.
[    0.000000] NR_IRQS: 576, nr_irqs: 576, preallocated irqs: 16
[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on 
contention.
[    0.000000] Constant clock event device register
[    0.000000] clocksource: Constant: mask: 0xffffffffffffffff 
max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
[    0.000000] sched_clock: 64 bits at 100MHz, resolution 10ns, wraps 
every 4398046511100ns
[    0.000004] Constant clock source device register
[    0.000116] Console: colour dummy device 80x25
[    0.000158] ACPI: Core revision 20240322
[    0.000247] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 200.00 BogoMIPS (lpj=400000)
[    0.000257] pid_max: default: 32768 minimum: 301
[    0.000292] LSM: initializing lsm=capability,yama
[    0.000301] Yama: becoming mindful.
[    0.000385] Mount-cache hash table entries: 16384 (order: 3, 131072 
bytes, linear)
[    0.000429] Mountpoint-cache hash table entries: 16384 (order: 3, 
131072 bytes, linear)
[    0.001283] rcu: Hierarchical SRCU implementation.
[    0.001286] rcu:     Max phase no-delay instances is 1000.
[    0.001488] smp: Bringing up secondary CPUs ...
[    0.001653] Booting CPU#1...
[    0.001694] 64-bit Loongson Processor probed (LA364 Core)
[    0.001698] CPU1 revision is: 0014b000 (Loongson-64bit)
[    0.001702] FPU1 revision is: 00000001
[    0.001715] CPU#1 finished
[    0.001767] smp: Brought up 1 node, 2 CPUs
[    0.002149] devtmpfs: initialized
[    0.002872] Performance counters: loongarch/loongson64 PMU enabled, 4 
64-bit counters available to each CPU.
[    0.003024] clocksource: jiffies: mask: 0xffffffff max_cycles: 
0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.003032] futex hash table entries: 512 (order: 1, 32768 bytes, linear)
[    0.003106] pinctrl core: initialized pinctrl subsystem
[    0.003439] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.003695] audit: initializing netlink subsys (disabled)
[    0.003756] audit: type=2000 audit(0.004:1): state=initialized 
audit_enabled=0 res=1
[    0.003930] thermal_sys: Registered thermal governor 'step_wise'
[    0.004038] hw-breakpoint: Found 4 breakpoint and 2 watchpoint registers.
[    0.004449] HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages
[    0.004453] HugeTLB: 112 KiB vmemmap can be freed for a 32.0 MiB page
[    0.004612] Demotion targets for Node 0: null
[    0.072010] raid6: lsx      gen()  4185 MB/s
[    0.140013] raid6: int64x8  gen()  1725 MB/s
[    0.207998] raid6: int64x4  gen()  2148 MB/s
[    0.276039] raid6: int64x2  gen()  1888 MB/s
[    0.343992] raid6: int64x1  gen()  1643 MB/s
[    0.343994] raid6: using algorithm lsx gen() 4185 MB/s
[    0.412000] raid6: .... xor() 2449 MB/s, rmw enabled
[    0.412002] raid6: using lsx recovery algorithm
[    0.412098] ACPI: Added _OSI(Module Device)
[    0.412101] ACPI: Added _OSI(Processor Device)
[    0.412103] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.412106] ACPI: Added _OSI(Processor Aggregator Device)
[    0.414353] ACPI: 1 ACPI AML tables successfully acquired and loaded
[    0.419490] ACPI Error: Could not enable GlobalLock event 
(20240322/evxfevnt-182)
[    0.419497] ACPI Warning: Could not enable fixed event - GlobalLock 
(1) (20240322/evxface-618)
[    0.419503] ACPI Error: No response from Global Lock hardware, 
disabling lock (20240322/evglock-59)
[    0.419906] ACPI: Interpreter enabled
[    0.419939] ACPI: PM: (supports S0 S3 S4 S5)
[    0.419941] ACPI: Using LPIC for interrupt routing
[    0.419960] ACPI: MCFG table detected, 1 entries
[    0.420518] ACPI: \_SB_.PCI0.PCIB.XHCI.PUBS: New power resource
[    0.424401] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.424413] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig 
Segments MSI HPX-Type3]
[    0.424417] acpi PNP0A08:00: _OSC: not requesting OS control; OS 
requires [ExtendedConfig ASPM ClockPM MSI]
[    0.424426] acpi PNP0A08:00: _OSC: platform retains control of PCIe 
features (AE_NOT_FOUND)
[    0.424431] acpi PNP0A08:00: MCFG quirk: ECAM at [mem 
0xfe00000000-0xfe0fffffff] for [bus 00-ff] with loongson_pci_ecam_ops
[    0.425509] acpi PNP0A08:00: ECAM at [mem 0xfe00000000-0xfe1fffffff] 
for [bus 00-ff]
[    0.425534] ACPI: Remapped I/O 0x0000000018000000 to [io 
0x0000-0xffff window]
[    0.425694] PCI host bridge to bus 0000:00
[    0.425698] pci_bus 0000:00: root bus resource [io 0x0000-0xffff window]
[    0.425703] pci_bus 0000:00: root bus resource [mem 
0x40000000-0x7fffffff window]
[    0.425706] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.425735] pci 0000:00:03.0: [0014:7a13] type 00 class 0x020000 
conventional PCI endpoint
[    0.425746] pci 0000:00:03.0: BAR 0 [mem 0x51290000-0x51297fff 64bit]
[    0.425899] pci 0000:00:03.1: [0014:7a13] type 00 class 0x020000 
conventional PCI endpoint
[    0.425908] pci 0000:00:03.1: BAR 0 [mem 0x51298000-0x5129ffff 64bit]
[    0.426034] pci 0000:00:03.2: [0014:7a03] type 00 class 0x020000 
conventional PCI endpoint
[    0.426042] pci 0000:00:03.2: BAR 0 [mem 0x512a0000-0x512a7fff 64bit]
[    0.426054] pci 0000:00:03.2: ROM [mem 0xfffff800-0xffffffff pref]
[    0.426121] pci 0000:00:04.0: [0014:7a44] type 00 class 0x0c0330 
conventional PCI endpoint
[    0.426129] pci 0000:00:04.0: BAR 0 [mem 0x51000000-0x510fffff 64bit]
[    0.426243] pci 0000:00:05.0: [0014:7a54] type 00 class 0x0c0380 
conventional PCI endpoint
[    0.426252] pci 0000:00:05.0: BAR 0 [mem 0x51200000-0x5123ffff 64bit]
[    0.426368] pci 0000:00:06.0: [0014:7a25] type 00 class 0x040000 
conventional PCI endpoint
[    0.426377] pci 0000:00:06.0: BAR 0 [mem 0x512a9000-0x512a90ff 64bit]
[    0.426383] pci 0000:00:06.0: BAR 2 [mem 0x40000000-0x4fffffff 64bit]
[    0.426388] pci 0000:00:06.0: BAR 4 [mem 0x51240000-0x5124ffff 64bit]
[    0.426449] pci 0000:00:06.1: [0014:7a36] type 00 class 0x030000 
conventional PCI endpoint
[    0.426457] pci 0000:00:06.1: BAR 0 [mem 0x51250000-0x5125ffff 64bit]
[    0.426462] pci 0000:00:06.1: BAR 2 [mem 0x512b4000-0x512b40ff]
[    0.426531] pci 0000:00:06.2: [0014:7a37] type 00 class 0x040300 
conventional PCI endpoint
[    0.426539] pci 0000:00:06.2: BAR 0 [mem 0x51260000-0x5126ffff 64bit]
[    0.426609] pci 0000:00:06.3: [0014:7a16] type 00 class 0x048000 
conventional PCI endpoint
[    0.426618] pci 0000:00:06.3: BAR 0 [mem 0x512a8000-0x512a81ff 64bit]
[    0.426685] pci 0000:00:07.0: [0014:7a07] type 00 class 0x040300 
conventional PCI endpoint
[    0.426694] pci 0000:00:07.0: BAR 0 [mem 0x51270000-0x5127ffff 64bit]
[    0.426766] pci 0000:00:08.0: [0014:7a18] type 00 class 0x010601 
conventional PCI endpoint
[    0.426781] pci 0000:00:08.0: BAR 5 [mem 0x512b3000-0x512b33ff]
[    0.426897] pci 0000:00:09.0: [0014:7a49] type 01 class 0x060400 PCIe 
Root Port
[    0.426912] pci 0000:00:09.0: BAR 0 [mem 0x512aa000-0x512aafff 64bit]
[    0.426920] pci 0000:00:09.0: PCI bridge to [bus 01]
[    0.426971] pci 0000:00:09.0: supports D1 D2
[    0.426974] pci 0000:00:09.0: PME# supported from D0 D1 D3hot D3cold
[    0.427076] pci 0000:00:0d.0: [0014:7a49] type 01 class 0x060400 PCIe 
Root Port
[    0.427090] pci 0000:00:0d.0: BAR 0 [mem 0x512ab000-0x512abfff 64bit]
[    0.427098] pci 0000:00:0d.0: PCI bridge to [bus 02]
[    0.427148] pci 0000:00:0d.0: supports D1 D2
[    0.427150] pci 0000:00:0d.0: PME# supported from D0 D1 D3hot D3cold
[    0.427253] pci 0000:00:0f.0: [0014:7a79] type 01 class 0x060400 PCIe 
Root Port
[    0.427267] pci 0000:00:0f.0: BAR 0 [mem 0x512ac000-0x512acfff 64bit]
[    0.427276] pci 0000:00:0f.0: PCI bridge to [bus 03]
[    0.427325] pci 0000:00:0f.0: supports D1 D2
[    0.427328] pci 0000:00:0f.0: PME# supported from D0 D1 D3hot D3cold
[    0.427420] pci 0000:00:16.0: [0014:7a1b] type 00 class 0x088000 
conventional PCI endpoint
[    0.427429] pci 0000:00:16.0: BAR 0 [mem 0x512ad000-0x512adfff 64bit]
[    0.427435] pci 0000:00:16.0: BAR 2 [mem 0x50000000-0x50ffffff 64bit]
[    0.427502] pci 0000:00:19.0: [0014:7a34] type 00 class 0x0c0330 
conventional PCI endpoint
[    0.427511] pci 0000:00:19.0: BAR 0 [mem 0x51100000-0x511fffff 64bit]
[    0.427578] pci 0000:00:1d.0: [0014:7a0e] type 00 class 0x108000 
conventional PCI endpoint
[    0.427586] pci 0000:00:1d.0: BAR 0 [mem 0x512ae000-0x512aefff 64bit]
[    0.427597] pci 0000:00:1d.0: ROM [mem 0xfffff800-0xffffffff pref]
[    0.427656] pci 0000:00:1d.1: [0014:7a1e] type 00 class 0x108000 
conventional PCI endpoint
[    0.427664] pci 0000:00:1d.1: BAR 0 [mem 0x512af000-0x512affff 64bit]
[    0.427675] pci 0000:00:1d.1: ROM [mem 0xfffff800-0xffffffff pref]
[    0.427734] pci 0000:00:1d.2: [0014:7a2e] type 00 class 0x108000 
conventional PCI endpoint
[    0.427742] pci 0000:00:1d.2: BAR 0 [mem 0x512b0000-0x512b0fff 64bit]
[    0.427753] pci 0000:00:1d.2: ROM [mem 0xfffff800-0xffffffff pref]
[    0.427815] pci 0000:00:1d.3: [0014:7a3e] type 00 class 0x108000 
conventional PCI endpoint
[    0.427823] pci 0000:00:1d.3: BAR 0 [mem 0x512b1000-0x512b1fff 64bit]
[    0.427834] pci 0000:00:1d.3: ROM [mem 0xfffff800-0xffffffff pref]
[    0.427895] pci 0000:00:1e.0: [0014:7a2f] type 00 class 0x088000 
conventional PCI endpoint
[    0.427903] pci 0000:00:1e.0: BAR 0 [mem 0x512b2000-0x512b2fff 64bit]
[    0.427914] pci 0000:00:1e.0: ROM [mem 0xfffff800-0xffffffff pref]
[    0.427972] pci 0000:00:1f.0: [0014:7a8e] type 00 class 0x108000 
conventional PCI endpoint
[    0.427981] pci 0000:00:1f.0: BAR 0 [mem 0x51280000-0x5128ffff 64bit]
[    0.427996] pci 0000:00:1f.0: ROM [mem 0xfffff800-0xffffffff pref]
[    0.428189] pci 0000:00:06.0: BAR 2 [mem 0x40000000-0x4fffffff 
64bit]: assigned
[    0.428197] pci 0000:00:16.0: BAR 2 [mem 0x50000000-0x50ffffff 
64bit]: assigned
[    0.428202] pci 0000:00:04.0: BAR 0 [mem 0x51000000-0x510fffff 
64bit]: assigned
[    0.428208] pci 0000:00:19.0: BAR 0 [mem 0x51100000-0x511fffff 
64bit]: assigned
[    0.428213] pci 0000:00:05.0: BAR 0 [mem 0x51200000-0x5123ffff 
64bit]: assigned
[    0.428218] pci 0000:00:06.0: BAR 4 [mem 0x51240000-0x5124ffff 
64bit]: assigned
[    0.428223] pci 0000:00:06.1: BAR 0 [mem 0x51250000-0x5125ffff 
64bit]: assigned
[    0.428229] pci 0000:00:06.2: BAR 0 [mem 0x51260000-0x5126ffff 
64bit]: assigned
[    0.428234] pci 0000:00:07.0: BAR 0 [mem 0x51270000-0x5127ffff 
64bit]: assigned
[    0.428239] pci 0000:00:1f.0: BAR 0 [mem 0x51280000-0x5128ffff 
64bit]: assigned
[    0.428245] pci 0000:00:03.0: BAR 0 [mem 0x51290000-0x51297fff 
64bit]: assigned
[    0.428250] pci 0000:00:03.1: BAR 0 [mem 0x51298000-0x5129ffff 
64bit]: assigned
[    0.428255] pci 0000:00:03.2: BAR 0 [mem 0x512a0000-0x512a7fff 
64bit]: assigned
[    0.428260] pci 0000:00:09.0: BAR 0 [mem 0x512a8000-0x512a8fff 
64bit]: assigned
[    0.428268] pci 0000:00:0d.0: BAR 0 [mem 0x512a9000-0x512a9fff 
64bit]: assigned
[    0.428276] pci 0000:00:0f.0: BAR 0 [mem 0x512aa000-0x512aafff 
64bit]: assigned
[    0.428284] pci 0000:00:16.0: BAR 0 [mem 0x512ab000-0x512abfff 
64bit]: assigned
[    0.428289] pci 0000:00:1d.0: BAR 0 [mem 0x512ac000-0x512acfff 
64bit]: assigned
[    0.428295] pci 0000:00:1d.1: BAR 0 [mem 0x512ad000-0x512adfff 
64bit]: assigned
[    0.428300] pci 0000:00:1d.2: BAR 0 [mem 0x512ae000-0x512aefff 
64bit]: assigned
[    0.428305] pci 0000:00:1d.3: BAR 0 [mem 0x512af000-0x512affff 
64bit]: assigned
[    0.428311] pci 0000:00:1e.0: BAR 0 [mem 0x512b0000-0x512b0fff 
64bit]: assigned
[    0.428316] pci 0000:00:03.2: ROM [mem 0x512b1000-0x512b17ff pref]: 
assigned
[    0.428321] pci 0000:00:1d.0: ROM [mem 0x512b1800-0x512b1fff pref]: 
assigned
[    0.428325] pci 0000:00:1d.1: ROM [mem 0x512b2000-0x512b27ff pref]: 
assigned
[    0.428328] pci 0000:00:1d.2: ROM [mem 0x512b2800-0x512b2fff pref]: 
assigned
[    0.428332] pci 0000:00:1d.3: ROM [mem 0x512b3000-0x512b37ff pref]: 
assigned
[    0.428336] pci 0000:00:1e.0: ROM [mem 0x512b3800-0x512b3fff pref]: 
assigned
[    0.428340] pci 0000:00:1f.0: ROM [mem 0x512b4000-0x512b47ff pref]: 
assigned
[    0.428344] pci 0000:00:08.0: BAR 5 [mem 0x512b4800-0x512b4bff]: assigned
[    0.428349] pci 0000:00:06.3: BAR 0 [mem 0x512b4c00-0x512b4dff 
64bit]: assigned
[    0.428355] pci 0000:00:06.0: BAR 0 [mem 0x512b4e00-0x512b4eff 
64bit]: assigned
[    0.428360] pci 0000:00:06.1: BAR 2 [mem 0x512b4f00-0x512b4fff]: assigned
[    0.428368] pci 0000:00:09.0: PCI bridge to [bus 01]
[    0.428376] pci 0000:00:0d.0: PCI bridge to [bus 02]
[    0.428385] pci 0000:00:0f.0: PCI bridge to [bus 03]
[    0.428898] gpio gpiochip0: Static allocation of GPIO base is 
deprecated, use dynamic allocation.
[    0.429835] iommu: Default domain type: Translated
[    0.429838] iommu: DMA domain TLB invalidation policy: strict mode
[    0.429977] SCSI subsystem initialized
[    0.430072] libata version 3.00 loaded.
[    0.430114] ACPI: bus type USB registered
[    0.430141] usbcore: registered new interface driver usbfs
[    0.430155] usbcore: registered new interface driver hub
[    0.430169] usbcore: registered new device driver usb
[    0.430243] pps_core: LinuxPPS API ver. 1 registered
[    0.430246] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 
Rodolfo Giometti <giometti@linux.it>
[    0.430251] PTP clock support registered
[    0.430424] efivars: Registered efivars operations
[    0.430557] Advanced Linux Sound Architecture Driver Initialized.
[    0.430901] pci 0000:00:06.1: vgaarb: setting as boot VGA device
[    0.430905] pci 0000:00:06.1: vgaarb: bridge control possible
[    0.430908] pci 0000:00:06.1: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[    0.430922] vgaarb: loaded
[    0.430990] clocksource: Switched to clocksource Constant
[    0.439730] VFS: Disk quotas dquot_6.6.0
[    0.439768] VFS: Dquot-cache hash table entries: 2048 (order 0, 16384 
bytes)
[    0.439895] netfs: FS-Cache loaded
[    0.440018] pnp: PnP ACPI init
[    0.440480] pnp: PnP ACPI: found 5 devices
[    0.443669] NET: Registered PF_INET protocol family
[    0.444034] IP idents hash table entries: 131072 (order: 6, 1048576 
bytes, linear)
[    0.447549] tcp_listen_portaddr_hash hash table entries: 4096 (order: 
2, 65536 bytes, linear)
[    0.447593] Table-perturb hash table entries: 65536 (order: 4, 262144 
bytes, linear)
[    0.447599] TCP established hash table entries: 65536 (order: 5, 
524288 bytes, linear)
[    0.447762] TCP bind hash table entries: 65536 (order: 7, 2097152 
bytes, linear)
[    0.448567] TCP: Hash tables configured (established 65536 bind 65536)
[    0.448848] MPTCP token hash table entries: 8192 (order: 3, 196608 
bytes, linear)
[    0.448906] UDP hash table entries: 4096 (order: 3, 131072 bytes, linear)
[    0.448944] UDP-Lite hash table entries: 4096 (order: 3, 131072 
bytes, linear)
[    0.449070] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.449347] RPC: Registered named UNIX socket transport module.
[    0.449350] RPC: Registered udp transport module.
[    0.449352] RPC: Registered tcp transport module.
[    0.449354] RPC: Registered tcp-with-tls transport module.
[    0.449356] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.449360] NET: Registered PF_XDP protocol family
[    0.449516] PCI: CLS 64 bytes, default 64
[    0.449558] ACPI: bus type thunderbolt registered
[    0.449851] Trying to unpack rootfs image as initramfs...
[    0.455340] Initialise system trusted keyrings
[    0.455464] workingset: timestamp_bits=40 max_order=19 bucket_order=0
[    0.455492] zbud: loaded
[    0.455719] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.455839] NFS: Registering the id_resolver key type
[    0.455851] Key type id_resolver registered
[    0.455853] Key type id_legacy registered
[    0.455864] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.455870] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver 
Registering...
[    0.456125] SGI XFS with ACLs, security attributes, quota, no debug 
enabled
[    0.456299] 9p: Installing v9fs 9p2000 file system support
[    0.456395] xor: measuring software checksum speed
[    0.457876]    8regs           :  6668 MB/sec
[    0.459630]    8regs_prefetch  :  5730 MB/sec
[    0.461108]    32regs          :  6673 MB/sec
[    0.462826]    32regs_prefetch :  5734 MB/sec
[    0.464011]    lsx             :  8430 MB/sec
[    0.464016] xor: using function: lsx (8430 MB/sec)
[    0.464025] Key type asymmetric registered
[    0.464028] Asymmetric key parser 'x509' registered
[    0.696811] Freeing initrd memory: 8384K
[    0.703131] Block layer SCSI generic (bsg) driver version 0.4 loaded 
(major 249)
[    0.703202] io scheduler mq-deadline registered
[    0.703206] io scheduler kyber registered
[    0.703225] io scheduler bfq registered
[    0.706820] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    0.707043] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[    0.707976] ACPI: button: Power Button [PWRF]
[    0.708071] Warning: Processor Platform Limit event detected, but not 
handled.
[    0.708074] Consider compiling CPUfreq support into your kernel.
[    0.709585] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
[    0.709711] 00:00: ttyS0 at MMIO 0x1fe001e0 (irq = 34, base_baud = 
6250000) is a ST16650
[    0.709729] printk: legacy console [ttyS0] enabled
[    3.122634] 00:01: ttyS1 at MMIO 0x10080000 (irq = 35, base_baud = 
3125000) is a ST16650
[    3.130855] 00:02: ttyS2 at MMIO 0x10080100 (irq = 35, base_baud = 
3125000) is a ST16650
[    3.139065] 00:03: ttyS3 at MMIO 0x10080200 (irq = 35, base_baud = 
3125000) is a ST16650
[    3.147277] 00:04: ttyS4 at MMIO 0x10080300 (irq = 35, base_baud = 
3125000) is a ST16650
[    3.156772] ACPI: bus type drm_connector registered
[    3.161768] loongson 0000:00:06.1: Found LS7A2000 bridge chipset, 
revision: 16
[    3.169011] loongson 0000:00:06.1: [drm] dc: 400MHz, gmc: 800MHz, 
gpu: 533MHz
[    3.176116] loongson 0000:00:06.1: [drm] Dedicated vram start: 
0x40000000, size: 256MiB
[    3.184263] loongson 0000:00:06.1: [drm] VRAM: 16384 pages ready
[    3.190238] loongson 0000:00:06.1: [drm] GTT: 32768 pages ready
[    3.196202] loongson 0000:00:06.1: [drm] lsdc-i2c0(sda pin mask=1, 
scl pin mask=2) created
[    3.204457] loongson 0000:00:06.1: [drm] lsdc-i2c1(sda pin mask=4, 
scl pin mask=8) created
[    3.212683] loongson 0000:00:06.1: [drm] display pipe-0 has HDMI 
and/or VGA
[    3.219609] loongson 0000:00:06.1: [drm] display pipe-1 has HDMI
[    3.225692] loongson 0000:00:06.1: [drm] Total 2 outputs
[    3.271100] loongson 0000:00:06.1: [drm] registered irq: 42
[    3.276958] [drm] Initialized loongson 1.0.0 20220701 for 
0000:00:06.1 on minor 0
[    3.393066] loongson 0000:00:06.1: [drm] *ERROR* Setting HDMI-1 PLL 
failed
[    3.488719] Console: switching to colour frame buffer device 128x48
[    3.547883] loongson 0000:00:06.1: [drm] fb0: loongsondrmfb frame 
buffer device
[    3.562239] brd: module loaded
[    3.567569] loop: module loaded
[    3.570914] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 
EST 2006)
[    3.578272] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 
2006)
[    3.585249] megasas: 07.727.03.00-rc1
[    3.588930] mpt3sas version 48.100.00.00 loaded
[    3.613177] ahci 0000:00:08.0: version 3.0
[    3.613235] ahci 0000:00:08.0: SSS flag set, parallel bus scan disabled
[    3.619836] ahci 0000:00:08.0: AHCI vers 0001.0300, 32 command slots, 
6 Gbps, SATA mode
[    3.627819] ahci 0000:00:08.0: 2/2 ports implemented (port mask 0x3)
[    3.634137] ahci 0000:00:08.0: flags: 64bit ncq sntf stag pm led clo 
only pmp pio slum part ccc apst
[    3.643751] scsi host0: ahci
[    3.646803] scsi host1: ahci
[    3.649743] ata1: SATA max UDMA/133 abar m1024@0x512b4800 port 
0x512b4900 irq 43 lpm-pol 0
[    3.657969] ata2: SATA max UDMA/133 abar m1024@0x512b4800 port 
0x512b4980 irq 43 lpm-pol 0
[    3.667006] e1000: Intel(R) PRO/1000 Network Driver
[    3.671856] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    3.677585] e1000e: Intel(R) PRO/1000 Network Driver
[    3.682518] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    3.688423] igb: Intel(R) Gigabit Ethernet Network Driver
[    3.693789] igb: Copyright (c) 2007-2014 Intel Corporation.
[    3.699343] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver
[    3.705398] ixgbe: Copyright (c) 1999-2016 Intel Corporation.
[    3.711438] dwmac-loongson-pci 0000:00:03.0: User ID: 0xd1, Synopsys 
ID: 0x10
[    3.718543] dwmac-loongson-pci 0000:00:03.0: DMA HW capability 
register supported
[    3.725993] dwmac-loongson-pci 0000:00:03.0: RX Checksum Offload 
Engine supported
[    3.733439] dwmac-loongson-pci 0000:00:03.0: COE Type 2
[    3.738635] dwmac-loongson-pci 0000:00:03.0: TX Checksum insertion 
supported
[    3.745641] dwmac-loongson-pci 0000:00:03.0: Wake-Up On Lan supported
[    3.752045] dwmac-loongson-pci 0000:00:03.0: Enhanced/Alternate 
descriptors
[    3.758968] dwmac-loongson-pci 0000:00:03.0: Enabled extended descriptors
[    3.765715] dwmac-loongson-pci 0000:00:03.0: Ring mode enabled
[    3.771517] dwmac-loongson-pci 0000:00:03.0: Enable RX Mitigation via 
HW Watchdog Timer
[    3.779480] dwmac-loongson-pci 0000:00:03.0: device MAC address 
aa:ee:21:fb:67:ac
[    3.789812] mdio_bus stmmac-18:02: attached PHY driver [unbound] 
(mii_bus:phy_addr=stmmac-18:02, irq=POLL)
[    3.800170] dwmac-loongson-pci 0000:00:03.1: User ID: 0xd1, Synopsys 
ID: 0x10
[    3.807296] dwmac-loongson-pci 0000:00:03.1: DMA HW capability 
register supported
[    3.814741] dwmac-loongson-pci 0000:00:03.1: RX Checksum Offload 
Engine supported
[    3.822191] dwmac-loongson-pci 0000:00:03.1: COE Type 2
[    3.827392] dwmac-loongson-pci 0000:00:03.1: TX Checksum insertion 
supported
[    3.834404] dwmac-loongson-pci 0000:00:03.1: Wake-Up On Lan supported
[    3.840814] dwmac-loongson-pci 0000:00:03.1: Enhanced/Alternate 
descriptors
[    3.847735] dwmac-loongson-pci 0000:00:03.1: Enabled extended descriptors
[    3.854487] dwmac-loongson-pci 0000:00:03.1: Ring mode enabled
[    3.860283] dwmac-loongson-pci 0000:00:03.1: Enable RX Mitigation via 
HW Watchdog Timer
[    3.868244] dwmac-loongson-pci 0000:00:03.1: device MAC address 
5e:ee:cb:23:62:f9
[    3.878410] mdio_bus stmmac-19:02: attached PHY driver [unbound] 
(mii_bus:phy_addr=stmmac-19:02, irq=POLL)
[    3.888777] dwmac-loongson-pci 0000:00:03.2: User ID: 0xd1, Synopsys 
ID: 0x10
[    3.895894] dwmac-loongson-pci 0000:00:03.2: DMA HW capability 
register supported
[    3.903355] dwmac-loongson-pci 0000:00:03.2: RX Checksum Offload 
Engine supported
[    3.910803] dwmac-loongson-pci 0000:00:03.2: COE Type 2
[    3.916008] dwmac-loongson-pci 0000:00:03.2: TX Checksum insertion 
supported
[    3.923027] dwmac-loongson-pci 0000:00:03.2: Wake-Up On Lan supported
[    3.929452] dwmac-loongson-pci 0000:00:03.2: Enhanced/Alternate 
descriptors
[    3.936382] dwmac-loongson-pci 0000:00:03.2: Enabled extended descriptors
[    3.943138] dwmac-loongson-pci 0000:00:03.2: Ring mode enabled
[    3.948940] dwmac-loongson-pci 0000:00:03.2: Enable RX Mitigation via 
HW Watchdog Timer
[    3.956915] dwmac-loongson-pci 0000:00:03.2: device MAC address 
2e:38:a1:7d:5e:af
[    3.974895] YT8531 Gigabit Ethernet stmmac-1a:00: attached PHY driver 
(mii_bus:phy_addr=stmmac-1a:00, irq=POLL)
[    3.984956] ata1: SATA link down (SStatus 0 SControl 300)
[    3.991260] xhci_hcd 0000:00:04.0: xHCI Host Controller
[    3.996529] xhci_hcd 0000:00:04.0: new USB bus registered, assigned 
bus number 1
[    4.004015] xhci_hcd 0000:00:04.0: USB3 root hub has no ports
[    4.009737] xhci_hcd 0000:00:04.0: hcc params 0x0230fe65 hci version 
0x110 quirks 0x0000000000000010
[    4.018968] xhci_hcd 0000:00:04.0: xHCI Host Controller
[    4.024241] xhci_hcd 0000:00:04.0: new USB bus registered, assigned 
bus number 2
[    4.031619] xhci_hcd 0000:00:04.0: Host supports USB 3.0 SuperSpeed
[    4.037912] usb usb1: string descriptor 0 read error: -22
[    4.043502] hub 1-0:1.0: USB hub found
[    4.047242] hub 1-0:1.0: 4 ports detected
[    4.051761] usb usb2: We don't know the algorithms for LPM for this 
host, disabling LPM.
[    4.059839] usb usb2: string descriptor 0 read error: -22
[    4.065378] hub 2-0:1.0: USB hub found
[    4.069121] hub 2-0:1.0: config failed, hub doesn't have any ports! 
(err -19)
[    4.076403] xhci_hcd 0000:00:19.0: xHCI Host Controller
[    4.081715] xhci_hcd 0000:00:19.0: new USB bus registered, assigned 
bus number 3
[    4.089187] xhci_hcd 0000:00:19.0: hcc params 0x0238fe6d hci version 
0x110 quirks 0x0000000000000010
[    4.098406] xhci_hcd 0000:00:19.0: xHCI Host Controller
[    4.103666] xhci_hcd 0000:00:19.0: new USB bus registered, assigned 
bus number 4
[    4.111031] xhci_hcd 0000:00:19.0: Host supports USB 3.0 SuperSpeed
[    4.117298] usb usb3: string descriptor 0 read error: -22
[    4.122831] hub 3-0:1.0: USB hub found
[    4.126573] hub 3-0:1.0: 4 ports detected
[    4.130756] usb usb4: We don't know the algorithms for LPM for this 
host, disabling LPM.
[    4.138833] usb usb4: string descriptor 0 read error: -22
[    4.144357] hub 4-0:1.0: USB hub found
[    4.148095] hub 4-0:1.0: 4 ports detected
[    4.152337] usbcore: registered new interface driver usb-storage
[    4.158349] i8042: PNP: No PS/2 controller found.
[    4.163155] mousedev: PS/2 mouse device common for all mice
[    4.171054] rtc-efi rtc-efi.0: registered as rtc0
[    4.176193] rtc-efi rtc-efi.0: setting system clock to 
2024-07-05T11:17:45 UTC (1720178265)
[    4.187282] loongson-rtc LOON0001:00: registered as rtc1
[    4.192591] i2c_dev: i2c /dev entries driver
[    4.199616] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) 
initialised: dm-devel@lists.linux.dev
[    4.208469] hid: raw HID events driver (C) Jiri Kosina
[    4.213617] usbcore: registered new interface driver usbhid
[    4.219158] usbhid: USB HID core driver
[    4.223261] snd_hda_intel 0000:00:06.2: Force to snoop mode by module 
option
[    4.230390] snd_hda_intel 0000:00:07.0: Force to snoop mode by module 
option
[    4.237601] Initializing XFRM netlink socket
[    4.241883] NET: Registered PF_INET6 protocol family
[    4.247402] Segment Routing with IPv6
[    4.248772] input: HDA Loongson HDMI/DP,pcm=3 as 
/devices/pci0000:00/0000:00:06.2/sound/card0/input1
[    4.251063] In-situ OAM (IOAM) with IPv6
[    4.260527] input: HDA Loongson HDMI/DP,pcm=7 as 
/devices/pci0000:00/0000:00:06.2/sound/card0/input2
[    4.264067] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    4.279247] NET: Registered PF_PACKET protocol family
[    4.284274] NET: Registered PF_KEY protocol family
[    4.289199] NET: Registered PF_RDS protocol family
[    4.293979] 9pnet: Installing 9P2000 support
[    4.298250] Key type dns_resolver registered
[    4.308694] Timer migration: 1 hierarchy levels; 8 children per 
group; 1 crossnode level
[    4.316790] registered taskstats version 1
[    4.320908] Loading compiled-in X.509 certificates
[    4.323001] usb 1-2: new high-speed USB device number 2 using xhci_hcd
[    4.332207] Demotion targets for Node 0: null
[    4.337195] Btrfs loaded, zoned=yes, fsverity=no
[    4.338508] snd_hda_intel 0000:00:07.0: CORB reset timeout#2, CORBRP 
= 65535
[    4.348834] ata2: SATA link down (SStatus 0 SControl 300)
[    4.348854] hdaudio hdaudioC1D0: no AFG or MFG node found
[    4.359682] hdaudio hdaudioC1D1: no AFG or MFG node found
[    4.365065] hdaudio hdaudioC1D2: no AFG or MFG node found
[    4.370452] hdaudio hdaudioC1D3: no AFG or MFG node found
[    4.375835] snd_hda_intel 0000:00:07.0: no codecs initialized
[    4.395001] usb 3-1: new low-speed USB device number 2 using xhci_hcd
[    4.495445] usb 1-2: string descriptor 0 read error: -22
[    4.507691] usb-storage 1-2:1.0: USB Mass Storage device detected
[    4.527001] scsi host2: usb-storage 1-2:1.0
[    4.571348] usb 3-1: string descriptor 0 read error: -22
[    4.602284] input: HID 0c45:760b as 
/devices/pci0000:00/0000:00:19.0/usb3/3-1/3-1:1.0/0003:0C45:760B.0001/input/input3
[    4.670996] usb 1-4: new low-speed USB device number 3 using xhci_hcd
[    4.677658] hid-generic 0003:0C45:760B.0001: input,hidraw0: USB HID 
v1.11 Keyboard [HID 0c45:760b] on usb-0000:00:19.0-1/input0
[    4.689374] clk: Disabling unused clocks
[    4.693078] input: HID 0c45:760b Consumer Control as 
/devices/pci0000:00/0000:00:19.0/usb3/3-1/3-1:1.1/0003:0C45:760B.0002/input/input4
[    4.693309] ALSA device list:
[    4.708323]   #0: HDA Loongson at 0x51260000 irq 49
[    4.713363] Freeing unused kernel image (initmem) memory: 640K
[    4.719162] This architecture does not have kernel memory protection.
[    4.725571] Run /init as init process
[    4.729211]   with arguments:
[    4.729214]     /init
[    4.729216]   with environment:
[    4.729219]     HOME=/
[    4.729221]     TERM=linux
[    4.729223]     BOOT_IMAGE=/boot/vmlinuz-5.x
[    4.765047] input: HID 0c45:760b System Control as 
/devices/pci0000:00/0000:00:19.0/usb3/3-1/3-1:1.1/0003:0C45:760B.0002/input/input5
[    4.777419] hid-generic 0003:0C45:760B.0002: input,hidraw1: USB HID 
v1.11 Device [HID 0c45:760b] on usb-0000:00:19.0-1/input1
[    4.837150] usb 1-4: string descriptor 0 read error: -22
[    4.873736] input: HID 10c4:8105 as 
/devices/pci0000:00/0000:00:04.0/usb1/1-4/1-4:1.0/0003:10C4:8105.0003/input/input6
[    4.885086] hid-generic 0003:10C4:8105.0003: input,hidraw2: USB HID 
v1.11 Mouse [HID 10c4:8105] on usb-0000:00:04.0-4/input0
[    5.575938] scsi 2:0:0:0: Direct-Access     SanDisk  USB Flash Drive  
1.00 PQ: 0 ANSI: 6
[    5.584592] scsi 2:0:0:0: Attached scsi generic sg0 type 0
[    5.599073] sd 2:0:0:0: [sda] 120127488 512-byte logical blocks: 
(61.5 GB/57.3 GiB)
[    5.613043] sd 2:0:0:0: [sda] Write Protect is off
[    5.617810] sd 2:0:0:0: [sda] Mode Sense: 43 00 00 00
[    5.626557] sd 2:0:0:0: [sda] Write cache: disabled, read cache: 
enabled, doesn't support DPO or FUA
[    5.655313]  sda: sda1 sda2
[    5.659180] sd 2:0:0:0: [sda] Attached SCSI removable disk
[    6.918950] EXT4-fs (sda2): mounted filesystem 
1ecbf33b-86de-4870-9171-9019c5ed78b3 r/w with ordered data mode. Quota 
mode: none.
[   10.047571] systemd[1]: systemd 253.5-2-arch running in system mode 
(+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS 
+OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD 
+LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 
+BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT 
default-hierarchy=unified)
[   10.079758] systemd[1]: Detected architecture loongarch64.
[   10.191099] systemd[1]: Hostname set to <archlinux>.
[   10.443126] systemd[1]: bpf-lsm: BPF LSM hook not enabled in the 
kernel, BPF LSM not supported
[   10.971483] systemd[1]: Queued start job for default target Graphical 
Interface.
[   11.020663] systemd[1]: Created slice Slice /system/getty.
[   11.043651] systemd[1]: Created slice Slice /system/modprobe.
[   11.067600] systemd[1]: Created slice Slice /system/serial-getty.
[   11.091488] systemd[1]: Created slice User and Session Slice.
[   11.115141] systemd[1]: Started Dispatch Password Requests to Console 
Directory Watch.
[   11.143103] systemd[1]: Started Forward Password Requests to Wall 
Directory Watch.
[   11.167330] systemd[1]: Set up automount Arbitrary Executable File 
Formats File System Automount Point.
[   11.195087] systemd[1]: Reached target Local Encrypted Volumes.
[   11.219062] systemd[1]: Reached target Local Integrity Protected Volumes.
[   11.243059] systemd[1]: Reached target Path Units.
[   11.255000] random: crng init done
[   11.263067] systemd[1]: Reached target Remote File Systems.
[   11.283162] systemd[1]: Reached target Slice Units.
[   11.303153] systemd[1]: Reached target Swaps.
[   11.323169] systemd[1]: Reached target Local Verity Protected Volumes.
[   11.347228] systemd[1]: Listening on Device-mapper event daemon FIFOs.
[   11.385279] systemd[1]: Listening on Process Core Dump Socket.
[   11.407251] systemd[1]: Listening on Journal Socket (/dev/log).
[   11.431233] systemd[1]: Listening on Journal Socket.
[   11.456311] systemd[1]: Listening on udev Control Socket.
[   11.479198] systemd[1]: Listening on udev Kernel Socket.
[   11.519136] systemd[1]: Mounting Huge Pages File System...
[   11.540734] systemd[1]: Mounting POSIX Message Queue File System...
[   11.564711] systemd[1]: Mounting Kernel Debug File System...
[   11.587218] systemd[1]: Kernel Trace File System was skipped because 
of an unmet condition check (ConditionPathExists=/sys/kernel/tracing).
[   11.627137] systemd[1]: Mounting Temporary Directory /tmp...
[   11.649000] systemd[1]: Starting Create List of Static Device Nodes...
[   11.687203] systemd[1]: Starting Load Kernel Module configfs...
[   11.708917] systemd[1]: Starting Load Kernel Module dm_mod...
[   11.751239] systemd[1]: Starting Load Kernel Module drm...
[   11.772925] systemd[1]: Starting Load Kernel Module fuse...
[   11.798154] fuse: init (API version 7.40)
[   11.811252] systemd[1]: Starting Load Kernel Module loop...
[   11.831221] systemd[1]: File System Check on Root Device was skipped 
because of an unmet condition check (ConditionPathIsReadWrite=!/).
[   11.846403] systemd[1]: Starting Journal Service...
[   11.873566] systemd[1]: Load Kernel Modules was skipped because no 
trigger condition checks were met.
[   11.882959] systemd[1]: TPM2 PCR Machine ID Measurement was skipped 
because of an unmet condition check 
(ConditionPathExists=/sys/firmware/efi/efivars/StubPcrKernelImage-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f).
[   11.903720] systemd-journald[200]: Collecting audit messages is disabled.
[   11.915397] systemd[1]: Starting Remount Root and Kernel File Systems...
[   11.932929] systemd[1]: Starting Apply Kernel Variables...
[   11.956991] systemd[1]: Starting Coldplug All udev Devices...
[   11.963448] EXT4-fs (sda2): re-mounted 
1ecbf33b-86de-4870-9171-9019c5ed78b3 r/w. Quota mode: none.
[   11.991703] systemd[1]: Mounted Huge Pages File System.
[   12.011460] systemd[1]: Started Journal Service.
[   12.296620] systemd-journald[200]: Received client request to flush 
runtime journal.
[   12.597780] systemd-journald[200]: 
/var/log/journal/7eb17db7fefc4d3b8010606a2401cee5/system.journal: 
Monotonic clock jumped backwards relative to last journal entry, rotating.
[   12.613378] systemd-journald[200]: Rotating system journal.
[   13.356420] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: renamed from eth1
[   13.368678] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: renamed from eth0
[   13.405276] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: renamed from eth2
[   13.544990] loongson-spi-pci 0000:00:16.0: can't derive routing for 
PCI INT A
[   13.552166] loongson-spi-pci 0000:00:16.0: PCI INT A: no GSI
[   13.683351] usbcore: registered new interface driver uas
[   13.740110] pstore: Using crash dump compression: deflate
[   13.745506] pstore: Registered efi_pstore as persistent store backend
[   14.239611] FAT-fs (sda1): Volume was not properly unmounted. Some 
data may be corrupt. Please run fsck.
[   16.257892] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register 
MEM_TYPE_PAGE_POOL RxQ-0
[   16.266096] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register 
MEM_TYPE_PAGE_POOL RxQ-1
[   16.274199] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register 
MEM_TYPE_PAGE_POOL RxQ-2
[   16.282258] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register 
MEM_TYPE_PAGE_POOL RxQ-3
[   16.290336] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register 
MEM_TYPE_PAGE_POOL RxQ-4
[   16.298461] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register 
MEM_TYPE_PAGE_POOL RxQ-5
[   16.306519] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register 
MEM_TYPE_PAGE_POOL RxQ-6
[   16.314567] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register 
MEM_TYPE_PAGE_POOL RxQ-7
[   16.324050] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: PHY 
[stmmac-18:02] driver [Generic PHY] (irq=POLL)
[   16.343589] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: No Safety 
Features support found
[   16.351552] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: IEEE 1588-2008 
Advanced Timestamp supported
[   16.360581] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: registered PTP 
clock
[   16.367439] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: configuring for 
phy/gmii link mode
[   16.382079] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register 
MEM_TYPE_PAGE_POOL RxQ-0
[   16.390170] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register 
MEM_TYPE_PAGE_POOL RxQ-1
[   16.398229] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register 
MEM_TYPE_PAGE_POOL RxQ-2
[   16.406279] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register 
MEM_TYPE_PAGE_POOL RxQ-3
[   16.414351] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register 
MEM_TYPE_PAGE_POOL RxQ-4
[   16.422422] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register 
MEM_TYPE_PAGE_POOL RxQ-5
[   16.430504] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register 
MEM_TYPE_PAGE_POOL RxQ-6
[   16.438555] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register 
MEM_TYPE_PAGE_POOL RxQ-7
[   16.448025] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: PHY 
[stmmac-19:02] driver [Generic PHY] (irq=POLL)
[   16.467550] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: No Safety 
Features support found
[   16.475464] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: IEEE 1588-2008 
Advanced Timestamp supported
[   16.484478] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: registered PTP 
clock
[   16.491354] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: configuring for 
phy/gmii link mode
[   16.506012] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register 
MEM_TYPE_PAGE_POOL RxQ-0
[   16.514105] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register 
MEM_TYPE_PAGE_POOL RxQ-1
[   16.522167] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register 
MEM_TYPE_PAGE_POOL RxQ-2
[   16.530235] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register 
MEM_TYPE_PAGE_POOL RxQ-3
[   16.538288] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register 
MEM_TYPE_PAGE_POOL RxQ-4
[   16.546331] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register 
MEM_TYPE_PAGE_POOL RxQ-5
[   16.554379] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register 
MEM_TYPE_PAGE_POOL RxQ-6
[   16.562424] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register 
MEM_TYPE_PAGE_POOL RxQ-7
[   16.571852] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: PHY 
[stmmac-1a:00] driver [YT8531 Gigabit Ethernet] (irq=POLL)
[   16.582549] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: No Safety 
Features support found
[   16.590745] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: IEEE 1588-2008 
Advanced Timestamp supported
[   16.599830] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: registered PTP 
clock
[   16.607330] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: configuring for 
phy/rgmii-id link mode
[   16.618296] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Link is Up - 
1Gbps/Full - flow control off
[  329.951433] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Link is Down
[  332.832685] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Link is Up - 
1Gbps/Full - flow control off
[  333.855327] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Link is Down
[  336.928480] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Link is Up - 
1Gbps/Full - flow control off
[  349.215440] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Link is Down
[  351.456477] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Link is Up - 
1Gbps/Full - flow control off

The device(7a03 and 7a13) can access the network.

$: cat /proc/interrupts

            CPU0       CPU1
  20:       3826      12138   CPUINTC  12  IPI
  21:      15242      11791   CPUINTC  11  timer
  22:          0          0   PCH PIC   1  acpi
  28:          0          0   PCH PIC   7  loongson-alarm
  29:          0          0   PCH PIC   8  ls2x-i2c, ls2x-i2c, ls2x-i2c, 
ls2x-i2c, ls2x-i2c, ls2x-i2c
  34:       7456          0   LIOINTC  10  ttyS0
  42:       1192          0   PCH PIC  17  0000:00:06.1
  43:          0          0   PCH PIC  18  ahci[0000:00:08.0]
  44:         40          0   PCH PIC  19  enp0s3f0
  45:          0          0   PCH PIC  20  enp0s3f1
  46:       1446          0   PCH PIC  21  enp0s3f2
  47:      11164          0   PCH PIC  22  xhci-hcd:usb1
  48:        338          0   PCH PIC  23  xhci-hcd:usb3
  49:          0          0   PCH PIC  24  snd_hda_intel:card0
IPI0:       117        132  LoongArch  1  Rescheduling interrupts
IPI1:      3713      12007  LoongArch  2  Function call interrupts
ERR:          1



Thanks,

Yanteng

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

[Russell King (Oracle)]

On Fri, Jul 05, 2024 at 07:17:01PM +0800, Yanteng Si wrote:
> 在 2024/7/4 04:33, Russell King (Oracle) 写道:
> > I think we should "lie" to userspace rather than report how the
> > hardware was actually programmed - again, because that's what would
> > happen with Marvell Alaska.
> > 
> > > What about other speeds? Is this limited to 1G? Since we have devices
> > > without auto-neg for 2500BaseX i assume it is not an issue there.
> > 1000base-X can have AN disabled - that's not an issue. Yes, there's
> > the ongoing issues with 2500base-X. 10Gbase-T wording is similar to
> > 1000base-T, so we probably need to do similar there. Likely also the
> > case for 2500base-T and 5000base-T as well.
> > 
> > So I'm thinking of something like this (untested):
> > 
> > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> > index 6c6ec9475709..197c4d5ab55b 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -2094,22 +2094,20 @@ EXPORT_SYMBOL(phy_reset_after_clk_enable);
> >   /**
> >    * genphy_config_advert - sanitize and advertise auto-negotiation parameters
> >    * @phydev: target phy_device struct
> > + * @advert: auto-negotiation parameters to advertise
> >    *
> >    * Description: Writes MII_ADVERTISE with the appropriate values,
> >    *   after sanitizing the values to make sure we only advertise
> >    *   what is supported.  Returns < 0 on error, 0 if the PHY's advertisement
> >    *   hasn't changed, and > 0 if it has changed.
> >    */
> > -static int genphy_config_advert(struct phy_device *phydev)
> > +static int genphy_config_advert(struct phy_device *phydev,
> > +				const unsigned long *advert)
> >   {
> >   	int err, bmsr, changed = 0;
> >   	u32 adv;
> > -	/* Only allow advertising what this PHY supports */
> > -	linkmode_and(phydev->advertising, phydev->advertising,
> > -		     phydev->supported);
> > -
> > -	adv = linkmode_adv_to_mii_adv_t(phydev->advertising);
> > +	adv = linkmode_adv_to_mii_adv_t(advert);
> >   	/* Setup standard advertisement */
> >   	err = phy_modify_changed(phydev, MII_ADVERTISE,
> > @@ -2132,7 +2130,7 @@ static int genphy_config_advert(struct phy_device *phydev)
> >   	if (!(bmsr & BMSR_ESTATEN))
> >   		return changed;
> > -	adv = linkmode_adv_to_mii_ctrl1000_t(phydev->advertising);
> > +	adv = linkmode_adv_to_mii_ctrl1000_t(advert);
> >   	err = phy_modify_changed(phydev, MII_CTRL1000,
> >   				 ADVERTISE_1000FULL | ADVERTISE_1000HALF,
> > @@ -2356,6 +2354,9 @@ EXPORT_SYMBOL(genphy_check_and_restart_aneg);
> >    */
> >   int __genphy_config_aneg(struct phy_device *phydev, bool changed)
> >   {
> > +	__ETHTOOL_DECLARE_LINK_MODE_MASK(fixed_advert);
> > +	const struct phy_setting *set;
> > +	unsigned long *advert;
> >   	int err;
> >   	err = genphy_c45_an_config_eee_aneg(phydev);
> > @@ -2370,10 +2371,25 @@ int __genphy_config_aneg(struct phy_device *phydev, bool changed)
> >   	else if (err)
> >   		changed = true;
> > -	if (AUTONEG_ENABLE != phydev->autoneg)
> > +	if (phydev->autoneg == AUTONEG_ENABLE) {
> > +		/* Only allow advertising what this PHY supports */
> > +		linkmode_and(phydev->advertising, phydev->advertising,
> > +			     phydev->supported);
> > +		advert = phydev->advertising;
> > +	} else if (phydev->speed < SPEED_1000) {
> >   		return genphy_setup_forced(phydev);
> > +	} else {
> > +		linkmode_zero(fixed_advert);
> > +
> > +		set = phy_lookup_setting(phydev->speed, phydev->duplex,
> > +					 phydev->supported, true);
> > +		if (set)
> > +			linkmode_set(set->bit, fixed_advert);
> > +
> > +		advert = fixed_advert;
> > +	}
> > -	err = genphy_config_advert(phydev);
> > +	err = genphy_config_advert(phydev, advert);
> >   	if (err < 0) /* error */
> >   		return err;
> >   	else if (err)
> 
> It looks great, but I still want to follow Russell's earlier advice and drop
> this patch
> 
> from v14, then submit it separately with the above code.

If the above change is made to phylib, then drivers do not need any
changes other than removing such workarounds detecting !AN with
speed = 1G.

The point of the above change is that drivers shouldn't be doing
anything and the issue should be handled entirely within phylib.

-- 
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 v13 12/15] net: stmmac: Fixed failure to set network speed to 1000.

[Yanteng Si]

在 2024/7/5 19:31, Russell King (Oracle) 写道:
> On Fri, Jul 05, 2024 at 07:17:01PM +0800, Yanteng Si wrote:
>> 在 2024/7/4 04:33, Russell King (Oracle) 写道:
>>> I think we should "lie" to userspace rather than report how the
>>> hardware was actually programmed - again, because that's what would
>>> happen with Marvell Alaska.
>>>
>>>> What about other speeds? Is this limited to 1G? Since we have devices
>>>> without auto-neg for 2500BaseX i assume it is not an issue there.
>>> 1000base-X can have AN disabled - that's not an issue. Yes, there's
>>> the ongoing issues with 2500base-X. 10Gbase-T wording is similar to
>>> 1000base-T, so we probably need to do similar there. Likely also the
>>> case for 2500base-T and 5000base-T as well.
>>>
>>> So I'm thinking of something like this (untested):
>>>
>>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>>> index 6c6ec9475709..197c4d5ab55b 100644
>>> --- a/drivers/net/phy/phy_device.c
>>> +++ b/drivers/net/phy/phy_device.c
>>> @@ -2094,22 +2094,20 @@ EXPORT_SYMBOL(phy_reset_after_clk_enable);
>>>    /**
>>>     * genphy_config_advert - sanitize and advertise auto-negotiation parameters
>>>     * @phydev: target phy_device struct
>>> + * @advert: auto-negotiation parameters to advertise
>>>     *
>>>     * Description: Writes MII_ADVERTISE with the appropriate values,
>>>     *   after sanitizing the values to make sure we only advertise
>>>     *   what is supported.  Returns < 0 on error, 0 if the PHY's advertisement
>>>     *   hasn't changed, and > 0 if it has changed.
>>>     */
>>> -static int genphy_config_advert(struct phy_device *phydev)
>>> +static int genphy_config_advert(struct phy_device *phydev,
>>> +				const unsigned long *advert)
>>>    {
>>>    	int err, bmsr, changed = 0;
>>>    	u32 adv;
>>> -	/* Only allow advertising what this PHY supports */
>>> -	linkmode_and(phydev->advertising, phydev->advertising,
>>> -		     phydev->supported);
>>> -
>>> -	adv = linkmode_adv_to_mii_adv_t(phydev->advertising);
>>> +	adv = linkmode_adv_to_mii_adv_t(advert);
>>>    	/* Setup standard advertisement */
>>>    	err = phy_modify_changed(phydev, MII_ADVERTISE,
>>> @@ -2132,7 +2130,7 @@ static int genphy_config_advert(struct phy_device *phydev)
>>>    	if (!(bmsr & BMSR_ESTATEN))
>>>    		return changed;
>>> -	adv = linkmode_adv_to_mii_ctrl1000_t(phydev->advertising);
>>> +	adv = linkmode_adv_to_mii_ctrl1000_t(advert);
>>>    	err = phy_modify_changed(phydev, MII_CTRL1000,
>>>    				 ADVERTISE_1000FULL | ADVERTISE_1000HALF,
>>> @@ -2356,6 +2354,9 @@ EXPORT_SYMBOL(genphy_check_and_restart_aneg);
>>>     */
>>>    int __genphy_config_aneg(struct phy_device *phydev, bool changed)
>>>    {
>>> +	__ETHTOOL_DECLARE_LINK_MODE_MASK(fixed_advert);
>>> +	const struct phy_setting *set;
>>> +	unsigned long *advert;
>>>    	int err;
>>>    	err = genphy_c45_an_config_eee_aneg(phydev);
>>> @@ -2370,10 +2371,25 @@ int __genphy_config_aneg(struct phy_device *phydev, bool changed)
>>>    	else if (err)
>>>    		changed = true;
>>> -	if (AUTONEG_ENABLE != phydev->autoneg)
>>> +	if (phydev->autoneg == AUTONEG_ENABLE) {
>>> +		/* Only allow advertising what this PHY supports */
>>> +		linkmode_and(phydev->advertising, phydev->advertising,
>>> +			     phydev->supported);
>>> +		advert = phydev->advertising;
>>> +	} else if (phydev->speed < SPEED_1000) {
>>>    		return genphy_setup_forced(phydev);
>>> +	} else {
>>> +		linkmode_zero(fixed_advert);
>>> +
>>> +		set = phy_lookup_setting(phydev->speed, phydev->duplex,
>>> +					 phydev->supported, true);
>>> +		if (set)
>>> +			linkmode_set(set->bit, fixed_advert);
>>> +
>>> +		advert = fixed_advert;
>>> +	}
>>> -	err = genphy_config_advert(phydev);
>>> +	err = genphy_config_advert(phydev, advert);
>>>    	if (err < 0) /* error */
>>>    		return err;
>>>    	else if (err)
>> It looks great, but I still want to follow Russell's earlier advice and drop
>> this patch
>>
>> from v14, then submit it separately with the above code.
> If the above change is made to phylib, then drivers do not need any
> changes other than removing such workarounds detecting !AN with
> speed = 1G.
>
> The point of the above change is that drivers shouldn't be doing
> anything and the issue should be handled entirely within phylib.
>
OK, I see. I will try this after send v14(Maybe tomorrow, or next Monday).


Thanks,

Yanteng

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Serge Semin]

On Fri, Jul 05, 2024 at 07:29:23PM +0800, Yanteng Si wrote:
> 
> 在 2024/7/5 18:59, Serge Semin 写道:
> > On Fri, Jul 05, 2024 at 06:45:50PM +0800, Yanteng Si wrote:
> > > 在 2024/7/5 18:16, Serge Semin 写道:
> > > > > > Seeing the discussion has started anyway, could you please find out
> > > > > > whether the multi-channel controller will still work if the MSI IRQs
> > > > > > allocation failed? Will the multi-channel-ness still work in that
> > > > > > case?
> > > > > Based on my test results:
> > > > > 
> > > > > In this case, multi-channel controller don't work. If the MSI IRQs
> > > > > allocation
> > > > > 
> > > > > failed, NIC will work in single channel.
> > > > What does "NIC will work in single channel" mean? Do the driver
> > > > (network traffic flow with a normal performance) still work even with
> > > > the plat->tx_queues_to_use and plat->rx_queues_to_use fields set to
> > > > eight? If it's then the multi-channel-ness still seems to be working
> > > > but the IRQs are delivered via the common MAC IRQ. If you get to
> > > > experience the data loss, or poor performance, or no traffic flowing
> > > > at all, then indeed the non-zero channels IRQs aren't delivered.
> > > > 
> > > > So the main question how did you find out that the controller work in
> > > > single channel?
> > > sorry, I meant that if the MSI allocation failed, it will fallback to INTx,
> > > in which case
> > > 
> > > only the single channel works.  if the MSI allocation failed, the
> > > multi-channel-ness
> > > 
> > > don't work.
> > Could you please clarify what are the symptoms by which you figured
> > out that the "multi-channel-ness" didn't work?
> > 
> > Suppose you have an LS2K2000 SoC-based device, the
> > plat->tx_queues_to_use and plat->rx_queues_to_use to eight and the
> > loongson_dwmac_msi_config() function call is omitted. What is
> > happening with the activated network interface and with the traffic
> > flow then?
> 
> Ok, here are the results of my test in LS2K2000:
> 
> 
> v14 based.
> 
> $: git diff
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 25ddd99ae112..f05b600a19cf 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -576,11 +576,11 @@ static int loongson_dwmac_probe(struct pci_dev *pdev,
> const struct pci_device_id
>         if (ret)
>                 goto err_disable_device;
> 
> -       if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
> -               ret = loongson_dwmac_msi_config(pdev, plat, &res);
> -               if (ret)
> -                       goto err_disable_device;
> -       }
> +       // if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
> +               // ret = loongson_dwmac_msi_config(pdev, plat, &res);
> +               // if (ret)
> +                       // goto err_disable_device;
> +       // }

Ok. This makes the common MAC IRQ to be used for all controller
events. Let's see what was in your boot-test further.

> 
>         ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>         if (ret)
> 
> 
> boot on LS2K2000.
> 
> dmesg:
> 
> ...
> [    3.711438] dwmac-loongson-pci 0000:00:03.0: User ID: 0xd1, Synopsys ID:
> 0x10
> [    3.718543] dwmac-loongson-pci 0000:00:03.0: DMA HW capability register
> supported
> [    3.725993] dwmac-loongson-pci 0000:00:03.0: RX Checksum Offload Engine
> supported
> [    3.733439] dwmac-loongson-pci 0000:00:03.0: COE Type 2
> [    3.738635] dwmac-loongson-pci 0000:00:03.0: TX Checksum insertion
> supported
> [    3.745641] dwmac-loongson-pci 0000:00:03.0: Wake-Up On Lan supported
> [    3.752045] dwmac-loongson-pci 0000:00:03.0: Enhanced/Alternate
> descriptors
> [    3.758968] dwmac-loongson-pci 0000:00:03.0: Enabled extended descriptors
> [    3.765715] dwmac-loongson-pci 0000:00:03.0: Ring mode enabled
> [    3.771517] dwmac-loongson-pci 0000:00:03.0: Enable RX Mitigation via HW
> Watchdog Timer
> [    3.779480] dwmac-loongson-pci 0000:00:03.0: device MAC address
> aa:ee:21:fb:67:ac
> [    3.789812] mdio_bus stmmac-18:02: attached PHY driver [unbound]
> (mii_bus:phy_addr=stmmac-18:02, irq=POLL)
> [    3.800170] dwmac-loongson-pci 0000:00:03.1: User ID: 0xd1, Synopsys ID:
> 0x10
> [    3.807296] dwmac-loongson-pci 0000:00:03.1: DMA HW capability register
> supported
> [    3.814741] dwmac-loongson-pci 0000:00:03.1: RX Checksum Offload Engine
> supported
> [    3.822191] dwmac-loongson-pci 0000:00:03.1: COE Type 2
> [    3.827392] dwmac-loongson-pci 0000:00:03.1: TX Checksum insertion
> supported
> [    3.834404] dwmac-loongson-pci 0000:00:03.1: Wake-Up On Lan supported
> [    3.840814] dwmac-loongson-pci 0000:00:03.1: Enhanced/Alternate
> descriptors
> [    3.847735] dwmac-loongson-pci 0000:00:03.1: Enabled extended descriptors
> [    3.854487] dwmac-loongson-pci 0000:00:03.1: Ring mode enabled
> [    3.860283] dwmac-loongson-pci 0000:00:03.1: Enable RX Mitigation via HW
> Watchdog Timer
> [    3.868244] dwmac-loongson-pci 0000:00:03.1: device MAC address
> 5e:ee:cb:23:62:f9
> [    3.878410] mdio_bus stmmac-19:02: attached PHY driver [unbound]
> (mii_bus:phy_addr=stmmac-19:02, irq=POLL)
> [    3.888777] dwmac-loongson-pci 0000:00:03.2: User ID: 0xd1, Synopsys ID:
> 0x10
> [    3.895894] dwmac-loongson-pci 0000:00:03.2: DMA HW capability register
> supported
> [    3.903355] dwmac-loongson-pci 0000:00:03.2: RX Checksum Offload Engine
> supported
> [    3.910803] dwmac-loongson-pci 0000:00:03.2: COE Type 2
> [    3.916008] dwmac-loongson-pci 0000:00:03.2: TX Checksum insertion
> supported
> [    3.923027] dwmac-loongson-pci 0000:00:03.2: Wake-Up On Lan supported
> [    3.929452] dwmac-loongson-pci 0000:00:03.2: Enhanced/Alternate
> descriptors
> [    3.936382] dwmac-loongson-pci 0000:00:03.2: Enabled extended descriptors
> [    3.943138] dwmac-loongson-pci 0000:00:03.2: Ring mode enabled
> [    3.948940] dwmac-loongson-pci 0000:00:03.2: Enable RX Mitigation via HW
> Watchdog Timer
> [    3.956915] dwmac-loongson-pci 0000:00:03.2: device MAC address
> 2e:38:a1:7d:5e:af

> [    3.974895] YT8531 Gigabit Ethernet stmmac-1a:00: attached PHY driver
> (mii_bus:phy_addr=stmmac-1a:00, irq=POLL)

* The line from which we figured out your PHY vendor.)

>
> ...
>
> [   16.257892] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register
> MEM_TYPE_PAGE_POOL RxQ-0
> [   16.266096] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register
> MEM_TYPE_PAGE_POOL RxQ-1
> [   16.274199] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register
> MEM_TYPE_PAGE_POOL RxQ-2
> [   16.282258] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register
> MEM_TYPE_PAGE_POOL RxQ-3
> [   16.290336] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register
> MEM_TYPE_PAGE_POOL RxQ-4
> [   16.298461] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register
> MEM_TYPE_PAGE_POOL RxQ-5
> [   16.306519] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register
> MEM_TYPE_PAGE_POOL RxQ-6
> [   16.314567] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Register
> MEM_TYPE_PAGE_POOL RxQ-7
> [   16.324050] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: PHY [stmmac-18:02]
> driver [Generic PHY] (irq=POLL)
> [   16.343589] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: No Safety Features
> support found
> [   16.351552] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: IEEE 1588-2008
> Advanced Timestamp supported
> [   16.360581] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: registered PTP
> clock
> [   16.367439] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: configuring for
> phy/gmii link mode
> [   16.382079] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register
> MEM_TYPE_PAGE_POOL RxQ-0
> [   16.390170] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register
> MEM_TYPE_PAGE_POOL RxQ-1
> [   16.398229] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register
> MEM_TYPE_PAGE_POOL RxQ-2
> [   16.406279] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register
> MEM_TYPE_PAGE_POOL RxQ-3
> [   16.414351] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register
> MEM_TYPE_PAGE_POOL RxQ-4
> [   16.422422] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register
> MEM_TYPE_PAGE_POOL RxQ-5
> [   16.430504] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register
> MEM_TYPE_PAGE_POOL RxQ-6
> [   16.438555] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: Register
> MEM_TYPE_PAGE_POOL RxQ-7
> [   16.448025] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: PHY [stmmac-19:02]
> driver [Generic PHY] (irq=POLL)
> [   16.467550] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: No Safety Features
> support found
> [   16.475464] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: IEEE 1588-2008
> Advanced Timestamp supported
> [   16.484478] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: registered PTP
> clock
> [   16.491354] dwmac-loongson-pci 0000:00:03.1 enp0s3f1: configuring for
> phy/gmii link mode
> [   16.506012] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register
> MEM_TYPE_PAGE_POOL RxQ-0
> [   16.514105] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register
> MEM_TYPE_PAGE_POOL RxQ-1
> [   16.522167] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register
> MEM_TYPE_PAGE_POOL RxQ-2
> [   16.530235] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register
> MEM_TYPE_PAGE_POOL RxQ-3
> [   16.538288] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register
> MEM_TYPE_PAGE_POOL RxQ-4
> [   16.546331] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register
> MEM_TYPE_PAGE_POOL RxQ-5
> [   16.554379] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register
> MEM_TYPE_PAGE_POOL RxQ-6
> [   16.562424] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Register
> MEM_TYPE_PAGE_POOL RxQ-7
> [   16.571852] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: PHY [stmmac-1a:00]
> driver [YT8531 Gigabit Ethernet] (irq=POLL)
> [   16.582549] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: No Safety Features
> support found
> [   16.590745] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: IEEE 1588-2008
> Advanced Timestamp supported
> [   16.599830] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: registered PTP
> clock
> [   16.607330] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: configuring for
> phy/rgmii-id link mode
> [   16.618296] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Link is Up -
> 1Gbps/Full - flow control off
> [  329.951433] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Link is Down
> [  332.832685] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Link is Up -
> 1Gbps/Full - flow control off
> [  333.855327] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Link is Down
> [  336.928480] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Link is Up -
> 1Gbps/Full - flow control off
> [  349.215440] dwmac-loongson-pci 0000:00:03.0 enp0s3f0: Link is Down
> [  351.456477] dwmac-loongson-pci 0000:00:03.2 enp0s3f2: Link is Up -
> 1Gbps/Full - flow control off
> 
> The device(7a03 and 7a13) can access the network.
> 
> $: cat /proc/interrupts
> 
>            CPU0       CPU1
>  20:       3826      12138   CPUINTC  12  IPI
>  21:      15242      11791   CPUINTC  11  timer
>  22:          0          0   PCH PIC   1  acpi
>  28:          0          0   PCH PIC   7  loongson-alarm
>  29:          0          0   PCH PIC   8  ls2x-i2c, ls2x-i2c, ls2x-i2c,
> ls2x-i2c, ls2x-i2c, ls2x-i2c
>  34:       7456          0   LIOINTC  10  ttyS0
>  42:       1192          0   PCH PIC  17  0000:00:06.1
>  43:          0          0   PCH PIC  18  ahci[0000:00:08.0]
>  44:         40          0   PCH PIC  19  enp0s3f0
>  45:          0          0   PCH PIC  20  enp0s3f1
>  46:       1446          0   PCH PIC  21  enp0s3f2
>  47:      11164          0   PCH PIC  22  xhci-hcd:usb1
>  48:        338          0   PCH PIC  23  xhci-hcd:usb3
>  49:          0          0   PCH PIC  24  snd_hda_intel:card0
> IPI0:       117        132  LoongArch  1  Rescheduling interrupts
> IPI1:      3713      12007  LoongArch  2  Function call interrupts
> ERR:          1
> 
> 

So, what made you thinking that the enp0s3f0, enp0s3f1 and enp0s3f2
interfaces weren't working? I failed to find any immediate problem in
the log.

The driver registered eight Rx-queues (and likely eight Tx-queues).
enp0s3f0 and enp0s3f2 links got up. Even the log reported that two
interfaces have some network access (whatever it meant in your
boot-script):

> The device(7a03 and 7a13) can access the network.

Yes, there is only one IRQ registered for each interface. But that's
what was expected seeing you have a single MAC IRQ detected. The
main question is: do the network traffic still get to flow in this
case? Are you able to send/receive data over all the DMA-channels?

-Serge(y)

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

[Yanteng Si]

>>> But if you aren't comfortable with such naming we can change the
>>> macro to something like:
>>> #define DWMAC_CORE_LOONGSON_MULTI_CH    0x10
>> Maybe DWMAC_CORE_LOONGSON_MULTICHAN or DWMAC_CORE_LOONGSON_MULTI_CHAN
>> is a little better?
>>
> Well, I don't have a strong opinion about that in this case.
> Personally I prefer to have the shortest and still readable version.
> It decreases the probability of the lines splitting in case of the
> long-line statements or highly indented code. From that perspective
> something like DWMAC_CORE_LS_MULTI_CH would be even better. But seeing
> the driver currently don't have such cases, we can use any of those
> name. But it's better to be of such length so the code lines the name
> is utilized in wouldn't exceed +80 chars.

Okay.

I added an indent before 0xXX and left three Spaces before the comment,

which uses huacai's MULTICHAN and doesn't exceed 80 chars.


Thanks,

Yanteng

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

[Serge Semin]

On Fri, Jul 05, 2024 at 08:06:32PM +0800, Yanteng Si wrote:
> > > > But if you aren't comfortable with such naming we can change the
> > > > macro to something like:
> > > > #define DWMAC_CORE_LOONGSON_MULTI_CH    0x10
> > > Maybe DWMAC_CORE_LOONGSON_MULTICHAN or DWMAC_CORE_LOONGSON_MULTI_CHAN
> > > is a little better?
> > > 
> > Well, I don't have a strong opinion about that in this case.
> > Personally I prefer to have the shortest and still readable version.
> > It decreases the probability of the lines splitting in case of the
> > long-line statements or highly indented code. From that perspective
> > something like DWMAC_CORE_LS_MULTI_CH would be even better. But seeing
> > the driver currently don't have such cases, we can use any of those
> > name. But it's better to be of such length so the code lines the name
> > is utilized in wouldn't exceed +80 chars.
> 
> Okay.
> 
> I added an indent before 0xXX and left three Spaces before the comment,
> 
> which uses huacai's MULTICHAN and doesn't exceed 80 chars.

I meant that it's better to have the length of the macro name so
!the code where it's utilized!
wouldn't exceed +80 chars. That's the criteria for the upper length
boundary I normally follow in such cases.

-Serge

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

[Yanteng Si]

在 2024/7/5 20:17, Serge Semin 写道:
> On Fri, Jul 05, 2024 at 08:06:32PM +0800, Yanteng Si wrote:
>>>>> But if you aren't comfortable with such naming we can change the
>>>>> macro to something like:
>>>>> #define DWMAC_CORE_LOONGSON_MULTI_CH    0x10
>>>> Maybe DWMAC_CORE_LOONGSON_MULTICHAN or DWMAC_CORE_LOONGSON_MULTI_CHAN
>>>> is a little better?
>>>>
>>> Well, I don't have a strong opinion about that in this case.
>>> Personally I prefer to have the shortest and still readable version.
>>> It decreases the probability of the lines splitting in case of the
>>> long-line statements or highly indented code. From that perspective
>>> something like DWMAC_CORE_LS_MULTI_CH would be even better. But seeing
>>> the driver currently don't have such cases, we can use any of those
>>> name. But it's better to be of such length so the code lines the name
>>> is utilized in wouldn't exceed +80 chars.
>> Okay.
>>
>> I added an indent before 0xXX and left three Spaces before the comment,
>>
>> which uses huacai's MULTICHAN and doesn't exceed 80 chars.
> I meant that it's better to have the length of the macro name so
> !the code where it's utilized!
> wouldn't exceed +80 chars. That's the criteria for the upper length
> boundary I normally follow in such cases.
>
Oh, I see!

Hmm, let's compare the two options:

DWMAC_CORE_LS_MULTI_CH

DWMAC_CORE_LS_MULTICHAN

With just one more char, the increased readability seems to be
worth it.


Thanks,

Yanteng

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

[Huacai Chen]

On Sat, Jul 6, 2024 at 6:31 PM Yanteng Si <siyanteng@loongson.cn> wrote:
>
>
> 在 2024/7/5 20:17, Serge Semin 写道:
> > On Fri, Jul 05, 2024 at 08:06:32PM +0800, Yanteng Si wrote:
> >>>>> But if you aren't comfortable with such naming we can change the
> >>>>> macro to something like:
> >>>>> #define DWMAC_CORE_LOONGSON_MULTI_CH    0x10
> >>>> Maybe DWMAC_CORE_LOONGSON_MULTICHAN or DWMAC_CORE_LOONGSON_MULTI_CHAN
> >>>> is a little better?
> >>>>
> >>> Well, I don't have a strong opinion about that in this case.
> >>> Personally I prefer to have the shortest and still readable version.
> >>> It decreases the probability of the lines splitting in case of the
> >>> long-line statements or highly indented code. From that perspective
> >>> something like DWMAC_CORE_LS_MULTI_CH would be even better. But seeing
> >>> the driver currently don't have such cases, we can use any of those
> >>> name. But it's better to be of such length so the code lines the name
> >>> is utilized in wouldn't exceed +80 chars.
> >> Okay.
> >>
> >> I added an indent before 0xXX and left three Spaces before the comment,
> >>
> >> which uses huacai's MULTICHAN and doesn't exceed 80 chars.
> > I meant that it's better to have the length of the macro name so
> > !the code where it's utilized!
> > wouldn't exceed +80 chars. That's the criteria for the upper length
> > boundary I normally follow in such cases.
> >
> Oh, I see!
>
> Hmm, let's compare the two options:
>
> DWMAC_CORE_LS_MULTI_CH
>
> DWMAC_CORE_LS_MULTICHAN
>
> With just one more char, the increased readability seems to be
> worth it.
If you really like short names, please use DWMAC_CORE_MULTICHAN. LS
has no valuable meaning in this loongson-specific file.

Huacai

>
>
> Thanks,
>
> Yanteng
>

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Yanteng Si]

在 2024/7/5 19:53, Serge Semin 写道:
>> $: cat /proc/interrupts
>>
>>             CPU0       CPU1
>>   20:       3826      12138   CPUINTC  12  IPI
>>   21:      15242      11791   CPUINTC  11  timer
>>   22:          0          0   PCH PIC   1  acpi
>>   28:          0          0   PCH PIC   7  loongson-alarm
>>   29:          0          0   PCH PIC   8  ls2x-i2c, ls2x-i2c, ls2x-i2c,
>> ls2x-i2c, ls2x-i2c, ls2x-i2c
>>   34:       7456          0   LIOINTC  10  ttyS0
>>   42:       1192          0   PCH PIC  17  0000:00:06.1
>>   43:          0          0   PCH PIC  18  ahci[0000:00:08.0]
>>   44:         40          0   PCH PIC  19  enp0s3f0
>>   45:          0          0   PCH PIC  20  enp0s3f1
>>   46:       1446          0   PCH PIC  21  enp0s3f2
>>   47:      11164          0   PCH PIC  22  xhci-hcd:usb1
>>   48:        338          0   PCH PIC  23  xhci-hcd:usb3
>>   49:          0          0   PCH PIC  24  snd_hda_intel:card0
>> IPI0:       117        132  LoongArch  1  Rescheduling interrupts
>> IPI1:      3713      12007  LoongArch  2  Function call interrupts
>> ERR:          1
>>
>>
> So, what made you thinking that the enp0s3f0, enp0s3f1 and enp0s3f2
> interfaces weren't working? I failed to find any immediate problem in
> the log.
I'm sorry. I made a mistake. It works fine.
>
> The driver registered eight Rx-queues (and likely eight Tx-queues).
> enp0s3f0 and enp0s3f2 links got up. Even the log reported that two
> interfaces have some network access (whatever it meant in your
> boot-script):
>
>> The device(7a03 and 7a13) can access the network.
> Yes, there is only one IRQ registered for each interface. But that's
> what was expected seeing you have a single MAC IRQ detected. The
> main question is: do the network traffic still get to flow in this
> case? Are you able to send/receive data over all the DMA-channels?

Yes, I can. in this case, enp0s3f0/1/2 can access www.sing.com.


Because I did another test. I turn on the checksum.

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 25ddd99ae112..e1cde9e0e530 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -133,8 +133,8 @@ static int loongson_gmac_data(struct pci_dev *pdev,
                 /* 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;
+               // for (i = 1; i < CHANNEL_NUM; i++)
+                       // plat->tx_queues_cfg[i].coe_unsupported = 1;
         } else {
                 plat->tx_queues_to_use = 1;
                 plat->rx_queues_to_use = 1;
@@ -185,8 +185,8 @@ static int loongson_gnet_data(struct pci_dev *pdev,
                 /* 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;
+               // for (i = 1; i < CHANNEL_NUM; i++)
+                       // plat->tx_queues_cfg[i].coe_unsupported = 1;
         } else {
                 plat->tx_queues_to_use = 1;
                 plat->rx_queues_to_use = 1;
@@ -576,11 +576,11 @@ static int loongson_dwmac_probe(struct pci_dev 
*pdev, const struct pci_device_id
         if (ret)
                 goto err_disable_device;

-       if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
-               ret = loongson_dwmac_msi_config(pdev, plat, &res);
-               if (ret)
-                       goto err_disable_device;
-       }
+       // if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
+               // ret = loongson_dwmac_msi_config(pdev, plat, &res);
+               // if (ret)
+                       // goto err_disable_device;
+       // }

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

In this case, enp0s3f0/1/2 cannot access the www.sing.com.

therefore, the network traffic still get to flow, and I can

send/receive data over all the DMA-channels.

If there are any other tests you would like me to do, please let

me know and I will be happy to do them.

Thanks,

Yanteng

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Serge Semin]

On Sat, Jul 06, 2024 at 09:31:43PM +0800, Yanteng Si wrote:
> 
> 在 2024/7/5 19:53, Serge Semin 写道:
> > > $: cat /proc/interrupts
> > > 
> > >             CPU0       CPU1
> > >   20:       3826      12138   CPUINTC  12  IPI
> > >   21:      15242      11791   CPUINTC  11  timer
> > >   22:          0          0   PCH PIC   1  acpi
> > >   28:          0          0   PCH PIC   7  loongson-alarm
> > >   29:          0          0   PCH PIC   8  ls2x-i2c, ls2x-i2c, ls2x-i2c,
> > > ls2x-i2c, ls2x-i2c, ls2x-i2c
> > >   34:       7456          0   LIOINTC  10  ttyS0
> > >   42:       1192          0   PCH PIC  17  0000:00:06.1
> > >   43:          0          0   PCH PIC  18  ahci[0000:00:08.0]
> > >   44:         40          0   PCH PIC  19  enp0s3f0
> > >   45:          0          0   PCH PIC  20  enp0s3f1
> > >   46:       1446          0   PCH PIC  21  enp0s3f2
> > >   47:      11164          0   PCH PIC  22  xhci-hcd:usb1
> > >   48:        338          0   PCH PIC  23  xhci-hcd:usb3
> > >   49:          0          0   PCH PIC  24  snd_hda_intel:card0
> > > IPI0:       117        132  LoongArch  1  Rescheduling interrupts
> > > IPI1:      3713      12007  LoongArch  2  Function call interrupts
> > > ERR:          1
> > > 
> > > 
> > So, what made you thinking that the enp0s3f0, enp0s3f1 and enp0s3f2
> > interfaces weren't working? I failed to find any immediate problem in
> > the log.
> I'm sorry. I made a mistake. It works fine.
> > 
> > The driver registered eight Rx-queues (and likely eight Tx-queues).
> > enp0s3f0 and enp0s3f2 links got up. Even the log reported that two
> > interfaces have some network access (whatever it meant in your
> > boot-script):
> > 
> > > The device(7a03 and 7a13) can access the network.
> > Yes, there is only one IRQ registered for each interface. But that's
> > what was expected seeing you have a single MAC IRQ detected. The
> > main question is: do the network traffic still get to flow in this
> > case? Are you able to send/receive data over all the DMA-channels?
> 
> Yes, I can. in this case, enp0s3f0/1/2 can access www.sing.com.
> 
> 
> Because I did another test. I turn on the checksum.
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index 25ddd99ae112..e1cde9e0e530 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -133,8 +133,8 @@ static int loongson_gmac_data(struct pci_dev *pdev,
>                 /* 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;
> +               // for (i = 1; i < CHANNEL_NUM; i++)
> +                       // plat->tx_queues_cfg[i].coe_unsupported = 1;
>         } else {
>                 plat->tx_queues_to_use = 1;
>                 plat->rx_queues_to_use = 1;
> @@ -185,8 +185,8 @@ static int loongson_gnet_data(struct pci_dev *pdev,
>                 /* 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;
> +               // for (i = 1; i < CHANNEL_NUM; i++)
> +                       // plat->tx_queues_cfg[i].coe_unsupported = 1;
>         } else {
>                 plat->tx_queues_to_use = 1;
>                 plat->rx_queues_to_use = 1;
> @@ -576,11 +576,11 @@ static int loongson_dwmac_probe(struct pci_dev *pdev,> const struct pci_device_id
>         if (ret)
>                 goto err_disable_device;
> 
> -       if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
> -               ret = loongson_dwmac_msi_config(pdev, plat, &res);
> -               if (ret)
> -                       goto err_disable_device;
> -       }
> +       if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
> +               // ret = loongson_dwmac_msi_config(pdev, plat, &res);
> +               // if (ret)
> +                       // goto err_disable_device;
> +       // }
> 
>         ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>         if (ret)
> 
> In this case, enp0s3f0/1/2 cannot access the www.sing.com.

Smart.) Indeed it implicitly proves that at least two channels get to
work. Checking out the interface queues statistics (ethtool -S
<interface>) would make it less implicit. Although something more
comprehensive covering all the channels would be better. But it's up
to you to decide whether you need such test implemented and performed.
I just wanted to make sure whether the common MAC IRQ case was indeed
tested since your original result contradicted to what the DW MAC
explicitly stated:

"The interrupts from different DMA channels are combined by using the
OR function to generate a single interrupt signal sbd_intr_o.
Therefore, the software needs to read the Interrupt Status Registers
of all DMA channels to get the source of interrupt. The MAC interrupt
status (Bits [29:26]) is updated only in the interrupt status register
of Channel 0."

The sbd_intr_o line is the main IRQ signal reporting all the DMA and
MAC events (so called "macirq" in the STMMAC driver). (There is a case
when the later events are reported via a separate mci_intr_o wire, but
it's rather rare.) So it seemed strange that the Loongson GMAC/GNET
HW-designers could have diverted the IRQs delivery logic so much.
That's why I was so persistent in asking the way the test was
performed.

-Serge(y)

> 
> therefore, the network traffic still get to flow, and I can
> 
> send/receive data over all the DMA-channels.
> 
> If there are any other tests you would like me to do, please let
> 
> me know and I will be happy to do them.
> 
> Thanks,
> 
> Yanteng
> 

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

[Serge Semin]

On Sat, Jul 06, 2024 at 06:36:06PM +0800, Huacai Chen wrote:
> On Sat, Jul 6, 2024 at 6:31 PM Yanteng Si <siyanteng@loongson.cn> wrote:
> >
> >
> > 在 2024/7/5 20:17, Serge Semin 写道:
> > > On Fri, Jul 05, 2024 at 08:06:32PM +0800, Yanteng Si wrote:
> > >>>>> But if you aren't comfortable with such naming we can change the
> > >>>>> macro to something like:
> > >>>>> #define DWMAC_CORE_LOONGSON_MULTI_CH    0x10
> > >>>> Maybe DWMAC_CORE_LOONGSON_MULTICHAN or DWMAC_CORE_LOONGSON_MULTI_CHAN
> > >>>> is a little better?
> > >>>>
> > >>> Well, I don't have a strong opinion about that in this case.
> > >>> Personally I prefer to have the shortest and still readable version.
> > >>> It decreases the probability of the lines splitting in case of the
> > >>> long-line statements or highly indented code. From that perspective
> > >>> something like DWMAC_CORE_LS_MULTI_CH would be even better. But seeing
> > >>> the driver currently don't have such cases, we can use any of those
> > >>> name. But it's better to be of such length so the code lines the name
> > >>> is utilized in wouldn't exceed +80 chars.
> > >> Okay.
> > >>
> > >> I added an indent before 0xXX and left three Spaces before the comment,
> > >>
> > >> which uses huacai's MULTICHAN and doesn't exceed 80 chars.
> > > I meant that it's better to have the length of the macro name so
> > > !the code where it's utilized!
> > > wouldn't exceed +80 chars. That's the criteria for the upper length
> > > boundary I normally follow in such cases.
> > >
> > Oh, I see!
> >
> > Hmm, let's compare the two options:
> >
> > DWMAC_CORE_LS_MULTI_CH
> >
> > DWMAC_CORE_LS_MULTICHAN
> >
> > With just one more char, the increased readability seems to be
> > worth it.
> If you really like short names, please use DWMAC_CORE_MULTICHAN. LS
> has no valuable meaning in this loongson-specific file.

At least some version of the Loongson vendor name should be in the
macro. Omitting it may cause a confusion since the name would turn to
a too generic form. Seeing the multi DMA-channels feature is the
Synopsys invention, should you meet the macro like DWMAC_CORE_MULTI_CH
in the code that may cause an impression that there is a special
Synopsys DW MAC ID for that. Meanwhile in fact the custom ID is
specific for the Loongson GMAC/GNET controllers only.

-Serge(y)

> 
> Huacai
> 
> >
> >
> > Thanks,
> >
> > Yanteng
> >

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

[Huacai Chen]

On Sun, Jul 7, 2024 at 6:51 PM Serge Semin <fancer.lancer@gmail.com> wrote:
>
> On Sat, Jul 06, 2024 at 06:36:06PM +0800, Huacai Chen wrote:
> > On Sat, Jul 6, 2024 at 6:31 PM Yanteng Si <siyanteng@loongson.cn> wrote:
> > >
> > >
> > > 在 2024/7/5 20:17, Serge Semin 写道:
> > > > On Fri, Jul 05, 2024 at 08:06:32PM +0800, Yanteng Si wrote:
> > > >>>>> But if you aren't comfortable with such naming we can change the
> > > >>>>> macro to something like:
> > > >>>>> #define DWMAC_CORE_LOONGSON_MULTI_CH    0x10
> > > >>>> Maybe DWMAC_CORE_LOONGSON_MULTICHAN or DWMAC_CORE_LOONGSON_MULTI_CHAN
> > > >>>> is a little better?
> > > >>>>
> > > >>> Well, I don't have a strong opinion about that in this case.
> > > >>> Personally I prefer to have the shortest and still readable version.
> > > >>> It decreases the probability of the lines splitting in case of the
> > > >>> long-line statements or highly indented code. From that perspective
> > > >>> something like DWMAC_CORE_LS_MULTI_CH would be even better. But seeing
> > > >>> the driver currently don't have such cases, we can use any of those
> > > >>> name. But it's better to be of such length so the code lines the name
> > > >>> is utilized in wouldn't exceed +80 chars.
> > > >> Okay.
> > > >>
> > > >> I added an indent before 0xXX and left three Spaces before the comment,
> > > >>
> > > >> which uses huacai's MULTICHAN and doesn't exceed 80 chars.
> > > > I meant that it's better to have the length of the macro name so
> > > > !the code where it's utilized!
> > > > wouldn't exceed +80 chars. That's the criteria for the upper length
> > > > boundary I normally follow in such cases.
> > > >
> > > Oh, I see!
> > >
> > > Hmm, let's compare the two options:
> > >
> > > DWMAC_CORE_LS_MULTI_CH
> > >
> > > DWMAC_CORE_LS_MULTICHAN
> > >
> > > With just one more char, the increased readability seems to be
> > > worth it.
> > If you really like short names, please use DWMAC_CORE_MULTICHAN. LS
> > has no valuable meaning in this loongson-specific file.
>
> At least some version of the Loongson vendor name should be in the
> macro. Omitting it may cause a confusion since the name would turn to
> a too generic form. Seeing the multi DMA-channels feature is the
> Synopsys invention, should you meet the macro like DWMAC_CORE_MULTI_CH
> in the code that may cause an impression that there is a special
> Synopsys DW MAC ID for that. Meanwhile in fact the custom ID is
> specific for the Loongson GMAC/GNET controllers only.
Well,
I prefer
DWMAC_CORE_LOONGSON_MULTI_CHAN / DWMAC_CORE_LOONGSON_MULTICHAN /
DWMAC_CORE_LOONGSON_MCH / DWMAC_CORE_MULTICHAN,
But I also accept DWMAC_CORE_LS_MULTI_CHAN / DWMAC_CORE_LS_MULTICHAN,
But I can't accept DWMAC_CORE_LS2K2000.

Huacai

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

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

[Yanteng Si]

在 2024/7/7 18:40, Serge Semin 写道:
> On Sat, Jul 06, 2024 at 09:31:43PM +0800, Yanteng Si wrote:
>> 在 2024/7/5 19:53, Serge Semin 写道:
>>>> $: cat /proc/interrupts
>>>>
>>>>              CPU0       CPU1
>>>>    20:       3826      12138   CPUINTC  12  IPI
>>>>    21:      15242      11791   CPUINTC  11  timer
>>>>    22:          0          0   PCH PIC   1  acpi
>>>>    28:          0          0   PCH PIC   7  loongson-alarm
>>>>    29:          0          0   PCH PIC   8  ls2x-i2c, ls2x-i2c, ls2x-i2c,
>>>> ls2x-i2c, ls2x-i2c, ls2x-i2c
>>>>    34:       7456          0   LIOINTC  10  ttyS0
>>>>    42:       1192          0   PCH PIC  17  0000:00:06.1
>>>>    43:          0          0   PCH PIC  18  ahci[0000:00:08.0]
>>>>    44:         40          0   PCH PIC  19  enp0s3f0
>>>>    45:          0          0   PCH PIC  20  enp0s3f1
>>>>    46:       1446          0   PCH PIC  21  enp0s3f2
>>>>    47:      11164          0   PCH PIC  22  xhci-hcd:usb1
>>>>    48:        338          0   PCH PIC  23  xhci-hcd:usb3
>>>>    49:          0          0   PCH PIC  24  snd_hda_intel:card0
>>>> IPI0:       117        132  LoongArch  1  Rescheduling interrupts
>>>> IPI1:      3713      12007  LoongArch  2  Function call interrupts
>>>> ERR:          1
>>>>
>>>>
>>> So, what made you thinking that the enp0s3f0, enp0s3f1 and enp0s3f2
>>> interfaces weren't working? I failed to find any immediate problem in
>>> the log.
>> I'm sorry. I made a mistake. It works fine.
>>> The driver registered eight Rx-queues (and likely eight Tx-queues).
>>> enp0s3f0 and enp0s3f2 links got up. Even the log reported that two
>>> interfaces have some network access (whatever it meant in your
>>> boot-script):
>>>
>>>> The device(7a03 and 7a13) can access the network.
>>> Yes, there is only one IRQ registered for each interface. But that's
>>> what was expected seeing you have a single MAC IRQ detected. The
>>> main question is: do the network traffic still get to flow in this
>>> case? Are you able to send/receive data over all the DMA-channels?
>> Yes, I can. in this case, enp0s3f0/1/2 can accesswww.sing.com.
>>
>>
>> Because I did another test. I turn on the checksum.
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> index 25ddd99ae112..e1cde9e0e530 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
>> @@ -133,8 +133,8 @@ static int loongson_gmac_data(struct pci_dev *pdev,
>>                  /* 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;
>> +               // for (i = 1; i < CHANNEL_NUM; i++)
>> +                       // plat->tx_queues_cfg[i].coe_unsupported = 1;
>>          } else {
>>                  plat->tx_queues_to_use = 1;
>>                  plat->rx_queues_to_use = 1;
>> @@ -185,8 +185,8 @@ static int loongson_gnet_data(struct pci_dev *pdev,
>>                  /* 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;
>> +               // for (i = 1; i < CHANNEL_NUM; i++)
>> +                       // plat->tx_queues_cfg[i].coe_unsupported = 1;
>>          } else {
>>                  plat->tx_queues_to_use = 1;
>>                  plat->rx_queues_to_use = 1;
>> @@ -576,11 +576,11 @@ static int loongson_dwmac_probe(struct pci_dev *pdev,> const struct pci_device_id
>>          if (ret)
>>                  goto err_disable_device;
>>
>> -       if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
>> -               ret = loongson_dwmac_msi_config(pdev, plat, &res);
>> -               if (ret)
>> -                       goto err_disable_device;
>> -       }
>> +       if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
>> +               // ret = loongson_dwmac_msi_config(pdev, plat, &res);
>> +               // if (ret)
>> +                       // goto err_disable_device;
>> +       // }
>>
>>          ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
>>          if (ret)
>>
>> In this case, enp0s3f0/1/2 cannot access thewww.sing.com.
> Smart.) Indeed it implicitly proves that at least two channels get to
> work. Checking out the interface queues statistics (ethtool -S
> <interface>) would make it less implicit. Although something more
> comprehensive covering all the channels would be better. But it's up
> to you to decide whether you need such test implemented and performed.

OK.

[root@archlinux ~]# ethtool -S enp0s3f2
NIC statistics:
      mmc_tx_octetcount_gb: 77779
      mmc_tx_framecount_gb: 765
      mmc_tx_broadcastframe_g: 4
      mmc_tx_multicastframe_g: 68
      mmc_tx_64_octets_gb: 199
      mmc_tx_65_to_127_octets_gb: 480
      mmc_tx_128_to_255_octets_gb: 75
      mmc_tx_256_to_511_octets_gb: 3
      mmc_tx_512_to_1023_octets_gb: 1
      mmc_tx_1024_to_max_octets_gb: 7
      mmc_tx_unicast_gb: 693
      mmc_tx_multicast_gb: 68
      mmc_tx_broadcast_gb: 4
      mmc_tx_underflow_error: 0
      mmc_tx_singlecol_g: 0
      mmc_tx_multicol_g: 0
      mmc_tx_deferred: 0
      mmc_tx_latecol: 0
      mmc_tx_exesscol: 0
      mmc_tx_carrier_error: 0
      mmc_tx_octetcount_g: 77779
      mmc_tx_framecount_g: 765
      mmc_tx_excessdef: 0
      mmc_tx_pause_frame: 0
      mmc_tx_vlan_frame_g: 0
      mmc_tx_oversize_g: 0
      mmc_tx_lpi_usec: 0
      mmc_tx_lpi_tran: 0
      mmc_rx_framecount_gb: 33212
      mmc_rx_octetcount_gb: 2202315
      mmc_rx_octetcount_g: 2202315
      mmc_rx_broadcastframe_g: 32383
      mmc_rx_multicastframe_g: 216
      mmc_rx_crc_error: 0
      mmc_rx_align_error: 0
      mmc_rx_run_error: 0
      mmc_rx_jabber_error: 0
      mmc_rx_undersize_g: 0
      mmc_rx_oversize_g: 0
      mmc_rx_64_octets_gb: 31088
      mmc_rx_65_to_127_octets_gb: 1888
      mmc_rx_128_to_255_octets_gb: 141
      mmc_rx_256_to_511_octets_gb: 91
      mmc_rx_512_to_1023_octets_gb: 2
      mmc_rx_1024_to_max_octets_gb: 2
      mmc_rx_unicast_g: 613
      mmc_rx_length_error: 0
      mmc_rx_autofrangetype: 0
      mmc_rx_pause_frames: 0
      mmc_rx_fifo_overflow: 0
      mmc_rx_vlan_frames_gb: 0
      mmc_rx_watchdog_error: 0
      mmc_rx_error: 0
      mmc_rx_lpi_usec: 0
      mmc_rx_lpi_tran: 0
      mmc_rx_discard_frames_gb: 0
      mmc_rx_discard_octets_gb: 0
      mmc_rx_align_err_frames: 0
      mmc_rx_ipv4_gd: 920
      mmc_rx_ipv4_hderr: 0
      mmc_rx_ipv4_nopay: 0
      mmc_rx_ipv4_frag: 0
      mmc_rx_ipv4_udsbl: 0
      mmc_rx_ipv4_gd_octets: 107826
      mmc_rx_ipv4_hderr_octets: 0
      mmc_rx_ipv4_nopay_octets: 0
      mmc_rx_ipv4_frag_octets: 0
      mmc_rx_ipv4_udsbl_octets: 0
      mmc_rx_ipv6_gd_octets: 17360
      mmc_rx_ipv6_hderr_octets: 0
      mmc_rx_ipv6_nopay_octets: 0
      mmc_rx_ipv6_gd: 219
      mmc_rx_ipv6_hderr: 0
      mmc_rx_ipv6_nopay: 0
      mmc_rx_udp_gd: 571
      mmc_rx_udp_err: 0
      mmc_rx_tcp_gd: 337
      mmc_rx_tcp_err: 0
      mmc_rx_icmp_gd: 231
      mmc_rx_icmp_err: 0
      mmc_rx_udp_gd_octets: 65149
      mmc_rx_udp_err_octets: 0
      mmc_rx_tcp_gd_octets: 23525
      mmc_rx_tcp_err_octets: 0
      mmc_rx_icmp_gd_octets: 8880
      mmc_rx_icmp_err_octets: 0
      mmc_sgf_pass_fragment_cntr: 0
      mmc_sgf_fail_fragment_cntr: 0
      mmc_tx_fpe_fragment_cntr: 0
      mmc_tx_hold_req_cntr: 0
      mmc_tx_gate_overrun_cntr: 0
      mmc_rx_packet_assembly_err_cntr: 0
      mmc_rx_packet_smd_err_cntr: 0
      mmc_rx_packet_assembly_ok_cntr: 0
      mmc_rx_fpe_fragment_cntr: 0
      tx_underflow: 0
      tx_carrier: 0
      tx_losscarrier: 0
      vlan_tag: 0
      tx_deferred: 0
      tx_vlan: 0
      tx_jabber: 0
      tx_frame_flushed: 0
      tx_payload_error: 0
      tx_ip_header_error: 0
      rx_desc: 0
      sa_filter_fail: 0
      overflow_error: 0
      ipc_csum_error: 0
      rx_collision: 0
      rx_crc_errors: 0
      dribbling_bit: 0
      rx_length: 0
      rx_mii: 0
      rx_multicast: 0
      rx_gmac_overflow: 0
      rx_watchdog: 0
      da_rx_filter_fail: 0
      sa_rx_filter_fail: 0
      rx_missed_cntr: 0
      rx_overflow_cntr: 0
      rx_vlan: 0
      rx_split_hdr_pkt_n: 0
      tx_undeflow_irq: 0
      tx_process_stopped_irq: 0
      tx_jabber_irq: 0
      rx_overflow_irq: 0
      rx_buf_unav_irq: 0
      rx_process_stopped_irq: 0
      rx_watchdog_irq: 0
      tx_early_irq: 0
      fatal_bus_error_irq: 0
      rx_early_irq: 0
      threshold: 1
      irq_receive_pmt_irq_n: 0
      mmc_tx_irq_n: 0
      mmc_rx_irq_n: 0
      mmc_rx_csum_offload_irq_n: 0
      irq_tx_path_in_lpi_mode_n: 0
      irq_tx_path_exit_lpi_mode_n: 0
      irq_rx_path_in_lpi_mode_n: 0
      irq_rx_path_exit_lpi_mode_n: 0
      phy_eee_wakeup_error_n: 0
      ip_hdr_err: 0
      ip_payload_err: 0
      ip_csum_bypassed: 0
      ipv4_pkt_rcvd: 920
      ipv6_pkt_rcvd: 219
      no_ptp_rx_msg_type_ext: 1139
      ptp_rx_msg_type_sync: 0
      ptp_rx_msg_type_follow_up: 0
      ptp_rx_msg_type_delay_req: 0
      ptp_rx_msg_type_delay_resp: 0
      ptp_rx_msg_type_pdelay_req: 0
      ptp_rx_msg_type_pdelay_resp: 0
      ptp_rx_msg_type_pdelay_follow_up: 0
      ptp_rx_msg_type_announce: 0
      ptp_rx_msg_type_management: 0
      ptp_rx_msg_pkt_reserved_type: 0
      ptp_frame_type: 0
      ptp_ver: 0
      timestamp_dropped: 0
      av_pkt_rcvd: 0
      av_tagged_pkt_rcvd: 0
      vlan_tag_priority_val: 0
      l3_filter_match: 0
      l4_filter_match: 0
      l3_l4_filter_no_match: 0
      irq_pcs_ane_n: 0
      irq_pcs_link_n: 0
      irq_rgmii_n: 0
      mtl_tx_status_fifo_full: 0
      mtl_tx_fifo_not_empty: 0
      mmtl_fifo_ctrl: 0
      mtl_tx_fifo_read_ctrl_write: 0
      mtl_tx_fifo_read_ctrl_wait: 0
      mtl_tx_fifo_read_ctrl_read: 0
      mtl_tx_fifo_read_ctrl_idle: 0
      mac_tx_in_pause: 0
      mac_tx_frame_ctrl_xfer: 0
      mac_tx_frame_ctrl_idle: 0
      mac_tx_frame_ctrl_wait: 0
      mac_tx_frame_ctrl_pause: 0
      mac_gmii_tx_proto_engine: 0
      mtl_rx_fifo_fill_level_full: 0
      mtl_rx_fifo_fill_above_thresh: 0
      mtl_rx_fifo_fill_below_thresh: 0
      mtl_rx_fifo_fill_level_empty: 0
      mtl_rx_fifo_read_ctrl_flush: 0
      mtl_rx_fifo_read_ctrl_read_data: 0
      mtl_rx_fifo_read_ctrl_status: 0
      mtl_rx_fifo_read_ctrl_idle: 0
      mtl_rx_fifo_ctrl_active: 0
      mac_rx_frame_ctrl_fifo: 0
      mac_gmii_rx_proto_engine: 0
      mtl_est_cgce: 0
      mtl_est_hlbs: 0
      mtl_est_hlbf: 0
      mtl_est_btre: 0
      mtl_est_btrlm: 0
      rx_pkt_n: 33212
      rx_normal_irq_n: 33004
      tx_pkt_n: 764
      tx_normal_irq_n: 33
      tx_clean: 651
      tx_set_ic_bit: 33
      tx_tso_frames: 0
      tx_tso_nfrags: 0
      normal_irq_n: 33037
      napi_poll: 33655
      q0_tx_pkt_n: 512
      q0_tx_irq_n: 26
      q1_tx_pkt_n: 15
      q1_tx_irq_n: 0
      q2_tx_pkt_n: 33
      q2_tx_irq_n: 1
      q3_tx_pkt_n: 9
      q3_tx_irq_n: 0
      q4_tx_pkt_n: 20
      q4_tx_irq_n: 0
      q5_tx_pkt_n: 9
      q5_tx_irq_n: 0
      q6_tx_pkt_n: 134
      q6_tx_irq_n: 5
      q7_tx_pkt_n: 32
      q7_tx_irq_n: 1
      q0_rx_pkt_n: 33212
      q0_rx_irq_n: 33004
      q1_rx_pkt_n: 0
      q1_rx_irq_n: 0
      q2_rx_pkt_n: 0
      q2_rx_irq_n: 0
      q3_rx_pkt_n: 0
      q3_rx_irq_n: 0
      q4_rx_pkt_n: 0
      q4_rx_irq_n: 0
      q5_rx_pkt_n: 0
      q5_rx_irq_n: 0
      q6_rx_pkt_n: 0
      q6_rx_irq_n: 0
      q7_rx_pkt_n: 0
      q7_rx_irq_n: 0
[root@archlinux ~]#


Thanks,

Yanteng

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

[Yanteng Si]

在 2024/7/7 21:57, Huacai Chen 写道:
> On Sun, Jul 7, 2024 at 6:51 PM Serge Semin <fancer.lancer@gmail.com> wrote:
>> On Sat, Jul 06, 2024 at 06:36:06PM +0800, Huacai Chen wrote:
>>> On Sat, Jul 6, 2024 at 6:31 PM Yanteng Si <siyanteng@loongson.cn> wrote:
>>>>
>>>> 在 2024/7/5 20:17, Serge Semin 写道:
>>>>> On Fri, Jul 05, 2024 at 08:06:32PM +0800, Yanteng Si wrote:
>>>>>>>>> But if you aren't comfortable with such naming we can change the
>>>>>>>>> macro to something like:
>>>>>>>>> #define DWMAC_CORE_LOONGSON_MULTI_CH    0x10
>>>>>>>> Maybe DWMAC_CORE_LOONGSON_MULTICHAN or DWMAC_CORE_LOONGSON_MULTI_CHAN
>>>>>>>> is a little better?
>>>>>>>>
>>>>>>> Well, I don't have a strong opinion about that in this case.
>>>>>>> Personally I prefer to have the shortest and still readable version.
>>>>>>> It decreases the probability of the lines splitting in case of the
>>>>>>> long-line statements or highly indented code. From that perspective
>>>>>>> something like DWMAC_CORE_LS_MULTI_CH would be even better. But seeing
>>>>>>> the driver currently don't have such cases, we can use any of those
>>>>>>> name. But it's better to be of such length so the code lines the name
>>>>>>> is utilized in wouldn't exceed +80 chars.
>>>>>> Okay.
>>>>>>
>>>>>> I added an indent before 0xXX and left three Spaces before the comment,
>>>>>>
>>>>>> which uses huacai's MULTICHAN and doesn't exceed 80 chars.
>>>>> I meant that it's better to have the length of the macro name so
>>>>> !the code where it's utilized!
>>>>> wouldn't exceed +80 chars. That's the criteria for the upper length
>>>>> boundary I normally follow in such cases.
>>>>>
>>>> Oh, I see!
>>>>
>>>> Hmm, let's compare the two options:
>>>>
>>>> DWMAC_CORE_LS_MULTI_CH
>>>>
>>>> DWMAC_CORE_LS_MULTICHAN
>>>>
>>>> With just one more char, the increased readability seems to be
>>>> worth it.
>>> If you really like short names, please use DWMAC_CORE_MULTICHAN. LS
>>> has no valuable meaning in this loongson-specific file.
>> At least some version of the Loongson vendor name should be in the
>> macro. Omitting it may cause a confusion since the name would turn to
>> a too generic form. Seeing the multi DMA-channels feature is the
>> Synopsys invention, should you meet the macro like DWMAC_CORE_MULTI_CH
>> in the code that may cause an impression that there is a special
>> Synopsys DW MAC ID for that. Meanwhile in fact the custom ID is
>> specific for the Loongson GMAC/GNET controllers only.
> Well,
> I prefer
> DWMAC_CORE_LOONGSON_MULTI_CHAN / DWMAC_CORE_LOONGSON_MULTICHAN /
> DWMAC_CORE_LOONGSON_MCH / DWMAC_CORE_MULTICHAN,
> But I also accept DWMAC_CORE_LS_MULTI_CHAN / DWMAC_CORE_LS_MULTICHAN,
> But I can't accept DWMAC_CORE_LS2K2000.
>
I'll use DWMAC_CORE_LS_MULTICHAN for now, Let's continue discussing

this macro in v14 (If necessary).


Thanks,

Yanteng