Serial ports with non connected RTS/CTS

Serial ports with non connected RTS/CTS

[Martin Fuzzey]

Hi all,

currently, at least for 8250 based serial ports using of_serial, there 
is no way of indicating that the RTS / CTS lines, although supported by 
the UART, are not actually connected on the board.

This means that userspace needs to know about this and not use the 
CRTSCTS termios flag (otherwise no data is sent).

This is currently the case for Debian stattach for example (nettools 
1.60) which unconditionally uses CRTSCTS (but the busybox version of 
slattach has a "-F" option that can be used to disable CRTSCTS).

Would it not be better to allow this situation to be described in the 
device tree?

Such an option already exists for the imx UART (""fsl,uart-has-rtscts")

of_serial already has the "auto-flow-control" DT property but, as stated 
in the documentation:
     "The  driver is allowed to detect support for the capability even 
without this  property."

In the past there was a (since reverted) property "has-hw-flow-control"
See
     06aa82e "serial: uart: add hw flow control support configuration"
     a6eec92 " Revert "serial: uart: add hw flow control support 
configuration"

However that just provided another (redundant) way of *activating* 
hardware flow control and did not allow it to be disactivated.

Would a new DT property "no-rtscts" to do this be acceptable?

I think it would have to be a negative property to avoid breaking old 
device trees.

Since there seems to have been some to and fro on this issue I thought 
it would be a good idea to discuss before writing the patch...

Regards,

Martin

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Serial ports with non connected RTS/CTS

[Lothar Waßmann]

Hi,

On Wed, 27 Jan 2016 11:30:32 +0100 Martin Fuzzey wrote:
> Hi all,
> 
> currently, at least for 8250 based serial ports using of_serial, there 
> is no way of indicating that the RTS / CTS lines, although supported by 
> the UART, are not actually connected on the board.
> 
> This means that userspace needs to know about this and not use the 
> CRTSCTS termios flag (otherwise no data is sent).
> 
> This is currently the case for Debian stattach for example (nettools 
> 1.60) which unconditionally uses CRTSCTS (but the busybox version of 
> slattach has a "-F" option that can be used to disable CRTSCTS).
> 
> Would it not be better to allow this situation to be described in the 
> device tree?
> 
> Such an option already exists for the imx UART (""fsl,uart-has-rtscts")
> 
> of_serial already has the "auto-flow-control" DT property but, as stated 
> in the documentation:
>      "The  driver is allowed to detect support for the capability even 
> without this  property."
> 
> In the past there was a (since reverted) property "has-hw-flow-control"
> See
>      06aa82e "serial: uart: add hw flow control support configuration"
>      a6eec92 " Revert "serial: uart: add hw flow control support 
> configuration"
> 
> However that just provided another (redundant) way of *activating* 
> hardware flow control and did not allow it to be disactivated.
> 
> Would a new DT property "no-rtscts" to do this be acceptable?
> 
> I think it would have to be a negative property to avoid breaking old 
> device trees.
> 
> Since there seems to have been some to and fro on this issue I thought 
> it would be a good idea to discuss before writing the patch...
> 
If a driver has no support for RTS/CTS (e.g. due to the missing
fsl,uart-has-rtscts property for i.MX UARTs) then trying to enable HW
flowcontrol via the TCETS ioctl should fail (as is the case with the
i.MX serial driver).
Thus it should be impossible to enable crtscts if the serial driver has
no RTC/CTS support without any need for userspace to know about the
HW details.


Lothar Waßmann
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Serial ports with non connected RTS/CTS

[Martin Fuzzey]

Hi,

On 27/01/16 11:58, Lothar Waßmann wrote:
>
> If a driver has no support for RTS/CTS (e.g. due to the missing
> fsl,uart-has-rtscts property for i.MX UARTs) then trying to enable HW
> flowcontrol via the TCETS ioctl should fail (as is the case with the
> i.MX serial driver).
> Thus it should be impossible to enable crtscts if the serial driver has
> no RTC/CTS support without any need for userspace to know about the
> HW details.

It doesn't do that for me [kernel 4.4]

The stty command to activate rtscts does return an error if the hardware 
doesn't support it.

# stty -F /dev/ttymxc1 crtscts
stty: /dev/ttymxc1: unable to perform all requested operations

But the TCETS ioctl  itselfdoes not fail:

ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B115200 -opost -isig -icanon -echo 
...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon 
-echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon 
-echo ...}) = 0
write(2, "stty: ", 6stty: )                   = 6
write(2, "/dev/ttymxc1: unable to perform "..., 56/dev/ttymxc1: unable 
to perform all requested operations) = 56


The error message is because stty does a TCGETS afterwards and errors if 
the result is different to that requested.

slattach does not compare the requested and actual configuaration


The kernel code in the imx driver is:
static void
imx_set_termios(struct uart_port *port, struct ktermios *termios,
            struct ktermios *old)
{
...
     if (termios->c_cflag & CRTSCTS) {
         if (sport->have_rtscts) {
             ucr2 &= ~UCR2_IRTS;

             if (port->rs485.flags & SER_RS485_ENABLED) {
                 /*
                  * RTS is mandatory for rs485 operation, so keep
                  * it under manual control and keep transmitter
                  * disabled.
                  */
                 if (!(port->rs485.flags &
                       SER_RS485_RTS_AFTER_SEND))
                     ucr2 |= UCR2_CTS;
             } else {
                 ucr2 |= UCR2_CTSC;
             }
         } else {
             termios->c_cflag &= ~CRTSCTS;
         }
     } else if (port->rs485.flags & SER_RS485_ENABLED)


So requesting RTSCTS if the hardware doesn't support it does not 
generate an error but the bit is reset in the termios structure.

This makes sense to me. Userspace can ask for something - the driver 
does it's best and reports to userspace what it actually did.
It's then up to userspace to decide if that's acceptable.

And indeed "man termios" :

"Note that *tcsetattr*() returns success if /any/ of the requested 
changes could be successfully carried out. Therefore, when making 
multiple changes it may be necessary to follow this call with a further 
call to *tcgetattr*() to check that all changes have been performed 
successfully. "



Martin


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Serial ports with non connected RTS/CTS

[Peter Hurley]

On 01/27/2016 02:30 AM, Martin Fuzzey wrote:
> Hi all,
> 
> currently, at least for 8250 based serial ports using of_serial, there is no way of indicating that the RTS / CTS lines, although supported by the UART, are not actually connected on the board.
> 
> This means that userspace needs to know about this and not use the CRTSCTS termios flag (otherwise no data is sent).
> 
> This is currently the case for Debian stattach for example (nettools 1.60) which unconditionally uses CRTSCTS (but the busybox version of slattach has a "-F" option that can be used to disable CRTSCTS).
> 
> Would it not be better to allow this situation to be described in the device tree?
> 
> Such an option already exists for the imx UART (""fsl,uart-has-rtscts")
> 
> of_serial already has the "auto-flow-control" DT property but, as stated in the documentation:
>     "The  driver is allowed to detect support for the capability even without this  property."
> 
> In the past there was a (since reverted) property "has-hw-flow-control"
> See
>     06aa82e "serial: uart: add hw flow control support configuration"
>     a6eec92 " Revert "serial: uart: add hw flow control support configuration"
> 
> However that just provided another (redundant) way of *activating* hardware flow control and did not allow it to be disactivated.
> 
> Would a new DT property "no-rtscts" to do this be acceptable?
> 
> I think it would have to be a negative property to avoid breaking old device trees.
> 
> Since there seems to have been some to and fro on this issue I thought it would be a good idea to discuss before writing the patch...

If I understand you correctly here
1) you want a way to describe the lack of CTS and RTS pins, and
2) you want the 8250 driver to mask off CRTSCTS when #1 is true.

Sounds ok to me, but I'm not sure how userspace will respond to
CRTSCTS not sticking. That will need some testing.

Regards,
Peter Hurley

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Serial ports with non connected RTS/CTS

[Rob Herring]

On Sat, Apr 02, 2016 at 09:36:38PM -0700, Peter Hurley wrote:
> On 01/27/2016 02:30 AM, Martin Fuzzey wrote:
> > Hi all,
> > 
> > currently, at least for 8250 based serial ports using of_serial, there is no way of indicating that the RTS / CTS lines, although supported by the UART, are not actually connected on the board.
> > 
> > This means that userspace needs to know about this and not use the CRTSCTS termios flag (otherwise no data is sent).
> > 
> > This is currently the case for Debian stattach for example (nettools 1.60) which unconditionally uses CRTSCTS (but the busybox version of slattach has a "-F" option that can be used to disable CRTSCTS).
> > 
> > Would it not be better to allow this situation to be described in the device tree?
> > 
> > Such an option already exists for the imx UART (""fsl,uart-has-rtscts")
> > 
> > of_serial already has the "auto-flow-control" DT property but, as stated in the documentation:
> >     "The  driver is allowed to detect support for the capability even without this  property."
> > 
> > In the past there was a (since reverted) property "has-hw-flow-control"
> > See
> >     06aa82e "serial: uart: add hw flow control support configuration"
> >     a6eec92 " Revert "serial: uart: add hw flow control support configuration"
> > 
> > However that just provided another (redundant) way of *activating* hardware flow control and did not allow it to be disactivated.
> > 
> > Would a new DT property "no-rtscts" to do this be acceptable?

Yes.

It's really a "the h/w designers left CTS tied/floating inactive by 
mistake" flag. What is done with RTS doesn't really matter. So just 
"no-cts" perhaps.

> > I think it would have to be a negative property to avoid breaking old device trees.

Agreed. 

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html