On 21/11/2023 09.34, Krzysztof Kozlowski wrote: > On 21/11/2023 09:27, Rasmus Villemoes wrote: >> On 21/11/2023 08.52, Krzysztof Kozlowski wrote: >>> 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. > > Which upstream boards use it? None, because the binding doesn't exist. > To me it looks like specific to each controller, not to RS485. What do you mean "controller"? It's not specific to one particular SOC/IP, any uart IP capable of both rs232 and rs485 could be wired to circuitry like this. >> Would a link to a schematic help? > > Yes, always :) https://ibb.co/B3gzySt The UART1.* signals on the right are from the SOC (in this case an imx8mp, but I know of other boards e.g. based on powerpc that use a similar scheme), and the COM1_Sel is just some gpio. The multiplexer is roughly in the middle (U2103). As you can see, if one wants to talk rs485, one must set COM1_Sel low (and that works just fine by describing the rs485-mux-gpio as ACTIVE_LOW), and if one wants to talk rs232, it must be set high. While userspace could be tasked with knowing about and handling that gpio on top of the ioctl() for switching mode, this really seems like the kind of thing that DT is supposed to describe and the kernel is supposed to handle. Rasmus
