On 23.12.23 13:49, Christoph Niedermaier wrote: > From: Lukas Wunner [mailto:lukas@xxxxxxxxx] > Sent: Thursday, December 21, 2023 4:53 PM >> >> On Thu, Dec 14, 2023 at 01:41:47PM +0000, Christoph Niedermaier wrote: >>> I will summarize the current situation from my point of view, maybe it helps: >>> >>> RS-232: >>> - Full Duplex Point-to-Point connection >>> - No transceiver control with RTS >>> - No termination >>> - No extra struct in use >>> >>> RS-422: >>> - Full Duplex Point-to-Point connection >>> - No transceiver control with RTS needed >>> - Termination possible >>> - Extra struct serial_rs485 needed if termination is used >>> => RS-422 can be used in RS-232 operation, but if a termination should be >>> switchable the RS485 flag has to be enabled. But then also transceiver >>> control will be enabled. Not a very satisfying situation. >> >> Well why don't we just allow enabling or disabling RS-485 termination >> independently from the SER_RS485_ENABLED bit in struct serial_rs485? >> >> Just let the user issue a TIOCSRS485 ioctl to toggle termination even >> if in RS-232 mode and use that mode for RS-422. >> >> Looks like the simplest solution to me. > > Sounds not bad. The termination should only depend on whether the GPIO is > given or not. > > Irrespective of this, I think the Linos idea of an RS-422 mode is not bad. > This allows you to take care of special features that were previously > overlooked. For example, hardware flow control can be switched off so that > this does not cause any problems. > Also note, that RS232 and RS422 may NOT always be the same from driver perspective. Take a look at 8250_excar.c for example. That driver has to configure the hardware accordingly when switching from RS232 to RS422 (see iot2040_rs485_config()). While a SER_RS485_MODE_RS422 flag set by userspace could work to switch to RS422, I still think that the cleanest solution would be another ioctl TIOCSRS422 with a parameter like struct serial_rs422 { __u32 flags; #define SER_RS422_ENABLED (1 << 0) #define SER_RS422_TERMINATE_BUS (1 << 1) __u32 padding[7] }; The SER_RS485_MODE_RS422 flag could still be used internally as a hint to the driver. That solution would also be expandable if needed. I planned to send a patch that implements this as a RFC to the mailing list (maybe in the next few days). Regards, Lino
