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@gmail.com>,
"Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
"Maxime Ripard" <maxime.ripard@bootlin.com>,
"Alban Bedel" <albeu@free.fr>,
linux-arm-kernel@lists.infradead.org,
linux-wireless@vger.kernel.org,
linux-mediatek@lists.infradead.org
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
WARNING: multiple messages have this Message-ID (diff)
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
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
"Kunihiko Hayashi" <hayashi.kunihiko@socionext.com>,
"Maxime Ripard" <maxime.ripard@bootlin.com>,
"Masahiro Yamada" <yamada.masahiro@socionext.com>,
"Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
"Frank Rowand" <frowand.list@gmail.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
linux-arm-kernel@lists.infradead.org,
"Petr Štetiar" <ynezz@true.cz>,
"Yisen Zhuang" <yisen.zhuang@huawei.com>,
"Vivien Didelot" <vivien.didelot@gmail.com>,
"Woojung Huh" <woojung.huh@microchip.com>,
devicetree@vger.kernel.org,
"Jassi Brar" <jaswinder.singh@linaro.org>,
linux-mediatek@lists.infradead.org,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"Kalle Valo" <kvalo@codeaurora.org>,
"Salil Mehta" <salil.mehta@huawei.com>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Microchip Linux Driver Support" <UNGLinuxDriver@microchip.com>,
"Alban Bedel" <albeu@free.fr>,
"David S. Miller" <davem@davemloft.net>,
"Heiner Kallweit" <hkallweit1@gmail.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-05-01 20:22 UTC|newest]
Thread overview: 25+ 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 ` 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 12:53 ` Petr Štetiar
2019-04-28 16:53 ` Andrew Lunn
2019-04-28 16:53 ` Andrew Lunn
2019-04-28 16:53 ` Andrew Lunn
2019-05-01 20:22 ` Rob Herring [this message]
2019-05-01 20:22 ` Rob Herring
2019-05-01 20:22 ` Rob Herring
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=albeu@free.fr \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=frowand.list@gmail.com \
--cc=hayashi.kunihiko@socionext.com \
--cc=hkallweit1@gmail.com \
--cc=jaswinder.singh@linaro.org \
--cc=kvalo@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=maxime.ripard@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=salil.mehta@huawei.com \
--cc=srinivas.kandagatla@linaro.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.