[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <289fa600-c722-48d7-bfb9-80ff31256cb5@lunn.ch>
Date: Mon, 16 Dec 2024 10:50:47 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
Mattias Forsblad <mattias.forsblad@...il.com>
Subject: Re: [PATCH 0/3] dsa: mv88e6xxx: Add RMU enable/disable ops
On Mon, Dec 16, 2024 at 12:59:10AM +0200, Vladimir Oltean wrote:
> Hi Andrew,
>
> On Sun, Dec 15, 2024 at 05:30:02PM +0000, Andrew Lunn wrote:
> > Add internal APIs for enabling the Remote Management Unit, and
> > extending the existing implementation to other families. Actually
> > making use of the RMU is not included here, that will be part of a
> > later big patch set, which without this preliminary patchset would be
> > too big.
> >
> > Signed-off-by: Andrew Lunn <andrew@...n.ch>
> > ---
>
> How big is the later patch set? Too big to accept even one more patch?
The patchset is 21 patches, if i only support one switch family.
I can remove a couple of patches, getting statistics via RMU, and
timing the RMU vs MDIO and disabling RMU if it is slower.
The other way i can slice it is split it into two patchsets:
1) incremental modifications to qca8k to centralise code
2) implement the mv88e6xxx changes to add RMU to it.
I did not really want to slice it like this, because the central API
is designed around what both QCA8K and Marvell needs, and hopefully is
generic enough for other devices. But there might be questions asked
when you can only see the qca8k refactor without the Marvell parts.
I can maybe squash some of the QCA patches together. Previously i was
doing lots of simple changes because i did not have hardware to test
on. I do have a QCA8K test system now.
> There is a risk that the RMU effort gets abandoned before it becomes
> functional. And in that case, we will have a newly introduced rmu_enable()
> operation which does nothing.
True, but i'm more motivated this time, i'm getting paid for the work :-)
And there is one other interested party as well that i know of.
This patch series is fully self contained, so it easy to revert, if
this ends up going nowhere.
Andrew
Powered by blists - more mailing lists