From: Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
To: Martin Fuzzey <mfuzzey-mB3Nsq4MPf1BDgjK7y7TUQ@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: Sat, 2 Apr 2016 21:36:38 -0700 [thread overview]
Message-ID: <57009DD6.2050006@hurleysoftware.com> (raw)
In-Reply-To: <56A89C48.1040604-mB3Nsq4MPf1BDgjK7y7TUQ@public.gmane.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: peter@hurleysoftware.com (Peter Hurley)
To: linux-arm-kernel@lists.infradead.org
Subject: Serial ports with non connected RTS/CTS
Date: Sat, 2 Apr 2016 21:36:38 -0700 [thread overview]
Message-ID: <57009DD6.2050006@hurleysoftware.com> (raw)
In-Reply-To: <56A89C48.1040604@parkeon.com>
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
next prev parent reply other threads:[~2016-04-03 4:36 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
2016-01-27 11:33 ` Martin Fuzzey
2016-04-03 4:36 ` Peter Hurley [this message]
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=57009DD6.2050006@hurleysoftware.com \
--to=peter-wagbzjegnqdsbiue7sb01tbpr1lh4cv8@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 \
--cc=mfuzzey-mB3Nsq4MPf1BDgjK7y7TUQ@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.