On 04/24/2019 07:07 PM, Linus Walleij wrote:
On Wed, Apr 24, 2019 at 3:10 PM gianluca <gianlucarenzi@xxxxxxxx> wrote:
On 04/23/2019 07:51 PM, Linus Walleij wrote:
Do I have to __DISABLE__ the sysfs support from kernel config?
No.
Ok, mainly because the kernel config has GPIOLIB enabled by default and
I added a _NOT_MODULE_ sysfs driver i.e. it is monolithic inside the
kernel...
The character device is created from inside the core GPIOLIB code
and cannot be disabled.
Got it.
No, I mean which is the 'entry point' for creating those
/dev/gpiochip[X] devices? I suppose some system call has to be issued to
tell udev to create those char drivers...
The character device for each gpiochip is created inside the
gpiochip_setup_dev() call in drivers/gpio/gpiolib.c
Ok.
What happens next is that the kernel invokes the uevent helper.
This used to be /sbin/hotplug but udev+systemd systems
nowadays use a netlink socket to send the events to userspace
and I have no idea how that works, sorry.
Well, in my systems I have systemd disable because we are heavly
customizing the boot sequence as we are using sysinit for booting...
Is this behaviour forced to *NOT* have gpio characters in udev /dev
structure during boot up?
As soon as possible I will check better in my boards which having Kernel
> 4.9 to find which issue is causing those drivers not to appear in /dev...
/dev/gpiochipN even appears on my Intel laptop.
I suppose you are using non OF_ but ACPI_ stuff. ;-)
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.
Ok.
Ok. Now this reveals a question: if I configure some pin using sysfs,
those pins can be used in gpiolib chardev stuff? I suppose I have to
unregister the driver with 'unexport'.
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.
exporting/unexporting just affects individual lines on a chip
it doesn't register/unregister the driver att all.
Ok, I will test it under userspace ASAP if it breaks up our software...
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.
It's a big deal to me afterall.
Kindest regards,
--
Eurek s.r.l. |
Electronic Engineering | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212
