netdev - Re: [PATCH net-next v5 2/5] net: stmmac: Add basic dw25gmac support in stmmac core

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: <wufpbnsa7w4bk57drsjywnbz2di63yfn7qrmkxfmdh57zuoaeh@6j4xgyonjy6l>
Date: Fri, 11 Oct 2024 03:01:19 +0300
From: Serge Semin <fancer.lancer@...il.com>
To: Jitendra Vegiraju <jitendra.vegiraju@...adcom.com>
Cc: netdev@...r.kernel.org, alexandre.torgue@...s.st.com, 
	joabreu@...opsys.com, davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com, mcoquelin.stm32@...il.com, bcm-kernel-feedback-list@...adcom.com, 
	richardcochran@...il.com, ast@...nel.org, daniel@...earbox.net, hawk@...nel.org, 
	john.fastabend@...il.com, rmk+kernel@...linux.org.uk, ahalaney@...hat.com, 
	xiaolei.wang@...driver.com, rohan.g.thomas@...el.com, Jianheng.Zhang@...opsys.com, 
	linux-kernel@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, 
	linux-arm-kernel@...ts.infradead.org, bpf@...r.kernel.org, andrew@...n.ch, linux@...linux.org.uk, 
	horms@...nel.org, florian.fainelli@...adcom.com
Subject: Re: [PATCH net-next v5 2/5] net: stmmac: Add basic dw25gmac support
 in stmmac core

Hi Jitendra

On Fri, Oct 04, 2024 at 09:05:36AM GMT, Jitendra Vegiraju wrote:
> Hi Serge,
> 
> On Mon, Sep 16, 2024 at 4:32 PM Jitendra Vegiraju
> <jitendra.vegiraju@...adcom.com> wrote:
> >
> ...
> 
> When you get a chance, I would like to get your input on the approach we need
> to take to incrementally add dw25gmac support.
> 
> In the last conversation there were some open questions around the case of
> initializing unused VDMA channels and related combination scenarios.
> 
> The hdma mapping provides flexibility for virtualization. However, our
> SoC device cannot use all VDMAs with one PCI function. The VDMAs are
> partitioned for SRIOV use in the firmware. This SoC defaults to 8 functions
> with 4 VDMA channels each. The initial effort is to support one PCI physical
> function with 4 VDMA channels.
> Also, currently the stmmac driver has inferred one-to-one relation between
> netif channels and physical DMAs. It would be a complex change to support
> each VDMA as its own netif channel and mapping fewer physical DMAs.
> Hence, for initial submission one-to-one mapping is assumed.
> 
> As you mentioned, a static one-to-one mapping of VDMA-TC-PDMA doesn't
> require the additional complexity of managing these mappings as proposed
> in the current patch series with *struct stmmac_hdma_cfg*.
> 
> To introduce dw25gmac incrementally, I am thinking of two approaches,
>   1. Take the current patch series forward using *struct stmmac_hdma_cfg*,
>      keeping the unused VDMAs in default state. We need to fix the
> initialization
>      loops to only initialize the VDMA and PDMAs being used.

>   2. Simplify the initial patch by removing *struct hdma_cfg* from the patch
>      series and still use static VDMA-TC-PDMA mapping.
> Please share your thoughts.
> If it helps, I can send patch series with option 2 above after
> addressing all other
> review comments.

IMO approach 2 seems more preferable. Please find my comments to your
previous email in this thread:
https://lore.kernel.org/netdev/sn5epdl4jdwj4t6mo55w4poz6vkdcuzceezsmpb7447hmaj2ot@gmlxst7gdcix/

> 
> Appreciate your guidance!

Always welcome. Thank you for submitting the patches and your patience
to proceed with the review process.

-Serge(y)

> -Jitendra