lkml.org 
[lkml]   [2020]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [net-next PATCH v3 4/5] net: phy: Introduce fwnode_get_phy_id()
From
Date
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.

>
>> 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.

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.

\
 
 \ /
  Last update: 2020-05-07 21:54    [W:0.078 / U:1.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site