[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241217193139.47f4c984@kernel.org>
Date: Tue, 17 Dec 2024 19:31:39 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Vladimir Oltean <olteanv@...il.com>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 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, 16 Dec 2024 16:59:40 +0200 Vladimir Oltean wrote:
> > > 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.
Yes, we're not religious about the 15 patch rule. If you give it
an honest try and it doesn't make sense just say so in the cover
letter.
Powered by blists - more mailing lists