linux-kernel - Re: [PATCH] gpio: zynq: Setup chip->base based on alias ID

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]

Message-ID: <CACRpkdbOa+AvhQT1RCWA_zQuTpp4qfNjZBFDOKLdaFqMGAe+cw@mail.gmail.com>
Date:   Thu, 26 Apr 2018 15:08:24 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Michal Simek <michal.simek@...inx.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Michal Simek <monstr@...str.eu>,
        Steffen Trumtrar <s.trumtrar@...gutronix.de>,
        Peter Crosthwaite <peter.crosthwaite@...inx.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Rob Herring <robherring2@...il.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] gpio: zynq: Setup chip->base based on alias ID

On Wed, Apr 11, 2018 at 3:55 PM, Michal Simek <michal.simek@...inx.com> wrote:

Thanks for your patch!

> In past Xilinx gpio-zynq driver was setting up gpio chip->base as 0
> which was chagned to autodetection when driver was upstreamed. Older
> systems, which were using this old version, setup SW stack which expects
> zynq gpio base as 0 and right now there is no way how to set this up.
>
> The patch is adding an option to setup chip->base based on aliases which
> is something what some other drivers are doing too.
> It means when gpio0 alias is setup then chip->base is 0. When gpio alias
> is not setup gpiochip_find_base() set it up properly which is current
> behavior.
>
> Signed-off-by: Michal Simek <michal.simek@...inx.com>

In general, we stopped any controlling of the GPIO base.

Also this use would have to be OK with the DT maintainers
as I never saw this use of alias before.

Please describe the use case for this.

The only use case which I can think about is userspace sysfs
and then I would really like to know why these userspace
users cannot use the character device that is nowadays
supported by libgpiod and there is even patches for some
IoT libraries to use it. The character device makes the
GPIO Linux "base" irrelevant for userspace.

GPIO sysfs is deprecated and moved to the obsolete ABI.

If there are legacy applications that use this I would have
to consider it, but since this has been -1 since the driver
was merged I find that unlikely.

Yours,
Linus Walleij