Hello Christoph, let me first say, for an upcoming new product we are currently developing, we tried different wirings, all related to that !RE pin of the transceiver. In a first hardware revision the engineer doing the schematic connected !RE to GND (always on) and it took me a while to recognize what was going on: everything send through TX was mirrored on RX, which makes using lots of standard applications on that port just fail. (To be fair, we need exactly that behaviour on a different board.) In a second iteration !RE is directly connected to DE now, so RE is now always the opposite of DE. DE itself is always connected to the RTS line of the UART, which allows the driver to switch direction. More below. Am Thu, Oct 27, 2022 at 12:06:56PM +0000 schrieb Christoph Niedermaier: > From: Rob Herring [mailto:robh@xxxxxxxxxx] > Sent: Wednesday, October 26, 2022 10:59 PM > > On Wed, Oct 26, 2022 at 06:50:46PM +0200, Christoph Niedermaier wrote: > >> Add the binding for a generic definition of a GPIO, that controls whether Rx > >> is connected or disconnected by an electrical circuit to have the ability > >> to receive the signals on the bus during sending or disable receiving during > >> sending. > >> > >> Signed-off-by: Christoph Niedermaier <cniedermaier@xxxxxxxxxxxxxxxxxx> > >> --- > >> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > >> Cc: Rob Herring <robh+dt@xxxxxxxxxx> > >> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx> > >> Cc: Marek Vasut <marex@xxxxxxx> > >> Cc: devicetree@xxxxxxxxxxxxxxx > >> To: linux-serial@xxxxxxxxxxxxxxx > >> To: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > >> --- > >> Documentation/devicetree/bindings/serial/rs485.yaml | 4 ++++ > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml > >> index 90a1bab40f05..0ebd7690f85d 100644 > >> --- a/Documentation/devicetree/bindings/serial/rs485.yaml > >> +++ b/Documentation/devicetree/bindings/serial/rs485.yaml > >> @@ -51,6 +51,10 @@ properties: > >> description: GPIO pin to enable RS485 bus termination. > >> maxItems: 1 > >> > >> + rs485-rx-during-tx-gpios: > >> + description: GPIO pin to control RS485 Rx enable during Tx. > > > > Active state means do what? And inactive? This is an output gating the > > RX signal or an input telling the receiver what to do during tx? The > > description is not adequate. > > > > How does this property relate to 'rs485-rx-during-tx' Any combination of > > the 2 being present or not is okay? If not, you need some constraints. > > > > Rob > > > Hi Rob, > > I have improved the message: > > The standard RS485 is a half-duplex bus that in most cased is driven by an > UART controller. The interface to the bus is controlled by a transceiver, that > has a pin called RE (Rx enable) or similar, which connects the bus to Rx signal > of the UART controller. This patch adds a binding for a generic definition of a > GPIO that can switch between two states to control the RE pin via an electrical > circuit: > - Active: > The RE pin is always active. The UART Rx see everything on the bus and > therefore also what happens with the Tx signal on the bus. > - Inactive: > The RE pin is always active, but during sending on the bus the pin RE is > inactive. So basically the receiving during sending is suppressed. > > Is it now more understandable, or have I still not considered an aspect? Better. But what about the questions Rob asked? There's already a property 'rs485-rx-during-tx' which leads to setting the flag SER_RS485_RX_DURING_TX in serial core. As far as I understood from a quick glance at core and drivers, this deals with half or full duplex from the UART point of view (not the transceiver). You need to explain, what's the difference to the new property. I suspect you want to somehow switch behaviour with that GPIO line? Which driver should switch that line in the end and when? (For third iteration of our hardware we thought about a GPIO controlling whether !RE is always on or connected to DE, but that's probably not what you have in mind?) Maybe a simple generic schematic could help explain or maybe you find a better name for the property? Greets Alex > > > Thanks and regards > Christoph
