lists.openwall.net   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:   Mon, 8 Mar 2021 11:37:04 -0700
From:   Rob Herring <robh@...nel.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Alexander Sverdlin <alexander.sverdlin@...il.com>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Kevin Hilman <khilman@...nel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpio: omap: Honor "aliases" node

On Tue, Mar 02, 2021 at 05:21:23PM +0100, Linus Walleij wrote:
> On Tue, Mar 2, 2021 at 2:18 AM Alexander Sverdlin
> <alexander.sverdlin@...il.com> wrote:
> 
> > Currently the naming of the GPIO chips depends on their order in the DT,
> > but also on the kernel version (I've noticed the change from v5.10.x to
> > v5.11). Honor the persistent enumeration in the "aliases" node like other
> > GPIO drivers do.
> >
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@...il.com>
> > ---
> > Yes, I noticed checkpatch "WARNING: DT binding docs and includes should be
> > a separate patch."
> > However, the parts below are tiny and barely make sense separately.
> 
> I've shut it down in the past because the instance ordering is a
> linuxism and the needs are in the Linux userspace somehow.
> It is different from a UART for example, which always need to
> be at the same place on any operating system, hence it has an
> alias.
> 
> For kernelspace the instance order should not matter, since
> all resources are obtained from the device tree anyway
> by phandle.

Thank you!

Can we remove the ones we have already for GPIO? 

BTW, It's been on my todo list for a while to start requiring 
documentation of alias names so we can reject new ones and get rid of 
some of the unused existing ones. Some platforms have numbered 
everything...

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ