Re: GPIOs not correctly exported via sysfs on ATSAMA5D2

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Fri, Feb 28, 2020 at 1:39 PM Ludovic Desroches
<ludovic.desroches@xxxxxxxxxxxxx> wrote:

> The AT91 PIO4 pinctrl driver doesn't implement gpio_request_enable()
> contrary to the AT91 PIO pinctrl driver. If we implement it, then you
> would be able to change the pin muxing and configuration from the sysfs.
> The issue is nothing prevent you do this and so to possibly break a
> device.
>
> There is the strict pinmux_ops property which prevents from this
> situation. The side effect is that we must not declare a pinmux/conf for
> a GPIO so all the DT files have to been updated. That's not a big deal,
> the problem is, at that time, the GPIO subsystem didn't allow to set the
> bias for instance. It may have changed but not sure it covers all the
> possible configurations we have from the pinmuxing subsystem.

Yes and Russell also points very clearly to the root of the problem:

- Some pin multiplexers are non-strict meaning a line can be used
  for say GPIO and something else (such as SDIO) at the same time.
  Usually this is an observation from electronics, such that the GPIO
  input register will always report the logical state on the line whether
  it is in "gpio mode" or something else, making it possible to snoop
  the line, or, as in the I2C case, it is perfectly fine to, without glitches,
  pull the line out of other use cases and into the GPIO realm and do
  GPIO things such as bus recovery actively driving the line despite
  it being connected in the mux to SDIO or I2C at the same time.

- At the same time some system designers and driver authors are
  driven by the ambition to create a system that is simple, has no
  exceptions and has a clear separation of concerns, making it
  impossible for the user - even a kernel developer or real savvy
  hacker playing around with the deprecated sysfs ABI - to shoot
  themselves in the foot. These are ambitious and admirable people
  that want to protect their users and make it easy to do the right
  thing. So they sort everything out and flag their pin multiplexers
  as "strict", allowing only one use case at the time: this device is
  either I2C or SDIO.

Personally I am not flagging any of my drivers strict because I'm
just a pragmatist and don't use the system architect type of reasoning
much in what I do. But it is admittedly a matter of taste. The flag
"strict" tells you something about the driver author's values and
ambition.

If we get to cases where the user is getting hurt by the strictness
rather than enjoying the protection it provides, such as being unable
to do I2C recovery, it may be reasonable to drop the strict setting
and just fail the ambition to separate the concerns, as clearly the
system architecture wasn't perfect in the first place, and trying to
be strict in the mux is going to be a bit like polishing dirt.

This case however looks a bit like tinkering, bring-up and hacking,
and as such it might be expected that the user hack around a bit
and recompile the kernel and device tree etc?

Yours,
Linus Walleij