All of lore.kernel.org
 help / color / mirror / Atom feed
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Tony Lindgren <tony@atomide.com>, Felipe Balbi <balbi@ti.com>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH 5/6] tty: serial: 8250-core: add rs485 support
Date: Thu, 10 Jul 2014 15:52:15 +0100	[thread overview]
Message-ID: <20140710155215.3e17ca08@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <1404928177-26554-6-git-send-email-bigeasy@linutronix.de>

>  static inline void __stop_tx(struct uart_8250_port *p)
>  {
> +	if (p->rs485.flags & SER_RS485_ENABLED) {
> +		int ret;
> +
> +		ret = (p->rs485.flags & SER_RS485_RTS_AFTER_SEND) ? 1 : 0;
> +		if (gpio_get_value(p->rts_gpio) != ret) {
> +			if (p->rs485.delay_rts_after_send > 0)
> +				mdelay(p->rs485.delay_rts_after_send);
> +			gpio_set_value(p->rts_gpio, ret);
> +		}

RTS is not normally a GPIO. We should be controlling the UART RTS here,
and if the UART has a magic special case RTS wired to a GPIO then really
the hardware specific part should handle that gunge. I don't care whether
the drive does it via serial_out magic or a more explicit hook but it
doesn't belong here in core code.

Likewise the mdelay probably should be in the device specific bits or
controlled by a flag as not all hardware is so braindead.

> @@ -1330,6 +1356,20 @@ static void serial8250_start_tx(struct uart_port *port)
>  	if (up->dma && !serial8250_tx_dma(up)) {

Ditto

> +int serial8250_probe_rs485(struct uart_8250_port *up,
> +		struct device *dev)
> +{
> +	struct serial_rs485 *rs485conf = &up->rs485;
> +	struct device_node *np = dev->of_node;
> +	u32 rs485_delay[2];
> +	enum of_gpio_flags flags;
> +	int ret;
> +
> +	rs485conf->flags = 0;
> +	if (!np)
> +		return 0;
> +
> +	/* check for tx enable gpio */
> +	up->rts_gpio = of_get_named_gpio_flags(np, "rts-gpio", 0, &flags);

No of_ dependencies in core 8250.c either please. That looks a perfectly
good implementation of serial8250_of_probe_rs485 however, just belongs in
the right place.

> +static int serial8250_ioctl(struct uart_port *port, unsigned int cmd,
> +		unsigned long arg)
> +{
> +	struct serial_rs485 rs485conf;
> +	struct uart_8250_port *up;
> +
> +	up = container_of(port, struct uart_8250_port, port);
> +	switch (cmd) {
> +	case TIOCSRS485:
> +		if (!gpio_is_valid(up->rts_gpio))
> +			return -ENODEV;

GPIO assumption again needs to go


> diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
> index 0ec21ec..056a73f 100644
> --- a/include/linux/serial_8250.h
> +++ b/include/linux/serial_8250.h
> @@ -78,6 +78,7 @@ struct uart_8250_port {
>  	unsigned char		acr;
>  	unsigned char		ier;
>  	unsigned char		lcr;
> +	unsigned char		fcr;
>  	unsigned char		mcr;
>  	unsigned char		mcr_mask;	/* mask of user bits */
>  	unsigned char		mcr_force;	/* mask of forced bits */
> @@ -94,6 +95,9 @@ struct uart_8250_port {
>  	unsigned char		msr_saved_flags;
>  
>  	struct uart_8250_dma	*dma;
> +	struct serial_rs485	rs485;
> +	int			rts_gpio;
> +	bool			rts_gpio_valid;

Keeping the gpio here doesn't look unreasonable if one is in use.

Alan

WARNING: multiple messages have this Message-ID (diff)
From: gnomes@lxorguk.ukuu.org.uk (One Thousand Gnomes)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/6] tty: serial: 8250-core: add rs485 support
Date: Thu, 10 Jul 2014 15:52:15 +0100	[thread overview]
Message-ID: <20140710155215.3e17ca08@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <1404928177-26554-6-git-send-email-bigeasy@linutronix.de>

>  static inline void __stop_tx(struct uart_8250_port *p)
>  {
> +	if (p->rs485.flags & SER_RS485_ENABLED) {
> +		int ret;
> +
> +		ret = (p->rs485.flags & SER_RS485_RTS_AFTER_SEND) ? 1 : 0;
> +		if (gpio_get_value(p->rts_gpio) != ret) {
> +			if (p->rs485.delay_rts_after_send > 0)
> +				mdelay(p->rs485.delay_rts_after_send);
> +			gpio_set_value(p->rts_gpio, ret);
> +		}

RTS is not normally a GPIO. We should be controlling the UART RTS here,
and if the UART has a magic special case RTS wired to a GPIO then really
the hardware specific part should handle that gunge. I don't care whether
the drive does it via serial_out magic or a more explicit hook but it
doesn't belong here in core code.

Likewise the mdelay probably should be in the device specific bits or
controlled by a flag as not all hardware is so braindead.

> @@ -1330,6 +1356,20 @@ static void serial8250_start_tx(struct uart_port *port)
>  	if (up->dma && !serial8250_tx_dma(up)) {

Ditto

> +int serial8250_probe_rs485(struct uart_8250_port *up,
> +		struct device *dev)
> +{
> +	struct serial_rs485 *rs485conf = &up->rs485;
> +	struct device_node *np = dev->of_node;
> +	u32 rs485_delay[2];
> +	enum of_gpio_flags flags;
> +	int ret;
> +
> +	rs485conf->flags = 0;
> +	if (!np)
> +		return 0;
> +
> +	/* check for tx enable gpio */
> +	up->rts_gpio = of_get_named_gpio_flags(np, "rts-gpio", 0, &flags);

No of_ dependencies in core 8250.c either please. That looks a perfectly
good implementation of serial8250_of_probe_rs485 however, just belongs in
the right place.

> +static int serial8250_ioctl(struct uart_port *port, unsigned int cmd,
> +		unsigned long arg)
> +{
> +	struct serial_rs485 rs485conf;
> +	struct uart_8250_port *up;
> +
> +	up = container_of(port, struct uart_8250_port, port);
> +	switch (cmd) {
> +	case TIOCSRS485:
> +		if (!gpio_is_valid(up->rts_gpio))
> +			return -ENODEV;

GPIO assumption again needs to go


> diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
> index 0ec21ec..056a73f 100644
> --- a/include/linux/serial_8250.h
> +++ b/include/linux/serial_8250.h
> @@ -78,6 +78,7 @@ struct uart_8250_port {
>  	unsigned char		acr;
>  	unsigned char		ier;
>  	unsigned char		lcr;
> +	unsigned char		fcr;
>  	unsigned char		mcr;
>  	unsigned char		mcr_mask;	/* mask of user bits */
>  	unsigned char		mcr_force;	/* mask of forced bits */
> @@ -94,6 +95,9 @@ struct uart_8250_port {
>  	unsigned char		msr_saved_flags;
>  
>  	struct uart_8250_dma	*dma;
> +	struct serial_rs485	rs485;
> +	int			rts_gpio;
> +	bool			rts_gpio_valid;

Keeping the gpio here doesn't look unreasonable if one is in use.

Alan

  parent reply	other threads:[~2014-07-10 14:52 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-09 17:49 (unknown), Sebastian Andrzej Siewior
2014-07-09 17:49 ` No subject Sebastian Andrzej Siewior
2014-07-09 17:49 ` [PATCH 1/6] tty: serial: 8250 core: provide a function to export uart_8250_port Sebastian Andrzej Siewior
2014-07-09 17:49   ` Sebastian Andrzej Siewior
2014-07-10 14:30   ` Olivier Galibert
2014-07-10 14:30     ` Olivier Galibert
2014-07-16  8:22     ` Sebastian Andrzej Siewior
2014-07-16  8:22       ` Sebastian Andrzej Siewior
2014-07-09 17:49 ` [PATCH 2/6] tty: serial: 8250 core: allow to overwrite & export serial8250_startup() Sebastian Andrzej Siewior
2014-07-09 17:49   ` Sebastian Andrzej Siewior
2014-07-10 14:54   ` One Thousand Gnomes
2014-07-10 14:54     ` One Thousand Gnomes
2014-07-10 14:55   ` Sebastian Andrzej Siewior
2014-07-10 14:55     ` Sebastian Andrzej Siewior
2014-07-09 17:49 ` [PATCH 3/6] tty: serial: 8250 core: add runtime pm Sebastian Andrzej Siewior
2014-07-09 17:49   ` Sebastian Andrzej Siewior
2014-07-10  6:28   ` Tony Lindgren
2014-07-10  6:28     ` Tony Lindgren
2014-07-16  8:26     ` Sebastian Andrzej Siewior
2014-07-16  8:26       ` Sebastian Andrzej Siewior
2014-07-21 13:34   ` Mika Westerberg
2014-07-21 13:34     ` Mika Westerberg
2014-07-09 17:49 ` [PATCH 4/6] tty: serial: 8250-core: reorder serial8250_stop_rx() & serial8250_start_tx() Sebastian Andrzej Siewior
2014-07-09 17:49   ` Sebastian Andrzej Siewior
2014-07-09 17:49 ` [PATCH 5/6] tty: serial: 8250-core: add rs485 support Sebastian Andrzej Siewior
2014-07-09 17:49   ` Sebastian Andrzej Siewior
2014-07-09 19:01   ` Lennart Sorensen
2014-07-09 19:01     ` Lennart Sorensen
2014-07-10 15:55     ` Sebastian Andrzej Siewior
2014-07-10 15:55       ` Sebastian Andrzej Siewior
2014-07-10 14:52   ` One Thousand Gnomes [this message]
2014-07-10 14:52     ` One Thousand Gnomes
2014-07-09 17:49 ` [PATCH 6/6] tty: serial: Add 8250-core based omap driver Sebastian Andrzej Siewior
2014-07-09 17:49   ` Sebastian Andrzej Siewior
2014-07-10  7:09   ` Tony Lindgren
2014-07-10  7:09     ` Tony Lindgren
2014-07-10 15:47     ` Sebastian Andrzej Siewior
2014-07-10 15:47       ` Sebastian Andrzej Siewior
2014-07-10 16:03       ` Carlos Hernandez
2014-07-10 16:03         ` Carlos Hernandez
2014-07-10 16:14         ` menon.nishanth
2014-07-10 16:14           ` menon.nishanth at gmail.com
2014-07-11  6:41       ` Tony Lindgren
2014-07-11  6:41         ` Tony Lindgren
2014-07-16 12:11         ` Sebastian Andrzej Siewior
2014-07-16 12:11           ` Sebastian Andrzej Siewior
2014-07-16 12:32           ` Tony Lindgren
2014-07-16 12:32             ` Tony Lindgren
2014-07-16 13:00             ` Sekhar Nori
2014-07-16 13:00               ` Sekhar Nori
2014-08-08 11:05   ` Heikki Krogerus
2014-08-08 11:05     ` Heikki Krogerus
2014-07-09 17:58 ` [RFC v3] 8250-core based serial driver for OMAP Sebastian Andrzej Siewior

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=20140710155215.3e17ca08@alan.etchedpixels.co.uk \
    --to=gnomes@lxorguk.ukuu.org.uk \
    --cc=balbi@ti.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=tony@atomide.com \
    /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.