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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 7 May 2020 14:54:09 -0500
From:   Jeremy Linton <>
To:     Andy Shevchenko <>
Cc:     Calvin Johnson <>,
        "Rafael J . Wysocki" <>,
        Russell King - ARM Linux admin <>,, Andrew Lunn <>,
        Florian Fainelli <>,
        Cristi Sovaiala <>,
        Florin Laurentiu Chiculita <>,
        Ioana Ciornei <>,
        Madalin Bucur <>,
        Greg Kroah-Hartman <>,
        Heikki Krogerus <>,
        Varun Sethi <>,
        "Rajesh V . Bikkina" <>,
        ACPI Devel Maling List <>,
        Linux Kernel Mailing List <>,
        Diana Madalina Craciun <>,
        netdev <>, Marcin Wojtas <>,
        Laurentiu Tudor <>,
        Makarand Pawagi <>,
        linux-arm Mailing List <>,
        Pankaj Bansal <>,
        "David S. Miller" <>,
        Heiner Kallweit <>
Subject: Re: [net-next PATCH v3 4/5] net: phy: Introduce fwnode_get_phy_id()


On 5/7/20 12:27 PM, Andy Shevchenko wrote:
> On Thu, May 7, 2020 at 4:26 PM Jeremy Linton <> 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. 
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.

Powered by blists - more mailing lists