Re: [PATCH 0/3] dsa: mv88e6xxx: Add RMU enable/disable ops

[Vladimir Oltean <olteanv@gmail.com>]

On Mon, Dec 16, 2024 at 10:50:47AM +0100, Andrew Lunn wrote:
> > 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.

So what's a no-go is introducing code with no user.

Splitting into 2 sets like this should be fine. You could post a link to
Github with the complete picture when you post the qca8k refactoring, so
that we know what to expect next and where things are going. Hopefully
it makes sense on its own and does not leave loose ends hanging.

I don't think that squashing multiple logical changes to fit the 15
patch limit is a good idea.