Re: [PATCH] gpio: mcp23s08: support setting pullups from device tree data

[Timo Teras <timo.teras@xxxxxx>]

On Mon, 07 Dec 2015 07:53:08 +0100
Alexander Stein <alexander.stein@xxxxxxxxxxxxxxxxxxxxx> wrote:

> On Friday 04 December 2015 13:46:13, Timo Teräs wrote:
> > Make pullup configurable from device tree data.
> > 
> > Signed-off-by: Timo Teräs <timo.teras@xxxxxx>
> > ---
> > I'm not fully certain how the pullup data should be made
> > configurable via OF. gpio-twl4030.c uses similar approach as this,
> > but gpio-samsung.c makes the pullup configuration seems to be part
> > of the custom data in gpio specifiers.  
> 
> I think this should be specified for each individual GPIO. e.g.
> > gpios = <&gpio-ctrl 0 GPIO_ACTIVE_HIGH GPIO_PULLUP>;  
> 
> You don't know (yet) which pins might need a internal pull-up when
> specifying the mcp23s08 node itself. You might override the
> controller node in your dts, but so you need to adjust 2 entries, one
> for the user and one for the pullup, rather than have all options at
> one place.

I think this is debatable. So consider this as opening a bit wider
discussion about the preferred way of exposing pullup/down configuration
via OF. And hopefully documenting it. (As mentioned there's already
code in for either way.)

Agreeably one might want to override it on PIN basis. Perhaps the GPIO
function can be changed or similar.

The other side is: Why would my gpio-keys input mapping specification
need know to what kind of GPIO input it is connected to? What if I
switch the GPIO expander - or the hardware schema?  I need to edit 10
different places rather than one - places that are about the high-level
functionality, not the hardware. Normally the pullup settings are
hardware layout dependant, so GPIO configuration would be the logical
place.

One generally wants to configure pullups correctly for all GPIOs
regardless of if they are connected or not; or if the relevant
high-level gpio driver is loaded or not. And this should be done as
early as possible - even before the driver for that specific GPIO pin
functionality is loaded.

This seems to be the way most platform data things work for different
GPIOs.

Perphaps others have more arguments for the per-pin configuration?
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html