On 2/25/25 8:54 PM, Linus Walleij wrote:
On Fri, Feb 21, 2025 at 8:41 PM Marek Vasut <marex@xxxxxxx> wrote:
I would very much like to avoid having to enable debugfs on production
systems to access GPIOs in early userspace (e.g. initramfs).
I didn't understand that. It was because Bartosz used the word "play":
Uh oh ... in short, the entire discussion between me and Bartosz at
FOSDEM could be summarized to (please correct me if I'm wrong and I'm
stuffing words into someone's mouth):
- Bartosz does not like fixed static GPIO number assignment, we agree
- Bartosz wants to write more userspace tools to operate GPIO chardev
API, we do not agree, Marek already has all the tools built into shell
(printf, echo, cat)
=> Some sysfs API "v2" which does not suffer from the defects of the
current one would be great. The benefit would be:
- Can be operated without extra tools, simple printf/echo/cat into
sysfs attributes would suffice
- Would work even in the simplest of userspaces (initramfs, remote
access VMs, etc.), which is practical for board bring up and well,
other limited deployments
That's really all this is about, get rid of the defects of the old sysfs
API, but keep the tooling requirements to minimum.
Also note that API "v2" attribute layout could differ from API "v1" ,
that is not a problem.
The gist of it is: some people need to play with GPIOs very early, for
example in an initramfs
So I took that word literal: explore, play around. Not develop
products.
This was so
far possible via the sysfs API without tools, currently it is becoming
not easily possible. A sysfs API "v2" which makes that possible would be
very much appreciated.
I understand, I'm fine with sysfs if it needs to be a "support forever"
ABI, as long as it's:
- Using the per-chip HW numberspace
This is no issue for me.
- Doesn't need any echo NN > export to see the lines in
sysfs.
Can we really make do without export/unexport ?
Consider this scenario:
- User open()s and write()s /sys/bus/gpio/gpiochip0/gpio0/value
- User keeps FD to /sys/bus/gpio/gpiochip0/gpio0/value open
- Kernel module gets loaded, binds to DT node which references the same GPIO
- User write()s /sys/bus/gpio/gpiochip0/gpio0/value open again
I wonder if this could pose a problem ?
I suspect the kernel module loading should fail , right ?
