From: Martin Fuzzey <mfuzzey-mB3Nsq4MPf1BDgjK7y7TUQ@public.gmane.org>
To: "Lothar Waßmann" <LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh@public.gmane.org>
Cc: "linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: Serial ports with non connected RTS/CTS
Date: Wed, 27 Jan 2016 12:33:32 +0100 [thread overview]
Message-ID: <56A8AB0C.8010407@parkeon.com> (raw)
In-Reply-To: <20160127115817.79e384b1-VjFSrY7JcPWvSplVBqRQBQ@public.gmane.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: mfuzzey@parkeon.com (Martin Fuzzey)
To: linux-arm-kernel@lists.infradead.org
Subject: Serial ports with non connected RTS/CTS
Date: Wed, 27 Jan 2016 12:33:32 +0100 [thread overview]
Message-ID: <56A8AB0C.8010407@parkeon.com> (raw)
In-Reply-To: <20160127115817.79e384b1@ipc1.ka-ro>
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
next prev parent reply other threads:[~2016-01-27 11:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 10:30 Serial ports with non connected RTS/CTS Martin Fuzzey
2016-01-27 10:30 ` Martin Fuzzey
[not found] ` <56A89C48.1040604-mB3Nsq4MPf1BDgjK7y7TUQ@public.gmane.org>
2016-01-27 10:58 ` Lothar Waßmann
2016-01-27 10:58 ` Lothar Waßmann
[not found] ` <20160127115817.79e384b1-VjFSrY7JcPWvSplVBqRQBQ@public.gmane.org>
2016-01-27 11:33 ` Martin Fuzzey [this message]
2016-01-27 11:33 ` Martin Fuzzey
2016-04-03 4:36 ` Peter Hurley
2016-04-03 4:36 ` Peter Hurley
[not found] ` <57009DD6.2050006-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
2016-04-04 5:16 ` Rob Herring
2016-04-04 5:16 ` Rob Herring
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=56A8AB0C.8010407@parkeon.com \
--to=mfuzzey-mb3nsq4mpf1bdgjk7y7tuq@public.gmane.org \
--cc=LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.