I thought that would make sense too! :) Someone would need to
write the code though. Having such a mechanism would provide
another "carrot" to migrate folk towards the gpiolib core.
I think adding a gpiochip primitive to mark a (potential) GPIO
as invalid would support the converse of /sys/kernel/debug/gpio.
Invalid GPIOs include pins set up for non-GPIO usage (like being
used for MMC or MII), or not wired up on a given board. Pins
that were valid as GPIOs and not requested by a kernel driver
might reasonably be managed by userspace code.
I expect it will become a lot more common. Remember that legacy
I2C drivers *couldn't* get any board-specific config data; that's
been problematic, since it meant the drivers themselves ended up
with lots of board-specific cruft. That prevented many drivers
from going upstream at all. (As I mentioned about pcf8574 code,
although in that case the problem was worsened by lack of any
reusable kernel interface for such GPIO signals.)
Could be. Right now we have three "GPIO expander" drivers using
the new "gpiolib" framework: pcf875x and pca9539 for I2C, and
mcp23s08 for SPI. There are many more that *could* be used with
Linux boxes. And there are other drivers/XYZ directories that
are (currently) that small. Maybe gpiolib should go upstream
like that, and lib/gpiolib should be in drivers/gpio too...
However, keep in mind that lots of chips export a few GPIOs but
don't have that as their core functionality ... one example is
the drivers/i2c/chips/tps65010 driver. So it'd never be the
case that GPIO drivers only live in that directory.
- Dave
-