> > And how is/should the RS-422 and RS-232 mode switching [be] handled? A
> > different set of IOCTLs?
Probably the RS485 one, or we've got termiox. Might be worth looking how
other Unixen handle it.
[added linux-serial list - this is bigger than USB in its needs]
>
> To allow for the complexity described above, I propose a rename of the
> current IOCTLs and control struct, or a completely new set of IOCTLs and
> structs to avoid incompatibilities if this is a concern (which I believe
> it is, but I also understand that there is an aversion agains new
> IOCTLs). I think we need the following IOCTLs:
>
> TIOCSSERIAL
> TIOCGSERIAL
These we cannot update or extend sanely, and a lot of drivers don't
support them. The locking would also not be ideal.
>
> and either extend the serial_struct type or introduce a new one, e.g.
> serial_ctrl, with the following components:
I'd actually stick these into the RS485 ioctl or termiox, one or the
other. Yes 422 isn't quite 485 but interface perfection is always fun
(and we can define a new ioctl of the same value if need be!)
>
>
> /*
> * SER_AUTO_TOGGLE Multidrop, i.e. TX driver is automatically
> enabled
> * before data is transmitted, then disabled
> immediately
> * after all data has been transmitted.
> * SER_RTS_CONTROL RTS (Request To Send) is used to control the TX
> * driver.
> * SER_DTR_CONTROL DTR (Data Terminal Ready) is used to control
> the TX
> * driver.
> *
> * SER_NO_ECHO Receiver only active when no TX.
This seems to have little to do with echo and more to do with full/half
duplex.
> * SER_LOCAL_ECHO Receiver will always be active.
> *
> * SER_NO_TERMINATION Device has no termination ("middle unit" for
> RS485.
> * SER_LOCAL_TERMINATION Device has termination ("end unit" for RS485.
> *
> * SER_SLAVE The device is slave.
> * SER_MASTER Receiver will always be active.
> *
> * SER_NO_SIGNALING RTS or DTR is enabled just before send.
> * SER_SIGNAL_BEFORE_SEND RTS or DTR is enabled just before send.
You have these two the same which I think is just a thinko in the
description ?
> * SER_SIGNAL_AFTER_SEND RTS or DTR is enabled just after send.
> There are some overlaps here, e.g. RS-422 could be seen as the same state
> as RS-485 with full duplex as master (termination accordingly).
Right - which is where treating them as one probably helps.
> But I'm on thin ice here. And since I have no previous knowledge of this
> part of the kernel nor any of the devices which currently supports RS-485,
> nor I'm not entirely sure how the Cris and Atmel devices maps to what I
> have described above, I would like some consensus before proceeding.
Apart from where the bits go (I'd put them in the rs485 struct) it looks
like a good summary. Some of the chips we have now I seem to remember
support configurable delays on the rts/dtr behaviour ?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
