RE: [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios binding

[Christoph Niedermaier]

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