linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Guenter Roeck <linux@roeck-us.net>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Julius Werner <jwerner@chromium.org>,
	Stephen Boyd <swboyd@chromium.org>,
	Brian Norris <briannorris@chromium.org>
Subject: Re: [RFC PATCH v1 1/3] dt-bindings: net: Add 'mac-address-lookup' property
Date: Wed, 15 Aug 2018 14:45:29 -0600	[thread overview]
Message-ID: <20180815204529.GA24830@rob-hp-laptop> (raw)
In-Reply-To: <20180814223758.117433-2-briannorris@chromium.org>

On Tue, Aug 14, 2018 at 03:37:56PM -0700, Brian Norris wrote:
> Some firmwares present data tables that can be parsed to retrieve
> device-specific details, like MAC addresses. While in some cases, one
> could teach the firmware to understand the device tree format and insert
> a 'mac-address'/'local-mac-address' property into the FDT on its own,
> this method can be brittle (e.g., involving memorizing expected FDT
> structure), and it's not strictly necessary -- especially when parsers
> for such firmware formats are already needed in the OS for other
> reasons.

If you have an 'ethernetN' alias then you don't need to know the 
structure. IIRC, that is what u-boot does.

> 
> One such format: the Vital Product Data (VPD) [1] used by Coreboot. It
> supports a table of key/value pairs, and some systems keep MAC addresses
> there in a well-known format. Allow a device tree to specify
>   (1) that the MAC address for a given device is stored in the VPD table
>       and
>   (2) what key should be used to retrieve the MAC address for said
>       device (e.g., "ethernet_mac0" or "wifi_mac1").
> 
> [1] Ref:
> https://chromium.googlesource.com/chromiumos/platform/vpd/+/master/README.md
> TL;DR: VPD consists of a TLV-like table, with key/value pairs of
> strings. This is often stored persistently on the boot flash and
> presented via in-memory Coreboot tables, for the operating system to
> read.
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
>  Documentation/devicetree/bindings/net/ethernet.txt | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
> index cfc376bc977a..d3fd1da18bf4 100644
> --- a/Documentation/devicetree/bindings/net/ethernet.txt
> +++ b/Documentation/devicetree/bindings/net/ethernet.txt
> @@ -4,6 +4,18 @@ NOTE: All 'phy*' properties documented below are Ethernet specific. For the
>  generic PHY 'phys' property, see
>  Documentation/devicetree/bindings/phy/phy-bindings.txt.
>  
> +- mac-address-lookup: string, indicating a method by which a MAC address may be
> +  discovered for this device. Methods may be parameterized by some value, such
> +  that the method can determine the device's MAC address using that parameter.
> +  For example, a firmware might store MAC addresses in a table, keyed by some
> +  predetermined string, and baked in read-only flash. A lookup method "foo"
> +  with a parameter "bar" should be written "foo:bar".
> +  Supported values for method:
> +    "google-vpd" - Google's Vital Product Data (VPD), as used in the Coreboot
> +      project. Documentation for VPD can be found at:
> +        https://chromium.googlesource.com/chromiumos/platform/vpd/+/master/README.md
> +  Example:
> +    mac-address-lookup = "google-vpd:ethernet_mac0"

This doesn't strike me as a very DT style way of describing this. I 
would expect something like a phandle to the VPD and an identifier. 

Also, an already common way besides local-mac-address is using nvmem 
binding which wouldn't use this and perhaps could be used here? This 
feels very much Google specific, not common (and maybe that is fine).

Rob

  reply	other threads:[~2018-08-15 20:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-14 22:37 [RFC PATCH v1 0/3] device property: Support MAC address in VPD Brian Norris
2018-08-14 22:37 ` [RFC PATCH v1 1/3] dt-bindings: net: Add 'mac-address-lookup' property Brian Norris
2018-08-15 20:45   ` Rob Herring [this message]
2018-08-14 22:37 ` [RFC PATCH v1 2/3] device property: Support complex MAC address lookup Brian Norris
2018-08-14 22:37 ` [RFC PATCH v1 3/3] firmware: vpd: add MAC address parser Brian Norris
2018-08-14 23:00 ` [RFC PATCH v1 0/3] device property: Support MAC address in VPD Florian Fainelli
2018-08-15  0:22   ` Brian Norris
2018-08-15  0:52     ` Florian Fainelli
2018-08-15  1:44       ` Brian Norris
2018-08-15 22:07         ` Stephen Boyd
2018-08-31  0:55           ` Brian Norris
2018-08-15 22:16         ` Rob Herring
2018-08-31  1:26           ` Brian Norris
2018-08-31  8:43             ` Srinivas Kandagatla
2018-08-31 21:28               ` Brian Norris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180815204529.GA24830@rob-hp-laptop \
    --to=robh@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=briannorris@chromium.org \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jwerner@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=netdev@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=swboyd@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).