[PATCH] gpio: Revert regression in sysfs-gpio (gpiolib.c)

From: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com>
To: stable@vger.kernel.org, regressions@lists.linux.dev,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	linux-gpio@vger.kernel.org, Thierry Reding <treding@nvidia.com>,
	Vidya Sagar <vidyas@nvidia.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Edmond Chung <edmondchung@google.com>,
	Andrew Chant <achant@google.com>,
	Will McVicker <willmcvicker@google.com>,
	Sergio Tanzilli <tanzilli@acmesystems.it>
Cc: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com>
Subject: [PATCH] gpio: Revert regression in sysfs-gpio (gpiolib.c)
Date: Fri, 17 Dec 2021 12:35:55 -0300	[thread overview]
Message-ID: <20211217153555.9413-1-marcelo.jimenez@gmail.com> (raw)

Some GPIO lines have stopped working after the patch
commit 2ab73c6d8323f ("gpio: Support GPIO controllers without pin-ranges")

And this has supposedly been fixed in the following patches
commit 89ad556b7f96a ("gpio: Avoid using pin ranges with !PINCTRL")
commit 6dbbf84603961 ("gpiolib: Don't free if pin ranges are not defined")

But an erratic behavior where some GPIO lines work while others do not work
has been introduced.

This patch reverts those changes so that the sysfs-gpio interface works
properly again.

Signed-off-by: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com>
---

Hi,

My system is ARM926EJ-S rev 5 (v5l) (AT91SAM9G25), the board is an ACME Systems Arietta.

The system used sysfs-gpio to manage a few gpio lines, and I have noticed that some have stopped working.

The test script is very simple:

	#! /bin/bash

	cd /sys/class/gpio/
	echo 24 > export 

	cd pioA24
	echo out > direction

	echo 0 > value
	cat value
	echo 1 > value
	cat value
	echo 0 > value
	cat value
	echo 1 > value
	cat value

	cd ..
	echo 24 > unexport

In a "good" kernel, this script outputs 0, 1, 0, 1. In a bad kernel, the output result is 1, 1, 1, 1. Also it must be possible to run this script twice without errors, that was the issue with the gpiochip_generic_free() call that had been addressed in another patch.

In my system PINCTRL is automatically selected by 
SOC_AT91SAM9 [=y] && ARCH_AT91 [=y] && ARCH_MULTI_V5 [=y]

So it is not an option to disable it to make it work.

Best regards,
Marcelo.


 drivers/gpio/gpiolib.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index af5bb8fedfea..ac69ec8fb37a 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1804,11 +1804,6 @@ static inline void gpiochip_irqchip_free_valid_mask(struct gpio_chip *gc)
  */
 int gpiochip_generic_request(struct gpio_chip *gc, unsigned offset)
 {
-#ifdef CONFIG_PINCTRL
-	if (list_empty(&gc->gpiodev->pin_ranges))
-		return 0;
-#endif
-
 	return pinctrl_gpio_request(gc->gpiodev->base + offset);
 }
 EXPORT_SYMBOL_GPL(gpiochip_generic_request);
@@ -1820,11 +1815,6 @@ EXPORT_SYMBOL_GPL(gpiochip_generic_request);
  */
 void gpiochip_generic_free(struct gpio_chip *gc, unsigned offset)
 {
-#ifdef CONFIG_PINCTRL
-	if (list_empty(&gc->gpiodev->pin_ranges))
-		return;
-#endif
-
 	pinctrl_gpio_free(gc->gpiodev->base + offset);
 }
 EXPORT_SYMBOL_GPL(gpiochip_generic_free);
-- 
2.30.2

