gpio: TODO: remove the pinctrl integration task

While there are surely some arguments in favor of integrating the GPIO
and pinctrl subsystems into one, I believe this is not the right
approach.

The GPIO subsystem uses intricate locking with SRCU to handle the fact
that both consumers and providers may run in different contexts.
Pin-controller drivers are always meant to run in process context. This
alone is a huge obstacle to any attempt at integration as evident by
many problems we already encountered during the hotplug rework.

The current glue code is pretty minimal and for most part already allows
GPIO controllers to query pinctrl about the information they need.

I suggest to drop this task and keep the subsystems separate even if
many pin-controllers implement GPIO functionality in addition to pin
functions.

Reviewed-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

Author: Bartosz Golaszewski

drivers/gpio/TODO

@@ -136,17 +136,6 @@ try to cover any generic kind of irqchip cascaded from a GPIO.
   dry-code conversions to gpiolib irqchip for maintainers to test
 
 
-Increase integration with pin control
-
-There are already ways to use pin control as back-end for GPIO and
-it may make sense to bring these subsystems closer. One reason for
-creating pin control as its own subsystem was that we could avoid any
-use of the global GPIO numbers. Once the above is complete, it may
-make sense to simply join the subsystems into one and make pin
-multiplexing, pin configuration, GPIO, etc selectable options in one
-and the same pin control and GPIO subsystem.
-
-
 Moving over to immutable irq_chip structures
 
 Most of the gpio chips implementing interrupt support rely on gpiolib