linux-kernel - Generic GPIO on USB / hotpluggable gpiolib device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 10 Sep 2010 09:51:55 +0100
From:	Andy Green <andy@...mcat.com>
To:	linux-kernel@...r.kernel.org
Subject: Generic GPIO on USB / hotpluggable gpiolib device

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/