Message-ID:
 <DS7PR11MB6102D0B2985344C770AEC293E2E4A@DS7PR11MB6102.namprd11.prod.outlook.com>
Date: Fri, 3 Oct 2025 12:59:40 +0000
From: <Divya.Koppera@...rochip.com>
To: <josef@...chen.org>, <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: phy: microchip_t1: LAN887X: Fix device init issues.



> -----Original Message-----
> From: Josef Raschen <josef@...chen.org>
> Sent: Tuesday, September 30, 2025 1:00 AM
> To: Andrew Lunn <andrew@...n.ch>
> Cc: Arun Ramadoss - I17769 <Arun.Ramadoss@...rochip.com>;
> UNGLinuxDriver <UNGLinuxDriver@...rochip.com>; Heiner Kallweit
> <hkallweit1@...il.com>; Russell King <linux@...linux.org.uk>; 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: [PATCH] net: phy: microchip_t1: LAN887X: Fix device init issues.
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> On 9/26/25 23:46, Andrew Lunn wrote:
> > On Fri, Sep 26, 2025 at 11:24:56PM +0200, Josef Raschen wrote:
> >> Hello Andrew,
> >>
> >> Thanks for your feedback.
> >>
> >> On 9/26/25 00:00, Andrew Lunn wrote:
> >>> On Thu, Sep 25, 2025 at 10:52:22PM +0200, Josef Raschen wrote:
> >>>> Currently, for a LAN8870 phy, before link up, a call to ethtool to
> >>>> set master-slave fails with 'operation not supported'. Reason:
> >>>> speed, duplex and master/slave are not properly initialized.
> >>>>
> >>>> This change sets proper initial states for speed and duplex and
> >>>> publishes master-slave states. A default link up for speed 1000,
> >>>> full duplex and slave mode then works without having to call ethtool.
> >>>
> >>> Hi Josef
> >>>
> >>> What you are missing from the commit message is an explanation why
> >>> the
> >>> LAN8870 is special, it needs to do something no other PHY does. Is
> >>> there something broken with this PHY? Some register not following
> >>> 802.3?
> >>>
> >>>       Andrew
> >>>
> >>> ---
> >>> pw-bot: cr
> >>>
> >>
> >> Special about the LAN8870 might be that it is a dual speed T1 phy.
> >> As most other T1 pyhs have only one possible configuration the
> >> unknown speed configuration was not a problem so far. But here, when
> >> calling link up without manually setting the speed before, it seems
> >> to pick speed 100 in phy_sanitize_settings(). I assume that this is
> >> not the desired behavior?
> >
> > What speeds does the PHY say it supports?
> >
> > phy_sanitize_settings() should pick the highest speed the PHY supports
> > as the default. So if it is picking 100, it suggests the PHY is not
> > reporting it supports 1000? Or phy_sanitize_settings() is broken for
> > 1000Base-T1? Please try understand why it is picking 100.
> 
> It should pick 1000 then for this phy. I checked already that the device is
> actually reporting being 100Base-T1 and 1000Base-T1 capable. I will have a
> look, why it doesn't pick SPEED_1000 then. I did not know that
> phy_sanitize_settings() is supposed to pick the highest speed already.
> 
Hi Josef & Andrew,

phy_sanitize_settings() is supposed to pick the least supported speed from the supported list when speed is not initialized.

In latest stable kernel(v6.12.x) we see a bug(Incorrect data types in phylink data structure and function arguments).
Due to which we are observing the highest supported speed is being selected.
Refer https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/phy/phy-core.c?h=v6.12.43#n305
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/phy.h?h=v6.12.43#n1277In 

Here comparison is done between unsigned and signed speed, due to which the match is been select for the highest speed itself.

Tested code:
308                 if (!match && p->speed <= speed) {
 309             	pr_info("lookup: speed = %d rcvd speed = %d\n", p->speed, speed);
 310                     /* Candidate */
 311                     match = p;
 312                    }

Output print:
[Fri Oct  3 18:24:27 2025] lookup: speed = 1000 rcvd speed = -1   ==> the comparison is false and this should not executed.

Latest net-next doesn't have this inconsistency with data type for the same speed parameter.
So there is no issue and we are seeing the correct lowest supported speed which is 100m.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/phy_caps.c?h=v6.17#n210
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/phy-caps.h?h=v6.17#n39

May be we need to fix the stable kernels to address the data type issue.

Thanks,
Divya
> >> The second problem is that ethtool initially does not allow to set
> >> master-slave at all. You first have to call ethtool without the
> >> master-slave argument, then again with it. This is fixed by reading
> >> the master slave configuration from the device which seems to be
> >> missing in the .config_init and .config_aneg functions. I took this
> >> solution from net/phy/dp83tg720.c.
> >
> > How does this work with a regular T4 or T2 PHY? Ideally, A T1 should
> > be no different. And ideally, we want a solution for all T1 PHYs,
> > assuming it is not something which is special for this PHY.
> 
> I agree, a generic solution would be best. I will read a bit into the code to see if
> there is a better solution.
> 
> Thanks,
> Josef

Powered by blists - more mailing lists