Re: [PATCH net-next v4] net: stmmac: dwxgmac2: enable L2 split header support

[Sagar Cheluvegowda <sagar.cheluvegowda@oss.qualcomm.com>]

On 10/19/2026 3:29 PM, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 4 potential
> issue(s) to consider.
>
> Critical: 0 · High: 1 · Medium: 1 (1) · Low: 2
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [High] On XLGMAC cores, dwxgmac2_enable_sph() now corrupts the RX queue
>   enable register.

Agreed. DWXLGMAC_CORE_2_00 shares dwxgmac210_dma_ops, and on XLGMAC
offset 0x140 is XLGMAC_RXQ_ENABLE_CTRL0, so clearing BIT(8) would
disable RX queue 4. In v5 I will move the EXT_CFG0/EXT_CFG1 L2 split
programming into a MAC-level callback implemented only for XGMAC, so
XLGMAC is no longer touched.

> - [Medium] dwxgmac2_enable_sph() programs MAC-global split and preamble
>   settings regardless of `en`.

Agreed. In v5 the MAC-global configuration will be done once rather
than per RX channel. SPLM/SAVE_EN will be set and the variable preamble
disabled only when split header is enabled, and reverted when it is
disabled (e.g. when RXCSUM is turned off via ethtool). The commit
message will be updated to match.

> - [Low] The patch includes a fix for an existing XGMAC split-header bug
>   inside a feature patch, with no Fixes: tag.

Agreed. I will send the FD/LD handling in dwxgmac2_get_rx_header_len()
as a separate patch to net with:

Fixes: 96147375d49f ("net: stmmac: xgmac: Only get SPH header len if available")

and rebase the L2 split header support on top of it for net-next.

> - [Low] dwxgmac2_enable_sph() sets the 2-bit SPLM field
>   (XGMAC_CONFIG1_SPLM_MASK = GENMASK(9,8)) with `value |=…

Will clear XGMAC_CONFIG1_SPLM_MASK before setting the mode in v5.

> Pre-existing issues:
> - [Medium] This problem wasn't introduced by this patch, but the stmmac
>   RX path has no dma_rmb() between seeing RDES3.OWN cleared and reading…

This is not introduced by this patch, and the new FD/LD logic does not
depend on it. It affects the common stmmac RX path rather than just
XGMAC, so I will look into it separately from this series.

I will also fix the checkpatch line length warning reported by the
netdev CI in v5.

pw-bot: cr

Regards,
Sagar