Message-ID: <aXN5BW9AZ-OKYVrt@shell.armlinux.org.uk>
Date: Fri, 23 Jan 2026 13:35:01 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH v2 0/3] net: phy: as21xxx: toggle In Band
 feature support

On Fri, Jan 23, 2026 at 02:09:01PM +0100, Christian Marangi wrote:
> On Fri, Jan 23, 2026 at 12:16:45PM +0000, Russell King (Oracle) wrote:
> > [Please note: gmail.com has become unreliable for email delivery,
> > google has too much power to decide what is spam and what isn't, with
> > no route for appeal. please consider switching to a different email
> > provider.]
> >
> 
> Thanks for reporting this. I'm also noticing for a while some legit
> email from mailing list going to spam. I have a new mail from a long
> time but never took the time to actually made the switch for kernel
> submission. Also it's mostly new so I guess it needs to earn some cretis
> as it will get directly rejected by some service. Chicken Egg problem...

It's worse than that. Google is permanently rejecting patch series from
me now - you won't even get it in your "spam" folder. This is only going
to get worse, because there is no way to appeal against this, and
domains such as my own, and even kernel.org, have to just suck it
because google has all the power due to its dominance, caused by people
using it.

The only solution to this is to stop using gmail, causing it to lose
market share.

> > On Fri, Jan 23, 2026 at 01:00:28PM +0100, Christian Marangi wrote:
> > > This is a new variant of the previous submitted patch adding a similar
> > > feature.
> > > 
> > > Old Aeonsemi Firmware permitted only to enable or disable In Band
> > > support and it couldn't be disabled after (or there wasn't a
> > > way to detect the current state of it)
> > > 
> > > As suggested by Russell this was bad Implementation. Some talk
> > > with Aeonsemi permitted to release a new firmware with correct
> > > implementation.
> > > 
> > > This series adds support for this if new firmware (1.9.1+) is
> > > used. On the new firmware, 2 new IPC command are introduced
> > > to GET the current state of DPC RA (Rate Adaption) or SET it.
> > > (DPC RA is effectively In Band mode)
> > > 
> > > It was verified on the same scenario and can confirm it works
> > > as expected. (Airoha AN7581/AN7583 with and without In Band
> > > mode) (If PCS is set to In Band and PHY isn't then no
> > > connection, so it's easy to verify correct functionality of
> > > this)
> > > 
> > > The new firmware is currently submitted to linux-firmware
> > > awaiting it to be merged.
> > > 
> > > For old firmware to save on compatibility we still enable
> > > In Band by default (this is what the current driver do)
> > > 
> > > This was discovered to be needed in some scenario as is effectively
> > > the most compatible featureset.
> > > 
> > > On a BananaPi R4 Pro, one of the 2 AS21xxx PHY is connected to
> > > one of the Switch port and such switch supports only In Band when
> > > set to USXGMII (assuming the Switch expect an SFP module to be
> > > attached where in absence of i2c or MDIO line In Band is always
> > > required)
> > 
> > Coupling the PHY's rate adaption with inband support, but not setting
> > phydev->rate_matching anywhere in this driver seems wrong, and highly
> > suspicious. I'm not sure what to think given what you've said above,
> > it just seems completely wrong what has happened here.
> > 
> 
> Honestly speaking the Rate Adaption thing is what I found in some
> strange API c code on the downstream driver where they say that in
> DPC_RA RA is Rate Adaption.
> 
> My personal idea is that, that thing toggle also other stuff and not only
> Rate Adaption.
> 
> On the Airoha PCS In Band is controlled by enabling and disabling AN
> register (and this also apply to Mediatek PCS)
> 
> With AN enabled, DPC RA needs to be enabled or no traffic.
> With AN disabled, DPC RA needs to be disabled or not traffic.
> 
> This both apply to Airoha and Mediatek PCS.
> 
> For the Switch, it's a different story. Everything is controlled by a
> Firmware blob and it's only possible to send command to setup the
> Serdes mode (USXGMII in this case)
> I made lots of test with forcing speed or trying to find a way to make
> it work but the only combo I found working was USXGMII + DPC_RA enabled.
> 
> For the lack of .get_rate_matching should be set to RATE_MATCH_NONE
> AFAIK for this PHY.
> 
> To give more info comments in the downstream driver at dpc_ra_enable
> have "Set USXGMII mode.".
> But I verified that PCS at USXGMII (but no In Band) and DPC_RA off
> I have correct link up and traffic. So it's not dropping to 10g base-r
> somehow with DPC_RA disabled and if it was the case the PCS should be
> configured for that mode (there are specific register for that).

Let me be clear: if the PHY hardware is doing rate adaption, then the
driver needs to be setting phydev->rate_matching accordingly when
reading the other media parameters from the PHY, so that other parts
of the system know that the media speed is not the speed that the
host interface to the PHY needs to operate at.

Only if the PHY is _not_ doing rate adaption, then setting it to
RATE_MATCH_NONE is appropriate. All other cases, it should be set
to one of the others.

-- 
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