Re: [PATCH RFT 4/5] gpio: gpio-pl061: use the generic request/free implementations

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Mon, Oct 5, 2015 at 3:12 PM, Jonas Gorski <jogo@xxxxxxxxxxx> wrote:
> [Me]
>> Can we think of a way to do this even more generic:
>> could gpiochip_generic_request() check if the range is
>> there instead?
>
> I thought about this, and AFAICT this would open a window in which gpio
> requests could bypass the pinctrl subsystem, as ranges are only registered
> after the gpio chip was registered.
> pinctrl_request_gpio() -> pinctrl_get_device_gpio_range() returns -EPROBEDEFER if
> it can't find a range for that reason.
>
> To solve this we could introduce a gpiochip_add_with_range(), then we can assign
> the generic _request/_free in gpiochip_add in case the callbacks aren't set yet
> (and keep the way _request/_free are implemented).

Hm! That sounds like a good idea. Alexandre, what do you think?

> static const struct __initconst pinctrl_gpio_range foo_range = {
>         .base = 0,
>         .pinbase = 0,
>         .npins = npins,
> };
>
> gpiochip_add_with_ranges(chip, "foo", &foo_range, 1);

Neato.

> which would be a bit more verbose, but for drivers like pinctrl-cygnus-gpio,
> which registers 51(!) pinranges for the same gpio chip, it would mean quite a
> bit of code reduction.

Now we're talking.

Are you interested in doing this refactoring? It'd be awesome.

(Do it on top of this series though, so we can merge this first.)

Yours,
Linus Walleij
--
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