Hi all,

I plan to rework GPIO API to fix the issue #2529
https://github.com/zephyrproject-rtos/zephyr/issues/2529. But first I
would like to clean it up a bit.

One thing which is confusing and feels inconsistent are GPIO_PIN_ENABLE,
GPIO_PIN_DISABLE configuration constants.

/*
 * GPIO_PIN_(EN-/DIS-)ABLE are for pin enable / disable.
 *
 * Individual pins can be enabled or disabled
 * if the controller supports this operation.
 */

According to the existing implementation - but not necessarily
description - they are meant to give control over the pin to the GPIO
module or let the pin be controlled by a peripheral. However, this
overlaps functionality provided by the pinmux driver.

Especially GPIO_PIN_DISABLE seems a dangerous option to have since it
gives back control over the pin to a peripheral however gives no way to
choose which peripheral it should be. Pin could become an input or an
output. Pinmux driver handles this in a clean way.

It may be the case that the original meaning of the two constant was
different and they were simply incorrectly implemented. E.g.
GPIO_PIN_DISABLE could mean disconnect pin from the pad. I believe some
SoC support this. If this is the case such option still should go to the
pinmux driver not GPIO one.

In any case the both constants are almost universally ignored by the
existing GPIO device drivers. Out of 17 drivers only 2 take
GPIO_PIN_ENABLE option into account. So in the majority case running
gpio_*_configure function always sets the pin in GPIO mode.

To remove current inconsistencies I propose to deprecate
GPIO_PIN_ENABLE, GPIO_PIN_DISABLE configuration constants. I have
prepared a relevant PR:

https://github.com/zephyrproject-rtos/zephyr/pull/4379

I'm posting this to the list as this is about API and I would like the
topic to have a bit more visibility.

Comments are most welcome.

Regards,
Piotr