Re: [PATCH RESEND net-next v6 2/3] net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller

[Yao Zi <me@ziyao.cc>]

On Mon, Jan 12, 2026 at 06:10:26AM +0000, Sai Krishna Gajula wrote:
> 
> 
> > -----Original Message-----
> > From: Yao Zi <me@ziyao.cc>
> > Sent: Friday, January 9, 2026 3:05 PM
> > To: Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller
> > <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> > Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Frank
> > <Frank.Sae@motor-comm.com>; Heiner Kallweit <hkallweit1@gmail.com>;
> > Russell King <linux@armlinux.org.uk>; Russell King (Oracle)
> > <rmk+kernel@armlinux.org.uk>; Vladimir Oltean
> > <vladimir.oltean@nxp.com>; Chen-Yu Tsai <wens@csie.org>; Jisheng Zhang
> > <jszhang@kernel.org>; Furong Xu <0x1207@gmail.com>
> > Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org; Mingcong Bai
> > <jeffbai@aosc.io>; Kexy Biscuit <kexybiscuit@aosc.io>; Yao Zi <me@ziyao.cc>;
> > Runhua He <hua@aosc.io>; Xi Ruoyao <xry111@xry111.site>
> > Subject: [PATCH RESEND net-next v6 2/3] net: stmmac: Add glue
> > driver for Motorcomm YT6801 ethernet controller
> > 
> > Motorcomm YT6801 is a PCIe ethernet controller based on DWMAC4 IP. It
> > integrates an GbE phy, supporting WOL, VLAN tagging and various types of
> > offloading. It ships an on-chip eFuse for storing various vendor configuration,
> > including MAC address.
> > Motorcomm YT6801 is a PCIe ethernet controller based on DWMAC4 IP. It
> > integrates an GbE phy, supporting WOL, VLAN tagging and various types of
> > offloading. It ships an on-chip eFuse for storing various vendor configuration,
> > including MAC address.
> > 
> > This patch adds basic glue code for the controller, allowing it to be set up and
> > transmit data at a reasonable speed. Features like WOL could be implemented
> > in the future.
> > 
> > Signed-off-by: Yao Zi <me@ziyao.cc>
> > Tested-by: Mingcong Bai <jeffbai@aosc.io>
> > Tested-by: Runhua He <hua@aosc.io>
> > Tested-by: Xi Ruoyao <xry111@xry111.site>
> > ---
> >  drivers/net/ethernet/stmicro/stmmac/Kconfig   |   9 +
> >  drivers/net/ethernet/stmicro/stmmac/Makefile  |   1 +
> >  .../ethernet/stmicro/stmmac/dwmac-motorcomm.c | 384
> > ++++++++++++++++++
> >  3 files changed, 394 insertions(+)

...

> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
> > b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
> > new file mode 100644
> > index 000000000000..8b45b9cf7202
> > --- /dev/null
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c

...

> > +static int motorcomm_efuse_read_patch(struct dwmac_motorcomm_priv
> > *priv,
> > +				      u8 index,
> > +				      struct motorcomm_efuse_patch *patch) {
> Minor nit
> This format breaks  kernel style function definition, use as below ( "{" in next line)
> static int motorcomm_efuse_read_patch(struct dwmac_motorcomm_priv
>                                                                           *priv,
> 				                 u8 index,
> 				                 struct motorcomm_efuse_patch *patch) 
> {

This is strange, I didn't put the left curly brace in the same line as
the argument list. You could confirm this in the mbox archived by
lore[1]. Same for other functions.

I've talked to other recipients of the patch, and one uses Outlook as
MTA reported similar issues. It seems Outlook MTA (not the server)
automatically removes the line break and the plus sign before the curly
brace.

I checked your Message-ID and found you're also using Outlook as service
provider, if Outlook is also your MTA, could you try turn off option
"Remove extra line breaks in plain text messages" and see whether the
problem gets fixed?

...

> > +static int motorcomm_setup_irq(struct pci_dev *pdev,
> > +			       struct stmmac_resources *res,
> > +			       struct plat_stmmacenet_data *plat) {
> > +	int ret;
> > +
> > +	ret = pci_alloc_irq_vectors(pdev, 6, 6, PCI_IRQ_MSIX);
> > +	if (ret > 0) {
> > +		res->rx_irq[0]	= pci_irq_vector(pdev, 0);
> > +		res->tx_irq[0]	= pci_irq_vector(pdev, 4);
> > +		res->irq	= pci_irq_vector(pdev, 5);
> > +
> > +		plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> > +	} else {
> > +		dev_info(&pdev->dev, "failed to allocate MSI-X vector: %d\n",
> > +			 ret);
> > +		dev_info(&pdev->dev, "try MSI instead\n");
> > +
> > +		ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
> > +		if (ret < 0)
> > +			return dev_err_probe(&pdev->dev, ret,
> > +					     "failed to allocate MSI\n");
> > +
> > +		res->irq = pci_irq_vector(pdev, 0);
> > +	}
> 
> If possible, add enum for MAX MSIX count (in this case 6 ), or dynamic values as per hardware. 

The only Motorcomm PCIe ethernet controller I could find is YT6801, so
I don't think there's a need for per-hardware values (at least for now).
Will add a constant to represent MSI-X count in the next version.

...

> Reviewed-by: Sai Krishna <saikrishnag@marvell.com>

Thanks for reviewing.

Best regards,
Yao Zi

[1]: https://lore.kernel.org/all/20260109093445.46791-4-me@ziyao.cc/raw