Re: [PATCH] [v7] net: emac: emac gigabit ethernet controller driver

[Timur Tabi <timur@codeaurora.org>]

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.