From: Ayush Singh <ayushsingh1325@gmail.com>
To: geert@linux-m68k.org
Cc: a.fatoum@pengutronix.de, brgl@bgdev.pl, jlu@pengutronix.de,
linus.walleij@linaro.org, linux-gpio@vger.kernel.org,
marex@denx.de, warthog618@gmail.com
Subject: Re: Replacing global GPIO numbers in sysfs with hardware offsets
Date: Tue, 25 Feb 2025 23:55:12 +0530 [thread overview]
Message-ID: <6c53bc06-34d1-4ac3-be12-f29d4e5031f8@gmail.com> (raw)
In-Reply-To: <CAMuHMdVxZab5X4HyKj2d_21WohKfpFrsnRYYjx9X1ys22xCvLA@mail.gmail.com>
> Ah, the dreaded userspace GPIO drivers...
> Please point them to my ELCE2020 presentation "Gadgets and Trinkets,
> The Upstream Linux Way"
> https://elinux.org/ELC_Europe_2020_Presentations#Day_1_Presentations
> Gr{oetje,eeting}s,
> Geert
One of the reasons of the prevalence of userspace drivers (and probably
the reason why kernel drivers for stuff like motors are not attractive)
is the lack of upstream solution for runtime devicetree overlays. It is
simply not attractive to have tutorials or examples that will require a
reboot to work. And since a lot of people will start with those examples,
they will continue using userspace drivers for their future projects.
Connectors is also a problem that has been stuck for a while (although
things seem to have started progressing).
I personally, would love if I could use kernel drivers instead of
userspace drivers since they are probably much better quality than
random userspace drivers, and will not require any external deps
(as long as they provide a good sysfs API). But I also dread
having to ask a user to reboot the system to get their blinky
example working, and reboot again, since they used the wrong
pin in the overlay.
Best Regards,
Ayush Singh
next prev parent reply other threads:[~2025-02-25 18:25 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-02 12:45 Replacing global GPIO numbers in sysfs with hardware offsets Bartosz Golaszewski
2025-02-03 14:23 ` Geert Uytterhoeven
2025-02-07 20:18 ` Bartosz Golaszewski
2025-02-09 9:40 ` Geert Uytterhoeven
2025-02-25 18:25 ` Ayush Singh [this message]
2025-02-25 20:20 ` Linus Walleij
2025-02-26 6:25 ` Ayush Singh
2025-02-14 9:14 ` Linus Walleij
2025-02-21 18:01 ` Marek Vasut
2025-02-25 19:54 ` Linus Walleij
2025-02-26 12:36 ` Marek Vasut
2025-02-26 19:07 ` Bartosz Golaszewski
2025-02-28 7:49 ` Linus Walleij
2025-02-28 8:49 ` Geert Uytterhoeven
2025-02-28 8:55 ` Linus Walleij
2025-02-28 9:53 ` Geert Uytterhoeven
2025-03-05 8:22 ` Linus Walleij
2025-03-05 8:41 ` Kent Gibson
2025-03-11 10:28 ` Bartosz Golaszewski
2025-03-11 10:52 ` Geert Uytterhoeven
2025-03-11 11:53 ` Bartosz Golaszewski
2025-03-11 15:26 ` Geert Uytterhoeven
2025-02-21 19:56 ` Ahmad Fatoum
2025-02-25 19:56 ` Linus Walleij
2025-02-24 1:49 ` Kent Gibson
2025-02-24 8:28 ` Geert Uytterhoeven
2025-02-26 9:23 ` Bartosz Golaszewski
2025-02-26 10:58 ` Kent Gibson
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=6c53bc06-34d1-4ac3-be12-f29d4e5031f8@gmail.com \
--to=ayushsingh1325@gmail.com \
--cc=a.fatoum@pengutronix.de \
--cc=brgl@bgdev.pl \
--cc=geert@linux-m68k.org \
--cc=jlu@pengutronix.de \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=marex@denx.de \
--cc=warthog618@gmail.com \
/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).