Questions
- What is the purpose and use-case of the
gpio-hogdeclaration? - Can a ‘hogged’ gpio pin be interfaced with from Userspace?
- 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.
Advertisement
Answer
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