STM32MP1 ECO Unused GPIO busy after gpioset

[debugging]

Kernel tree does not assign any driver to pin PZ2. After gpioset -c gpiochip11 2=1, the pins goes actually high (from low) but the gpioset program stalls. SSH at that moment into the device shows:

line 0: "PZ0" input
line 1: "PZ1" input
line 2: "PZ2" output consumer="gpioset"
line 3: "PZ3" input
line 4: "PZ4" input consumer="kernel"
line 5: "PZ5" input consumer="kernel"
line 6: "PZ6" input
line 7: "PZ7" input

Aborting CTRL-C/Z gpioset causes the device to be busy upon a next set.

Is there a way to set the pin and the client release itself as consumer of  GPIO pin to be able to change the pin later back to low?

root@stm32mp1:~# gpioset -c gpiochip11 2=1
^Z[1]+ Stopped gpioset -c gpiochip11 2=1
root@stm32mp1:~# gpioset -c gpiochip11 2=0
gpioset: unable to request lines on chip '/dev/gpiochip11': Device or resource busy

root@stm32mp1:~# gpioget -c gpiochip11 2
gpioget: unable to request lines: Device or resource busy

[PatrickF · Accepted solution]

Hi @debugging 

according to https://wiki.st.com/stm32mpu/wiki/How_to_control_a_GPIO_in_userspace, it is needed to use CTRL+C (and not CTRL+Z which keep the gpioset process running in background, which block further ressource usage). I don't know why gpioset is working like that.

To force exit of gpioset immediately, you need to use '-t0'

gpioset -t0 -c gpiochip11 2=1

Regards.

[debugging]

Tank you very much.  this helps a lot. Perhaps good to add to the wiki.

[PatrickF]

wiki update is planned even if the listed CTRL+C works and this is more a libgpio v2 specificity (seems an intended behavior).
I think it is minor as only command line issue. In an application, behavior is more clean.

regards.