RE: [PATCH/RFC] 8250: Auto RS485 direction control

["Tosoni" <jp.tosoni@acksys.fr>]

> -----Original Message-----
> From: Laurent Pinchart
>
> On Monday 04 August 2008, Grant Edwards wrote:
> > On 2008-08-04, Laurent Pinchart <laurentp@cse-semaphore.com> wrote:

(...)

> We already have 3 distinct modes for RTS/CTS (see my mail
> from today 11:23:36 in this thread). If we add DSR/DTR
> hardware support we can easily get 5 or 6 modes. We will run
> out of bits in c_cflags.
>
The three modes which you identify are
(A) bus direction
(B) send data request (well... RTS=Request To Send :-)) which should be
acknowledged by CTS
(C) input flow control
but, the RTS is widely used for (A)=bus direction BECAUSE it is the same
behaviour than (B)=request to send... because RTS was initially made to set
the "bus direction" in the attached modem.
So the three modes are really 2.

People require the (A+B) usage because is in the RS232 and also in V24
specs. But DTR+DSR handshake, really, it's not standardized in any way nor
in broad use. I don't think this is a real need (my personal opinion). My
company once had a card implementing DTR/DSR flow control, nobody used it
and it has been dropped from newer cards.
If we really want it we could resort to a setserial flag to say "RTS/CTS
flow is implemented with DTR/DSR", but then, why not swapping the pin
cabling on the connector then ?

My conclusion: only one bit is needed in c_cflags.
BUT: think of all the upper APIs (termio, termios, tcset/get... and people
using directly TCSET/TCGET ioctls. I am afraid that changing a single bit in
such a widely used API might break a lot of existing apps.

(...)
>
> As the number of bits in c_cflags is not infinite we will
> need an ioctl to configure the desired hardware handshake
> mode (as most modes don't control the data flow I'd rather
> talk about hardware handshake which is a more generic name).
> We can either use one of the struct serial_struct reserved
> fields with TIOCSSERIAL, or create another ioctl.
>
In the Linux CRIS architecture I've seen an IOCTL doing exactly this, with
extra parameters to set the delays RTS-to-Tx and /Tx-to-/RTS. It sounds like
a non intrusive way of adding the feature.

This would definitely be my preferred way of doing (it's the one which I use
in my 16C950 driver).

JP Tosoni