netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	Wong Vee Khee <vee.khee.wong@intel.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Russell King <linux@armlinux.org.uk>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Voon Weifeng <weifeng.voon@intel.com>,
	Ong Boon Leong <boon.leong.ong@intel.com>
Subject: Re: [PATCH net V2 1/1] net: phy: fix invalid phy id when probe using C22
Date: Thu, 18 Mar 2021 11:58:07 -0700	[thread overview]
Message-ID: <665e347d-b4fc-b893-0317-3d04624fc1ba@gmail.com> (raw)
In-Reply-To: <YFOYclhA75hjmQHY@kroah.com>



On 3/18/2021 11:14 AM, Greg KH wrote:
> 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 :)

We would still be creating what is technically an user-space interface
breakage since prior to a given kernel version we would return 0 for
that PHY OUI, and after another point it would be something different. I
don't know what software out there may be expecting to find 0 and not
determine that the PHY was fixed already because it is under
/sys/class/mdio_bus/fixed-0
-- 
Florian

  reply	other threads:[~2021-03-18 18:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18  9:09 [PATCH net V2 1/1] net: phy: fix invalid phy id when probe using C22 Wong Vee Khee
2021-03-18 13:25 ` Heiner Kallweit
2021-03-18 16:02   ` Florian Fainelli
2021-03-18 16:21     ` Russell King - ARM Linux admin
2021-03-18 16:48     ` Heiner Kallweit
2021-03-18 18:14     ` Greg KH
2021-03-18 18:58       ` Florian Fainelli [this message]
2021-03-19  7:40 ` Heiner Kallweit
2021-03-19  8:56   ` Russell King - ARM Linux admin
2021-03-22 12:39     ` Wong, Vee Khee
2021-03-26  1:57 ` [net] c0da0048be: WARNING:at_net/core/devlink.c:#devlink_port_type_warn kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=665e347d-b4fc-b893-0317-3d04624fc1ba@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=boon.leong.ong@intel.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=vee.khee.wong@intel.com \
    --cc=weifeng.voon@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).