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

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f3a49762-aa66-1949-bd6b-77bd6a74acc1@linaro.org>
Date:	Tue, 16 Aug 2016 15:20:09 -0600
From:	Al Stone <al.stone@...aro.org>
To:	Timur Tabi <timur@...eaurora.org>, Rob Herring <robh@...nel.org>
Cc:	netdev <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	Sagar Dharia <sdharia@...eaurora.org>,
	Shanker Donthineni <shankerd@...eaurora.org>,
	Vikram Sethi <vikrams@...eaurora.org>,
	Christopher Covington <cov@...eaurora.org>,
	Gilad Avidov <gavidov@...eaurora.org>,
	Andrew Lunn <andrew@...n.ch>,
	Bjorn Andersson <bjorn.andersson@...aro.org>,
	Mark Langsdorf <mlangsdo@...hat.com>,
	"jcm@...hat.com" <jcm@...hat.com>,
	Andy Gross <agross@...eaurora.org>,
	David Miller <davem@...emloft.net>,
	Florian Fainelli <f.fainelli@...il.com>,
	Lino Sanfilippo <LinoSanfilippo@....de>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH] [v7] net: emac: emac gigabit ethernet controller driver

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@...aro.org
-----------------------------------