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

Commit Message

Yanteng Si May 29, 2024, 10:19 a.m. UTC

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 <[e-mail]>
Signed-off-by: Yinggang Gu <[e-mail]>
Signed-off-by: Yanteng Si <[e-mail]>
---
 .../ethernet/stmicro/stmmac/dwmac-loongson.c  | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

Comments

Serge Semin June 14, 2024, 4:19 p.m. UTC | #1

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/[e-mail]/
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 <[e-mail]>
> Signed-off-by: Yinggang Gu <[e-mail]>
> Signed-off-by: Yanteng Si <[e-mail]>
> ---
>  .../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
>

Yanteng Si June 17, 2024, 10 a.m. UTC | #2

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/[e-mail]/
> 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 <[e-mail]>
>> Signed-off-by: Yinggang Gu <[e-mail]>
>> Signed-off-by: Yanteng Si <[e-mail]>
>> ---
>>   .../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
>>

Serge Semin June 24, 2024, 1:47 a.m. UTC | #3

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/[e-mail]/
> > 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)

Yanteng Si June 25, 2024, 12:31 p.m. UTC | #4

在 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/[e-mail]/
>>> 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)

Serge Semin July 1, 2024, 10:57 p.m. UTC | #5

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/[e-mail]/
> > > > 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)
>

Serge Semin July 2, 2024, 8:28 a.m. UTC | #6

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 <[e-mail]>
> Signed-off-by: Yinggang Gu <[e-mail]>
> Signed-off-by: Yanteng Si <[e-mail]>
> ---
>  .../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
>

Yanteng Si July 2, 2024, 9:24 a.m. UTC | #7

在 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/[e-mail]/
>>>>> 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)
>

Yanteng Si July 2, 2024, 1:14 p.m. UTC | #8

在 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 <[e-mail]>
>> Signed-off-by: Yinggang Gu <[e-mail]>
>> Signed-off-by: Yanteng Si <[e-mail]>
>> ---
>>   .../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
>>

Serge Semin July 2, 2024, 2:09 p.m. UTC | #9

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 <[e-mail]>
> > > Signed-off-by: Yinggang Gu <[e-mail]>
> > > Signed-off-by: Yanteng Si <[e-mail]>
> > > ---
> > >   .../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
> > > 
>

Yanteng Si July 3, 2024, 9:41 a.m. UTC | #10

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

Serge Semin July 3, 2024, 4:19 p.m. UTC | #11

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

Yanteng Si July 4, 2024, 8:56 a.m. UTC | #12

在 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

Serge Semin July 5, 2024, 10:16 a.m. UTC | #13

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

Yanteng Si July 5, 2024, 10:45 a.m. UTC | #14

在 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

Serge Semin July 5, 2024, 10:59 a.m. UTC | #15

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)

Yanteng Si July 5, 2024, 11:29 a.m. UTC | #16

在 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 <[e-mail]>
[    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: [e-mail]
[    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

Serge Semin July 5, 2024, 11:53 a.m. UTC | #17

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)

Yanteng Si July 6, 2024, 1:31 p.m. UTC | #18

在 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

Serge Semin July 7, 2024, 10:40 a.m. UTC | #19

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
>

Yanteng Si July 8, 2024, 7 a.m. UTC | #20

在 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

Patch

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;