[PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[Matthias Fuchs]

Hi,

please see my patch for enabling the RS485 half-duplex control below.
Please note that I am using this on a PowerPC platform. So I needed to
add the ioctl to the PowerPC header. As Wolfgang stated, it is
already in the x86 header. I am not sure if I have to post the modification
on the powerpc header to the PowerPC list or if it will be accepted here
as well.  .... But first I will have to see what you think of this patch :-)

Matthias


Some Exar UARTs support a auto rs485 mode. In this mode
the UART's RTS# pin is activated during transmitting and
can be used to enable a rs485 line driver. This has nothing
to do with attempts to do this by manually by asserting/
deasserting handshake lines.

Signed-off-by: Matthias Fuchs <mfuchs@ma-fu.de>
---
 arch/powerpc/include/asm/ioctls.h |    2 +
 drivers/serial/8250.c             |   59 +++++++++++++++++++++++++++++++++++++
 2 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/ioctls.h b/arch/powerpc/include/asm/ioctls.h
index 279a622..1842186 100644
--- a/arch/powerpc/include/asm/ioctls.h
+++ b/arch/powerpc/include/asm/ioctls.h
@@ -89,6 +89,8 @@
 #define TIOCSBRK	0x5427  /* BSD compatibility */
 #define TIOCCBRK	0x5428  /* BSD compatibility */
 #define TIOCGSID	0x5429  /* Return the session ID of FD */
+#define TIOCGRS485	0x542e
+#define TIOCSRS485	0x542f
 #define TIOCGPTN	_IOR('T',0x30, unsigned int) /* Get Pty Number (of pty-mux device) */
 #define TIOCSPTLCK	_IOW('T',0x31, int)  /* Lock/unlock Pty */
 
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 303272a..e6df50f 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2511,6 +2511,64 @@ serial8250_type(struct uart_port *port)
 	return uart_config[type].name;
 }
 
+static int 
+serial8250_ioctl_port(struct uart_port *port, unsigned int cmd, unsigned long arg)
+{
+	struct uart_8250_port *up = (struct uart_8250_port *)port;
+
+	switch (cmd) {
+	case TIOCSRS485:
+	{
+		struct serial_rs485 rs485ctrl;
+		unsigned char fctr;
+
+		if (port->type != PORT_16850)
+			return -ENODEV;
+
+		if (copy_from_user(&rs485ctrl, 
+				   (struct serial_rs485 *)arg,
+				   sizeof(rs485ctrl)))
+			return -EFAULT;
+
+		serial_outp(up, UART_LCR, 0xbf);
+		fctr = serial_inp(up, UART_FCTR);
+		if (rs485ctrl.flags & SER_RS485_ENABLED)
+			fctr |= 0x08;
+		else
+			fctr &= ~0x08;
+		serial_outp(up, UART_FCTR, fctr);
+		serial_outp(up, UART_LCR, 0);
+		return 0;
+	}
+
+	case TIOCGRS485:
+	{
+		struct serial_rs485 rs485ctrl;
+
+		if (port->type != PORT_16850)
+			return -ENODEV;
+
+		serial_outp(up, UART_LCR, 0xbf);
+		if (serial_inp(up, UART_FCTR) & 0x08)
+			rs485ctrl.flags = SER_RS485_ENABLED;
+		else
+			rs485ctrl.flags = 0;
+		serial_outp(up, UART_LCR, 0);
+
+		if (copy_to_user((struct serial_rs485 *)arg,
+				 &rs485ctrl,
+				 sizeof(rs485ctrl)))
+			return -EFAULT;
+		return 0;
+	}
+
+	default:
+		return -ENOIOCTLCMD;
+	}
+
+	return 0;
+}
+
 static struct uart_ops serial8250_pops = {
 	.tx_empty	= serial8250_tx_empty,
 	.set_mctrl	= serial8250_set_mctrl,
@@ -2529,6 +2587,7 @@ static struct uart_ops serial8250_pops = {
 	.request_port	= serial8250_request_port,
 	.config_port	= serial8250_config_port,
 	.verify_port	= serial8250_verify_port,
+	.ioctl		= serial8250_ioctl_port,
 #ifdef CONFIG_CONSOLE_POLL
 	.poll_get_char = serial8250_get_poll_char,
 	.poll_put_char = serial8250_put_poll_char,
-- 
1.5.6.3

Re: [PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[Laurent Pinchart]

Hi Matthias,

On Friday 19 December 2008 00:48:34 Matthias Fuchs wrote:
> Hi,
>
> please see my patch for enabling the RS485 half-duplex control below.
> Please note that I am using this on a PowerPC platform. So I needed to
> add the ioctl to the PowerPC header. As Wolfgang stated, it is
> already in the x86 header. I am not sure if I have to post the modification
> on the powerpc header to the PowerPC list or if it will be accepted here
> as well.  .... But first I will have to see what you think of this patch
> :-)

You will have to submit ioctls.h modifications as a separate patch to the 
powerpc-dev mailing list.

The patch looks good, a few comments below.

> Matthias
>
>
> Some Exar UARTs support a auto rs485 mode. In this mode
> the UART's RTS# pin is activated during transmitting and
> can be used to enable a rs485 line driver. This has nothing
> to do with attempts to do this by manually by asserting/
> deasserting handshake lines.
>
> Signed-off-by: Matthias Fuchs <mfuchs@ma-fu.de>
> ---
>  arch/powerpc/include/asm/ioctls.h |    2 +
>  drivers/serial/8250.c             |   59
> +++++++++++++++++++++++++++++++++++++ 2 files changed, 61 insertions(+), 0
> deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ioctls.h
> b/arch/powerpc/include/asm/ioctls.h index 279a622..1842186 100644
> --- a/arch/powerpc/include/asm/ioctls.h
> +++ b/arch/powerpc/include/asm/ioctls.h
> @@ -89,6 +89,8 @@
>  #define TIOCSBRK	0x5427  /* BSD compatibility */
>  #define TIOCCBRK	0x5428  /* BSD compatibility */
>  #define TIOCGSID	0x5429  /* Return the session ID of FD */
> +#define TIOCGRS485	0x542e
> +#define TIOCSRS485	0x542f
>  #define TIOCGPTN	_IOR('T',0x30, unsigned int) /* Get Pty Number (of
> pty-mux device) */ #define TIOCSPTLCK	_IOW('T',0x31, int)  /* Lock/unlock
> Pty */
>
> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index 303272a..e6df50f 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c
> @@ -2511,6 +2511,64 @@ serial8250_type(struct uart_port *port)
>  	return uart_config[type].name;
>  }
>
> +static int
> +serial8250_ioctl_port(struct uart_port *port, unsigned int cmd, unsigned
> long arg) +{
> +	struct uart_8250_port *up = (struct uart_8250_port *)port;
> +
> +	switch (cmd) {
> +	case TIOCSRS485:
> +	{
> +		struct serial_rs485 rs485ctrl;
> +		unsigned char fctr;
> +
> +		if (port->type != PORT_16850)
> +			return -ENODEV;

According to the ioctl manpage, -ENOTTY might be better:

"ENOTTY The specified request does not apply to the kind of object that the 
descriptor d references."

> +		if (copy_from_user(&rs485ctrl,
> +				   (struct serial_rs485 *)arg,
> +				   sizeof(rs485ctrl)))
> +			return -EFAULT;
> +
> +		serial_outp(up, UART_LCR, 0xbf);
> +		fctr = serial_inp(up, UART_FCTR);
> +		if (rs485ctrl.flags & SER_RS485_ENABLED)
> +			fctr |= 0x08;
> +		else
> +			fctr &= ~0x08;
> +		serial_outp(up, UART_FCTR, fctr);
> +		serial_outp(up, UART_LCR, 0);

Doesn't this require locking ? serial8250_break_ctl and serial8250_set_termios 
both take the port.lock spinlock to prevent races from messing up with 
UART_LCR.

> +		return 0;
> +	}
> +
> +	case TIOCGRS485:
> +	{
> +		struct serial_rs485 rs485ctrl;
> +
> +		if (port->type != PORT_16850)
> +			return -ENODEV;

What about setting rs485ctrl.flags to 0 and returning with success when RS485 
auto direction control is not supported by the hardware ? I'm not sure if the 
preferred semantic for get requests on unsupported features is to return an 
error or return a 'feature disabled' value.

> +		serial_outp(up, UART_LCR, 0xbf);
> +		if (serial_inp(up, UART_FCTR) & 0x08)
> +			rs485ctrl.flags = SER_RS485_ENABLED;
> +		else
> +			rs485ctrl.flags = 0;
> +		serial_outp(up, UART_LCR, 0);

Ditto, doesn't this require locking ?

> +
> +		if (copy_to_user((struct serial_rs485 *)arg,
> +				 &rs485ctrl,
> +				 sizeof(rs485ctrl)))
> +			return -EFAULT;
> +		return 0;
> +	}
> +
> +	default:
> +		return -ENOIOCTLCMD;
> +	}
> +
> +	return 0;
> +}
> +
>  static struct uart_ops serial8250_pops = {
>  	.tx_empty	= serial8250_tx_empty,
>  	.set_mctrl	= serial8250_set_mctrl,
> @@ -2529,6 +2587,7 @@ static struct uart_ops serial8250_pops = {
>  	.request_port	= serial8250_request_port,
>  	.config_port	= serial8250_config_port,
>  	.verify_port	= serial8250_verify_port,
> +	.ioctl		= serial8250_ioctl_port,
>  #ifdef CONFIG_CONSOLE_POLL
>  	.poll_get_char = serial8250_get_poll_char,
>  	.poll_put_char = serial8250_put_poll_char,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

Re: [PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[Laurent Pinchart]

Hi Matthias,

On Friday 19 December 2008 00:48:34 Matthias Fuchs wrote:
> Hi,
>
> please see my patch for enabling the RS485 half-duplex control below.
> Please note that I am using this on a PowerPC platform. So I needed to
> add the ioctl to the PowerPC header. As Wolfgang stated, it is
> already in the x86 header. I am not sure if I have to post the modification
> on the powerpc header to the PowerPC list or if it will be accepted here
> as well.  .... But first I will have to see what you think of this patch
> :-)
>
> Matthias
>
>
> Some Exar UARTs support a auto rs485 mode. In this mode
> the UART's RTS# pin is activated during transmitting and
> can be used to enable a rs485 line driver. This has nothing
> to do with attempts to do this by manually by asserting/
> deasserting handshake lines.

[snip]
> +		serial_outp(up, UART_LCR, 0xbf);
> +		fctr = serial_inp(up, UART_FCTR);
> +		if (rs485ctrl.flags & SER_RS485_ENABLED)
> +			fctr |= 0x08;
> +		else
> +			fctr &= ~0x08;
> +		serial_outp(up, UART_FCTR, fctr);
> +		serial_outp(up, UART_LCR, 0);

You might also want to add a

#define UART_FCTR_RS485	0x08

to include/linux/serial_reg.h instead of using a hardcoded 0x08 constant.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

Re: [PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[Chris Gibson]

Two and a half weeks ago I submitted a patch to implement RS485 auto
direction control on either (or both) the RTS and the DTR lines with
varying pre and post delay settings that would work for _all_ uarts that
support mctrl.

This patch had a variation on the ioctl suggested by Alan Cox, that was
a variation on an ioctl that was already in existence in the kernel.   

The ioctl was devised to allow considerable flexibility, and I hoped
that it would be considered for future auto direction control.

Sorry for sounding grumpy but is any one interested?

On Fri, 2008-12-19 at 16:13 +0100, Laurent Pinchart wrote:
> Hi Matthias,
> 
> On Friday 19 December 2008 00:48:34 Matthias Fuchs wrote:
> > Hi,
> >
> > please see my patch for enabling the RS485 half-duplex control below.
> > Please note that I am using this on a PowerPC platform. So I needed to
> > add the ioctl to the PowerPC header. As Wolfgang stated, it is
> > already in the x86 header. I am not sure if I have to post the modification
> > on the powerpc header to the PowerPC list or if it will be accepted here
> > as well.  .... But first I will have to see what you think of this patch
> > :-)
> >
> > Matthias
> >
> >
> > Some Exar UARTs support a auto rs485 mode. In this mode
> > the UART's RTS# pin is activated during transmitting and
> > can be used to enable a rs485 line driver. This has nothing
> > to do with attempts to do this by manually by asserting/
> > deasserting handshake lines.
> 
> [snip]
> > +		serial_outp(up, UART_LCR, 0xbf);
> > +		fctr = serial_inp(up, UART_FCTR);
> > +		if (rs485ctrl.flags & SER_RS485_ENABLED)
> > +			fctr |= 0x08;
> > +		else
> > +			fctr &= ~0x08;
> > +		serial_outp(up, UART_FCTR, fctr);
> > +		serial_outp(up, UART_LCR, 0);
> 
> You might also want to add a
> 
> #define UART_FCTR_RS485	0x08
> 
> to include/linux/serial_reg.h instead of using a hardcoded 0x08 constant.
> 

Re: [PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

Hello Chris,

On Sun, Dec 21, 2008 at 08:50:04PM +1100, Chris Gibson wrote:
> Two and a half weeks ago I submitted a patch to implement RS485 auto
> direction control on either (or both) the RTS and the DTR lines with
> varying pre and post delay settings that would work for _all_ uarts that
> support mctrl.

Just observing the case, I assume that this concern about software RS485
is still valid:

http://article.gmane.org/gmane.linux.serial/2568

All the best,

   Wolfram

-- 
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[Matthias Fuchs]

Hi Laurent,

I agree with your comments and will update and repost my patch 
during the upcoming holy days.

Matthias

> Hi Matthias,
>
> On Friday 19 December 2008 00:48:34 Matthias Fuchs wrote:
> > Hi,
> >
> > please see my patch for enabling the RS485 half-duplex control below.
> > Please note that I am using this on a PowerPC platform. So I needed to
> > add the ioctl to the PowerPC header. As Wolfgang stated, it is
> > already in the x86 header. I am not sure if I have to post the
> > modification on the powerpc header to the PowerPC list or if it will be
> > accepted here as well.  .... But first I will have to see what you think
> > of this patch
> >
> > :-)
>
> You will have to submit ioctls.h modifications as a separate patch to the
> powerpc-dev mailing list.
>
> The patch looks good, a few comments below.
>
> > Matthias
> >
> >
> > Some Exar UARTs support a auto rs485 mode. In this mode
> > the UART's RTS# pin is activated during transmitting and
> > can be used to enable a rs485 line driver. This has nothing
> > to do with attempts to do this by manually by asserting/
> > deasserting handshake lines.
> >
> > Signed-off-by: Matthias Fuchs <mfuchs@ma-fu.de>
> > ---
> >  arch/powerpc/include/asm/ioctls.h |    2 +
> >  drivers/serial/8250.c             |   59
> > +++++++++++++++++++++++++++++++++++++ 2 files changed, 61 insertions(+),
> > 0 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/ioctls.h
> > b/arch/powerpc/include/asm/ioctls.h index 279a622..1842186 100644
> > --- a/arch/powerpc/include/asm/ioctls.h
> > +++ b/arch/powerpc/include/asm/ioctls.h
> > @@ -89,6 +89,8 @@
> >  #define TIOCSBRK	0x5427  /* BSD compatibility */
> >  #define TIOCCBRK	0x5428  /* BSD compatibility */
> >  #define TIOCGSID	0x5429  /* Return the session ID of FD */
> > +#define TIOCGRS485	0x542e
> > +#define TIOCSRS485	0x542f
> >  #define TIOCGPTN	_IOR('T',0x30, unsigned int) /* Get Pty Number (of
> > pty-mux device) */ #define TIOCSPTLCK	_IOW('T',0x31, int)  /* Lock/unlock
> > Pty */
> >
> > diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> > index 303272a..e6df50f 100644
> > --- a/drivers/serial/8250.c
> > +++ b/drivers/serial/8250.c
> > @@ -2511,6 +2511,64 @@ serial8250_type(struct uart_port *port)
> >  	return uart_config[type].name;
> >  }
> >
> > +static int
> > +serial8250_ioctl_port(struct uart_port *port, unsigned int cmd, unsigned
> > long arg) +{
> > +	struct uart_8250_port *up = (struct uart_8250_port *)port;
> > +
> > +	switch (cmd) {
> > +	case TIOCSRS485:
> > +	{
> > +		struct serial_rs485 rs485ctrl;
> > +		unsigned char fctr;
> > +
> > +		if (port->type != PORT_16850)
> > +			return -ENODEV;
>
> According to the ioctl manpage, -ENOTTY might be better:
>
> "ENOTTY The specified request does not apply to the kind of object that the
> descriptor d references."
>
> > +		if (copy_from_user(&rs485ctrl,
> > +				   (struct serial_rs485 *)arg,
> > +				   sizeof(rs485ctrl)))
> > +			return -EFAULT;
> > +
> > +		serial_outp(up, UART_LCR, 0xbf);
> > +		fctr = serial_inp(up, UART_FCTR);
> > +		if (rs485ctrl.flags & SER_RS485_ENABLED)
> > +			fctr |= 0x08;
> > +		else
> > +			fctr &= ~0x08;
> > +		serial_outp(up, UART_FCTR, fctr);
> > +		serial_outp(up, UART_LCR, 0);
>
> Doesn't this require locking ? serial8250_break_ctl and
> serial8250_set_termios both take the port.lock spinlock to prevent races
> from messing up with UART_LCR.
>
> > +		return 0;
> > +	}
> > +
> > +	case TIOCGRS485:
> > +	{
> > +		struct serial_rs485 rs485ctrl;
> > +
> > +		if (port->type != PORT_16850)
> > +			return -ENODEV;
>
> What about setting rs485ctrl.flags to 0 and returning with success when
> RS485 auto direction control is not supported by the hardware ? I'm not
> sure if the preferred semantic for get requests on unsupported features is
> to return an error or return a 'feature disabled' value.
>
> > +		serial_outp(up, UART_LCR, 0xbf);
> > +		if (serial_inp(up, UART_FCTR) & 0x08)
> > +			rs485ctrl.flags = SER_RS485_ENABLED;
> > +		else
> > +			rs485ctrl.flags = 0;
> > +		serial_outp(up, UART_LCR, 0);
>
> Ditto, doesn't this require locking ?
>
> > +
> > +		if (copy_to_user((struct serial_rs485 *)arg,
> > +				 &rs485ctrl,
> > +				 sizeof(rs485ctrl)))
> > +			return -EFAULT;
> > +		return 0;
> > +	}
> > +
> > +	default:
> > +		return -ENOIOCTLCMD;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> >  static struct uart_ops serial8250_pops = {
> >  	.tx_empty	= serial8250_tx_empty,
> >  	.set_mctrl	= serial8250_set_mctrl,
> > @@ -2529,6 +2587,7 @@ static struct uart_ops serial8250_pops = {
> >  	.request_port	= serial8250_request_port,
> >  	.config_port	= serial8250_config_port,
> >  	.verify_port	= serial8250_verify_port,
> > +	.ioctl		= serial8250_ioctl_port,
> >  #ifdef CONFIG_CONSOLE_POLL
> >  	.poll_get_char = serial8250_get_poll_char,
> >  	.poll_put_char = serial8250_put_poll_char,

Re: [PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[Matthias Fuchs]

Oops,

I must admit that I was not aware of that thread. Mea culpa!
I will go through those arguments and see if I can take some
effort from that. 

Again, I will not take care of any software RS485 and I will
never use any name that contains RTS. 

I will also keep my ioctl implementation instead of any termios stuff
- when nobody contradicts.

Matthias

> Hello Chris,
>
> On Sun, Dec 21, 2008 at 08:50:04PM +1100, Chris Gibson wrote:
> > Two and a half weeks ago I submitted a patch to implement RS485 auto
> > direction control on either (or both) the RTS and the DTR lines with
> > varying pre and post delay settings that would work for _all_ uarts that
> > support mctrl.
>
> Just observing the case, I assume that this concern about software RS485
> is still valid:
>
> http://article.gmane.org/gmane.linux.serial/2568

Re: [PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[Christopher Gibson]

Recent discussions on RS485 auto direction control seem to be split over
a number of threads.

Here are the threads that I'm aware of:
http://marc.info/?t=121805745200001&r=1&w=2
http://marc.info/?t=121690034200007&r=1&w=2
http://marc.info/?t=122821576400003&r=1&w=2
http://marc.info/?t=122822457300004&r=1&w=2
http://marc.info/?t=122954923400001&r=1&w=2
http://marc.info/?t=122964426200001&r=1&w=2
http://marc.info/?t=121566595900001&r=1&w=2
http://marc.info/?t=121805198200004&r=1&w=2


Also of interest is the set of patches by Aristeu Rozanski on 
http://marc.info/?l=linux-serial&r=1&b=200809&w=2
An issue related to a RS485 support is also covered in the message
http://marc.info/?l=linux-serial&m=121811414618759&w=2

Apologies to all if I've missed any thing, feel free to add to the list.

or some of the same on the gmane site:
http://thread.gmane.org/gmane.linux.serial/2563/focus=2568
http://thread.gmane.org/gmane.linux.serial/2957
http://thread.gmane.org/gmane.linux.serial/2936
http://thread.gmane.org/gmane.linux.serial/2612/focus=2618


On Mon, 2008-12-22 at 19:02 +0100, Matthias Fuchs wrote:
> Oops,
> 
> I must admit that I was not aware of that thread. Mea culpa!
> I will go through those arguments and see if I can take some
> effort from that. 
> 
> Again, I will not take care of any software RS485 and I will
> never use any name that contains RTS. 
> 
> I will also keep my ioctl implementation instead of any termios stuff
> - when nobody contradicts.
> 
> Matthias
> 
> > Hello Chris,
> >
> > On Sun, Dec 21, 2008 at 08:50:04PM +1100, Chris Gibson wrote:
> > > Two and a half weeks ago I submitted a patch to implement RS485 auto
> > > direction control on either (or both) the RTS and the DTR lines with
> > > varying pre and post delay settings that would work for _all_ uarts that
> > > support mctrl.
> >
> > Just observing the case, I assume that this concern about software RS485
> > is still valid:
> >
> > http://article.gmane.org/gmane.linux.serial/2568
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
-- 
Christopher Gibson <chris@toftronix.com.au>

Re: [PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[Christopher Gibson]

On Mon, 2008-12-22 at 16:59 +0100, Wolfram Sang wrote:
> Hello Chris,
> 
> On Sun, Dec 21, 2008 at 08:50:04PM +1100, Chris Gibson wrote:
> > Two and a half weeks ago I submitted a patch to implement RS485 auto
> > direction control on either (or both) the RTS and the DTR lines with
> > varying pre and post delay settings that would work for _all_ uarts that
> > support mctrl.
> 
> Just observing the case, I assume that this concern about software RS485
> is still valid:
> 
> http://article.gmane.org/gmane.linux.serial/2568

Thank you for the reply.

In answer to the above thread - the implementation in the patch I
provided addresses some of the concerned mentioned.  The polling of the
shift empty register is done with a timer, so the loss of CPU time is
minimal.  The ioctl's provide a mechanism for which the driver
turnaround delay, and jitter can be established, allowing a user
application the ability to determine the suitability of a particular
direction control implementation to fulfil its timing requirements.

The short fall of the implementation is that it's timing is only as good
as the Linux system timer.  This is less of a limitation with the latter
kernels with higher speed system timers.

My main concern though is not whether or not this software
implementation of auto direction control is adopted into the kernel,
(though I guess I would feel proud if it was :) but rather that the
ioctl that has gone into V2.6.28-rc1 is only part way toward what it
should be, and this is starting to be used already.

best regards
-- 
Christopher Gibson <chris@toftronix.com.au>

Re: [PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[Matthias Fuchs]

Hi Christopher,

I checked all your referenced threads. Here is my summary:

1) RS485 seems to be an issue for several people.
2) enabling hardware RS485 via ioct is never totally dismissed.
3) Discussion about software direction control will never end.

So I suggest not to mix hardware and software direction control
as the same issue. When the hardware supports direction control
we should implement it as ioctl. 

Even this sounds a little bit egoistic, it might bring us a little forward.

I will update my initial patch and consider Laurent's comments.

Matthias

> Recent discussions on RS485 auto direction control seem to be split over
> a number of threads.
> 
> Here are the threads that I'm aware of:
> http://marc.info/?t=121805745200001&r=1&w=2
> http://marc.info/?t=121690034200007&r=1&w=2
> http://marc.info/?t=122821576400003&r=1&w=2
> http://marc.info/?t=122822457300004&r=1&w=2
> http://marc.info/?t=122954923400001&r=1&w=2
> http://marc.info/?t=122964426200001&r=1&w=2
> http://marc.info/?t=121566595900001&r=1&w=2
> http://marc.info/?t=121805198200004&r=1&w=2
> 

Re: [PATCH/RFC] serial: Add ioctl to enable auto rs485 mode with some Exar UARTs

[Christopher Gibson]

Thanks for the reply.

On Fri, 2009-01-02 at 16:29 +0100, Matthias Fuchs wrote:
> Hi Christopher,
> 
> I checked all your referenced threads. Here is my summary:
> 
> 1) RS485 seems to be an issue for several people.
> 2) enabling hardware RS485 via ioct is never totally dismissed.
> 3) Discussion about software direction control will never end.
> 

Fair points.

I was considering the possibility of combining both a software and
hardware combination such that software would provide for pre-and post
delays if the required delays were outside the abilities of the
hardware.  Am yet to create an implementation of this though, and I'm
still pondering on how to cleanly communicate the abilities between the
general serial-core and the lower level hardware interface.

> 
> 
> So I suggest not to mix hardware and software direction control
> as the same issue. When the hardware supports direction control
> we should implement it as ioctl.
> 
> Even this sounds a little bit egoistic, it might bring us a little forward.
> 

I fully support this.  I may, if I get my act together, use your patch
as a basis for demonstrating a software/hardware combination (but don't
hold your breath!).

Christopher Gibson