Re: GPIOs not correctly exported via sysfs on ATSAMA5D2

[Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx>]

On Fri, Feb 28, 2020 at 01:39:10PM +0100, Ludovic Desroches wrote:
> Hello Romain,
> 
> On Fri, Feb 28, 2020 at 11:58:21AM +0100, Romain Izard wrote:
> > 
> > Hello,
> > 
> > While experimenting with a new chip, I connected it on the SDIO
> > interface on my board based on a SAMA5D2 SoC. For a first step, I need
> > to drive the pins on the SDIO bus at a given level to program this new
> > chip. To do so, I tried to control the GPIO lines manually by unbinding
> > the SDHCI controller, and using /sys/class/gpio/export to control the
> > pins, with the following code:
> > 
> > echo a0000000.sdio-host > /sys/bus/platform/drivers/sdhci-at91/unbind
> > echo 4 > /sys/class/gpio/export
> > echo low > /sys/class/gpio/PA4/direction
> > 
> > Unfortunately, the state of the pin does not change and it remains
> > driven to 1. I checked the configuration register with devmem2, and it
> > appeared that the selected function remains the SDIO function even after
> > calling export.
> > 
> > The issue does not appear when I use a GPIO in a driver with an explicit
> > pinctrl configuration in the device tree, which explains why I did not
> > see it until now.
> > 
> > The kernel version used is Linux 5.4.22
> > 
> > Is this a user error from my part, or is there something missing in the
> > AT91 PIO4 pinctrl driver ?
> 
> This is a known issue.
> 
> 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.

There is also the problem of I2C bus recovery, where an I2C driver
may wish to claim the GPIOs for the I2C bus, but keep the I2C bus
connected to the I2C controller except when performing recovery.

I tripped over problems with that on a Marvell SoC, someone else has
recently reported exactly the same problem as a regression compared
to previous kernels for another SoC in the last day.

The assumption that if a GPIO is claimed, we want the pin to be in
GPIO mode is not universally true, a point that has been missed and
is now coming back to bite.  From what Linus said when we discussed
it, it's very difficult to fix in the GPIO/pinctrl layers.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up