lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 1 May 2019 15:22:00 -0500
From:   Rob Herring <>
To:     Andrew Lunn <>
Cc:     Petr Štetiar <>,,,,
        "David S. Miller" <>,
        Mark Rutland <>,
        Vivien Didelot <>,
        Florian Fainelli <>,
        Yisen Zhuang <>,
        Salil Mehta <>,
        Woojung Huh <>,
        Microchip Linux Driver Support <>,
        Kunihiko Hayashi <>,
        Masahiro Yamada <>,
        Jassi Brar <>,
        Kalle Valo <>,
        Matthias Brugger <>,
        Heiner Kallweit <>,
        Frank Rowand <>,
        Srinivas Kandagatla <>,
        Maxime Ripard <>,
        Alban Bedel <>,,,
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.


Powered by blists - more mailing lists