Hi, On 14.12.23 14:41, Christoph Niedermaier wrote: > From: Crescent CY Hsieh <crescentcy.hsieh@xxxxxxxx> > Sent: Thursday, December 14, 2023 11:25 AM >> On Mon, Dec 11, 2023 at 03:07:59PM +0200, Andy Shevchenko wrote: >>> On Sat, Dec 09, 2023 at 12:47:47PM +0100, Lino Sanfilippo wrote: >>>> On 06.12.23 16:42, Lino Sanfilippo wrote: >>> >>>>>>>> Crescent CY Hsieh (+cc) is in parallel trying to add an RS-422 mode bit >>>>>>>> to struct serial_rs485: >>>>>>>> >>>>>>>> https://lore.kernel.org/all/20231121095122.15948-1-crescentcy.hsieh@xxxxxxxx/ >>>>>>>> >>>>>>> >>>>>>> That new flag was suggested by me instead of using SER_RS422_ENABLED, which >>>>>>> would mostly be redundant to SER_RS485_ENABLED. >>>> >>>> A cleaner solution would probably be to not handle RS422 with the RS485 settings at >>>> all, but to introduce another set of ioctls to set and read it. >>>> >>>> An own RS422 structure like >>>> >>>> struct serial_rs422 { >>>> __u32 flags; >>>> #define SER_RS422_ENABLED (1 << 0) >>>> #define SER_RS422_TERMINATE_BUS (1 << 1) >>>> }; >>>> >>>> >>>> could be used as the parameter for these new ioctls. >>>> >>>> Any comments on this? >>> >>> I have (maybe not so constructive) a comment. Please, at all means try to not >>> extend the existing serial data structures, we have too many ones with too many >>> fields already. For user space, though, one may use unions and flags, but for >>> internal ones it might be better ways, I think. >> >> How about revising the name of 'TIOCSRS485' and 'serial_rs485' to a >> general one, and put RS422 and RS485 configuration flags into that >> structure? >> >> So that in userspace it could set RS422 or RS485 configurations using a >> single ioctl command and one structure. >> >> In this way, it won't be confused in userspace and won't add new data >> structure internally as well. >> > > 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. > Thats why I vote for a RS422 mode. > RS-485 (2-wire) very common: > - Half Duplex RS-485 bus > - Transceiver control with RTS is needed > - Termination possible > - Extra struct serial_rs485 is needed > => RS-485 has to be enabled and configured: > - Set SER_RS485_ENABLED > - Set SER_RS485_RTS_ON_SEND or SER_RS485_RTS_AFTER_SEND > - Set/clear SER_RS485_RX_DURING_TX depending on whether > the receiver path should be on or off during sending. > If it's set it allows to monitor the sending on the bus > and detect whether another bus device is transmitting > at the same time. > - Set/clear SER_RS485_TERMINATE_BUS for bus termination. > > RS-485 (4-wire) little used: > - Full Duplex RS-485 bus > - Transceiver control with RTS is needed > - Termination possible > - Extra struct serial_rs485 is needed > => RS-485 has to be enabled and configured: > - Set SER_RS485_ENABLED > - Set SER_RS485_RTS_ON_SEND or SER_RS485_RTS_AFTER_SEND > - Set SER_RS485_RX_DURING_TX, as the receiver should always > be enabled independently of TX, because TX and RX are > separated from each other by their own wires. > - Set/clear SER_RS485_TERMINATE_BUS for bus termination. How can the driver distinguish between RS485 full duplex and half duplex then? In full duplex RTS control is not needed AFAIU. > > I think the GPIOs reflect the flag states and are meaningful: > - SER_RS485_TERMINATE_BUS: Switch bus termination on/off by GPIO > - SER_RS485_RX_DURING_TX: Used to enable/disable RX during TX > in hardware by GPIO (for 2-wire) > - SER_RS485_ENABLED: Muxing between RS-232 and RS-485 by GPIO > > Switching RS-485 on during boot could also be handled by a devicetree > overlay. Evaluate the GPIO and load a DTO accordingly before booting. > > Please correct me if I have misrepresented something... > > If I looked at it in this new way, I would discard my idea with the > FULL_DUPLEX and HALF_DUPLEX. For a better use of RS-422 it would be > good to disable transceiver control via RTS. It can be done by clearing > the existing flags SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND > at the same time, but I think it is confusing. Better would be a flag > for RS-422: > > RS-422: Set SER_RS422_MODE for disabling > transceiver control via RTS. > RS-485 (2-wire and 4-wire): Clear SER_RS422_MODE for enabling > transceiver control via RTS. > > Finally, at present it is also not possible to distinguish between RS485 > 2-wire and 4-wire operation. I think it isn't necessary, as different > hardware has to be used anyway. The hardware then determines the > configuration, see above. But the driver should somehow be informed that there exists a full duplex hardware setup, so that it does not need to control the RTS line. Maybe by means of a device tree property? Regards, Lino > > > Regards > Christoph
