linux-kernel - Re: [PATCH] gpio: sysfs: Try numbered exports if symbolic names fail

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: <CACRpkda+GhBF9f7nemrhL_mbgO0YENkWQJKZG_WA3g+ibp6ZhQ@mail.gmail.com>
Date:   Sat, 12 Dec 2020 00:41:50 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Johan Hovold <johan@...nel.org>
Cc:     "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Manivannan Sadhasivam <mani@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpio: sysfs: Try numbered exports if symbolic names fail

On Thu, Dec 10, 2020 at 9:33 AM Johan Hovold <johan@...nel.org> wrote:

> I suggested having the driver set a flag which determines whether to use
> the line names in sysfs or not.

Aha I get it.

I need to think about if I can fix that in some good way.

> The above will trigger a bunch of nasty warnings and backtraces in the
> sysfs code (for every gpio line!), which is not something we want for
> normal operation.

At this point I feel any use of sysfs kind of deserves that but OK
it's a bit nasty.

> Having the sysfs interface for the same USB device
> depend on probe order is not very nice either.

The sysfs for a USB device is already very dependent on probe order.
Since all dynamic gpio_chips pass -1 as base they will be allocated
some global GPIO numbers at random (well, semi-random)
depending on probe order.

The user will not have any idea whatsoever what to echo into the sysfs
export file without inspecting other things such as debugfs.
That's how unstable this interface is, and one of the reasons we
are trying to get rid of the global GPIO numberspace to begin with...

Maybe that is actually an argument for any multi-instance GPIO
devices to
depends on !GPIO_SYSFS

It's a sad excuse for an ABI, the form it has was maybe acceptable
in debugfs.

> Since the USB GPIO controller do not register any names today (as
> gpiolib currently require a flat name space), there's no need to worry
> about legacy scripts depending on those either (or rather, the argument
> goes the other way since adding names now could break a functioning
> script).

OK I get how you think this should work.

> Just add a flag to suppress the renaming and we can safely start adding
> names to hotpluggable controllers (if the rest of gpiolib can handle
> non-unique names).

I'll see if I can think of something clean enough. I don't really want to
add fields into the struct gpio_chip pertaining to a legacy ABI.

Yours,
Linus Walleij