[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZAnefI4vCZSIPkEK@shell.armlinux.org.uk>
Date: Thu, 9 Mar 2023 13:26:20 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Lukasz Majewski <lukma@...x.de>
Cc: Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <olteanv@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Alexander Duyck <alexander.duyck@...il.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/7] dsa: marvell: Add helper function to validate the
max_frame_size variable
On Thu, Mar 09, 2023 at 01:21:13PM +0000, Russell King (Oracle) wrote:
> On Thu, Mar 09, 2023 at 01:54:19PM +0100, Lukasz Majewski wrote:
> > This commit shall be regarded as a transition one, as this function helps
> > to validate the correctness of max_frame_size variable added to
> > mv88e6xxx_info structure.
> >
> > It is necessary to avoid regressions as manual assessment of this value
> > turned out to be error prone.
> >
> > Signed-off-by: Lukasz Majewski <lukma@...x.de>
> > Suggested-by: Russell King (Oracle) <linux@...linux.org.uk>
>
> Shouldn't this be patch 2 - immediately after populating the
> .max_frame_size members, and before adding any additional devices?
Moreover, shouldn't the patch order be:
1, 5, 6 (fixing the entry that needs it), 7 (which then gets the
max frame size support in place), 4 (so that .set_max_frame_size for
6250 is in place), 2, 3
?
In other words, get the new infrastructure you need in place first
(that being the new .max_frame_size and the .set_max_frame_size
function) before then adding the new support.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists