Re: GPIOs not correctly exported via sysfs on ATSAMA5D2

[Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>]

On Fri, Feb 28, 2020 at 02:36:11PM +0100, Linus Walleij wrote:
> 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.

This points out another problem: Drivers behave differently in an area
where there is no technical need. So people are surprised which is a bad
thing. For me giving a gpio/pinctrl driver maintainer the freedom to
label the device as "strict" or not is similar to putting policy in the
kernel which is frowed for.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |