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]

Date:	Tue, 16 Aug 2016 08:39:12 -0500
From:	Timur Tabi <timur@...eaurora.org>
To:	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>,
	Al Stone <al.stone@...aro.org>
Subject: Re: [PATCH] [v7] net: emac: emac gigabit ethernet controller driver

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.