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

Serge Semin fancer.lancer at gmail.com
Thu Oct 10 17:01:19 PDT 2024


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 at broadcom.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



More information about the linux-arm-kernel mailing list