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: <57B4BA0C.2080602@codeaurora.org>
Date:	Wed, 17 Aug 2016 14:25:00 -0500
From:	Timur Tabi <timur@...eaurora.org>
To:	Al Stone <al.stone@...aro.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>,
	"Abdulhamid, Harb" <harba@...eaurora.org>
Subject: Re: [PATCH] [v7] net: emac: emac gigabit ethernet controller driver

Timur Tabi wrote:
>
> The question, how should adpt->phy.version be initialized on device tree
> and ACPI platforms?
>
> The reason why this is confusing is because there are conflicting
> perspectives of this "internal PHY".  It both is and is not part of the
> EMAC.  It is a separate block in the chip, and can be replaced with
> other SGMII blocks, and in the future there will be a "v3" and maybe a
> "v4" or who knows what.  In fact, maybe using version numbers is
> inappropriate and we'll need to use vendor names or something.
>
> The problem is that the internal PHY has mechanism for
> self-identification.  There is no ACPI or device tree node for it. There
> is no register you can query to see if it's there or what version it
> is.  The MAC part of the EMAC has no knowledge of the PHY part.  The
> driver just has to know it's there.
>
> This is why I'm advocating a separate property (DT and ACPI) to identify
> the internal PHY.

So we had some internal discussion on this.  Different compatible 
properties for DT are okay, and for ACPI we'll either create a 
"phy-version" property (DT-like properties are called DSDs in ACPI) or 
use an HRV (a specific property for the hardware version).

But this speaks to the greater problem of mapping DT compatible strings 
to ACPI.  Like I said, the ACPI equivalent of a compatible string is the 
HID.  But unlike DT, we cannot create new HIDs whenever we feel like it. 
  The process for generating and assigning HIDs is much more involved, 
and we do have a very limited namespace.

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.