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: <YFOYclhA75hjmQHY@kroah.com>
Date:   Thu, 18 Mar 2021 19:14:10 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Wong Vee Khee <vee.khee.wong@...el.com>,
        Andrew Lunn <andrew@...n.ch>,
        Russell King <linux@...linux.org.uk>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Voon Weifeng <weifeng.voon@...el.com>,
        Ong Boon Leong <boon.leong.ong@...el.com>
Subject: Re: [PATCH net V2 1/1] net: phy: fix invalid phy id when probe using
 C22

On Thu, Mar 18, 2021 at 09:02:22AM -0700, Florian Fainelli wrote:
> 
> 
> On 3/18/2021 6:25 AM, Heiner Kallweit wrote:
> > On 18.03.2021 10:09, Wong Vee Khee wrote:
> >> When using Clause-22 to probe for PHY devices such as the Marvell
> >> 88E2110, PHY ID with value 0 is read from the MII PHYID registers
> >> which caused the PHY framework failed to attach the Marvell PHY
> >> driver.
> >>
> >> Fixed this by adding a check of PHY ID equals to all zeroes.
> >>
> > 
> > I was wondering whether we have, and may break, use cases where a PHY,
> > for whatever reason, reports PHY ID 0, but works with the genphy
> > driver. And indeed in swphy_read_reg() we return PHY ID 0, therefore
> > the patch may break the fixed phy.
> > Having said that I think your patch is ok, but we need a change of
> > the PHY ID reported by swphy_read_reg() first.
> > At a first glance changing the PHY ID to 0x00000001 in swphy_read_reg()
> > should be sufficient. This value shouldn't collide with any real world
> > PHY ID.
> 
> It most likely would not, but it could be considered an ABI breakage,
> unless we filter out what we report to user-space via SIOGCMIIREG and
> /sys/class/mdio_bus/*/*/phy_id
> 
> Ideally we would have assigned an unique PHY OUI to the fixed PHY but
> that would have required registering Linux as a vendor, and the process
> is not entirely clear to me about how to go about doing that.

If you need me to do that under the umbrella of the Linux Foundation,
I'll be glad to do so if you point me at the proper group to do that
with.

We did this for a few years with the USB-IF and have a vendor id
assigned to us for Linux through them, until they kicked us out because.
But as the number is in a global namespace, it can't be reused so we
keep it :)

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ