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]
Date:   Thu, 18 Mar 2021 17:48:38 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Florian Fainelli <f.fainelli@...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>
Cc:     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 18.03.2021 17:02, 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.
> --

In the OUI list I found entry 58-9C-FC, belonging to FreeBSD Foundation.
Not sure what they use it for, but it seems adding Linux as a vendor
wouldn't be a total exception.

> Florian
> 
Heiner

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ