Re: [RFC PATCH] gpio: add GPIO hogging mechanism

[boris brezillon]

Hello Greg,

On 19/12/2013 17:41, Greg Kroah-Hartman wrote:
> On Thu, Dec 19, 2013 at 03:34:31PM +0100, Boris BREZILLON wrote:
> > GPIO hogging is a way to request and configure specific GPIO without
> > explicitly requesting it in the device driver.
> >
> > The request and configuration procedure is handled in the core device
> > driver code before the driver probe function is called.
> >
> > It allows specific GPIOs to be configured without any driver specific code.
> >
> > Particularly usefull when a external device is connected to a bus and the
> > bus connections depends on an external switch controlled by a GPIO pin.
> > Or when some GPIOs have to be exported to sysfs without any userspace
> > intervention.
> >
> > Signed-off-by: Boris BREZILLON <b.brezillon@xxxxxxxxxxx>
> > ---
> >   Documentation/devicetree/bindings/gpio/gpio.txt |   47 ++++++++
> >   drivers/base/Makefile                           |    1 +
> >   drivers/base/dd.c                               |    5 +
> >   drivers/base/gpio.c                             |   59 ++++++++++
> I don't understand what makes GPIO's "special" enough to get included in
> the driver core like this, and called for each and every device that is
> added to the system.


> What's wrong with the generic device callbacks/notifiers we already
> have?  Why does this need to be in the driver core?  And what exactly
> are you doing all of this for in the first place?

Nothing's wrong with the generic device callbacks/notifiers, but in some
cases we don't want a generic driver to handle board specificities.

This is the case for the at91rm9200ek board (see this thread:
https://www.mail-archive.com/devicetree@xxxxxxxxxxxxxxx/msg06838.html).

Since we are moving all boards to dt, we can't configure each board at
startup, and the rm9200ek board used to set a pin to a specific value 
(this pin
is connected to an external switch which connects MMC signals to the MMC
connector or SPI signals to an SPI device depending on the pin value) in 
order
to enable the MMC0 port or an SPI device.

I first proposed to handle this using a pinctrl pinconf definition (with 
pinctrl
output-high config). As pinctrl are requesting pinconf before calling 
driver probe
function, this was absolutely transparent to the generic driver.
But, as Linus pointed out, this pin is not really related to the SPI or 
MMC device
itself.
This is why Linus suggested the GPIO hog approach.

Anyway, I'm open to any other solution that wouldn't introduce specific
cases in arch specific code or generic drivers.

Best Regards,

Boris
> greg k-h

--
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/