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-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
