Re: GPIO Character device driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24.04.19 19:07, Linus Walleij wrote:

Hi folks,

> The character device is created from inside the core GPIOLIB code
> and cannot be disabled.

Actually, I've got a patch somewhere in the pipeline for making it
optional. (for small systems that don't need/want it).
In the long run, both - chardev and sysfs - could even go to their
own modules. Both interfaces have their pros and cons, and there're
lots of scenarios where neither is needed.

> The character device for each gpiochip is created inside the
> gpiochip_setup_dev() call in drivers/gpio/gpiolib.c
> 
> What happens next is that the kernel invokes the uevent helper.
> This used to be /sbin/hotplug 

Uh, you still remember that old things ... ;-)

> but udev+systemd systems
> nowadays use a netlink socket to send the events to userspace
> and I have no idea how that works, sorry.

In short it goes like this:

* the kernel sends a message via netlink to the userspace agent,
  including things like major/minor, device name, etc.
* the userspace agent (eg. udev or mdev) looks in his database/config
  what to do now. usually this finally ends up in creating some device
  node somewhere in /dev, but could also include running some commands,
  create symlinks, etc, etc.

To get back to the problem of this thread:

When the device node doesn't appear, there're several things might be
wrong:

a) gpio subsystem is missing. can be checked eg. via sysfs:

nekrad@orion:/sys$ find /sys/class/gpio/
/sys/class/gpio/
/sys/class/gpio/export
/sys/class/gpio/unexport

Here you see, on my machine, gpio subsystem is active, but no
actual gpio devices registered. (they should appear as gpiochip*)

a) gpiolib doesn't register the device. that can be checked via
   /proc/devices:

nekrad@orion:~$ cat /proc/devices | grep gpiochip
254 gpiochip

You see, it's there. (otherwise output would be empty)

b) userland agent doesn't create the device node, when it should.

You'll have to debug your userland agent (most people have udev).

udev, should just use kernel device name (as shown in /proc/devices) as
the device node name, if no other rules dictate anything else.
(eg. my ancient trusty userland doesn't know about ttyprintk, but udev
still creates /dev/ttyprintk)

> It doesn't matter. The /dev/gpiochipN are the same no matter what
> hardware description you use. The appear when the driver
> call [devm_]gpiochip_add[_data](). This is the same for all
> GPIO drivers.

Yes, once the gpio chip is registered, it should appear as some
/dev/gpiochipN (major X, major N - on my box X=254, i guess X is
dynamic for gpiochip).

So, when the gpiochip appears in /sys/class/gpio, but /dev/gpiochipN
is missing, the problem most likely is in the userland agent.
(As Linus already mentioned: gpio chardev currently can't be opted-out)

> I want to forget how the sysfs works but it is protected AFAIK
> so you cannot use the same pins with sysfs and the chardev.

Just had a quick look: both interfaces goes the gpiod_request() route,
then then does the locking/conflict check.

>> P.S.: by the way, it is an HONOR to me, having a mail with the 2nd Linus
>> of the Kernel! ;-P
> 
> I'm just some engineer, it's not that big deal.

Dont be so shy, just take the compliment as it is :)


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux