11

Questions

  1. What is the purpose and use-case of the gpio-hog declaration?
  2. Can a 'hogged' gpio pin be interfaced with from Userspace?
  3. If a 'hogged' gpio pin cannot be interfaced with from Userspace, then is there any mechanism to configure GPIO pins in the dts file for Userspace interaction?

Background

I am trying to configure many (10+) GPIOs to speak with a low level chip from Userspace. I have spoken to the chip easily using sysfs exports, but both the documentation in the kernel and programming forums have me concerned about using this mechanisms in our production system.

Reading more kernel documentation I read about gpio-hog declarations and it seemed like the ideal mechanism to at least initially configure the GPIOs. From the documentation:

GPIO hogging is a mechanism providing automatic GPIO request and configuration as part of the gpio-controller's driver probe function.

As well as setting the correct low level, vendor settings, I enabled hogging on the desired gpio pins and they came up reporting the correct settings. The problem is that the gpio's are seemingly owned by the kernel and cannot be interfaced with by any Userspace tools such as sysfs or libgpiod. This makes hogging essentially useless to me and also makes me wonder what it's real purpose is. I am exploring libgpiod as a last resort, but the documentation makes it seem that hogging should be the mechanism I use.

Liam Kelly
  • 3,524
  • 1
  • 17
  • 41
  • 3
    *"is there any mechanism to configure GPIO pins in the dts file for Userspace interaction?"* -- For input it's **gpio-keys** that can be read from **/dev/input/eventN** for notification of input transitions. For output it's **leds-gpio**, and controlled by **/sys/class/leds//brightness**. See **Documentation/gpio/drivers-on-gpio.txt** for more devices. – sawdust Jan 18 '18 at 23:32
  • 9
    @sawdust, not really -- the `gpio-keys` and `gpio-leds` are intended for using with, well, real keys and real LEDs. Using them for plain logic IO is far from elegant. For example, manipulating a GPIO value via a parameter called `brightness` doesn't make sense. – Jan Kundrát Feb 07 '18 at 15:37
  • @JanKundrát very much in agreement. – Liam Kelly Feb 07 '18 at 17:18
  • 1
    @JanKundrát -- The question was for *"any mechanism"*, which I assumed to include quick and dirty methods. What doesn't make sense IMO is insisting on doing this in userspace. If you want elegant, then write a kernel driver. – sawdust Feb 07 '18 at 21:33
  • 2
    @sawdust's solution is definitely a stable Q&D fix. I really have no idea how stable Userspace is because the kernel warns about using it too frequently: `DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS. PLEASE READ THE DOCUMENT NAMED "drivers-on-gpio.txt" IN THIS DOCUMENTATION DIRECTORY TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT. REALLY.` I was hoping for a basic `gpio-out` and `gpio-in` driver that could be extend to have `key` and `led` behavior, but I'll take what i can get for the time being. – Liam Kelly Feb 07 '18 at 21:38
  • *"I am exploring libgpiod as a last resort"* -- Now that the kernel allows definition of gpio pins in the DT and assigning a name, **libgpiod** is a reasonable choice. My aversion to userspace is the (old) use of gpio numbers, but if you use a gpio by *name*, then there is a level of abstraction and portability that is almost equivalent to `drivers-on-gpio`. See https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt – sawdust Sep 07 '19 at 00:25

1 Answers1

8

hog meaning - to take or use a lot of something in a way that prevents other people from having it

so basically gpio-hog property tells the controller to set the pin high/low during bootup, and no other driver/user space would request it.

If you intend to use the gpio in user space you shouldnt be using gpio-hog

Prabhakar Lad
  • 1,248
  • 1
  • 8
  • 12
  • 1
    I am just confused at the utility in setting a gpio to a single mode and not being able to use it. Why would anyone use this? – Liam Kelly Jan 18 '18 at 17:22
  • 2
    For one exmaple suppose you want a pin to be always high/low when booted. But there are many cases just pick up a Linux board which you have handy and look at the device tree file of it and then look at the schematics of the board and that will give you more examples. – Prabhakar Lad Jan 18 '18 at 17:47
  • 2
    It seems sensible to have a way in the device tree to set and lock a pin's direction, but then allow it to be controlled (output) or read (input) by userspace. For an output, it would be useful to be able to set an initial value, but then let it be changed later in userspace. Eg turning on a power-control pin at boot-up. – Craig McQueen Nov 30 '20 at 13:08