Message-ID: <aO_X6Hv2R_mgpOXR@shell.armlinux.org.uk>
Date: Wed, 15 Oct 2025 18:20:40 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Jose Abreu <joabreu@...opsys.com>,
	Andrew Lunn <andrew+netdev@...n.ch>, davem@...emloft.net,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Richard Cochran <richardcochran@...il.com>,
	Köry Maincent <kory.maincent@...tlin.com>,
	Alexis Lothoré <alexis.lothore@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/3] net: stmmac: Move subsecond increment
 configuration in dedicated helper

On Wed, Oct 15, 2025 at 06:20:03PM +0200, Maxime Chevallier wrote:
> Hi Russell,
> 
> On 15/10/2025 17:06, Russell King (Oracle) wrote:
> > On Wed, Oct 15, 2025 at 12:27:21PM +0200, Maxime Chevallier wrote:
> >> +static void stmmac_update_subsecond_increment(struct stmmac_priv *priv)
> >> +{
> >> +	bool xmac = priv->plat->has_gmac4 || priv->plat->has_xgmac;
> > 
> > Just to say that I have patches that get rid of these has_xxx flags for
> > the cores, and these changes (and the additional platform glue patches
> > that have been posted) will conflict with them.
> 
> Fair, I was in your position not so long ago :)
> 
> For this particular series, it should be straightforward to fix the
> conflict, but for the pending new glue divers we'll have to
> find the sweet spot for these changes.
> 
> Maybe send it as an RFC so that people can see what to expect ?

My experience of sending RFCs is the engagement is sadly low to non-
existent, leading to the question of whether sending RFCs has any
use at all. I'm pretty fed up with the whole mainline kernel process,
trying to get engagement from people, that I question why I bother
most of the time.

> > Given the rate of change in stmmac, at some point we're going to have
> > to work out some way of stopping stmmac development to get such an
> > invasive cleanup change merged
> 
> Agreed.
> 
>  - but with my variability and pressures
> > on the time I can spend even submitting patches, I've no idea how that
> > will work... I was going to send them right at the start of this
> > cycle, but various appointments on Monday and Tuesday this week plus
> > work pressures prevented that happening.
> 
> To give your more visibility, that's the only work I plan to do on
> stmmac for that cycle, the rest is going to be phy_port,
> and probably some netdevsim-phy.

I'd prefer that my five patch series I've just sent out is merged
(the patches I'm talking about w.r.t. has_xxx follow immediately
after these in my queue.) However, I don't think there's any
conflicts between the five I've sent out and these changes looking
at their overall diffs. That said, pushing out loads of patches in
one day isn't helpful to the already overworked reviewers.

> Do you plan to send the next round of PCS stuff next, or the cleanups
> for the has_xxx flags you were mentioning ?

It depends whether there's any conflicting changes. I have such a
backlog that I'm trying to send out as many non-conflicting netdev
related topics as I can to get the maximum merged when I have the
opportunity, even if the topics end up touching the same files.
I just totalled up the backlog - it's around 120 stmmac related
patches (including adding the phylink core WoL support), plus about
20 for marvell PTP. Eek! :/

When one has so many patches, "what to send out next" becomes a major
decision, and really depends on previous patch set progress.

As you explicitly ask about the PCS stuff and cleanups, I've sent
the first batch (which is the bulk) of PCS stuff today, and non-
overlapping cleanup changes.  If the cleanup changes go in, then
the next tranch of cleanups will have the has_xxx change in.

If the PCS changes go in, then I'll send out the next two patches
which move the PCS interrupt control over to phylink. After that
comes the potentially regression inducing change - making stmmac's
PCS follow what phylink requests of it. I'm expecting that to cause
trouble, but I have no confidence that it'll get enough testing to
uncover issues before being merged. This change really needs testing
on those platforms that use the DWMAC integrated PCS (not xpcs).

If all goes well with the patches I've sent today, then I'm expecting
them to be merged over this coming weekend. That means the next patches
will be sent early next week.

So... if your changes can be merged before or around the time that my
5-patch cleanup gets merged, I can rebase my changes on top, but if
your patch set needs re-posting, I suggest we have another discussion
how we proceed.

As mentioned, I'm aware that there are other patches that have already
been submitted that add platform glue that reference the has_xxx stuff,
so if these get merged, a rebase is going to be required. (annoyingly,
this will be high-risk because of getting the compile coverage to
catch every reference.. unless I remember to grep for them after
rebasing.)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists