Pinmuxing (Loadable) Kernel Module?

In my practical work pinmuxing is a daily issue. Available solutions are anoying:

  • The device tree configuration at boot time is too unflexible.

  • The universal_io solutions are much better, but unusable for my purposes since they use human readable names.

  • So I made a similar solution using numbers, but it’s a pitty to bloat the kernel memory by so much device tree entries. Most of them unused all the time. And often I’d like to use a further mode, not yet pre-defined.
    What I miss is a simple and flexible solution. A kernel module that provides a single entry in sysfs:

  • Write access (root privileges) configures a pin (if not reserved), ie. like

  • value 0x010c002e sets CM register at offset 0x010c to mode 0x2e, or alternatively

  • value 0x6c3f sets ball number 0x6c to mode 0x3f, or anything similar.- Optional: Read access returns a list of all current ball configurations in the same format (with a mark free / reserved).
    Does anybody

  • knows about,

  • uses,

  • develops (or is willing to develop)
    such a kernel module?

Posts copied from

You mean like this?


That should read add mode feature

Yes and no …

The user space aspect is what I mean. But I’m speaking about pin muxing. That is

  • all that GPIO stuff in your document, as well as

  • the ball mode feature (GPIO, CAP, PWM, …) and

  • pullup /pulldown restistor settings.
    Instead of several folders and files in sysfs and human readable parameters, I’d like to see

  • a single entry that

  • gets opened once and can

  • controll all free pins by a single write access,

  • receiving a single parameter that is a combination of ball#/value (or register offset/value - like in the device tree source).
    The pins to operate on could get defined in the device tree. But it’d be better when the driver could auto-determine them (the not reserved one).

In short, I’m searching for a solution to set the parameters of a device tree entry like

B08_28: 08_28 {pinctrl-single,pins = <0x020 0x28>;};


at run time via sysfs.


Well, that is what I meant by mode, which is pinmux Mode1 through Mode7, plus the pullup, pulldown, direction, etc. Rather than starting from scratch, I think it would be simple to add this to gpiolib. Also, gpiolib has uses debugfs to display info about the gpio pins. Look at /sys/kernel/debug/gpio. Not sure how you would implement this in a generic way so that it would apply to other architectures. Without this, I don’t believe it will be accepted by mainline.


Hi John, please excuse my late reply. I haven’t been in the office for a while.

I agree, it wouldn’t be easy the implement this in a generic way to the gpiolib driver. And even if possible, we’ll end up with a pinmux feature in a driver named gpiolib. Another stumbling stone in the big “find the right driver” game. Sure, that’s not the way to go.

But what about adapting the driver pinctrl-single? This driver has all features we need. We just have to implement entries in sysfs to additionally control the pins after boot time. I see no reason why that shouldn’t be possible in a generic way for all architectures.

Your statement is much appriciated.