All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	Richard Genoud <richard.genoud@gmail.com>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	NXP Linux Team <linux-imx@nxp.com>,
	"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Ludovic Desroches <ludovic.desroches@microchip.com>
Subject: Re: [PATCH 1/3] serial: atmel: Don't check for mctrl_gpio_to_gpiod() returning error
Date: Wed, 14 Aug 2019 13:08:04 +0200	[thread overview]
Message-ID: <20190814110804.2ceo2upc3su7muup@pengutronix.de> (raw)
In-Reply-To: <CAMuHMdWNj-H9B8E9=NeCgLracBuJODfPyBYJERh=vt4oNFUkGw@mail.gmail.com>

On Wed, Aug 14, 2019 at 12:20:33PM +0200, Geert Uytterhoeven wrote:
> Hi Uwe,
> 
> On Wed, Aug 14, 2019 at 11:36 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Wed, Aug 14, 2019 at 11:29:22AM +0200, Geert Uytterhoeven wrote:
> > > Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
> > > routine"), mctrl_gpio_init() returns failure if the assignment to any
> > > member of the gpio array results in an error pointer.
> > > Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
> > > in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
> > > !CONFIG_GPIOLIB case.
> > > Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
> > > returning an error value.  A simple NULL check is sufficient.
> > >
> > > This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
> > > drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > >  drivers/tty/serial/atmel_serial.c | 12 ++++--------
> > >  1 file changed, 4 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> > > index 19a85d6fe3d20541..e9620a81166b7dc1 100644
> > > --- a/drivers/tty/serial/atmel_serial.c
> > > +++ b/drivers/tty/serial/atmel_serial.c
> > > @@ -303,32 +303,28 @@ static unsigned int atmel_get_lines_status(struct uart_port *port)
> > >
> > >       mctrl_gpio_get(atmel_port->gpios, &ret);
> > >
> > > -     if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
> > > -                                             UART_GPIO_CTS))) {
> > > +     if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> > >               if (ret & TIOCM_CTS)
> > >                       status &= ~ATMEL_US_CTS;
> > >               else
> > >                       status |= ATMEL_US_CTS;
> > >       }
> >
> > The change is fine, but it seems the atmel driver doesn't use mctrl_gpio
> > as expected (at least as expected by me). IMHO driving the hardware
> > function of the CTS pin shouldn't be conditional on the presence of a
> > cts-gpio. Is there a reason not to just drop the if completely?
> 
> The above code returns the hardware status if CTS is not a GPIO, and
> returns (overrides with) the GPIO status if CTS is a GPIO.
> Isn't that correct, or am I missing something?

I took a deeper look into this driver now. The task for
atmel_get_lines_status() isn't to implement the get_mctrl() callback.

Instead this is called in the irqhandler to set ATMEL_US_RI in a
"pending" value that then later in atmel_handle_status() is translated
to a "ring" event that is handled there.

So the right cleanup would be to let atmel_get_lines_status() just be

	return atmel_uart_readl(port, ATMEL_US_CSR);

. If something happend on the lines implemented as gpio the driver's irq
function isn't called anyhow.

Best regards
Uwe

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

WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
	Richard Genoud <richard.genoud@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Ludovic Desroches <ludovic.desroches@microchip.com>,
	NXP Linux Team <linux-imx@nxp.com>,
	Fabio Estevam <festevam@gmail.com>, Jiri Slaby <jslaby@suse.com>,
	Shawn Guo <shawnguo@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/3] serial: atmel: Don't check for mctrl_gpio_to_gpiod() returning error
Date: Wed, 14 Aug 2019 13:08:04 +0200	[thread overview]
Message-ID: <20190814110804.2ceo2upc3su7muup@pengutronix.de> (raw)
In-Reply-To: <CAMuHMdWNj-H9B8E9=NeCgLracBuJODfPyBYJERh=vt4oNFUkGw@mail.gmail.com>

On Wed, Aug 14, 2019 at 12:20:33PM +0200, Geert Uytterhoeven wrote:
> Hi Uwe,
> 
> On Wed, Aug 14, 2019 at 11:36 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Wed, Aug 14, 2019 at 11:29:22AM +0200, Geert Uytterhoeven wrote:
> > > Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
> > > routine"), mctrl_gpio_init() returns failure if the assignment to any
> > > member of the gpio array results in an error pointer.
> > > Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
> > > in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
> > > !CONFIG_GPIOLIB case.
> > > Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
> > > returning an error value.  A simple NULL check is sufficient.
> > >
> > > This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
> > > drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > >  drivers/tty/serial/atmel_serial.c | 12 ++++--------
> > >  1 file changed, 4 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> > > index 19a85d6fe3d20541..e9620a81166b7dc1 100644
> > > --- a/drivers/tty/serial/atmel_serial.c
> > > +++ b/drivers/tty/serial/atmel_serial.c
> > > @@ -303,32 +303,28 @@ static unsigned int atmel_get_lines_status(struct uart_port *port)
> > >
> > >       mctrl_gpio_get(atmel_port->gpios, &ret);
> > >
> > > -     if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
> > > -                                             UART_GPIO_CTS))) {
> > > +     if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> > >               if (ret & TIOCM_CTS)
> > >                       status &= ~ATMEL_US_CTS;
> > >               else
> > >                       status |= ATMEL_US_CTS;
> > >       }
> >
> > The change is fine, but it seems the atmel driver doesn't use mctrl_gpio
> > as expected (at least as expected by me). IMHO driving the hardware
> > function of the CTS pin shouldn't be conditional on the presence of a
> > cts-gpio. Is there a reason not to just drop the if completely?
> 
> The above code returns the hardware status if CTS is not a GPIO, and
> returns (overrides with) the GPIO status if CTS is a GPIO.
> Isn't that correct, or am I missing something?

I took a deeper look into this driver now. The task for
atmel_get_lines_status() isn't to implement the get_mctrl() callback.

Instead this is called in the irqhandler to set ATMEL_US_RI in a
"pending" value that then later in atmel_handle_status() is translated
to a "ring" event that is handled there.

So the right cleanup would be to let atmel_get_lines_status() just be

	return atmel_uart_readl(port, ATMEL_US_CSR);

. If something happend on the lines implemented as gpio the driver's irq
function isn't called anyhow.

Best regards
Uwe

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

WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
	Richard Genoud <richard.genoud@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Ludovic Desroches <ludovic.desroches@microchip.com>,
	NXP Linux Team <linux-imx@nxp.com>,
	Fabio Estevam <festevam@gmail.com>, Jiri Slaby <jslaby@suse.com>,
	Shawn Guo <shawnguo@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/3] serial: atmel: Don't check for mctrl_gpio_to_gpiod() returning error
Date: Wed, 14 Aug 2019 13:08:04 +0200	[thread overview]
Message-ID: <20190814110804.2ceo2upc3su7muup@pengutronix.de> (raw)
In-Reply-To: <CAMuHMdWNj-H9B8E9=NeCgLracBuJODfPyBYJERh=vt4oNFUkGw@mail.gmail.com>

On Wed, Aug 14, 2019 at 12:20:33PM +0200, Geert Uytterhoeven wrote:
> Hi Uwe,
> 
> On Wed, Aug 14, 2019 at 11:36 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Wed, Aug 14, 2019 at 11:29:22AM +0200, Geert Uytterhoeven wrote:
> > > Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
> > > routine"), mctrl_gpio_init() returns failure if the assignment to any
> > > member of the gpio array results in an error pointer.
> > > Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
> > > in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
> > > !CONFIG_GPIOLIB case.
> > > Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
> > > returning an error value.  A simple NULL check is sufficient.
> > >
> > > This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
> > > drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > >  drivers/tty/serial/atmel_serial.c | 12 ++++--------
> > >  1 file changed, 4 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> > > index 19a85d6fe3d20541..e9620a81166b7dc1 100644
> > > --- a/drivers/tty/serial/atmel_serial.c
> > > +++ b/drivers/tty/serial/atmel_serial.c
> > > @@ -303,32 +303,28 @@ static unsigned int atmel_get_lines_status(struct uart_port *port)
> > >
> > >       mctrl_gpio_get(atmel_port->gpios, &ret);
> > >
> > > -     if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
> > > -                                             UART_GPIO_CTS))) {
> > > +     if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> > >               if (ret & TIOCM_CTS)
> > >                       status &= ~ATMEL_US_CTS;
> > >               else
> > >                       status |= ATMEL_US_CTS;
> > >       }
> >
> > The change is fine, but it seems the atmel driver doesn't use mctrl_gpio
> > as expected (at least as expected by me). IMHO driving the hardware
> > function of the CTS pin shouldn't be conditional on the presence of a
> > cts-gpio. Is there a reason not to just drop the if completely?
> 
> The above code returns the hardware status if CTS is not a GPIO, and
> returns (overrides with) the GPIO status if CTS is a GPIO.
> Isn't that correct, or am I missing something?

I took a deeper look into this driver now. The task for
atmel_get_lines_status() isn't to implement the get_mctrl() callback.

Instead this is called in the irqhandler to set ATMEL_US_RI in a
"pending" value that then later in atmel_handle_status() is translated
to a "ring" event that is handled there.

So the right cleanup would be to let atmel_get_lines_status() just be

	return atmel_uart_readl(port, ATMEL_US_CSR);

. If something happend on the lines implemented as gpio the driver's irq
function isn't called anyhow.

Best regards
Uwe

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-08-14 11:08 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14  9:27 [PATCH 0/3] serial: Don't check for mctrl_gpio_to_gpiod() returning error Geert Uytterhoeven
2019-08-14  9:27 ` Geert Uytterhoeven
2019-08-14  9:27 ` Geert Uytterhoeven
2019-08-14  9:27 ` [PATCH 1/3] serial: atmel: " Geert Uytterhoeven
2019-08-14  9:27   ` Geert Uytterhoeven
2019-08-14  9:27   ` Geert Uytterhoeven
2019-08-14  9:27 ` [PATCH 2/3] serial: mxs-auart: " Geert Uytterhoeven
2019-08-14  9:27   ` Geert Uytterhoeven
2019-08-14  9:27   ` Geert Uytterhoeven
2019-08-14  9:27 ` [PATCH 3/3] serial: sh-sci: " Geert Uytterhoeven
2019-08-14  9:27   ` Geert Uytterhoeven
2019-08-14  9:27   ` Geert Uytterhoeven
2019-08-14  9:29 ` [PATCH 0/3] serial: " Geert Uytterhoeven
2019-08-14  9:29   ` Geert Uytterhoeven
2019-08-14  9:29   ` Geert Uytterhoeven
2019-08-14  9:29   ` [PATCH 1/3] serial: atmel: " Geert Uytterhoeven
2019-08-14  9:29     ` Geert Uytterhoeven
2019-08-14  9:29     ` Geert Uytterhoeven
2019-08-14  9:35     ` Uwe Kleine-König
2019-08-14  9:35       ` Uwe Kleine-König
2019-08-14  9:35       ` Uwe Kleine-König
2019-08-14 10:20       ` Geert Uytterhoeven
2019-08-14 10:20         ` Geert Uytterhoeven
2019-08-14 11:08         ` Uwe Kleine-König [this message]
2019-08-14 11:08           ` Uwe Kleine-König
2019-08-14 11:08           ` Uwe Kleine-König
2019-08-20 15:47           ` Richard Genoud
2019-08-20 15:47             ` Richard Genoud
2019-08-21 15:27             ` Richard Genoud
2019-08-21 15:27               ` Richard Genoud
2019-08-21 16:04               ` Geert Uytterhoeven
2019-08-21 16:04                 ` Geert Uytterhoeven
2019-08-20 15:11         ` Richard Genoud
2019-08-20 15:11           ` Richard Genoud
2019-08-14  9:29   ` [PATCH 2/3] serial: mxs-auart: " Geert Uytterhoeven
2019-08-14  9:29     ` Geert Uytterhoeven
2019-08-14  9:29     ` Geert Uytterhoeven
2019-08-19 12:26     ` Simon Horman
2019-08-19 12:26       ` Simon Horman
2019-08-19 12:26       ` Simon Horman
2019-08-14  9:29   ` [PATCH 3/3] serial: sh-sci: " Geert Uytterhoeven
2019-08-14  9:29     ` Geert Uytterhoeven
2019-08-14  9:29     ` Geert Uytterhoeven
2019-08-19  9:51     ` Simon Horman
2019-08-19  9:51       ` Simon Horman
2019-08-19  9:51       ` Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190814110804.2ceo2upc3su7muup@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=alexandre.belloni@bootlin.com \
    --cc=festevam@gmail.com \
    --cc=frieder.schrempf@kontron.de \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=ludovic.desroches@microchip.com \
    --cc=nicolas.ferre@microchip.com \
    --cc=richard.genoud@gmail.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.