On Sun, Dec 24, 2023 at 10:11:17AM +0000, Christoph Niedermaier wrote: > 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? Exactly, if you are going for this, just make a new entry into union, and use flags for that. So, you probably will have the same IOCTL, but which will serve RS422/RS385 purposes excluding odds of the use of the pieces. -- With Best Regards, Andy Shevchenko
