From: Brian Norris <computersforpeace@gmail.com>
To: Rob Herring <robh+dt@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>
Cc: 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: [RFC PATCH v1 0/3] device property: Support MAC address in VPD
Date: Tue, 14 Aug 2018 15:37:55 -0700 [thread overview]
Message-ID: <20180814223758.117433-1-briannorris@chromium.org> (raw)
Hi all,
Preface: I'm sure there are at least a few minor issues with this
patchset as-is. But I'd appreciate ("RFC") if I can get general feedback
on the approach here; perhaps there are alternatives, or perhaps I've
missed similar proposals in the past. (My problems don't feel all that
unique.)
---
Today, we have generic support for 'mac-address' and 'local-mac-address'
properties in both Device Tree nodes and in generic Device Properties,
such that network device drivers can pick up a hardware address from
there, in cases where the MAC address isn't baked into the network card.
This method of MAC address retrieval presumes that either:
(a) there's a unique device tree (or similar) stored on a given device
or
(b) some other entity (e.g., boot firmware) will modify device nodes
runtime to place that MAC address into the appropriate device
properties.
Option (a) is not feasbile for many systems.
Option (b) can work, but there are some reasons why one might not want
to do that:
(1) This requires that system firmware understand the device tree
structure, sometimes to the point of memorizing path names (e.g.,
/soc/wifi@xxxxxxxx). At least for Device Tree, these path names are
not necessarily an ABI, and so this introduces unneeded fragility.
(2) Other than this device-tree shim requirement, system firmware may
have no reason to understand anything about network devices.
So instead, I'm looking for a way to have a device node describe where
to find its MAC address, rather than having the device node contain the
MAC address directly. Then system firmware doesn't have to manage
anything.
In particular, I add support for the Google Vital Product Data (VPD)
format, used within the Coreboot project. The format is described here:
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.
We already have a VPD driver that parses this table and presents it to
user space. This series extends that driver to allow in-kernel lookups
of MAC address entries.
Thanks,
Brian
Brian Norris (3):
dt-bindings: net: Add 'mac-address-lookup' property
device property: Support complex MAC address lookup
firmware: vpd: add MAC address parser
.../devicetree/bindings/net/ethernet.txt | 12 +++
drivers/base/property.c | 83 ++++++++++++++++++-
drivers/firmware/google/vpd.c | 67 +++++++++++++++
include/linux/property.h | 23 +++++
4 files changed, 183 insertions(+), 2 deletions(-)
--
2.18.0.865.gffc8e1a3cd6-goog
next reply other threads:[~2018-08-14 22:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-14 22:37 Brian Norris [this message]
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
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=20180814223758.117433-1-briannorris@chromium.org \
--to=computersforpeace@gmail.com \
--cc=andrew@lunn.ch \
--cc=briannorris@chromium.org \
--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=robh+dt@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).