[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8dad36e2-88c0-4c10-a629-be032353fac2@lunn.ch>
Date: Sat, 21 Sep 2024 01:22:44 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Frank Sae <Frank.Sae@...or-comm.com>, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
xiaogang.fan@...or-comm.com, fei.zhang@...or-comm.com,
hua.sun@...or-comm.com
Subject: Re: [RFC] net:yt6801: Add Motorcomm yt6801 PCIe driver
> > +static int fxgmac_change_mtu(struct net_device *netdev, int mtu)
> > +{
> > + struct fxgmac_pdata *pdata = netdev_priv(netdev);
> > + int old_mtu = netdev->mtu;
> > + int ret, max_mtu;
> > +
> > + max_mtu = FXGMAC_JUMBO_PACKET_MTU - ETH_HLEN;
> > + if (mtu > max_mtu) {
> > + yt_err(pdata, "MTU exceeds maximum supported value\n");
>
> Always nice to include the offending value (mtu) instead of just a
> constant string with no real information other than "we were here".
This is actually pointless, the core will do this check and never
actually call this function if the MTU is out of range.
FYI: Networking people have not taken any sort of serious look at the
code, it needs breaking up into smaller patches.
Feel free to review PCI parts, but i suggest you ignore networking
for the moment.
Andrew
Powered by blists - more mailing lists