Re: "gpioN" named functions for GPIO pins

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 6, 2015 at 12:26 PM, Jonas Gorski <jogo@xxxxxxxxxxx> wrote:

> As far as I understand the second paragraph, it should suffice to
> define functions named "gpio0", "gpio1", etc. instead of adding a
> gpio_request_enable().
>
> But I fail to see in pinctrl_request_gpio() where this happens:
>
> pinctrl_request_gpio() calls pinmux_request_gpio(), which calls
> pin_request(); pin_request() then calls ops->gpio_request_enable() if
> present and a gpiorange is given, or ops->request() if present.
> Nowhere I can see that any "gpio%d" function is even looked for, at
> least that was the heuristic I used to find that place where
> pinctrl_request_gpio was supposed to obtain the function "gpioN".

No you're right...

pinctrl_request_gpio() ->
pinmux_request_gpio() ->
pin_request() ->

Then you get to this:

        /*
         * If there is no kind of request function for the pin we just assume
         * we got it by default and proceed.
         */
        if (gpio_range && ops->gpio_request_enable)
                /* This requests and enables a single GPIO pin */
                status = ops->gpio_request_enable(pctldev, gpio_range, pin);
        else if (ops->request)
                status = ops->request(pctldev, pin);
        else
                status = 0;

It will try to acquire it as a single pin but not check that the function
name is correct.

So it's not very strict, this will be allowed no matter what function
name you set on that pin.

I guess people use this by setting the mux up in the usual way
with functions+groups e.g. through a device tree, then this will
just fall through nicely and the mux be correct.

But it should call:
.get_functions_count()
.get_function_name()
if a proper name is found, call
.set_mux() with the right function and group set to zero
(this should be OK, maybe we should even look for groups...)
THEN if that works, call ops->request()

But I fear regressions if we actually do this ...

If you want to fix it, go ahead!

Alternatively delete this from the documentation.

I'm quite perplexed this is so wrong :/ I must have been stressed
out when reviewing something. Or probably documented it the way
I thought it works but was just wrong about that.

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




[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux