From: "Tosoni" <jp.tosoni@acksys.fr>
To: 'Laurent Pinchart' <laurentp@cse-semaphore.com>
Cc: linux-serial@vger.kernel.org
Subject: RE: [PATCH/RFC] 8250: Auto RS485 direction control
Date: Mon, 4 Aug 2008 18:47:40 +0200 [thread overview]
Message-ID: <015301c8f651$cfea6cd0$2e01a8c0@acksys.local> (raw)
In-Reply-To: <200808041637.02058.laurentp@cse-semaphore.com>
> Original Message From: Laurent Pinchart
> Sent: Monday, August 04, 2008 4:37 PM
>
> On Monday 04 August 2008, Tosoni wrote:
> > About the flags names -- CARTS, UART_FCTR_RS485
> >
> > May I suggest CRTSTOGGLE since it is known by that kind
> > of name in other OS's :-)
>
> I like Russell's proposal of sticking to CRTSCTS and adding
> options to setserial:
>
> > Should CRTSCTS be a global "enable some kind of flow
> control" bit and
> > setserial be used to configure the actual flow control method
> > (conventional RTS/CTS, DTR/DSR, alternate RTS/CTS, RS485 on RTS,
> > RS485 on DTR) ?
>
> Any opinion on that ?
It sounds fine, and it's much better than nothing.
Here are some drawbacks I can see:
1. We are talking about userland to kernel interface. It should
look like a "virtual" or "ideal" serial port. See this example:
The Philips SC28L202 chip can implement RS485 on RTS with its
MD2(5) register, but is is definitely NOT compatible with the 16C550.
What if I want to make a driver for it ? (and it might well happen)
Must I support setserial for it then ? Will setserial evolve when my
SC28L202 driver evolves ?
AFAIK setserial was added to handle new, specific features for 8250
compatible cards without breaking *NIX TERMIOS compatibility. If a
general feature can be added without resorting to setserial nor breaking
*NIX compatibility, let's do so ! (else let's do our best with setserial)
2. As far as I remember the CRTSCTS flag has a long history back to
XENIX and SCO Unix ports. This flag is well defined and used in
many *NIX implementations and I am reluctant to alter its meaning.
On the other hand, using CRTSCTS would garantee that is any
architecture we will find this bit available in termios, which may
not be the case with a brand new bit definition.
Last remark:
Interestingly, the RTS envelope on the Oxford chips is implemented
with... the DTR pin. On our cards we have a piece of hardware which
redirect the uart DTR pin to the external RTS in this case.
>
> > And further, it says was RTS will do, instead of why. Maybe
> someone could
> > use it for something other than RS485 ?
>
> I agree with you here. The name should reflect that RTS is
> used in 'envelope' mode (asserted during data transmission,
> idle between frames).
>
> Best regards,
>
> --
> 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
>
next prev parent reply other threads:[~2008-08-04 17:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-24 11:47 [PATCH/RFC] 8250: Auto RS485 direction control Laurent Pinchart
2008-07-24 11:57 ` Alan Cox
2008-07-24 12:24 ` Russell King
2008-07-24 12:27 ` Alan Cox
2008-07-24 12:52 ` Russell King
2008-07-24 13:00 ` Alan Cox
2008-07-24 13:18 ` Laurent Pinchart
2008-07-24 14:13 ` Matt Schulte
2008-07-24 14:47 ` Russell King
2008-07-24 12:10 ` Russell King
2008-08-04 14:14 ` Tosoni
2008-08-04 14:22 ` Grant Edwards
2008-08-04 14:36 ` Laurent Pinchart
2008-08-04 16:15 ` Grant Edwards
2008-08-04 16:21 ` Grant Edwards
2008-08-05 9:41 ` Laurent Pinchart
2008-08-05 12:55 ` Tosoni
2008-08-06 14:30 ` Christopher Gibson
2008-08-06 16:33 ` Tosoni
2008-08-09 10:08 ` Christopher Gibson
2008-08-07 8:50 ` Laurent Pinchart
2008-08-07 13:50 ` Grant Edwards
2008-08-10 3:49 ` Christopher Gibson
2008-08-10 3:57 ` Christopher Gibson
2008-08-29 12:22 ` Christopher Gibson
2008-12-02 13:09 ` [PATCH/RFC] " Christopher Gibson
2008-12-04 11:14 ` Christopher Gibson
2008-08-04 16:47 ` Tosoni [this message]
2008-08-04 17:46 ` [PATCH/RFC] 8250: " Grant Edwards
2008-08-04 20:59 ` Matt Schulte
2008-08-05 9:23 ` Laurent Pinchart
2008-08-05 9:34 ` Tosoni
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='015301c8f651$cfea6cd0$2e01a8c0@acksys.local' \
--to=jp.tosoni@acksys.fr \
--cc=laurentp@cse-semaphore.com \
--cc=linux-serial@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox