Sharing GPIO pins for different purposes

[nylnx]

Hi, I have a use case where I want to temporarily take over the GPIO pins from a device driver (in my case UART) and control these pins like a normal GPIO and also give control back to the UART driver afterwards. I'm on STM32 hardware and switching from GPIO to device GPIO needs setting the "alternate function" and therefore only the pin control API could do this. I also know about different pin-ctrls, but only "default" and "sleep" is supported and obviously doesn't match my use case.

The only solutions I could come up so far are:

• Copy the STM32 UART driver and extend it in a custom driver: This is bad, because I don't want to maintain the custom driver forever.
• Bypass the device driver and just do it with STM32 HAL and steal the GPIO out from under the driver: Ugly, but probably would work.
• Omit the pinctrl-0 in the UART devicetree definition and have a second custom uart-pin-handle-driver that provides more control to the pin management: Don't know if this would work, a lot of work for something "small" and also feels kind of wrong.

I would be very curious about other (better) ideas on how to approach this problem and what others might have done to solve it. It seems like a relatively pedestrian problem, since especially in embedded, there can be many reasons to share a pin for very different purposes, but I could not find any documentation or even discussions about this.

Thanks in advance :)

[nylnx]

cc @henrikbrixandersen @gmarull

[gmarull]

You can take the I2C recovery case (not all platforms implement this), where pins are switched from pinctrl to GPIO and back to pinctrl.

[nylnx]

I looked at the I2C recovery case, but there is locking and especially it's a special use case for I2C which is already supported. But in a more generally applicable case there is no solution, since there is no concept for sharing a GPIO. Sure, I can always make a custom driver, but this will just lead to code duplication.

I am looking for a hopefully elegant solution without having a special driver for it. Sure I need to make sure the UART is not actively communicating, but apart from that I would like to have a way to control the pins without the driver knowing about it (more than its standard API interface).

Maybe another example is more clear: What if I wanted to switch the UART output pins for a given UART peripheral? What would/could I do in this case?

[JPHutchins]

@nylnx I'd love to continue this discussion, here are my initial thoughts.

For context, the product uses UART over USBC pins and therefore needs to initialize UART in the "sleep" state - otherwise, the product could damage USBC peers that aren't expecting the pullup on the pins we're using. The STM32 implementation MUST be patched to solve this critical issue.

pinctrl's assumption of a "default" and "sleep" state is causing device drivers to assume certain behavior and take important control away from the designer. Where the authors of a driver have implemented pinctrl in driver initialization, they initialize to the "default" state. The name "default" incorrectly assumes that this initial state is a "functional", rather than a "sleep", state.

I feel like I heard something about a new API for dynamic driver initialization. It would solve my problem if I could initialize the UART device only once the USBC negotiation has occurred. Of course, I'd need to be able to deinit as well, sending the UART pins back into high-impedance.

[nylnx]

Good to hear that I am not alone on this :) I thought about it a bit more and the following points seem to be important:

1. Pin initialization should not be done by the device itself. GPIO are a shared resource and should be treated as such. There can be a convenience default initializer, but it should not be in the device code, but rather triggered by a special flag or an additional compatible.
2. There has to be some way to get a handle to a device and use it as a pinctrl-handle. I think I've seen a multi-API feature request or something somewhere and it may have a connection, but I could not find it...
3. Being able to dynamically switch between different pin assignments would be really cool. What I'm not sure, is, if it would be feasible to expect that devices react to loosing pin control or what would happen then, also on different hardware. This would maybe have to be like a mutex situation, but this also sounds like a nightmare :D
4. Pin initialization, device initialization and also power management in general are a hot topic currently, but nobody seems to have a high-level overview of all the different use cases that drive this (most likely) necessary redesign. Maybe this needs to be brought to the architecture working group or we need a separate issue, where ideas are collected.