On 08/16/2016 07:39 AM, Timur Tabi wrote: > Rob Herring wrote: > >>> In ACPI, the equivalent to a compatible string is the HID, which is QCOM8070 >>> for the EMAC. The problem is that it's very difficult, if not impossible, >>> to create new HIDs for different versions of the same device. >> >> Different versions are different devices IMO. > > Not that I disagree, but this appears to be an inherent problem with ACPI. The > namespace for ACPI HIDs is very limited. We only really have control over the > last two digits. My apologies if the stuff below is things you already know...I never know how much people already know about ACPI, and sometimes just don't know when to shut up :). An _HID is a three or four character company ID followed by four digits that the company decides on. The only thing the ASWG (ACPI Spec Working Group) controls are those first characters; you can do whatever you'd like with the four digits that follow. Not knowing enough about the products in mind here, or future plans for them, I'd recommend taking a look at section 6.1 of the spec. There's an ACPI object called _HRV (Hardware Revision) that may do what you need; there is also the _CID (Compatible ID), or if this is a PCI device, perhaps the _CLS (Class Code) can be used. I guess what I'm really trying to say is that the "name space" mentioned here [*] is not that limited and has quite a bit of flexibility. [*] "ACPI namespace" has a fairly specific meaning that is different. >>> The other problem is that the "internal PHY" of the EMAC is technically a >>> separate device, and it's interchangeable. Future versions of our chips >>> will use different internal PHYs, but the EMAC will stay the same. >> >> How do you know? EMAC could just as easily change. It's Gigabit today, >> 10G tomorrow. > > My point is that the EMAC part won't change for the foreseeable future, but I > know the internal PHY component will change. The new "version" of the EMAC/PHY > combo on a future chip will have the same ACPI HID. So I need some other way to > differentiate the two. I can't query the hardware, because the EMAC half will > be identical. > >> But if it is separate, then maybe you should model it as a separate >> device using the phy binding. > > It's only separate in hardware. The driver controls both parts as a unified whole. > >>> So I would like a solution that works on DT and ACPI. I suppose I could use >>> compatible strings on DT, and a "phy-version" DSD (property) on ACPI. If >>> that's acceptable to everyone, then I can do that. It seems clunky to me. >> >> On one hand, why should I care about ACPI for defining DT bindings? >> OTOH, having a phy-version property alone would not be a big deal, but >> you still need distinct compatible strings regardless. > > So you're saying that it's okay to have separate compatible strings AND a > phy-version property? That would solve the problem. > Does the ACPI portion of the driver *have* to know about the PHY? In general, the ACPI assumption on ARM [**] is that those have all been set up before we get to the kernel. So, does it need to be visible to the ACPI part of the driver at all? [**] See Documentation/arm64/arm-acpi.txt. -- ciao, al ----------------------------------- Al Stone Software Engineer Linaro Enterprise Group al.stone@xxxxxxxxxx ----------------------------------- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
