[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190501202200.GB15495@bogus>
Date: Wed, 1 May 2019 15:22:00 -0500
From: Rob Herring <robh@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Petr Štetiar <ynezz@...e.cz>,
netdev@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Mark Rutland <mark.rutland@....com>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Yisen Zhuang <yisen.zhuang@...wei.com>,
Salil Mehta <salil.mehta@...wei.com>,
Woojung Huh <woojung.huh@...rochip.com>,
Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Jassi Brar <jaswinder.singh@...aro.org>,
Kalle Valo <kvalo@...eaurora.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Frank Rowand <frowand.list@...il.com>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Maxime Ripard <maxime.ripard@...tlin.com>,
Alban Bedel <albeu@...e.fr>,
linux-arm-kernel@...ts.infradead.org,
linux-wireless@...r.kernel.org, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v2 2/4] dt-bindings: doc: Reflect new NVMEM
of_get_mac_address behaviour
On Sun, Apr 28, 2019 at 06:53:26PM +0200, Andrew Lunn wrote:
> On Sun, Apr 28, 2019 at 02:53:20PM +0200, Petr Štetiar wrote:
> > As of_get_mac_address now supports NVMEM under the hood, we need to update
> > the bindings documentation with the new nvmem-cell* properties, which would
> > mean copy&pasting a lot of redundant information to every binding
> > documentation currently referencing some of the MAC address properties.
> >
> > So I've just removed all the references to the optional MAC address
> > properties and replaced them with the reference to the net/ethernet.txt
> > file. While at it, I've also removed other optional Ethernet properties.
>
> Hi Petr
>
> I think each individual binding needs to give a hint if
> of_get_mac_address() is used, and hence if these optional properties
> are respected. The same is true for other optional properties. I don't
> want to have to look at the driver to know which optional properties
> are implemented, the binding should tell me. What the optional
> properties mean, and which order they are used in can then be defined
> in ethernet.txt.
>
> So i would suggests something like:
>
> The MAC address will be determined using the optional properties
> defined in ethernet.txt.
>
> And leave all the other optional parameters in the bindings.
Yes. Generally we need to know which properties from a common pool of
properties apply to a specific binding. Also there are typically
additional constraints for a specific binding.
Rob
Powered by blists - more mailing lists