Re: GPIOs not correctly exported via sysfs on ATSAMA5D2

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

 



On Mon, Mar 2, 2020 at 10:30 PM Uwe Kleine-König
<u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
> On Mon, Mar 02, 2020 at 05:34:19PM +0100, Linus Walleij wrote:

> > That's especially annoying. I would consider adding a specific
> > consumer flag for GPIOs used this way, in additon to
> > GPIOD_ASIS, something like GPIOD_ASIS_NOMUX
> > (thinking of better names).
>
> This is not only relevant for GPIOD_ASIS. GPIOs for recovery are
> registered (in the case of i2c-imx) with:
>
>         rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN);
>         rinfo->scl_gpiod = devm_gpiod_get(&pdev->dev, "scl", GPIOD_OUT_HIGH_OPEN_DRAIN);
>
> so we'd need a _NOMUX variant for each gpiod_flags value.

Oh we don't need a special variant for everything. In the end
it is just a bitfield, sorry if I was unclear. :(

#define GPIOD_FLAGS_BIT_NOMUX    BIT(5)

rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN |
GPIOD_FLAGS_BIT_NOMUX);

or
GPIOD_OUT_HIGH_OPEN_DRAIN | GPIOD_FLAGS_BIT_NOMUX
is fine.

It is just convenient helpers after all.

> Also if a board makes use of i2c, the corresponding pins shouldn't be
> muxed to GPIO if userspace requests the GPIO via gpioctl or sysfs.
> (IMHO i2c isn't special here, this should apply to all used pins,
> shouldn't it?)

This is another reason why people tag their pin controllers
as strict, and in that case this works.

For those that are not strict, userspace can intercept
the same pins and wreac havoc. Using GPIO from userspace
is indeed in many cases a good gun to shoot oneself in
the foot with.

The solution is not perfect, improvements can be made.

> > Since the calling site knows about this usecase we can
> > open code the semantics for this specifically.
>
> Since the calling site doesn't know if the pin is used otherwise, it
> should default to _NOMUX?

Sorry I'm not following?

I was thinking that if the I2C driver knows it will be doing this
imperative I2C recovery by shaking the pins from the GPIO
side of things, it will request the pins with the flag
GPIOD_FLAGS_BIT_NOMUX and then the GPIO and
pin control subsystems knows: "aha they wanna use these
behind the back of pin control so let's not enforce stuff,
just give them a handle to the line and make sure nobody
else goes and use these lines".

Yours,
Linus Walleij




[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