RE: [PATCH net-next 0/5] Eliminate CONFIG_NR_CPUS dependency in dpaa-eth and enable COMPILE_TEST in fsl_qbman
> -Original Message- > From: Vladimir Oltean > Sent: Thursday, July 11, 2024 2:00 AM > To: net...@vger.kernel.org > Cc: David S. Miller ; Eric Dumazet > ; Jakub Kicinski ; Paolo Abeni > ; Breno Leitao ; Herbert Xu > ; Madalin Bucur ; > linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-arm- > ker...@lists.infradead.org > Subject: [PATCH net-next 0/5] Eliminate CONFIG_NR_CPUS dependency in dpaa- > eth and enable COMPILE_TEST in fsl_qbman > > Breno's previous attempt at enabling COMPILE_TEST for the fsl_qbman > driver (now included here as patch 5/5) triggered compilation warnings > for large CONFIG_NR_CPUS values: > https://lore.kernel.org/all/202406261920.l5pzm1rj-...@intel.com/ > > Patch 1/5 switches two NR_CPUS arrays in the dpaa-eth driver to dynamic > allocation to avoid that warning. There is more NR_CPUS usage in the > fsl-qbman driver, but that looks relatively harmless and I couldn't find > a good reason to change it. > > I noticed, while testing, that the driver doesn't actually work properly > with high CONFIG_NR_CPUS values, and patch 2/5 addresses that. > > During code analysis, I have identified two places which treat > conditions that can never happen. Patches 4/5 and 5/5 simplify the > probing code - dpaa_fq_setup() - just a little bit. > > Finally we have at 5/5 the patch that triggered all of this. There is > an okay from Herbert to take it via netdev, despite it being on soc/qbman: > https://lore.kernel.org/all/zns%2fevvbc7pdv...@gondor.apana.org.au/ > > Breno Leitao (1): > soc: fsl: qbman: FSL_DPAA depends on COMPILE_TEST > > Vladimir Oltean (4): > net: dpaa: avoid on-stack arrays of NR_CPUS elements > net: dpaa: eliminate NR_CPUS dependency in egress_fqs[] and conf_fqs[] > net: dpaa: stop ignoring TX queues past the number of CPUs > net: dpaa: no need to make sure all CPUs receive a corresponding Tx > queue > > .../net/ethernet/freescale/dpaa/dpaa_eth.c| 72 +++ > .../net/ethernet/freescale/dpaa/dpaa_eth.h| 20 -- > .../ethernet/freescale/dpaa/dpaa_ethtool.c| 10 ++- > drivers/soc/fsl/qbman/Kconfig | 2 +- > 4 files changed, 65 insertions(+), 39 deletions(-) > > -- > 2.34.1 For the series, Acked-by: Madalin Bucur Thanks, Madalin
RE: [PATCH devicetree 3/4] powerpc: dts: t1040rdb: put SGMII PHY under &mdio0 label
> -Original Message-
> From: Vladimir Oltean
> Sent: Wednesday, July 22, 2020 8:24 PM
> To: robh...@kernel.org; shawn...@kernel.org; m...@ellerman.id.au;
> devicet...@vger.kernel.org
> Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
> d...@lists.ozlabs.org; linux-ker...@vger.kernel.org;
> net...@vger.kernel.org; Madalin Bucur (OSS) ;
> Radu-andrei Bulie ; fido_...@inbox.ru
> Subject: [PATCH devicetree 3/4] powerpc: dts: t1040rdb: put SGMII PHY
> under &mdio0 label
>
> We're going to add 8 more PHYs in a future patch. It is easier to follow
> the hardware description if we don't need to fish for the path of the
> MDIO controllers inside the SoC and just use the labels.
>
Please align to the existing structure, it may be easier to add something
without paying attention to that but it's better to keep things organized.
This structure is used across all the device trees of the platforms using
DPAA, let's not start diverging now.
> Signed-off-by: Vladimir Oltean
> ---
> arch/powerpc/boot/dts/fsl/t1040rdb.dts | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/t1040rdb.dts
> b/arch/powerpc/boot/dts/fsl/t1040rdb.dts
> index 65ff34c49025..40d7126dbe90 100644
> --- a/arch/powerpc/boot/dts/fsl/t1040rdb.dts
> +++ b/arch/powerpc/boot/dts/fsl/t1040rdb.dts
> @@ -59,12 +59,6 @@ ethernet@e4000 {
> phy-handle = <&phy_sgmii_2>;
> phy-connection-type = "sgmii";
> };
> -
> - mdio@fc000 {
> - phy_sgmii_2: ethernet-phy@3 {
> - reg = <0x03>;
> - };
> - };
> };
> };
>
> @@ -76,3 +70,9 @@ cpld@3,0 {
> };
>
> #include "t1040si-post.dtsi"
> +
> +&mdio0 {
> + phy_sgmii_2: ethernet-phy@3 {
> + reg = <0x3>;
> + };
> +};
> --
> 2.25.1
RE: FSL P5020/P5040: DPAA Ethernet issue with the latest Git kernel
> From: Christian Zigotzky > Sent: Tuesday, July 7, 2020 9:26 PM > To: Madalin Bucur (OSS) > Cc: mad skateman ; Camelia Alexandra Groza > ; > linuxppc-...@ozlabs.org; net...@vger.kernel.org; R.T.Dickinson > ; > Darren Stevens > Subject: Re: FSL P5020/P5040: DPAA Ethernet issue with the latest Git kernel > > > On 7. Jul 2020, at 17:53, Madalin Bucur (OSS) > <mailto:madalin.bu...@oss.nxp.com> wrote: > Was DPAA functional before commit A? > How about after commit A and before commit B? > The DPAA Ethernet works from the kernel 5.6-rc4 [1] till the Git kernel from > the > 11 of June [2]. It doesn’t work since the commit “fix bitmap_parse” [3]. > [1] https://forum.hyperion-entertainment.com/viewtopic.php?p=49936#p49936 > [2] https://forum.hyperion-entertainment.com/viewtopic.php?p=50848#p50848 > [3] https://forum.hyperion-entertainment.com/viewtopic.php?p=50980#p50980 Hi, can you please try to disable the network manager (see [1]), then boot with the latest kernel, that does not work, and setup the interfaces manually? Madalin [1] https://help.ubuntu.com/community/NetworkManager#Stopping_and_Disabling_NetworkManager
RE: [PATCH net-next 00/23] Clean driver, module and FW versions
> -Original Message- > From: David Miller > Sent: Monday, March 2, 2020 5:02 AM > To: l...@kernel.org > Subject: Re: [PATCH net-next 00/23] Clean driver, module and FW versions > > From: Leon Romanovsky > Date: Sun, 1 Mar 2020 16:44:33 +0200 > > > This is second batch of the series which removes various static > > versions in favour of globaly defined Linux kernel version. > > This generally looks fine to me but I'll let it sit for a few days so > that others can review. Reviewed drivers/net/ethernet/freescale changes, thank you! Reviewed-by: Madalin Bucur
