From: Jakub Kicinski <kuba@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Russell King <linux@armlinux.org.uk>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Mattias Forsblad <mattias.forsblad@gmail.com>
Subject: Re: [PATCH 0/3] dsa: mv88e6xxx: Add RMU enable/disable ops
Date: Tue, 17 Dec 2024 19:31:39 -0800 [thread overview]
Message-ID: <20241217193139.47f4c984@kernel.org> (raw)
In-Reply-To: <20241216145940.ybbwiige7dhkpzaa@skbuf>
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.
prev parent reply other threads:[~2024-12-18 3:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-15 17:30 [PATCH 0/3] dsa: mv88e6xxx: Add RMU enable/disable ops Andrew Lunn
2024-12-15 17:30 ` [PATCH 1/3] net: dsa: mv88e6xxx: Add RMU enable for switches that support disable Andrew Lunn
2024-12-15 17:30 ` [PATCH 2/3] net: dsa: mv88e6xxx: Enable RMU on 6165 family Andrew Lunn
2024-12-15 17:30 ` [PATCH 3/3] net: dsa: mv88e6xxx: Enable RMU on 6351 family Andrew Lunn
2024-12-15 17:42 ` [PATCH 0/3] dsa: mv88e6xxx: Add RMU enable/disable ops Andrew Lunn
2024-12-15 22:59 ` Vladimir Oltean
2024-12-16 9:50 ` Andrew Lunn
2024-12-16 14:59 ` Vladimir Oltean
2024-12-18 3:31 ` Jakub Kicinski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241217193139.47f4c984@kernel.org \
--to=kuba@kernel.org \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mattias.forsblad@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).