From: Jeremy Linton <jeremy.linton@arm.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: netdev@vger.kernel.org, davem@davemloft.net, andrew@lunn.ch,
f.fainelli@gmail.com, hkallweit1@gmail.com,
madalin.bucur@oss.nxp.com, calvin.johnson@oss.nxp.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC 04/11] net: phy: Handle c22 regs presence better
Date: Mon, 25 May 2020 17:22:07 -0500 [thread overview]
Message-ID: <a9490c28-ebe1-ed6d-e65e-2e1d0a06386b@arm.com> (raw)
In-Reply-To: <20200525220127.GO1551@shell.armlinux.org.uk>
On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
> On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
>> Hi,
>>
>> On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
>>> On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
>>>> Hi,
>>>>
>>>> On 5/23/20 1:37 PM, Russell King - ARM Linux admin wrote:
>>>>> On Fri, May 22, 2020 at 04:30:52PM -0500, Jeremy Linton wrote:
>>>>>> Until this point, we have been sanitizing the c22
>>>>>> regs presence bit out of all the MMD device lists.
>>>>>> This is incorrect as it causes the 0xFFFFFFFF checks
>>>>>> to incorrectly fail. Further, it turns out that we
>>>>>> want to utilize this flag to make a determination that
>>>>>> there is actually a phy at this location and we should
>>>>>> be accessing it using c22.
>>>>>>
>>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>>>>> ---
>>>>>> drivers/net/phy/phy_device.c | 16 +++++++++++++---
>>>>>> 1 file changed, 13 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>>>>>> index f0761fa5e40b..2d677490ecab 100644
>>>>>> --- a/drivers/net/phy/phy_device.c
>>>>>> +++ b/drivers/net/phy/phy_device.c
>>>>>> @@ -689,9 +689,6 @@ static int get_phy_c45_devs_in_pkg(struct mii_bus *bus, int addr, int dev_addr,
>>>>>> return -EIO;
>>>>>> *devices_in_package |= phy_reg;
>>>>>> - /* Bit 0 doesn't represent a device, it indicates c22 regs presence */
>>>>>> - *devices_in_package &= ~BIT(0);
>>>>>> -
>>>>>> return 0;
>>>>>> }
>>>>>> @@ -742,6 +739,8 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
>>>>>> int i;
>>>>>> const int num_ids = ARRAY_SIZE(c45_ids->device_ids);
>>>>>> u32 *devs = &c45_ids->devices_in_package;
>>>>>> + bool c22_present = false;
>>>>>> + bool valid_id = false;
>>>>>> /* Find first non-zero Devices In package. Device zero is reserved
>>>>>> * for 802.3 c45 complied PHYs, so don't probe it at first.
>>>>>> @@ -770,6 +769,10 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
>>>>>> return 0;
>>>>>> }
>>>>>> + /* Bit 0 doesn't represent a device, it indicates c22 regs presence */
>>>>>> + c22_present = *devs & BIT(0);
>>>>>> + *devs &= ~BIT(0);
>>>>>> +
>>>>>> /* Now probe Device Identifiers for each device present. */
>>>>>> for (i = 1; i < num_ids; i++) {
>>>>>> if (!(c45_ids->devices_in_package & (1 << i)))
>>>>>> @@ -778,6 +781,13 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
>>>>>> ret = _get_phy_id(bus, addr, i, &c45_ids->device_ids[i], true);
>>>>>> if (ret < 0)
>>>>>> return ret;
>>>>>> + if (valid_phy_id(c45_ids->device_ids[i]))
>>>>>> + valid_id = true;
>>>>>
>>>>> Here you are using your "devices in package" validator to validate the
>>>>> PHY ID value. One of the things it does is mask this value with
>>>>> 0x1fffffff. That means you lose some of the vendor OUI. To me, this
>>>>> looks completely wrong.
>>>>
>>>> I think in this case I was just using it like the comment in
>>>> get_phy_device() "if the phy_id is mostly F's, there is no device here".
>>>>
>>>> My understanding is that the code is trying to avoid the 0xFFFFFFFF returns
>>>> that seem to indicate "bus ok, phy didn't respond".
>>>>
>>>> I just checked the OUI registration, and while there are a couple OUI's
>>>> registered that have a number of FFF's in them, none of those cases seems to
>>>> overlap sufficiently to cause this to throw them out. Plus a phy would also
>>>> have to have model+revision set to 'F's. So while might be possible, if
>>>> unlikely, at the moment I think the OUI registration keeps this from being a
>>>> problem. Particularly, if i'm reading the mapping correctly, the OUI mapping
>>>> guarantees that the field cannot be all '1's due to the OUI having X & M
>>>> bits cleared. It sort of looks like the mapping is trying to lose those
>>>> bits, by tossing bit 1 & 2, but the X & M are in the wrong octet (AFAIK, I
>>>> just read it three times cause it didn't make any sense).
>>>
>>> I should also note that we have at least one supported PHY where one
>>> of the MMDs returns 0xfffe for even numbered registers and 0x0000 for
>>> odd numbered registers in one of the vendor MMDs for addresses 0
>>> through 0xefff - which has a bit set in the devices-in-package.
>>>
>>> It also returns 0x0082 for almost every register in MMD 2, but MMD 2's
>>> devices-in-package bit is clear in most of the valid MMDs, so we
>>> shouldn't touch it.
>>>
>>> These reveal the problem of randomly probing MMDs - they can return
>>> unexpected values and not be as well behaved as we would like them to
>>> be. Using register 8 to detect presence may be beneficial, but that
>>> may also introduce problems as we haven't used that before (and we
>>> don't know whether any PHY that wrong.) I know at least the 88x3310
>>> gets it right for all except the vendor MMDs, where the low addresses
>>> appear non-confromant to the 802.3 specs. Both vendor MMDs are
>>> definitely implemented, just not with anything conforming to 802.3.
>>
>> Yes, we know even for the NXP reference hardware, one of the phy's doesn't
>> probe out correctly because it doesn't respond to the ieee defined
>> registers. I think at this point, there really isn't anything we can do
>> about that unless we involve the (ACPI) firmware in currently nonstandard
>> behaviors.
>>
>> So, my goals here have been to first, not break anything, and then do a
>> slightly better job finding phy's that are (mostly?) responding correctly to
>> the 802.3 spec. So we can say "if you hardware is ACPI conformant, and you
>> have IEEE conformant phy's you should be ok". So, for your example phy, I
>> guess the immediate answer is "use DT" or "find a conformant phy", or even
>> "abstract it in the firmware and use a mailbox interface".
>
> You haven't understood. The PHY does conform for most of the MMDs,
> but there are a number that do not conform.
Probably...
Except that i'm not sure how that is a problem at the moment, its still
going to trigger as a found phy, and walk the same mmd list as before
requesting drivers. Those drivers haven't changed their behavior so
where is the problem? If there is a problem its in 7/11 where things are
getting kicked due to seemingly invalid Ids.
The 1/11 devices=0 case actually appears to be a bug i'm fixing because
you won't get an ID or a MMD list from that (before or after).
next prev parent reply other threads:[~2020-05-25 22:22 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-22 21:30 [RFC 00/11] Make C45 autoprobe more robust Jeremy Linton
2020-05-22 21:30 ` [RFC 01/11] net: phy: Don't report success if devices weren't found Jeremy Linton
2020-05-23 18:20 ` Russell King - ARM Linux admin
2020-05-25 2:46 ` Jeremy Linton
2020-05-25 9:45 ` Russell King - ARM Linux admin
2020-05-25 21:02 ` Jeremy Linton
2020-05-25 21:07 ` Russell King - ARM Linux admin
2020-05-25 21:59 ` Jeremy Linton
2020-05-22 21:30 ` [RFC 02/11] net: phy: Simplify MMD device list termination Jeremy Linton
2020-05-23 18:36 ` Russell King - ARM Linux admin
2020-05-25 2:48 ` Jeremy Linton
2020-05-25 8:09 ` Russell King - ARM Linux admin
2020-05-22 21:30 ` [RFC 03/11] net: phy: refactor c45 phy identification sequence Jeremy Linton
2020-05-23 15:28 ` Andrew Lunn
2020-05-23 17:16 ` Jeremy Linton
2020-05-23 17:32 ` Jeremy Linton
2020-05-23 19:12 ` Russell King - ARM Linux admin
2020-05-23 18:30 ` Russell King - ARM Linux admin
2020-05-23 19:51 ` Andrew Lunn
2020-05-23 20:01 ` Russell King - ARM Linux admin
2020-05-25 2:37 ` Jeremy Linton
2020-05-22 21:30 ` [RFC 04/11] net: phy: Handle c22 regs presence better Jeremy Linton
2020-05-23 18:37 ` Russell King - ARM Linux admin
2020-05-25 3:34 ` Jeremy Linton
2020-05-25 9:53 ` Russell King - ARM Linux admin
2020-05-25 10:06 ` Russell King - ARM Linux admin
2020-05-25 21:51 ` Jeremy Linton
2020-05-25 22:01 ` Russell King - ARM Linux admin
2020-05-25 22:22 ` Jeremy Linton [this message]
2020-05-25 23:09 ` Russell King - ARM Linux admin
2020-05-25 23:22 ` Jeremy Linton
2020-05-25 23:33 ` Russell King - ARM Linux admin
2020-05-25 23:42 ` Jeremy Linton
2020-05-25 23:46 ` Andrew Lunn
2020-05-25 23:57 ` Russell King - ARM Linux admin
2020-05-25 23:16 ` Jeremy Linton
2020-05-25 23:30 ` Russell King - ARM Linux admin
2020-05-25 22:06 ` Andrew Lunn
2020-05-25 22:17 ` Jeremy Linton
2020-05-25 23:06 ` Andrew Lunn
2020-05-25 23:07 ` Russell King - ARM Linux admin
2020-05-25 23:12 ` Andrew Lunn
2020-05-25 23:46 ` Jeremy Linton
2020-05-25 23:47 ` Andrew Lunn
2020-05-22 21:30 ` [RFC 05/11] net: phy: Scan the entire MMD device space Jeremy Linton
2020-05-22 21:30 ` [RFC 06/11] net: phy: Hoist no phy detected state Jeremy Linton
2020-05-22 21:30 ` [RFC 07/11] net: phy: reset invalid phy reads of 0 back to 0xffffffff Jeremy Linton
2020-05-23 18:44 ` Russell King - ARM Linux admin
2020-05-25 4:20 ` Jeremy Linton
2020-05-25 8:20 ` Russell King - ARM Linux admin
2020-05-22 21:30 ` [RFC 08/11] net: phy: Allow mdio buses to auto-probe c45 devices Jeremy Linton
2020-05-24 14:44 ` Andrew Lunn
2020-05-25 4:28 ` Jeremy Linton
2020-05-25 8:25 ` Russell King - ARM Linux admin
2020-05-25 13:43 ` Andrew Lunn
2020-05-25 22:09 ` Jeremy Linton
2020-05-25 22:41 ` Russell King - ARM Linux admin
2020-05-22 21:30 ` [RFC 09/11] net: phy: Refuse to consider phy_id=0 a valid phy Jeremy Linton
2020-05-22 21:30 ` [RFC 10/11] net: example acpize xgmac_mdio Jeremy Linton
2020-05-23 18:48 ` Russell King - ARM Linux admin
2020-05-22 21:30 ` [RFC 11/11] net: example xgmac enable extended scanning Jeremy Linton
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=a9490c28-ebe1-ed6d-e65e-2e1d0a06386b@arm.com \
--to=jeremy.linton@arm.com \
--cc=andrew@lunn.ch \
--cc=calvin.johnson@oss.nxp.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=madalin.bucur@oss.nxp.com \
--cc=netdev@vger.kernel.org \
/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).