Linux: stop using /sys/class/gpio!

[DiTBho]

so, as you can read here /sys/class/gpio is deprecated and has been removed from the kernel

for example, today I am working on these two kernels

• kernel-5.4.128 has it
• kernel-5.15.107 doesn't have it

it's time to change && update



(or it's time to forward-port the old sys/class/gpio from k5.4 to k5.15
and I will update myself and userspace apps another day in the future, probably with 6.2 kernels

mumble  )

[Monkeh]

And you only had seven years of warning! Despicable.

[DiTBho]

And you only had seven years of warning! Despicable.

lazy lazy 

[SiliconWizard]

Being on version 5 is already good, Android 12 is still on a 4.14 kernel.

[Monkeh]

Being on version 5 is already good, Android 12 is still on a 4.14 kernel.

That's quite new compared to many embedded devices. Pretty sure some vendors are still shipping SDKs and binary drivers for 2.6.

[DiTBho]

2.4 

[Nominal Animal]

That's what we get when we don't design the interface well enough from the get go.

I am personally of two minds.  On one hand, I don't like the kernel support discontinuity at all, and not all GPIO implementations have moved yet.
On the other hand, the sysfs approach with a global namespace is just silly.  There are several cases when plain GPIO pins are available on chips or modules that may or may not be available.  Using a global numbering scheme, where the probe order determines the pin numbering, is just utterly silly.

Compare to the Linux Input subsystem and its event interface and event codes (and optionally hiddev); specifically struct input_event event interfaces /dev/input/eventN provide.

Basically, the event/evdev interface is based on a character driver, from which you read (one or more complete) struct input_event structures (that have not changed since 2001, since Vojtech Pavlik and others spent some time designing it).  There are a few ioctl()s you can use to control e.g. whether the events are consumed (grabbed, see EVIOCGRAB) or whether one only reads the events with others seeing the events too (default).

It's just one of the reasons why I keep harping about designing interfaces properly, with security in mind, from the get go.  (The evdev character device owner and access mode is set by udev; I personally set rules to generate useful stable symlinks to special devices.)

[SiliconWizard]

Agreed.

[DiTBho]

so, I prepared a special sysfs kernel module that
- reads the gpio-phy(1) nodes from the OF (device tree) description
- for special types(1), reads the gpio pin from OF and prepares /sys/gpio-phy-en/$item/{ value }
- which also exports it to the sysfs-gpio-chardev

this way I don't need the old interface, it's compatible with the new interface and it's also accessible as sysfs, which is enough for my need


gpio used to enable/disable the phy
marked as "compatible,gpio-phy-en"

[SiliconWizard]

Is it written in my-c?

[Nominal Animal]

Is it written in my-c?

No, you can currently only use C in the Linux kernel, although Rust support is being introduced.

The hardware involved is Mikrotik RBM33G (OpenWRT support); a MIPS (mipsel_24kc architecture) routerboard using Mediatek MT7621A SoC.  I have one myself, and it's a pretty interesting cheap little board for firewalls or full-featured 4G/LTE modems and/or wireless access points.  You can even use two separate LTE modems, and handle connection failover.

Problem is, the hardware is not so widely used, so changes like the aforementioned GPIO –– one of the GPIO pins controlling the USB 3.0 port PHY; i.e. the port is only turned on if you set the GPIO pin high –– do not get the changes applied when subsystems are being deprecated and moved.

A tiny custom kernel driver is the perfect solution here, especially if one needs the USB 3 early in the boot, say for connection to the root filesystem.
(I have a Kioxia NVMe on mine, but I've also used cheap (<10€) Jmicron JMS578 etc. -based USB-SATA bridges on my other USB 3 -capable SBCs without any issues.)

[DiTBho]

Is it written in my-c?

mipsel-unknown-linux-gnu:{binutils,gcc}={2.35.1,9.3.0}.

[DiTBho]

Is it written in my-c?

No, you can currently only use C in the Linux kernel, although Rust support is being introduced.

umm, I am not sure about what super-gurus did on their Apple M1 Linux port.
Someone said there is a Rust kernel driver, but I haven't yet investigated 

[SiliconWizard]

Is it written in my-c?

No, you can currently only use C in the Linux kernel, although Rust support is being introduced.

Ha, if it's forbidden, then...
(Kidding aside, I'm not sure DiTBho was really considering getting his contributions accepted in the Linux kernel, although, who knows... Otherwise, you can well do as you please. At least I hope so.  )

[Nominal Animal]

(Kidding aside, I'm not sure DiTBho was really considering getting his contributions accepted in the Linux kernel, although, who knows... Otherwise, you can well do as you please. At least I hope so.  )

I've suggested submitting the kernel patches in PMs.  It costs nothing except a bit of time and a self-esteem/ego hit to post them on LKML (as it is likely nobody responds to the patch), and especially when one describes the use case, at least it will be recorded forever in the mailing list archives.

There are a couple I should send too.  One (to kernel-janitors) is about seq_file_path() not escaping a backslash character, so filenames "foo"+newline+"bar" and "foo"+backslash+"n"+"bar" will be shown as the same string (in certain kernel interfaces).  Only mm/swapfile.c:swap_show() does it right currently.

It's just that to send patches correctly to LKML, one should follow the Submitting Patches guidelines, including sending a Developers Certificate of Origin, using ones real name ("using a known identity (sorry, no anonymous contributions.)") –– well, one does not need to send it, just mention they've read and signed it in the first (couple of) patch submissions –– which is still a bit of an issue for myself .  I do have a permanent iki.fi email address under my real name, I just kinda-sorta still need the pseudonym to use as a crutch in social interactions.

I'm a special sensitive snowflake... 

[DiTBho]

I've suggested submitting the kernel patches in PMs.

I asked a developer what he thinks and he said the "hacks" don't deserve attention since in my case a better thing to do would be to fix the voltage regulator && the device tree part && the gpio-specific part of the Mediatek SoC.

Code: [Select]

        reg_usb_vbus: reg_usb_vbus
        {
                compatible = "regulator-fixed";
                regulator-name = "usb_vbus";
                regulator-min-microvolt = <5000000>;
                regulator-max-microvolt = <5000000>;
                //gpio = <&gpio 12 GPIO_ACTIVE_HIGH>; <---- commented, handled by phy-en
                enable-active-high;
                regulator-boot-on;
                regulator-always-on;
        };
(this part of device-tree is correct  but the kernel driver doesn't correctly handle it)

So, okey ... mine is not a "patch" but rather a "hack" 

[DiTBho]

oh, back to reason why I opened this topic: need to learn chardev-gpio? good examples in the link 

[5U4GB]

That's quite new compared to many embedded devices. Pretty sure some vendors are still shipping SDKs and binary drivers for 2.6.

2.6.2x is the forever kernel.  There are essentially two versions of Linux that you need to deal with, $latest_release and 2.6.2x.

[DiTBho]

2.6.2x is the forever kernel.  There are essentially two versions of Linux that you need to deal with, $latest_release and 2.6.2x.

yup, when you talk with devs, they are usually to say "kernel_next", which means $latest_release
         git clone https://git.kernel.org/pub/... something
but, sometimes you still find it useful to deal with the simplicity of kernel  v2.4

kernel v2.4 have simpler PCI code for example, and the kernel tree embeds most of the initializations that kernels >2.6 expect to be performed by the firmware

[Monkeh]

That's quite new compared to many embedded devices. Pretty sure some vendors are still shipping SDKs and binary drivers for 2.6.

2.6.2x is the forever kernel.  There are essentially two versions of Linux that you need to deal with, $latest_release and 2.6.2x.

That's what they'd like, but no, I actively refuse to have anything to do with such.

[metertech58761]

...is this why there are as many versions of Linux as grains of sand in a bucket?

[Nominal Animal]

...is this why there are as many versions of Linux as grains of sand in a bucket?

No, that is unrelated.  This is a bad design issue.

The reason there are so many versions of Linux is simply because of its configurability, adaptability, and evolution.  Limiting to a smaller set of versions would necessarily limit those, too, so it is undesirable from the Linux users' perspective.  Because the developers are also the users, that will not happen.

Usually, the userspace interface is stable, but in rare cases like this one it just has to be modified because the original interface just cannot be maintained.
DiTBho's solution is, in my experience, the correct one here: a tiny backported/forward-ported kernel driver to handle the early boot (before any filesystems are mounted) requirements.