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.
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.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
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
