lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33ee7998-df36-492c-9507-a08c3a6dad9b@loongson.cn>
Date: Fri, 10 May 2024 18:13:40 +0800
From: Yanteng Si <siyanteng@...ngson.cn>
To: Serge Semin <fancer.lancer@...il.com>
Cc: andrew@...n.ch, hkallweit1@...il.com, peppe.cavallaro@...com,
 alexandre.torgue@...s.st.com, joabreu@...opsys.com, Jose.Abreu@...opsys.com,
 chenhuacai@...nel.org, linux@...linux.org.uk, guyinggang@...ngson.cn,
 netdev@...r.kernel.org, chris.chenfeiyang@...il.com, siyanteng01@...il.com
Subject: Re: [PATCH net-next v12 02/15] net: stmmac: Add multi-channel support

Hi Serge

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

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

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

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


Thanks,

Yanteng


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ