[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250926122116.iixyzxl3cjp2z66j@DEN-DL-M31836.microchip.com>
Date: Fri, 26 Sep 2025 14:21:16 +0200
From: Horatiu Vultur <horatiu.vultur@...rochip.com>
To: Vladimir Oltean <vladimir.oltean@....com>
CC: Jakub Kicinski <kuba@...nel.org>, <andrew@...n.ch>,
<hkallweit1@...il.com>, <linux@...linux.org.uk>, <davem@...emloft.net>,
<edumazet@...gle.com>, <pabeni@...hat.com>, <richardcochran@...il.com>,
<vadim.fedorenko@...ux.dev>, <rmk+kernel@...linux.org.uk>,
<christophe.jaillet@...adoo.fr>, <rosenp@...il.com>,
<steen.hegelund@...rochip.com>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net v2] phy: mscc: Fix PTP for vsc8574 and VSC8572
The 09/26/2025 15:20, Vladimir Oltean wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Fri, Sep 26, 2025 at 09:11:11AM +0200, Horatiu Vultur wrote:
> > I have been asking around about these revisions of the PHYs and what is
> > available:
> > vsc856x - only rev B exists
> > vsc8575 - only rev B exists
> > vsc8582 - only rev B exists
> > vsc8584 - only rev B exists
> > vsc8574 - rev A,B,C,D,E exists
> > vsc8572 - rev A,B,C,D,E exists
> >
> > For vsc856x, vsc8575, vsc8582, vsc8584 the lower 4 bits in register 3
> > will have a value of 1.
> > For vsc8574 and vsc8572 the lower 4 bits in register 3 will have a value
> > of 0 for rev A, 1 for rev B and C, 2 for D and E.
> >
> > Based on this information, I think both commits a5afc1678044 and
> > 75a1ccfe6c72 are correct regarding the revision check.
> >
> > So, now to be able to fix the PTP for vsc8574 and vsc8572, I can do the
> > following:
> > - start to use PHY_ID_MATCH_MODEL for vsc856x, vsc8575, vsc8582, vsc8584
> > - because of this change I will need to remove also the WARN_ON() in the
> > function vsc8584_config_init()
> > - then I can drop the check for revision in vsc8584_probe()
> > - then I can make vsc8574 and vsc8572 to use vsc8584_probe()
> >
> > What do you think about this?
>
> This sounds good, however I don't exactly understand how it fits in with
> your response to Russell to replace phydev->phy_id with phydev->drv->phy_id
> in the next revision. If the revision check in vsc8584_probe() goes away,
> where will you use phydev->drv->phy_id?
I got a little bit confused here.
Because no one answer to this email, I thought it might not be OK, so
that is the reason why I said that I will go with Russell approach.
But if you think that this approach that I proposed here is OK (as you seem
to be). Then I will go with this and then I will not do Russell
suggestion because it is not needed anymore.
--
/Horatiu
Powered by blists - more mailing lists