On 21/11/2023 08.52, Krzysztof Kozlowski wrote: > On 20/11/2023 16:10, Rasmus Villemoes wrote: >> Some boards are capable of both rs232 and rs485, and control which >> external terminals are active via a gpio-controlled mux. Allow >> describing that gpio in DT so that the kernel can transparently handle >> the proper setting when the uart is switched between rs232 and rs485 >> modes. >> >> Signed-off-by: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx> >> --- >> Documentation/devicetree/bindings/serial/rs485.yaml | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml >> index 9418fd66a8e9..e8136c7d22ed 100644 >> --- a/Documentation/devicetree/bindings/serial/rs485.yaml >> +++ b/Documentation/devicetree/bindings/serial/rs485.yaml >> @@ -61,6 +61,11 @@ properties: >> the active state enables RX during TX. >> maxItems: 1 >> >> + rs485-mux-gpios: >> + description: GPIO pin to control muxing of the SOC signals to the RS485 >> + transceiver. >> + maxItems: 1 > > Aren't you duplicating > https://lore.kernel.org/all/3Nk.ZZrp.5w3Yn0Ecy5C.1bMzDp@xxxxxxxxx/ ? Hadn't seen that, but no, this is not at all the same. That patch seems to define an input pin to tell whether to enable rs485 mode or not (sort of early run-time version of the linux,rs485-enabled-at-boot-time). > Anyway, similar comments: this does not look like generic RS485 > property. Are you saying that standard defines such GPIO? No, I'm saying that several boards that exist in the wild have the RX/TX/CTS etc. pins routed to a multiplexer, which in turn routes those signals to either a rs485 transceiver or an rs232 driver (and those in turn are connected to different screw terminals). So no, it's not a property of the rs485 protocol itself, but very much related to making use of rs485 (and rs232, though of course not simultaneously) on such boards. Would a link to a schematic help? Rasmus
