Re: [net-next PATCH v3 4/5] net: phy: Introduce fwnode_get_phy_id()

[Calvin Johnson <calvin.johnson@oss.nxp.com>]

On Thu, May 07, 2020 at 02:54:09PM -0500, Jeremy Linton wrote:
> Hi,
> 
> On 5/7/20 12:27 PM, Andy Shevchenko wrote:
> > On Thu, May 7, 2020 at 4:26 PM Jeremy Linton <jeremy.linton@arm.com> wrote:
> > > On 5/5/20 8:29 AM, Calvin Johnson wrote:
> > 
> > > > +             if (sscanf(cp, "ethernet-phy-id%4x.%4x",
> > > > +                        &upper, &lower) == 2) {
> > > > +                     *phy_id = ((upper & 0xFFFF) << 16) | (lower & 0xFFFF);
> > > > +                     return 0;
> > > > +             }
> > 
> > > Isn't the ACPI _CID() conceptually similar to the DT compatible
> > > property?
> > 
> > Where?
> 
> Not, sure I understand exactly what your asking. AFAIK, in general the dt
> property is used to select a device driver/etc based on a more to less
> compatible set of substrings. The phy case is a bit different because it
> codes a numerical part number into the string rather than just using
> arbitrary strings to select a driver and device. But it uses that as a
> vendor selector for binding to the correct driver/device.
> 
> Rephrasing the ACPI spec, the _CID() is either a single compatible id, or a
> list of ids in order of preference. Each id is either a HID (string or EISA
> type id) or a bus specific string encoding vendor/device/etc. (https://elixir.bootlin.com/linux/v5.7-rc4/source/drivers/acpi/acpica/utids.c#L186).
> One of the examples is "PCI\VEN_vvvv&DEV_dddd"
> 
> So that latter case seems to be almost exactly what we have here.

Got your point. Yes, the ACPI spec says the same.
If we are using _CID as a string, then it must be a string that uses a
bus-specific nomenclature. This AFAIU may take the format
"PHY\VEN_IDvvvv&ID_DDDD" as you mentioned below and not
"ethernet-phy-id004d.d072" as used in DT.
So, we need to define it some where in the Linux ACPI Documentation.
I don't see any best place to document this. Any suggestions?

> 
> > 
> > > It even appears to be getting used in a similar way to
> > > identify particular phy drivers in this case.
> > 
> > _CID() is a string. It can't be used as pure number.
> > 
> 
> It does have a numeric version defined for EISA types. OTOH I suspect that
> your right. If there were a "PHY\VEN_IDvvvv&ID_DDDD" definition, it may not
> be ideal to parse it. Instead the normal ACPI model of exactly matching the
> complete string in the phy driver might be more appropriate.

IMO, it should be fine to parse the string to extract the phy_id. Is there any
reason why we cannot do this?

> 
> Similarly to how I suspect the next patch's use of "compatible" isn't ideal
> either, because whether a device is c45 or not, should tend to be fixed to a
> particular vendor/device implementation and not a firmware provided
> property.

I tend to agree with you on this. Even for DT, ideal case, IMO should be:

1) mdiobus_scan scans the mdiobus for c22 devices by reading phy id from
registers 2 and 3
2) if not found scan for c45 devices <= looks like this is missing in Linux
3) look for phy_id from compatible string.

Meanwhile, please note some usage of compatible property in edk2-platforms:
https://github.com/tianocore/edk2-platforms/blob/master/Platform/96Boards/Secure96Dxe/Secure96.asl#L20
https://github.com/tianocore/edk2-platforms/blob/master/Silicon/Marvell/Armada7k8k/AcpiTables/Armada80x0McBin/Dsdt.asl#L280
https://github.com/tianocore/edk2-platforms/blob/master/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Optee.asl#L17

Regards
Calvin