netdev - RE: [PATCH 2/2] net: dsa: microchip: Provide Module 4 KSZ9477 errata (DS80000754C)

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: <BYAPR11MB3558EFBB4DBC86AC3C338747ECE7A@BYAPR11MB3558.namprd11.prod.outlook.com>
Date: Tue, 29 Aug 2023 21:57:50 +0000
From: <Tristram.Ha@...rochip.com>
To: <olteanv@...il.com>
CC: <f.fainelli@...il.com>, <andrew@...n.ch>, <davem@...emloft.net>,
	<edumazet@...gle.com>, <kuba@...nel.org>, <Woojung.Huh@...rochip.com>,
	<pabeni@...hat.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <UNGLinuxDriver@...rochip.com>,
	<lukma@...x.de>
Subject: RE: [PATCH 2/2] net: dsa: microchip: Provide Module 4 KSZ9477 errata
 (DS80000754C)

> On Fri, Aug 25, 2023 at 06:48:41PM +0000, Tristram.Ha@...rochip.com wrote:
> > > > IMHO adding functions to MMD modification would facilitate further
> > > > development (for example LED setup).
> > >
> > > We already have some KSZ9477 specific initialization done in the Micrel
> > > PHY driver under drivers/net/phy/micrel.c, can we converge on the PHY
> > > driver which has a reasonable amount of infrastructure for dealing with
> > > workarounds, indirect or direct MMD accesses etc.?
> >
> > Actually the internal PHY used in the KSZ9897/KSZ9477/KSZ9893 switches
> > are special and only used inside those switches.  Putting all the switch
> > related code in Micrel PHY driver does not really help.  When the switch
> > is reset all those PHY registers need to be set again, but the PHY driver
> > only executes those code during PHY initialization.  I do not know if
> > there is a good way to tell the PHY to re-initialize again.
> 
> Suppose there was a method to tell the PHY driver to re-initialize itself.
> What would be the key points in which the DSA switch driver would need
> to trigger that method? Where is the switch reset at runtime?

Currently the DSA switch driver loads independently and is then
controlled by the main DSA driver.  The switch is reset during
initialization, and later the PHYs are initialized.  I was talking
hypothetically that the switch may need to be reset to correct some
hardware problems, but then there may be no good way to tell the PHYs to
re-initialize.