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