linux-kernel - Re: [PATCH net-next V2 2/2] net: axienet: Add support for 2500base-X only configuration.

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: <Z9HjOAnpNkmZcoeo@shell.armlinux.org.uk>
Date: Wed, 12 Mar 2025 19:40:40 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: "Gupta, Suraj" <Suraj.Gupta2@....com>
Cc: Andrew Lunn <andrew@...n.ch>,
	"Pandey, Radhey Shyam" <radhey.shyam.pandey@....com>,
	"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	"Simek, Michal" <michal.simek@....com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"git (AMD-Xilinx)" <git@....com>,
	"Katakam, Harini" <harini.katakam@....com>
Subject: Re: [PATCH net-next V2 2/2] net: axienet: Add support for 2500base-X
 only configuration.

On Wed, Mar 12, 2025 at 04:08:02PM +0000, Gupta, Suraj wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@...n.ch>
> > Sent: Wednesday, March 12, 2025 9:03 PM
> > To: Gupta, Suraj <Suraj.Gupta2@....com>
> > Cc: Russell King <linux@...linux.org.uk>; Pandey, Radhey Shyam
> > <radhey.shyam.pandey@....com>; andrew+netdev@...n.ch;
> > davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> > pabeni@...hat.com; robh@...nel.org; krzk+dt@...nel.org; conor+dt@...nel.org;
> > Simek, Michal <michal.simek@....com>; netdev@...r.kernel.org;
> > devicetree@...r.kernel.org; linux-kernel@...r.kernel.org; linux-arm-
> > kernel@...ts.infradead.org; git (AMD-Xilinx) <git@....com>; Katakam, Harini
> > <harini.katakam@....com>
> > Subject: Re: [PATCH net-next V2 2/2] net: axienet: Add support for 2500base-X only
> > configuration.
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Wed, Mar 12, 2025 at 03:06:32PM +0000, Gupta, Suraj wrote:
> > > [AMD Official Use Only - AMD Internal Distribution Only]
> > >
> > > > -----Original Message-----
> > > > From: Andrew Lunn <andrew@...n.ch>
> > > > Sent: Wednesday, March 12, 2025 8:29 PM
> > > > To: Gupta, Suraj <Suraj.Gupta2@....com>
> > > > Cc: Russell King <linux@...linux.org.uk>; Pandey, Radhey Shyam
> > > > <radhey.shyam.pandey@....com>; andrew+netdev@...n.ch;
> > > > davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> > > > pabeni@...hat.com; robh@...nel.org; krzk+dt@...nel.org;
> > > > conor+dt@...nel.org; Simek, Michal <michal.simek@....com>;
> > > > netdev@...r.kernel.org; devicetree@...r.kernel.org;
> > > > linux-kernel@...r.kernel.org; linux-arm- kernel@...ts.infradead.org;
> > > > git (AMD-Xilinx) <git@....com>; Katakam, Harini
> > > > <harini.katakam@....com>
> > > > Subject: Re: [PATCH net-next V2 2/2] net: axienet: Add support for
> > > > 2500base-X only configuration.
> > > >
> > > > Caution: This message originated from an External Source. Use proper
> > > > caution when opening attachments, clicking links, or responding.
> > > >
> > > >
> > > > > > On Wed, Mar 12, 2025 at 02:25:27PM +0100, Andrew Lunn wrote:
> > > > > > > > +   /* AXI 1G/2.5G ethernet IP has following synthesis options:
> > > > > > > > +    * 1) SGMII/1000base-X only.
> > > > > > > > +    * 2) 2500base-X only.
> > > > > > > > +    * 3) Dynamically switching between (1) and (2), and is not
> > > > > > > > +    * implemented in driver.
> > > > > > > > +    */
> > > >
> > > > > - Keeping previous discussion short, identification of (3) depends
> > > > > on how user implements switching logic in FPGA (external GT or RTL
> > > > > logic). AXI 1G/2.5G IP provides only static speed selections and
> > > > > there is no standard register to communicate that to software.
> > > >
> > > > So if anybody has synthesised it as 3) this change will break their system?
> > > >
> > > >         Andrew
> > >
> > > It will just restrict their system to (2)
> >
> > Where as before, it was doing SGMII/1000base-X only. So such systems break?
> >
> >         Andrew
> 
> If the user wants (3), they need to add their custom FPGA logic which anyway will require additional driver changes. (3) was not completely supported by existing driver.

This is not an approach that works with the Linux kernel, sorry.

What we have today is a driver that works for people's hardware - and
we don't know what the capabilities of that hardware is.

If there's hardware out there today which has XAE_ABILITY_2_5G set, but
defaults to <=1G mode, this will work with the current driver. However,
with your patch applied, it stops working because instead of the driver
indicating MAC_10FD | MAC_100FD | MAC_1000FD, it only indicates
MAC_2500FD. If this happens, it will regress users setups, and that is
something we try not to do.

Saying "someone else needs to add the code for their FPGA logic" misses
the point - there may not be "someone else" to do that, which means
the only option is to revert your change if it were merged. That in
itself can cause its own user regressions because obviously stuff that
works with this patch stops working.

This is why we're being cautious, and given your responses, it's not
making Andrew or myself feel that there's a reasonable approach being
taken here.

>From everything you have said, I am getting the feeling that using
XAE_ABILITY_2_5G to decide which of (1) or (2) is supported is just
wrong. Given that we're talking about an implementation that has been
synthesized at 2.5G and can't operate slower, maybe there's some way
that could be created to specify that in DT?

e.g. (and I'm sure the DT folk aren't going to like it)...

	xlnx,axi-ethernet-X.YY.Z-2.5G

(where X.YY.Z is the version) for implementations that can _only_ do
2.5G, and leave all other implementations only doing 1G and below.

Or maybe some DT property. Or something else.

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