From: Lino Sanfilippo [mailto:LinoSanfilippo@xxxxxx] Sent: Saturday, December 23, 2023 2:41 PM > 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). Having your own ioctl is a nice distinction, but when I think about it for a moment, questions come to mind: >From userspace perspective then there are two termination flags SER_RS485_TERMINATE_BUS and SER_RS422_TERMINATE_BUS? How will they interact internally? What about the devicetree property? Will there be rs422-term-gpios as well? Could the user enable RS422 and RS485 at the same time? Regards and Merry Christmas Christoph
