On Thu, 2022-09-22 at 18:30 +0200, Lukas Wunner wrote: > On Thu, Sep 22, 2022 at 06:06:56PM +0200, Greg Kroah-Hartman wrote: > > On Thu, Sep 22, 2022 at 05:43:53PM +0200, Lukas Wunner wrote: > > > On Thu, Sep 22, 2022 at 04:43:51PM +0200, Greg Kroah-Hartman wrote: > > > > On Wed, Sep 21, 2022 at 06:39:33AM +0200, Lukas Wunner wrote: > > > > > When a UART port is newly registered, uart_configure_port() seeks to > > > > > deassert RS485 Transmit Enable by setting the RTS bit in port->mctrl. > > > > > However a number of UART drivers interpret a set RTS bit as *assertion* > > > > > instead of deassertion: Affected drivers include those using > > > > > serial8250_em485_config() (except 8250_bcm2835aux.c) and some using > > > > > mctrl_gpio (e.g. imx.c). > > > > > > > > > > Since the interpretation of the RTS bit is driver-specific, it is not > > > > > suitable as a means to centrally deassert Transmit Enable in the serial > > > > > core. Instead, the serial core must call on drivers to deassert it in > > > > > their driver-specific way. One way to achieve that is to call > > > > > ->rs485_config(). It implicitly deasserts Transmit Enable. > > > > > > > > > > So amend uart_configure_port() and uart_resume_port() to invoke > > > > > uart_rs485_config(). That allows removing calls to uart_rs485_config() > > > > > from drivers' ->probe() hooks and declaring the function static. > > > [...] > > > > This message never made it to lore.kernel.org, so I can't seem to apply > > > > it using `b4`. > > > > > > > > Can you resend it so that it does make it to the public archives? > > > > > > Yes, both v1 and v2 didn't make it to the mailing list archive. > > > My suspicion is that the Cc: line was probably too long. > > > > > > I resent as v3 with only you in To: and the mailing list in Cc: and > > > this time it went through: > > > > > > https://lore.kernel.org/linux-serial/2de36eba3fbe11278d5002e4e501afe0ceaca039.1663860626.git.lukas@xxxxxxxxx/ > > > > > > On the bright side, v2 contained an embarrassing checkpatch issue > > > (superfluous newline) and resending as v3 provided a welcome > > > opportunity to fix that. :) > > > > v3 did not have a changelog :( > > > > v4? > > Well, the changelog is above. (Only the superfluous newline was removed > in v3 vis-à-vis v2.) > > Here's a v4 with full changelog: > > https://lore.kernel.org/linux-serial/2de36eba3fbe11278d5002e4e501afe0ceaca039.1663863805.git.lukas@xxxxxxxxx/ Hi Lukas, I've noticed that this patch (well, the version that was applied to tty.git) also changed the setting of the DTR flag in the MCR register. Without your patch, I can see that the values passed to serial8250_out_MCR() alternate between 0x03 and 0x01 when switching between tx and rx, but with your patch, the values become 0x02 and 0x00. I'm not sure if setups RS485 exist where the DTR flag is relevant, but as this was not mentioned in the commit message, I suspect that the change might have been unintended.
