Pinctrl hogging

Pinctrl hogging

[noman pouigt]

Kernel version: 3.10

Is there any way to configure default settings for some of the gpios
eventhough there is no one driving them? I am also trying to configure
some of the gpios as irq lines using just the device tree without
writing any device driver for it as it will be used by userspace.

I looked into the existing kernel code in 3.10 kernel and couldn't
find out any reliable way to do that? I did find out some pinctrl
hogging patches but that is part of latest kernel.

Just to workaround this problem I have created a dummy driver
specifically for this purpose. Is there any better way?

Thanks,

Re: Pinctrl hogging

[Linus Walleij]

On Thu, Jul 21, 2016 at 6:21 PM, noman pouigt <variksla@gmail.com> wrote:

> Is there any way to configure default settings for some of the gpios
> eventhough there is no one driving them?

There are gpio hogs but I don't remember which kernel we
introduced them in. Please keep in sync with upstream.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/gpio/gpio.txt?id=6b516a1093006a39368dd11a5396be5bb00c99df

> I am also trying to configure
> some of the gpios as irq lines using just the device tree without
> writing any device driver for it as it will be used by userspace.

I don't recommend randomly using GPIO from userspace. Have you read:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/gpio/drivers-on-gpio.txt

If you still have a valid usecase for userspace GPIO, consider
getting the latest v4.8 kernel when it's out in some two months
and use the new chardev ABI that I just merged. The sysfs
ABI is not good, and that is why it has been obsolted.

We can name lines with gpio-line-names =""; in device tree and
there are example tools for how to use GPIOs from userspace
in a proper way:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/gpio

> Just to workaround this problem I have created a dummy driver
> specifically for this purpose. Is there any better way?

Keeping in touch with upstream and driving changes upstream is
always the best solution.

Yours,
Linus Walleij