Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Linus Walleij]

On Wed, Nov 30, 2011 at 7:35 AM, Greg KH <gregkh@xxxxxxx> wrote:

> So, how do you want this type of interface to look like, uevents only?
>
> Or something like gpio?
>
> Actually, why can't we just use gpio as-is here and just treat these
> devices as "generic" i/o "pins"?

For device drivers we have the issue that the management of
the GPIO pin-space give me the creeps. It is simple when things
are simple and then ugly things have start to happen, such
as dynamically bumping the GPIO pin range and associated
IRQ range at compile time using unreadable nested macros.
You roof the space at some arbitrary number at compile-time
in ARCH_NR_GPIOS and if you don't define it,
<asm-generic/gpio.h> will helpfully define that your system
has 256 GPIO pins.

The effect of the above on unified cross-ARM-arch kernels is
confusing as the meaning of the GPIO pinspace will
shift at runtime depending on what system it's running on.

A new subsystem could allocate switch/pin/line assignments
dynamically which is way more viable. (And how we chose to
do in in pinctrl.)

For userspace several people, notably the GPIOlib subsystem
maintainer Grant, expressed concerns about the sysfs interface
to GPIO. So I would not shoehorn new stuff in there, solidifying
it even more.

So I would recommend doing this as a new subsystem to save
us from trouble. There is more to be gained from splitting things
apart than keeping them together in this case IMO.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/