Two drivers using same gpio pin

[queseuq]

I've been digging around the kernel a bit to see if I can work this out but I thought it would be quicker to post the question here.

Basically I want to combine the gpio-poweroff-overlay and gpio-shutdown-overlay into a single overlay that does both tasks on the same pin. This seems feasible in theory as the gpio-poweroff driver allows the pin to the set as in input until shutdown, however both drivers (gpio-poweroff and gpio-keys) seem to use different methods to get their gpio_desc (although they both include gpio/consumer.h)

My question is, if I pass the same gpio pin to both, will they still be able to get a gpio_desc and 'just work' or can only one driver hold a gpio_desc for a pin?

[PhilE]

Attempting to use the same GPIO from multiple drivers looks like it will fail. The various gpio_* API calls, including devm_gpiod_get and devm_fwnode_get_gpiod_from_child, go through gpiod_request that claims the descriptor, failing eith -EBUSY if it has already been claimed.

Assuming you could share the pin at the software level, how were you going to arrange that pushing the switch doesn't trigger a premature power-off? Are you really that short of pins to warrant the complexity?

[PiGraham]

Clueless comment - Could you create one driver that does both functions and sorts out which internally?

[queseuq]

Thanks for the reply, I thought that might be the case but want to check just in case.

Assuming you could share the pin at the software level, how were you going to arrange that pushing the switch doesn't trigger a premature power-off? Are you really that short of pins to warrant the complexity?

I'm using this circuit as a power controller -> http://www.mosaic-industries.com/embedd ... controller

It's designed such that a single button can control power on, shutdown and a hard power off and works off a single pin. I've recently found references to the LTC2951-1 in the forum which does something similar but I don't think it comes in a though hole package, and that's as far as my soldering skills go.

Ah well, back to the drawing board I guess!

[PhilE]

That's not a clueless comment, it's a sensible question. Yes you could, but it goes against the Linux philosophy of doing one thing and doing it well. Better would be to create a GPIO sharing driver that claims one (or more) GPIOs and presents them as a number of distinct GPIOs, managing the mode switches internally.

[PiGraham]

That's not a clueless comment, it's a sensible question. Yes you could, but it goes against the Linux philosophy of doing one thing and doing it well. Better would be to create a GPIO sharing driver that claims one (or more) GPIOs and presents them as a number of distinct GPIOs, managing the mode switches internally.

Thanks.
I meant clueless about the detail of DT and these drivers.

On the philosophical point, you could look at it as one thing - power control, in one driver on one pin, rather than two drivers on two pins. I see a certain elegant efficiency to it.

[PhilE]

I suppose one could minimise the duplication of effort by getting the gpio-poweroff driver to advertise itself as a tiny gpio controller, sharing its own gpio as if it were a different gpio.

[queseuq]

I suppose one could minimise the duplication of effort by getting the gpio-poweroff driver to advertise itself as a tiny gpio controller, sharing its own gpio as if it were a different gpio.

This sounds interesting but a bit beyond me unfortunately. I presume I'd have to do something more that just add 'gpio_controller' to the overlay node

[PhilE]

This sounds interesting but a bit beyond me unfortunately. I presume I'd have to do something more that just add 'gpio_controller' to the overlay node

That would be part of the solution, but yes, somebody would have to extend the gpio-poweroff driver to implement the GPIO pass-through interface.

[queseuq]

For anyone interested in this, I found that I could export the pin directly from the kernel driver. I can then (hopefully) use a userspace daemon to monitor it's state. I've opened a pull request (https://github.com/raspberrypi/linux/pull/2552) to add this functionality upstream.

[PhilE]

I've merged the PR, so the updated driver and overlay will be in the next firmware release.