devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Petr Štetiar" <ynezz@true.cz>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Vivien Didelot" <vivien.didelot@gmail.com>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Yisen Zhuang" <yisen.zhuang@huawei.com>,
	"Salil Mehta" <salil.mehta@huawei.com>,
	"Woojung Huh" <woojung.huh@microchip.com>,
	"Microchip Linux Driver Support" <UNGLinuxDriver@microchip.com>,
	"Kunihiko Hayashi" <hayashi.kunihiko@socionext.com>,
	"Masahiro Yamada" <yamada.masahiro@socionext.com>,
	"Jassi Brar" <jaswinder.singh@linaro.org>,
	"Kalle Valo" <kvalo@codeaurora.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Frank Rowand" <frowand.list@g>
Subject: Re: [PATCH v2 2/4] dt-bindings: doc: Reflect new NVMEM of_get_mac_address behaviour
Date: Wed, 1 May 2019 15:22:00 -0500	[thread overview]
Message-ID: <20190501202200.GB15495@bogus> (raw)
In-Reply-To: <20190428165326.GI23059@lunn.ch>

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

  reply	other threads:[~2019-05-01 20:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-28 12:53 [PATCH v2 0/4] of_net: Add NVMEM support to of_get_mac_address Petr Štetiar
2019-04-28 12:53 ` [PATCH v2 1/4] " Petr Štetiar
2019-05-01 20:19   ` Rob Herring
2019-05-02  9:05     ` Petr Štetiar
2019-05-07 16:06       ` Rob Herring
2019-05-08  9:02         ` Petr Štetiar
2019-04-28 12:53 ` [PATCH v2 2/4] dt-bindings: doc: Reflect new NVMEM of_get_mac_address behaviour Petr Štetiar
2019-04-28 16:53   ` Andrew Lunn
2019-05-01 20:22     ` Rob Herring [this message]
2019-04-28 12:53 ` [PATCH v2 3/4] net: macb: Drop nvmem_get_mac_address usage Petr Štetiar
2019-04-28 16:56   ` Andrew Lunn
2019-04-28 21:08     ` Petr Štetiar
2019-04-28 21:36       ` Andrew Lunn
2019-04-29  7:55         ` Petr Štetiar
2019-04-29 13:02           ` Andrew Lunn
2019-04-30 14:13             ` Handling of EPROBE_DEFER in of_get_mac_address [Was: Re: [PATCH v2 3/4] net: macb: Drop nvmem_get_mac_address usage] Petr Štetiar
2019-05-01 13:54               ` Andrew Lunn
2019-04-28 12:53 ` [PATCH v2 4/4] net: davinci_emac: Drop nvmem_get_mac_address usage Petr Štetiar
2019-04-28 16:58   ` Andrew Lunn

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=20190501202200.GB15495@bogus \
    --to=robh@kernel.org \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=frowand.list@g \
    --cc=hayashi.kunihiko@socionext.com \
    --cc=hkallweit1@gmail.com \
    --cc=jaswinder.singh@linaro.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=salil.mehta@huawei.com \
    --cc=vivien.didelot@gmail.com \
    --cc=woojung.huh@microchip.com \
    --cc=yamada.masahiro@socionext.com \
    --cc=yisen.zhuang@huawei.com \
    --cc=ynezz@true.cz \
    /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).