Re: [PATCH v2] serial: Deassert Transmit Enable on probe in driver-specific way

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux