From: Johan Hovold <johan@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Johan Hovold <johan@kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Manivannan Sadhasivam <mani@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] gpio: sysfs: Try numbered exports if symbolic names fail
Date: Mon, 14 Dec 2020 10:07:57 +0100 [thread overview]
Message-ID: <X9crbWwMiCC9ePLW@localhost> (raw)
In-Reply-To: <CACRpkda+GhBF9f7nemrhL_mbgO0YENkWQJKZG_WA3g+ibp6ZhQ@mail.gmail.com>
On Sat, Dec 12, 2020 at 12:41:50AM +0100, Linus Walleij wrote:
> On Thu, Dec 10, 2020 at 9:33 AM Johan Hovold <johan@kernel.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.
It would be a bug in gpiolib as the warnings are due to collisions when
trying to register two sysfs files using the same path.
> > 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...
That's not true. The gpiochip has a "base" sysfs attribute from which
any user can construct the gpio number by simply adding an offset.
Having the lines sometimes show up using their names and sometimes
using this number, is what would be a problem.
> Maybe that is actually an argument for any multi-instance GPIO
> devices to
> depends on !GPIO_SYSFS
No, not at all. Just suppress the rename of the sysfs directories based
on line names, which was a bad idea from the start (the names should
have been exported through a separate name attribute).
Johan
prev parent reply other threads:[~2020-12-14 9:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 16:18 [PATCH] gpio: sysfs: Try numbered exports if symbolic names fail Linus Walleij
2020-12-10 8:34 ` Johan Hovold
2020-12-11 23:41 ` Linus Walleij
2020-12-14 9:07 ` Johan Hovold [this message]
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=X9crbWwMiCC9ePLW@localhost \
--to=johan@kernel.org \
--cc=bgolaszewski@baylibre.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mani@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).