linux-kernel - RE: [PATCH net-next v2 2/2] net: phy: microchip

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:
 <CY5PR11MB6234815EB819D321645984708B042@CY5PR11MB6234.namprd11.prod.outlook.com>
Date: Tue, 17 Dec 2024 09:00:23 +0000
From: <Tarun.Alle@...rochip.com>
To: <andrew@...n.ch>
CC: <Arun.Ramadoss@...rochip.com>, <UNGLinuxDriver@...rochip.com>,
	<hkallweit1@...il.com>, <linux@...linux.org.uk>, <davem@...emloft.net>,
	<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next v2 2/2] net: phy: microchip_t1: Auto-negotiation
 support for LAN887x

Hi Andrew,

Thanks for the review.

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Tuesday, December 17, 2024 5:10 AM
> To: Tarun Alle - I68638 <Tarun.Alle@...rochip.com>
> Cc: Arun Ramadoss - I17769 <Arun.Ramadoss@...rochip.com>;
> UNGLinuxDriver <UNGLinuxDriver@...rochip.com>; hkallweit1@...il.com;
> linux@...linux.org.uk; davem@...emloft.net; edumazet@...gle.com;
> kuba@...nel.org; pabeni@...hat.com; netdev@...r.kernel.org; linux-
> kernel@...r.kernel.org
> Subject: Re: [PATCH net-next v2 2/2] net: phy: microchip_t1: Auto-negotiation
> support for LAN887x
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> On Mon, Dec 16, 2024 at 09:28:30PM +0530, Tarun Alle wrote:
> > Adds auto-negotiation support for lan887x T1 phy. After this commit,
> > by default auto-negotiation is on and default advertised speed is 1000M.
> 
> So i asked about the implications of this. I would of expected something like:
> 
> This will break any system which expects forced behaviour, without actually
> configuring forced behaviour both on the local system and where the link
> partner is expecting forced configuration, not autoneg.
> 

We confirmed that there are no customers who are directly using the net-next. 
Hence, we are setting this to default auto-neg which is also chip default. But if
any regressions on T1PHYs are dependent,  we will address this default setting.

> I think we also need some more details about the autoneg in the commit
> message. When used against a standards conforming 100M PHY, negotiation
> will fail by default, because this PHY is not conformant with 100M, or 1G
> autoneg.
> 

I should have given the same errata details in the commit message. Will take care.

> I don't like you are going to cause regressions, especially when you have decided
> regressions are worth it for a half broken autoneg.
> 
> I actually think it should default to fixed, as it is today. Maybe with the option to
> enable the broken autoneg. This is different to all PHYs we have today, but we try
> hard to avoid regressions.
> 
> What are the plans for this PHY? Will there be a new revision soon which fixes
> the broken autoneg? Maybe you should forget about autoneg for this revision
> of this PHY, it is too broken, and wait for the next revision which actually
> conforms to the standard?
> 

I understand your point and I agree with you. We can drop this patch for this chip 
revision as we have plans for new revision.

>         Andrew

Thanks,
Tarun Alle.