linux-kernel - Re: [net-next PATCH v2 0/3] net: phy: as21xxx: toggle In Band feature support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <697372f1.df0a0220.291d22.85ee@mx.google.com>
Date: Fri, 23 Jan 2026 14:09:01 +0100
From: Christian Marangi <ansuelsmth@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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 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...

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

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

-- 
	Ansuel