linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it
@ 2019-06-20  6:24 Stefan Roese
  2019-06-20  6:24 ` [PATCH 2/2 v9] tty/serial/8250: use mctrl_gpio helpers Stefan Roese
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Stefan Roese @ 2019-06-20  6:24 UTC (permalink / raw)
  To: linux-serial
  Cc: linux-kernel, Mika Westerberg, Andy Shevchenko, Yegor Yefremov,
	Greg Kroah-Hartman, Giulio Benetti

This patch adds a check for the GPIOs property existence, before the
GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio
support is added (2nd patch in this patch series) on x86 platforms using
ACPI.

Here Mika's comments from 2016-08-09:

"
I noticed that with v4.8-rc1 serial console of some of our Broxton
systems does not work properly anymore. I'm able to see output but input
does not work.

I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
("tty/serial/8250: use mctrl_gpio helpers").

The reason why it fails is that in ACPI we do not have names for GPIOs
(except when _DSD is used) so we use the "idx" to index into _CRS GPIO
resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The
UART device in Broxton has following (simplified) ACPI description:

    Device (URT4)
    {
        ...
        Name (_CRS, ResourceTemplate () {
            GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                    "\\_SB.GPO0", 0x00, ResourceConsumer)
            {
                0x003A
            }
            GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                    "\\_SB.GPO0", 0x00, ResourceConsumer)
            {
                0x003D
            }
        })

In this case it finds the first GPIO (0x003A which happens to be RX pin
for that UART), turns it into GPIO which then breaks input for the UART
device. This also breaks systems with bluetooth connected to UART (those
typically have some GPIOs in their _CRS).

Any ideas how to fix this?

We cannot just drop the _CRS index lookup fallback because that would
break many existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).
"

This patch implements the fix suggested by Mika in his statement above.

Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
v9:
- Rebased on top of "tty-next", patch 2/3 dropped as its already applied

v8:
- Rebased on top of "tty-next"

v7:
- Include <linux/property.h> to fix compile breakage on OMAP

v6:
- No change

v5:
- Simplified the code a bit (Andy)
- Added gpio_str == NULL handling (Andy)

v4:
- Add missing free() calls (Johan)
- Added Mika's reviewed by tag
- Added Johan to Cc

v3:
- No change

v2:
- Include the problem description and analysis from Mika into the commit
  text, as suggested by Greg.

 drivers/tty/serial/serial_mctrl_gpio.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/tty/serial/serial_mctrl_gpio.c b/drivers/tty/serial/serial_mctrl_gpio.c
index 39ed56214cd3..2b400189be91 100644
--- a/drivers/tty/serial/serial_mctrl_gpio.c
+++ b/drivers/tty/serial/serial_mctrl_gpio.c
@@ -12,6 +12,7 @@
 #include <linux/termios.h>
 #include <linux/serial_core.h>
 #include <linux/module.h>
+#include <linux/property.h>
 
 #include "serial_mctrl_gpio.h"
 
@@ -116,6 +117,19 @@ struct mctrl_gpios *mctrl_gpio_init_noauto(struct device *dev, unsigned int idx)
 
 	for (i = 0; i < UART_GPIO_MAX; i++) {
 		enum gpiod_flags flags;
+		char *gpio_str;
+		bool present;
+
+		/* Check if GPIO property exists and continue if not */
+		gpio_str = kasprintf(GFP_KERNEL, "%s-gpios",
+				     mctrl_gpios_desc[i].name);
+		if (!gpio_str)
+			continue;
+
+		present = device_property_present(dev, gpio_str);
+		kfree(gpio_str);
+		if (!present)
+			continue;
 
 		if (mctrl_gpios_desc[i].dir_out)
 			flags = GPIOD_OUT_LOW;
-- 
2.22.0

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH 2/2 v9] tty/serial/8250: use mctrl_gpio helpers
  2019-06-20  6:24 [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Stefan Roese
@ 2019-06-20  6:24 ` Stefan Roese
  2019-06-24  8:42 ` [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Geert Uytterhoeven
  2019-07-25 12:10 ` Uwe Kleine-König
  2 siblings, 0 replies; 8+ messages in thread
From: Stefan Roese @ 2019-06-20  6:24 UTC (permalink / raw)
  To: linux-serial
  Cc: linux-kernel, Yegor Yefremov, Andy Shevchenko, Mika Westerberg,
	Giulio Benetti, Greg Kroah-Hartman

From: Yegor Yefremov <yegorslists@googlemail.com>

This patch permits the usage for GPIOs to control
the CTS/RTS/DTR/DSR/DCD/RI signals.

Changed by Stefan:
Only call mctrl_gpio_init(), if the device has no ACPI companion device
to not break existing ACPI based systems. Also only use the mctrl_gpio_
functions when "gpios" is available.

Use MSR / MCR <-> TIOCM wrapper functions.

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v9:
- Rebased on top of "tty-next", patch 2/3 dropped as its already applied

v8:
- Rebased on top of "tty-next"

v7:
- Change serial8250_do_get_mctrl() so that systems with a "mixed setup"
  (i.e. CTS controlled by UART but other status pins controlled by GPIO)
  are also supported again (Yegor)

v6:
- Use newly introduced TIOCM <-> MCR/MSR wrapper functions
- serial8250_in_MCR(): Don't save the already read MCR bits in TIOCM
  format but "or" them later to the GPIO MCR value
- Correctly use "!up->gpios" (Andy)
- Removed Mika's reviewed by tag (because of changes)

v5:
- Dropped a few "if (up->gpios)" checks, as the mctrl_gpio_foo() API
  handles gpios == NULL (return)
- 8250_omap: Changed "IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(up->gpios, ...))"
  to "up->gpios == NULL", as mctrl_gpio_to_gpiod() does not handle
  gpios == NULL correctly.

v4:
- Added Mika's reviewed by tag
- Added Johan to Cc

v3:
- Only call mctrl_gpio_init(), if the device has no ACPI companion device
  to not break existing ACPI based systems, as suggested by Andy

v2:
- No change

Please note that this patch was already applied before [1]. And later
reverted [2] because it introduced problems on some x86 based boards
(ACPI GPIO related). Here a detailed description of the issue at that
time:

https://lkml.org/lkml/2016/8/9/357
http://www.spinics.net/lists/linux-serial/msg23071.html

This is a re-send of the original patch that was applied at that time.
With patch 1/2 from this series this issue should be fixed now (please
note that I can't test it on such an x86 platform causing these
problems).

Andy (or Mika), perhaps it would be possible for you to test this
patch again, now with patch 1/2 of this series applied as well?
That would be really helpful.

Thanks,
Stefan

[1] 4ef03d328769 ("tty/serial/8250: use mctrl_gpio helpers")
[2] 5db4f7f80d16 ("Revert "tty/serial/8250: use mctrl_gpio helpers"")

 .../devicetree/bindings/serial/8250.txt       | 19 ++++++++++++
 drivers/tty/serial/8250/8250.h                | 18 +++++++++++-
 drivers/tty/serial/8250/8250_core.c           | 17 +++++++++++
 drivers/tty/serial/8250/8250_omap.c           | 29 ++++++++++---------
 drivers/tty/serial/8250/8250_port.c           | 11 ++++++-
 drivers/tty/serial/8250/Kconfig               |  1 +
 include/linux/serial_8250.h                   |  1 +
 7 files changed, 81 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index 3cba12f855b7..20d351f268ef 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -53,6 +53,9 @@ Optional properties:
   programmable TX FIFO thresholds.
 - resets : phandle + reset specifier pairs
 - overrun-throttle-ms : how long to pause uart rx when input overrun is encountered.
+- {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD
+  line respectively. It will use specified GPIO instead of the peripheral
+  function pin for the UART feature. If unsure, don't specify this property.
 
 Note:
 * fsl,ns16550:
@@ -74,3 +77,19 @@ Example:
 		interrupts = <10>;
 		reg-shift = <2>;
 	};
+
+Example for OMAP UART using GPIO-based modem control signals:
+
+	uart4: serial@49042000 {
+		compatible = "ti,omap3-uart";
+		reg = <0x49042000 0x400>;
+		interrupts = <80>;
+		ti,hwmods = "uart4";
+		clock-frequency = <48000000>;
+		cts-gpios = <&gpio3 5 GPIO_ACTIVE_LOW>;
+		rts-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;
+		dtr-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
+		dsr-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
+		dcd-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>;
+		rng-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
+	};
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 57db8c1689af..33ad9d6de532 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -11,6 +11,8 @@
 #include <linux/serial_reg.h>
 #include <linux/dmaengine.h>
 
+#include "../serial_mctrl_gpio.h"
+
 struct uart_8250_dma {
 	int (*tx_dma)(struct uart_8250_port *p);
 	int (*rx_dma)(struct uart_8250_port *p);
@@ -214,11 +216,25 @@ static inline int serial8250_MSR_to_TIOCM(int msr)
 static inline void serial8250_out_MCR(struct uart_8250_port *up, int value)
 {
 	serial_out(up, UART_MCR, value);
+
+	if (up->gpios)
+		mctrl_gpio_set(up->gpios, serial8250_MCR_to_TIOCM(value));
 }
 
 static inline int serial8250_in_MCR(struct uart_8250_port *up)
 {
-	return serial_in(up, UART_MCR);
+	int mctrl;
+
+	mctrl = serial_in(up, UART_MCR);
+
+	if (up->gpios) {
+		unsigned int mctrl_gpio = 0;
+
+		mctrl_gpio = mctrl_gpio_get_outputs(up->gpios, &mctrl_gpio);
+		mctrl |= serial8250_TIOCM_to_MCR(mctrl_gpio);
+	}
+
+	return mctrl;
 }
 
 #if defined(__alpha__) && !defined(CONFIG_PCI)
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index e441221e04b9..a4470771005f 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -14,6 +14,7 @@
  *	      serial8250_register_8250_port() ports
  */
 
+#include <linux/acpi.h>
 #include <linux/module.h>
 #include <linux/moduleparam.h>
 #include <linux/ioport.h>
@@ -982,6 +983,8 @@ int serial8250_register_8250_port(struct uart_8250_port *up)
 
 	uart = serial8250_find_match_or_unused(&up->port);
 	if (uart && uart->port.type != PORT_8250_CIR) {
+		struct mctrl_gpios *gpios;
+
 		if (uart->port.dev)
 			uart_remove_one_port(&serial8250_reg, &uart->port);
 
@@ -1016,6 +1019,20 @@ int serial8250_register_8250_port(struct uart_8250_port *up)
 		if (up->port.flags & UPF_FIXED_TYPE)
 			uart->port.type = up->port.type;
 
+		/*
+		 * Only call mctrl_gpio_init(), if the device has no ACPI
+		 * companion device
+		 */
+		if (!has_acpi_companion(uart->port.dev)) {
+			gpios = mctrl_gpio_init(&uart->port, 0);
+			if (IS_ERR(gpios)) {
+				if (PTR_ERR(gpios) != -ENOSYS)
+					return PTR_ERR(gpios);
+			} else {
+				uart->gpios = gpios;
+			}
+		}
+
 		serial8250_set_defaults(uart);
 
 		/* Possibly override default I/O functions.  */
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index ed25cfc3be13..3ef65cbd2478 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -141,18 +141,20 @@ static void omap8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
 
 	serial8250_do_set_mctrl(port, mctrl);
 
-	/*
-	 * Turn off autoRTS if RTS is lowered and restore autoRTS setting
-	 * if RTS is raised
-	 */
-	lcr = serial_in(up, UART_LCR);
-	serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
-	if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS))
-		priv->efr |= UART_EFR_RTS;
-	else
-		priv->efr &= ~UART_EFR_RTS;
-	serial_out(up, UART_EFR, priv->efr);
-	serial_out(up, UART_LCR, lcr);
+	if (!up->gpios) {
+		/*
+		 * Turn off autoRTS if RTS is lowered and restore autoRTS
+		 * setting if RTS is raised
+		 */
+		lcr = serial_in(up, UART_LCR);
+		serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
+		if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS))
+			priv->efr |= UART_EFR_RTS;
+		else
+			priv->efr &= ~UART_EFR_RTS;
+		serial_out(up, UART_EFR, priv->efr);
+		serial_out(up, UART_LCR, lcr);
+	}
 }
 
 /*
@@ -453,7 +455,8 @@ static void omap_8250_set_termios(struct uart_port *port,
 	priv->efr = 0;
 	up->port.status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS | UPSTAT_AUTOXOFF);
 
-	if (termios->c_cflag & CRTSCTS && up->port.flags & UPF_HARD_FLOW) {
+	if (termios->c_cflag & CRTSCTS && up->port.flags & UPF_HARD_FLOW &&
+	    !up->gpios) {
 		/* Enable AUTOCTS (autoRTS is enabled when RTS is raised) */
 		up->port.status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
 		priv->efr |= UART_EFR_CTS;
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 6bd3f65ac967..71f54454a0f2 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1656,6 +1656,8 @@ static void serial8250_disable_ms(struct uart_port *port)
 	if (up->bugs & UART_BUG_NOMSR)
 		return;
 
+	mctrl_gpio_disable_ms(up->gpios);
+
 	up->ier &= ~UART_IER_MSI;
 	serial_port_out(port, UART_IER, up->ier);
 }
@@ -1668,6 +1670,8 @@ static void serial8250_enable_ms(struct uart_port *port)
 	if (up->bugs & UART_BUG_NOMSR)
 		return;
 
+	mctrl_gpio_enable_ms(up->gpios);
+
 	up->ier |= UART_IER_MSI;
 
 	serial8250_rpm_get(up);
@@ -1939,12 +1943,17 @@ unsigned int serial8250_do_get_mctrl(struct uart_port *port)
 {
 	struct uart_8250_port *up = up_to_u8250p(port);
 	unsigned int status;
+	unsigned int val;
 
 	serial8250_rpm_get(up);
 	status = serial8250_modem_status(up);
 	serial8250_rpm_put(up);
 
-	return serial8250_MSR_to_TIOCM(status);
+	val = serial8250_MSR_to_TIOCM(status);
+	if (up->gpios)
+		return mctrl_gpio_get(up->gpios, &val);
+
+	return val;
 }
 EXPORT_SYMBOL_GPL(serial8250_do_get_mctrl);
 
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index 296115f6a4d8..509f6a3bb9ff 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -8,6 +8,7 @@ config SERIAL_8250
 	tristate "8250/16550 and compatible serial support"
 	depends on !S390
 	select SERIAL_CORE
+	select SERIAL_MCTRL_GPIO if GPIOLIB
 	---help---
 	  This selects whether you want to include the driver for the standard
 	  serial ports.  The standard answer is Y.  People who might say N
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 5e0b59422a68..bb2bc99388ca 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -110,6 +110,7 @@ struct uart_8250_port {
 						 *   if no_console_suspend
 						 */
 	unsigned char		probe;
+	struct mctrl_gpios	*gpios;
 #define UART_PROBE_RSA	(1 << 0)
 
 	/*
-- 
2.22.0

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it
  2019-06-20  6:24 [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Stefan Roese
  2019-06-20  6:24 ` [PATCH 2/2 v9] tty/serial/8250: use mctrl_gpio helpers Stefan Roese
@ 2019-06-24  8:42 ` Geert Uytterhoeven
  2019-06-24 15:29   ` Stefan Roese
  2019-07-25 12:10 ` Uwe Kleine-König
  2 siblings, 1 reply; 8+ messages in thread
From: Geert Uytterhoeven @ 2019-06-24  8:42 UTC (permalink / raw)
  To: Stefan Roese
  Cc: open list:SERIAL DRIVERS, Linux Kernel Mailing List,
	Mika Westerberg, Andy Shevchenko, Yegor Yefremov,
	Greg Kroah-Hartman, Giulio Benetti, Linus Walleij,
	Bartosz Golaszewski, open list:GPIO SUBSYSTEM

CC gpio

This is now commit d99482673f950817 ("serial: mctrl_gpio: Check if GPIO
property exisits before requesting it") in tty-next.

On Thu, Jun 20, 2019 at 8:24 AM Stefan Roese <sr@denx.de> wrote:
> This patch adds a check for the GPIOs property existence, before the
> GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio
> support is added (2nd patch in this patch series) on x86 platforms using
> ACPI.
>
> Here Mika's comments from 2016-08-09:
>
> "
> I noticed that with v4.8-rc1 serial console of some of our Broxton
> systems does not work properly anymore. I'm able to see output but input
> does not work.
>
> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
> ("tty/serial/8250: use mctrl_gpio helpers").
>
> The reason why it fails is that in ACPI we do not have names for GPIOs
> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO
> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The
> UART device in Broxton has following (simplified) ACPI description:
>
>     Device (URT4)
>     {
>         ...
>         Name (_CRS, ResourceTemplate () {
>             GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>                     "\\_SB.GPO0", 0x00, ResourceConsumer)
>             {
>                 0x003A
>             }
>             GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>                     "\\_SB.GPO0", 0x00, ResourceConsumer)
>             {
>                 0x003D
>             }
>         })
>
> In this case it finds the first GPIO (0x003A which happens to be RX pin
> for that UART), turns it into GPIO which then breaks input for the UART
> device. This also breaks systems with bluetooth connected to UART (those
> typically have some GPIOs in their _CRS).
>
> Any ideas how to fix this?
>
> We cannot just drop the _CRS index lookup fallback because that would
> break many existing machines out there so maybe we can limit this to
> only DT enabled machines. Or alternatively probe if the property first
> exists before trying to acquire the GPIOs (using
> device_property_present()).
> "
>
> This patch implements the fix suggested by Mika in his statement above.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Yegor Yefremov <yegorslists@googlemail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
> v9:
> - Rebased on top of "tty-next", patch 2/3 dropped as its already applied
>
> v8:
> - Rebased on top of "tty-next"
>
> v7:
> - Include <linux/property.h> to fix compile breakage on OMAP
>
> v6:
> - No change
>
> v5:
> - Simplified the code a bit (Andy)
> - Added gpio_str == NULL handling (Andy)
>
> v4:
> - Add missing free() calls (Johan)
> - Added Mika's reviewed by tag
> - Added Johan to Cc
>
> v3:
> - No change
>
> v2:
> - Include the problem description and analysis from Mika into the commit
>   text, as suggested by Greg.
>
>  drivers/tty/serial/serial_mctrl_gpio.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/tty/serial/serial_mctrl_gpio.c b/drivers/tty/serial/serial_mctrl_gpio.c
> index 39ed56214cd3..2b400189be91 100644
> --- a/drivers/tty/serial/serial_mctrl_gpio.c
> +++ b/drivers/tty/serial/serial_mctrl_gpio.c
> @@ -12,6 +12,7 @@
>  #include <linux/termios.h>
>  #include <linux/serial_core.h>
>  #include <linux/module.h>
> +#include <linux/property.h>
>
>  #include "serial_mctrl_gpio.h"
>
> @@ -116,6 +117,19 @@ struct mctrl_gpios *mctrl_gpio_init_noauto(struct device *dev, unsigned int idx)
>
>         for (i = 0; i < UART_GPIO_MAX; i++) {
>                 enum gpiod_flags flags;
> +               char *gpio_str;
> +               bool present;
> +
> +               /* Check if GPIO property exists and continue if not */
> +               gpio_str = kasprintf(GFP_KERNEL, "%s-gpios",
> +                                    mctrl_gpios_desc[i].name);

This will silently break DTBs using "(cts|dsr|dcd|rng|rts|dtr)-gpio" instead
of "(cts|dsr|dcd|rng|rts|dtr)-gpios".

> +               if (!gpio_str)
> +                       continue;
> +
> +               present = device_property_present(dev, gpio_str);
> +               kfree(gpio_str);
> +               if (!present)
> +                       continue;
>
>                 if (mctrl_gpios_desc[i].dir_out)
>                         flags = GPIOD_OUT_LOW;

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it
  2019-06-24  8:42 ` [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Geert Uytterhoeven
@ 2019-06-24 15:29   ` Stefan Roese
  2019-06-24 15:35     ` Geert Uytterhoeven
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Roese @ 2019-06-24 15:29 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: open list:SERIAL DRIVERS, Linux Kernel Mailing List,
	Mika Westerberg, Andy Shevchenko, Yegor Yefremov,
	Greg Kroah-Hartman, Giulio Benetti, Linus Walleij,
	Bartosz Golaszewski, open list:GPIO SUBSYSTEM

On 24.06.19 10:42, Geert Uytterhoeven wrote:
> CC gpio
> 
> This is now commit d99482673f950817 ("serial: mctrl_gpio: Check if GPIO
> property exisits before requesting it") in tty-next.
> 
> On Thu, Jun 20, 2019 at 8:24 AM Stefan Roese <sr@denx.de> wrote:
>> This patch adds a check for the GPIOs property existence, before the
>> GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio
>> support is added (2nd patch in this patch series) on x86 platforms using
>> ACPI.
>>
>> Here Mika's comments from 2016-08-09:
>>
>> "
>> I noticed that with v4.8-rc1 serial console of some of our Broxton
>> systems does not work properly anymore. I'm able to see output but input
>> does not work.
>>
>> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
>> ("tty/serial/8250: use mctrl_gpio helpers").
>>
>> The reason why it fails is that in ACPI we do not have names for GPIOs
>> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO
>> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
>> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The
>> UART device in Broxton has following (simplified) ACPI description:
>>
>>      Device (URT4)
>>      {
>>          ...
>>          Name (_CRS, ResourceTemplate () {
>>              GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>>                      "\\_SB.GPO0", 0x00, ResourceConsumer)
>>              {
>>                  0x003A
>>              }
>>              GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>>                      "\\_SB.GPO0", 0x00, ResourceConsumer)
>>              {
>>                  0x003D
>>              }
>>          })
>>
>> In this case it finds the first GPIO (0x003A which happens to be RX pin
>> for that UART), turns it into GPIO which then breaks input for the UART
>> device. This also breaks systems with bluetooth connected to UART (those
>> typically have some GPIOs in their _CRS).
>>
>> Any ideas how to fix this?
>>
>> We cannot just drop the _CRS index lookup fallback because that would
>> break many existing machines out there so maybe we can limit this to
>> only DT enabled machines. Or alternatively probe if the property first
>> exists before trying to acquire the GPIOs (using
>> device_property_present()).
>> "
>>
>> This patch implements the fix suggested by Mika in his statement above.
>>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
>> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
>> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Cc: Yegor Yefremov <yegorslists@googlemail.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>
>> ---
>> v9:
>> - Rebased on top of "tty-next", patch 2/3 dropped as its already applied
>>
>> v8:
>> - Rebased on top of "tty-next"
>>
>> v7:
>> - Include <linux/property.h> to fix compile breakage on OMAP
>>
>> v6:
>> - No change
>>
>> v5:
>> - Simplified the code a bit (Andy)
>> - Added gpio_str == NULL handling (Andy)
>>
>> v4:
>> - Add missing free() calls (Johan)
>> - Added Mika's reviewed by tag
>> - Added Johan to Cc
>>
>> v3:
>> - No change
>>
>> v2:
>> - Include the problem description and analysis from Mika into the commit
>>    text, as suggested by Greg.
>>
>>   drivers/tty/serial/serial_mctrl_gpio.c | 14 ++++++++++++++
>>   1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/tty/serial/serial_mctrl_gpio.c b/drivers/tty/serial/serial_mctrl_gpio.c
>> index 39ed56214cd3..2b400189be91 100644
>> --- a/drivers/tty/serial/serial_mctrl_gpio.c
>> +++ b/drivers/tty/serial/serial_mctrl_gpio.c
>> @@ -12,6 +12,7 @@
>>   #include <linux/termios.h>
>>   #include <linux/serial_core.h>
>>   #include <linux/module.h>
>> +#include <linux/property.h>
>>
>>   #include "serial_mctrl_gpio.h"
>>
>> @@ -116,6 +117,19 @@ struct mctrl_gpios *mctrl_gpio_init_noauto(struct device *dev, unsigned int idx)
>>
>>          for (i = 0; i < UART_GPIO_MAX; i++) {
>>                  enum gpiod_flags flags;
>> +               char *gpio_str;
>> +               bool present;
>> +
>> +               /* Check if GPIO property exists and continue if not */
>> +               gpio_str = kasprintf(GFP_KERNEL, "%s-gpios",
>> +                                    mctrl_gpios_desc[i].name);
> 
> This will silently break DTBs using "(cts|dsr|dcd|rng|rts|dtr)-gpio" instead
> of "(cts|dsr|dcd|rng|rts|dtr)-gpios".

Should both options be supported ("cts-gpio" vs "cts-gpios")?
Documentation/devicetree/bindings/serial/serial.txt only mentions
the "-gpios" variant.

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it
  2019-06-24 15:29   ` Stefan Roese
@ 2019-06-24 15:35     ` Geert Uytterhoeven
  2019-06-25  5:27       ` Stefan Roese
  0 siblings, 1 reply; 8+ messages in thread
From: Geert Uytterhoeven @ 2019-06-24 15:35 UTC (permalink / raw)
  To: Stefan Roese
  Cc: open list:SERIAL DRIVERS, Linux Kernel Mailing List,
	Mika Westerberg, Andy Shevchenko, Yegor Yefremov,
	Greg Kroah-Hartman, Giulio Benetti, Linus Walleij,
	Bartosz Golaszewski, open list:GPIO SUBSYSTEM

Hi Stefan,

On Mon, Jun 24, 2019 at 5:29 PM Stefan Roese <sr@denx.de> wrote:
> On 24.06.19 10:42, Geert Uytterhoeven wrote:
> > On Thu, Jun 20, 2019 at 8:24 AM Stefan Roese <sr@denx.de> wrote:
> >> This patch adds a check for the GPIOs property existence, before the
> >> GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio
> >> support is added (2nd patch in this patch series) on x86 platforms using
> >> ACPI.
> >>
> >> Here Mika's comments from 2016-08-09:
> >>
> >> "
> >> I noticed that with v4.8-rc1 serial console of some of our Broxton
> >> systems does not work properly anymore. I'm able to see output but input
> >> does not work.
> >>
> >> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
> >> ("tty/serial/8250: use mctrl_gpio helpers").
> >>
> >> The reason why it fails is that in ACPI we do not have names for GPIOs
> >> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO
> >> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
> >> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The
> >> UART device in Broxton has following (simplified) ACPI description:
> >>
> >>      Device (URT4)
> >>      {
> >>          ...
> >>          Name (_CRS, ResourceTemplate () {
> >>              GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
> >>                      "\\_SB.GPO0", 0x00, ResourceConsumer)
> >>              {
> >>                  0x003A
> >>              }
> >>              GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
> >>                      "\\_SB.GPO0", 0x00, ResourceConsumer)
> >>              {
> >>                  0x003D
> >>              }
> >>          })
> >>
> >> In this case it finds the first GPIO (0x003A which happens to be RX pin
> >> for that UART), turns it into GPIO which then breaks input for the UART
> >> device. This also breaks systems with bluetooth connected to UART (those
> >> typically have some GPIOs in their _CRS).
> >>
> >> Any ideas how to fix this?
> >>
> >> We cannot just drop the _CRS index lookup fallback because that would
> >> break many existing machines out there so maybe we can limit this to
> >> only DT enabled machines. Or alternatively probe if the property first
> >> exists before trying to acquire the GPIOs (using
> >> device_property_present()).
> >> "
> >>
> >> This patch implements the fix suggested by Mika in his statement above.
> >>
> >> Signed-off-by: Stefan Roese <sr@denx.de>

> >> --- a/drivers/tty/serial/serial_mctrl_gpio.c
> >> +++ b/drivers/tty/serial/serial_mctrl_gpio.c

> >> @@ -116,6 +117,19 @@ struct mctrl_gpios *mctrl_gpio_init_noauto(struct device *dev, unsigned int idx)
> >>
> >>          for (i = 0; i < UART_GPIO_MAX; i++) {
> >>                  enum gpiod_flags flags;
> >> +               char *gpio_str;
> >> +               bool present;
> >> +
> >> +               /* Check if GPIO property exists and continue if not */
> >> +               gpio_str = kasprintf(GFP_KERNEL, "%s-gpios",
> >> +                                    mctrl_gpios_desc[i].name);
> >
> > This will silently break DTBs using "(cts|dsr|dcd|rng|rts|dtr)-gpio" instead
> > of "(cts|dsr|dcd|rng|rts|dtr)-gpios".
>
> Should both options be supported ("cts-gpio" vs "cts-gpios")?
> Documentation/devicetree/bindings/serial/serial.txt only mentions
> the "-gpios" variant.

Well, the "-gpio" variant is deprecated, but still supported by
devm_gpiod_get_index_optional(), and there are active users in upstream
DTS files.

My main objection is (trying to) replicate the matching logic inside
gpiolib.c, causing subtle semantic differences. And keeping it consistent,
of course.

It would be nice if this could be fixed inside acpi_find_gpio(), so
users don't need to be updated.  There may be other subsystems where
the difference between DT and ACPI may cause issues, unbeknownst.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it
  2019-06-24 15:35     ` Geert Uytterhoeven
@ 2019-06-25  5:27       ` Stefan Roese
  2019-06-25 11:19         ` Andy Shevchenko
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Roese @ 2019-06-25  5:27 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: open list:SERIAL DRIVERS, Linux Kernel Mailing List,
	Mika Westerberg, Andy Shevchenko, Yegor Yefremov,
	Greg Kroah-Hartman, Giulio Benetti, Linus Walleij,
	Bartosz Golaszewski, open list:GPIO SUBSYSTEM

Hi Geert,

On 24.06.19 17:35, Geert Uytterhoeven wrote:
> On Mon, Jun 24, 2019 at 5:29 PM Stefan Roese <sr@denx.de> wrote:
>> On 24.06.19 10:42, Geert Uytterhoeven wrote:
>>> On Thu, Jun 20, 2019 at 8:24 AM Stefan Roese <sr@denx.de> wrote:
>>>> This patch adds a check for the GPIOs property existence, before the
>>>> GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio
>>>> support is added (2nd patch in this patch series) on x86 platforms using
>>>> ACPI.
>>>>
>>>> Here Mika's comments from 2016-08-09:
>>>>
>>>> "
>>>> I noticed that with v4.8-rc1 serial console of some of our Broxton
>>>> systems does not work properly anymore. I'm able to see output but input
>>>> does not work.
>>>>
>>>> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
>>>> ("tty/serial/8250: use mctrl_gpio helpers").
>>>>
>>>> The reason why it fails is that in ACPI we do not have names for GPIOs
>>>> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO
>>>> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
>>>> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The
>>>> UART device in Broxton has following (simplified) ACPI description:
>>>>
>>>>       Device (URT4)
>>>>       {
>>>>           ...
>>>>           Name (_CRS, ResourceTemplate () {
>>>>               GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>>>>                       "\\_SB.GPO0", 0x00, ResourceConsumer)
>>>>               {
>>>>                   0x003A
>>>>               }
>>>>               GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>>>>                       "\\_SB.GPO0", 0x00, ResourceConsumer)
>>>>               {
>>>>                   0x003D
>>>>               }
>>>>           })
>>>>
>>>> In this case it finds the first GPIO (0x003A which happens to be RX pin
>>>> for that UART), turns it into GPIO which then breaks input for the UART
>>>> device. This also breaks systems with bluetooth connected to UART (those
>>>> typically have some GPIOs in their _CRS).
>>>>
>>>> Any ideas how to fix this?
>>>>
>>>> We cannot just drop the _CRS index lookup fallback because that would
>>>> break many existing machines out there so maybe we can limit this to
>>>> only DT enabled machines. Or alternatively probe if the property first
>>>> exists before trying to acquire the GPIOs (using
>>>> device_property_present()).
>>>> "
>>>>
>>>> This patch implements the fix suggested by Mika in his statement above.
>>>>
>>>> Signed-off-by: Stefan Roese <sr@denx.de>
> 
>>>> --- a/drivers/tty/serial/serial_mctrl_gpio.c
>>>> +++ b/drivers/tty/serial/serial_mctrl_gpio.c
> 
>>>> @@ -116,6 +117,19 @@ struct mctrl_gpios *mctrl_gpio_init_noauto(struct device *dev, unsigned int idx)
>>>>
>>>>           for (i = 0; i < UART_GPIO_MAX; i++) {
>>>>                   enum gpiod_flags flags;
>>>> +               char *gpio_str;
>>>> +               bool present;
>>>> +
>>>> +               /* Check if GPIO property exists and continue if not */
>>>> +               gpio_str = kasprintf(GFP_KERNEL, "%s-gpios",
>>>> +                                    mctrl_gpios_desc[i].name);
>>>
>>> This will silently break DTBs using "(cts|dsr|dcd|rng|rts|dtr)-gpio" instead
>>> of "(cts|dsr|dcd|rng|rts|dtr)-gpios".
>>
>> Should both options be supported ("cts-gpio" vs "cts-gpios")?
>> Documentation/devicetree/bindings/serial/serial.txt only mentions
>> the "-gpios" variant.
> 
> Well, the "-gpio" variant is deprecated, but still supported by
> devm_gpiod_get_index_optional(), and there are active users in upstream
> DTS files.
> 
> My main objection is (trying to) replicate the matching logic inside
> gpiolib.c, causing subtle semantic differences. And keeping it consistent,
> of course.
> 
> It would be nice if this could be fixed inside acpi_find_gpio(), so
> users don't need to be updated.  There may be other subsystems where
> the difference between DT and ACPI may cause issues, unbeknownst.

Sure, I can fix this. I would prefer to do this in a follow-up patch
though, if nobody objects.

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it
  2019-06-25  5:27       ` Stefan Roese
@ 2019-06-25 11:19         ` Andy Shevchenko
  0 siblings, 0 replies; 8+ messages in thread
From: Andy Shevchenko @ 2019-06-25 11:19 UTC (permalink / raw)
  To: Stefan Roese
  Cc: Geert Uytterhoeven, open list:SERIAL DRIVERS,
	Linux Kernel Mailing List, Mika Westerberg, Yegor Yefremov,
	Greg Kroah-Hartman, Giulio Benetti, Linus Walleij,
	Bartosz Golaszewski, open list:GPIO SUBSYSTEM

On Tue, Jun 25, 2019 at 07:27:33AM +0200, Stefan Roese wrote:
> On 24.06.19 17:35, Geert Uytterhoeven wrote:
> > On Mon, Jun 24, 2019 at 5:29 PM Stefan Roese <sr@denx.de> wrote:
> > > On 24.06.19 10:42, Geert Uytterhoeven wrote:

> > > Should both options be supported ("cts-gpio" vs "cts-gpios")?
> > > Documentation/devicetree/bindings/serial/serial.txt only mentions
> > > the "-gpios" variant.
> > 
> > Well, the "-gpio" variant is deprecated, but still supported by
> > devm_gpiod_get_index_optional(), and there are active users in upstream
> > DTS files.
> > 
> > My main objection is (trying to) replicate the matching logic inside
> > gpiolib.c, causing subtle semantic differences. And keeping it consistent,
> > of course.
> > 
> > It would be nice if this could be fixed inside acpi_find_gpio(), so
> > users don't need to be updated.  There may be other subsystems where
> > the difference between DT and ACPI may cause issues, unbeknownst.
> 
> Sure, I can fix this. I would prefer to do this in a follow-up patch
> though, if nobody objects.

In case if you are going to do this, use approach from GPIO library. Perhaps,
it may require to create something like for_each_gpio_suffix() helper.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it
  2019-06-20  6:24 [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Stefan Roese
  2019-06-20  6:24 ` [PATCH 2/2 v9] tty/serial/8250: use mctrl_gpio helpers Stefan Roese
  2019-06-24  8:42 ` [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Geert Uytterhoeven
@ 2019-07-25 12:10 ` Uwe Kleine-König
  2 siblings, 0 replies; 8+ messages in thread
From: Uwe Kleine-König @ 2019-07-25 12:10 UTC (permalink / raw)
  To: Stefan Roese
  Cc: linux-serial, linux-kernel, Mika Westerberg, Andy Shevchenko,
	Yegor Yefremov, Greg Kroah-Hartman, Giulio Benetti

Hello,

On Thu, Jun 20, 2019 at 08:24:19AM +0200, Stefan Roese wrote:
> This patch adds a check for the GPIOs property existence, before the
> GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio
> support is added (2nd patch in this patch series) on x86 platforms using
> ACPI.
> 
> Here Mika's comments from 2016-08-09:
> 
> "
> I noticed that with v4.8-rc1 serial console of some of our Broxton
> systems does not work properly anymore. I'm able to see output but input
> does not work.
> 
> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
> ("tty/serial/8250: use mctrl_gpio helpers").
> 
> The reason why it fails is that in ACPI we do not have names for GPIOs
> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO
> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The
> UART device in Broxton has following (simplified) ACPI description:
> 
>     Device (URT4)
>     {
>         ...
>         Name (_CRS, ResourceTemplate () {
>             GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>                     "\\_SB.GPO0", 0x00, ResourceConsumer)
>             {
>                 0x003A
>             }
>             GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>                     "\\_SB.GPO0", 0x00, ResourceConsumer)
>             {
>                 0x003D
>             }
>         })
> 
> In this case it finds the first GPIO (0x003A which happens to be RX pin
> for that UART), turns it into GPIO which then breaks input for the UART
> device. This also breaks systems with bluetooth connected to UART (those
> typically have some GPIOs in their _CRS).
> 
> Any ideas how to fix this?
> 
> We cannot just drop the _CRS index lookup fallback because that would
> break many existing machines out there so maybe we can limit this to
> only DT enabled machines. Or alternatively probe if the property first
> exists before trying to acquire the GPIOs (using
> device_property_present()).
> "
> 
> This patch implements the fix suggested by Mika in his statement above.
> 
> Signed-off-by: Stefan Roese <sr@denx.de>
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Yegor Yefremov <yegorslists@googlemail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
> v9:
> - Rebased on top of "tty-next", patch 2/3 dropped as its already applied
> 
> v8:
> - Rebased on top of "tty-next"
> 
> v7:
> - Include <linux/property.h> to fix compile breakage on OMAP
> 
> v6:
> - No change
> 
> v5:
> - Simplified the code a bit (Andy)
> - Added gpio_str == NULL handling (Andy)
> 
> v4:
> - Add missing free() calls (Johan)
> - Added Mika's reviewed by tag
> - Added Johan to Cc
> 
> v3:
> - No change
> 
> v2:
> - Include the problem description and analysis from Mika into the commit
>   text, as suggested by Greg.
> 
>  drivers/tty/serial/serial_mctrl_gpio.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/tty/serial/serial_mctrl_gpio.c b/drivers/tty/serial/serial_mctrl_gpio.c
> index 39ed56214cd3..2b400189be91 100644
> --- a/drivers/tty/serial/serial_mctrl_gpio.c
> +++ b/drivers/tty/serial/serial_mctrl_gpio.c
> @@ -12,6 +12,7 @@
>  #include <linux/termios.h>
>  #include <linux/serial_core.h>
>  #include <linux/module.h>
> +#include <linux/property.h>
>  
>  #include "serial_mctrl_gpio.h"
>  
> @@ -116,6 +117,19 @@ struct mctrl_gpios *mctrl_gpio_init_noauto(struct device *dev, unsigned int idx)
>  
>  	for (i = 0; i < UART_GPIO_MAX; i++) {
>  		enum gpiod_flags flags;
> +		char *gpio_str;
> +		bool present;
> +
> +		/* Check if GPIO property exists and continue if not */
> +		gpio_str = kasprintf(GFP_KERNEL, "%s-gpios",
> +				     mctrl_gpios_desc[i].name);
> +		if (!gpio_str)
> +			continue;

Is it a good idea to handle a memory allocation problem with a continue?

> +		present = device_property_present(dev, gpio_str);
> +		kfree(gpio_str);
> +		if (!present)
> +			continue;
>  

Assuming this fixes the situation on x86 this means that there
device_property_present(...) returns false and
devm_gpiod_get_index_optional returns an error code.

I wonder what the problem is here. Is CONFIG_GPIOLIB on in the failing
situation?

I assume this will end in the usual discussion if gpiod_get_*_optional
should return an error code if GPIOLIB is off.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2019-07-25 12:10 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-20  6:24 [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Stefan Roese
2019-06-20  6:24 ` [PATCH 2/2 v9] tty/serial/8250: use mctrl_gpio helpers Stefan Roese
2019-06-24  8:42 ` [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it Geert Uytterhoeven
2019-06-24 15:29   ` Stefan Roese
2019-06-24 15:35     ` Geert Uytterhoeven
2019-06-25  5:27       ` Stefan Roese
2019-06-25 11:19         ` Andy Shevchenko
2019-07-25 12:10 ` Uwe Kleine-König

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).