On Thu, Jul 28, 2016 at 01:07:41PM -0700, Sören Brinkmann wrote:
> On Thu, 2016-07-28 at 10:38:25 +0200, Helmut Grohne wrote:
> > In commit d3755f5e6cd2 ("tty: xuartps: Force enable the UART in
> > xuartps_console_write") added some logic to enable TX before writing
> > and resetting it back to the original state. Uwe Kleine-König
> > discovered that commit e3538c37ee38 ("tty: xuartps: Beautify
> > read-modify writes") breaks that logic and always leaves TX enabled.
> > This commit reverts the unintended functional change.
> >
> > Fixes: e3538c37ee38 ("tty: xuartps: Beautify read-modify writes")
What does this fix? A PM regression?
> > Signed-off-by: Helmut Grohne <h.grohne@xxxxxxxxxx>
> > ---
> > drivers/tty/serial/xilinx_uartps.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > Note that e3538c37ee38 partially hides a hardware race condition that
> > becomes visible again after applying this patch.
>
> Is there any harm in this functional change? I'm more afraid of exposing
> the race again, TBH.
IMHO the right action is to fix the race before applying Helmut's patch.
(That is, let cdns_uart_console_wait_tx block until both FIFO and
shifter are empty. BTW, the kerneldoc to cdns_uart_console_wait_tx is
wrong and needs a s/full/empty/).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
