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] [day] [month] [year] [list]
Date:   Thu, 11 Jun 2020 11:31:18 +0530
From:   Calvin Johnson <calvin.johnson@....nxp.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Jeremy Linton <jeremy.linton@....com>,
        Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH RFC v2 6/9] net: phy: add support for probing MMDs >= 8
 for devices-in-package

On Wed, Jun 10, 2020 at 05:34:17PM +0100, Russell King - ARM Linux admin wrote:
> On Wed, Jun 10, 2020 at 09:46:33PM +0530, Calvin Johnson wrote:
> > Hi Russell,
> > 
> > On Wed, May 27, 2020 at 11:34:11AM +0100, Russell King wrote:
> > > Add support for probing MMDs above 7 for a valid devices-in-package
> > > specifier, but only probe the vendor MMDs for this if they also report
> > > that there the device is present in status register 2.  This avoids
> > > issues where the MMD is implemented, but does not provide IEEE 802.3
> > > compliant registers (such as the MV88X3310 PHY.)
> > 
> > While this patch looks good to me, commit message doesn't seem to align
> > with the code changes as it is dealing with MMD at addresses 30 & 31.
> > Can you please clarify?
> 
> IEEE 802.3 does not define the "device-is-present" two bits in register
> 8 for all MMDs - it is only present for MMDs 1, 2, 3, 4, 5, 30 and 31.
> None of the other MMDs, even those that have been recently defined (at
> least in IEEE 802.3-2018) have these bits.
> 
> Hence, we can't use them except on the MMDs where they are defined to
> be present.
> 
> I considered also checking them in MMDs 1, 2, 3, 4, 5, but decided that
> the risk of regression was too high for this patch; that's something
> which could be added in a separate patch though, to avoid having to
> revert the entire thing if a regression is found at a later date.
 
It makes sense to me now.

Thanks
Calvin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ