Generic GPIO on USB / hotpluggable gpiolib device

Generic GPIO on USB / hotpluggable gpiolib device

[Andy Green]

Hi -

I just wrote a small driver that exposes a USB device's IO as generic 
GPIO using a little protocol.  I often needed a simple way to bitbang 
something from my laptop and this is going to be very useful to 
implement it.

It works fine with dynamic GPIO allocation and so on, but I maybe 
realized at the end why nobody did this until now, in gpiolib it says...

/**
  * gpiochip_remove() - unregister a gpio_chip
  * @chip: the chip to unregister
  *
  * A gpio_chip with any GPIOs still requested may not be removed.
  */
int gpiochip_remove(struct gpio_chip *chip)
{
...
	for (id = chip->base; id < chip->base + chip->ngpio; id++) {
		if (test_bit(FLAG_REQUESTED, &gpio_desc[id].flags)) {
			status = -EBUSY;
			break;
		}
	}
...

In short gpiolib doesn't have the concept that the chip can be 
hot(un)plugged randomly, including at times when something has requested 
the GPIO.

I am quite certain that USB generic GPIO would be something very nice 
for end users, to be able to casually plug in even the cheapest USB 
micro and bitbang as much GPIO as you like from userspace in a 
standardized way (including being able to exploit the existing bitbang 
protocol drivers on the exposed GPIO) would be very handy.  The protocol 
is simple and flexible (1 x IN endpoint and 1 x OUT endpoint, only one 
packet per call, device announces number of GPIO it supports).

What'd be the feeling if I enhanced gpiolib a bit along the lines of:

  - changing the chip set() function to be able to return errors, at the 
moment it's void return from that

  - adding a flag marking a chip as "dead", causing all IO via it to 
fail immediately and it to be auto-removed when the last request goes

Does this seem workable?  What to do about say SPI bitbang protocol 
driver instance that sees its generic gpio calls started failing?

-Andy