[PATCH] serial: xilinx_uartps: unset STOPBRK when setting STARTBRK

[PATCH] serial: xilinx_uartps: unset STOPBRK when setting STARTBRK

[Julien Malik]

Zynq UG585 states, in chapter B.33, for XUARTPS_CR_STARTBRK:
It can only be set if STPBRK (Stop transmitter break) is not high

This fixes tcsendbreak, which otherwise does not actually break.

Signed-Off-By: Julien Malik <julien.malik@unseenlabs.fr>
---
 drivers/tty/serial/xilinx_uartps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 8e521c69a959..2e69fceaa792 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -657,7 +657,7 @@ static void cdns_uart_break_ctl(struct uart_port *port, int ctl)
 	status = readl(port->membase + CDNS_UART_CR);
 
 	if (ctl == -1)
-		writel(CDNS_UART_CR_STARTBRK | status,
+		writel(CDNS_UART_CR_STARTBRK | (~CDNS_UART_CR_STOPBRK & status),
 				port->membase + CDNS_UART_CR);
 	else {
 		if ((status & CDNS_UART_CR_STOPBRK) == 0)
-- 
2.25.1

Re: [PATCH] serial: xilinx_uartps: unset STOPBRK when setting STARTBRK

[Julien MALIK - UNSEENLABS]

Le 24/06/2023 à 23:03, Julien Malik a écrit :
> Zynq UG585 states, in chapter B.33, for XUARTPS_CR_STARTBRK:
> It can only be set if STPBRK (Stop transmitter break) is not high
>
> This fixes tcsendbreak, which otherwise does not actually break.
>
> Signed-Off-By: Julien Malik <julien.malik@unseenlabs.fr>
> ---
>   drivers/tty/serial/xilinx_uartps.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
> index 8e521c69a959..2e69fceaa792 100644
> --- a/drivers/tty/serial/xilinx_uartps.c
> +++ b/drivers/tty/serial/xilinx_uartps.c
> @@ -657,7 +657,7 @@ static void cdns_uart_break_ctl(struct uart_port *port, int ctl)
>   	status = readl(port->membase + CDNS_UART_CR);
>   
>   	if (ctl == -1)
> -		writel(CDNS_UART_CR_STARTBRK | status,
> +		writel(CDNS_UART_CR_STARTBRK | (~CDNS_UART_CR_STOPBRK & status),
>   				port->membase + CDNS_UART_CR);
>   	else {
>   		if ((status & CDNS_UART_CR_STOPBRK) == 0)


Dear reviewers,


This is a kind ping to attract more attention to this small patch.


The issue and corresponding fix has already been suggested back in 2016 
on the xilinx forum [1].


This is my very first patch submission to the kernel.

Though I did my best, maybe I did not follow best practices, in which 
case I'm all ears to suggestions.


Best regards,

Julien

[1] 
https://support.xilinx.com/s/question/0D52E00006hpUSKSA2/cannot-send-serial-line-break-in-linux-380-trd-145

Re: [PATCH] serial: xilinx_uartps: unset STOPBRK when setting STARTBRK

[Greg Kroah-Hartman]

On Thu, Oct 12, 2023 at 07:40:16AM +0000, Julien MALIK - UNSEENLABS wrote:
> Le 24/06/2023 à 23:03, Julien Malik a écrit :
> > Zynq UG585 states, in chapter B.33, for XUARTPS_CR_STARTBRK:
> > It can only be set if STPBRK (Stop transmitter break) is not high
> >
> > This fixes tcsendbreak, which otherwise does not actually break.
> >
> > Signed-Off-By: Julien Malik <julien.malik@unseenlabs.fr>
> > ---
> >   drivers/tty/serial/xilinx_uartps.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
> > index 8e521c69a959..2e69fceaa792 100644
> > --- a/drivers/tty/serial/xilinx_uartps.c
> > +++ b/drivers/tty/serial/xilinx_uartps.c
> > @@ -657,7 +657,7 @@ static void cdns_uart_break_ctl(struct uart_port *port, int ctl)
> >   	status = readl(port->membase + CDNS_UART_CR);
> >   
> >   	if (ctl == -1)
> > -		writel(CDNS_UART_CR_STARTBRK | status,
> > +		writel(CDNS_UART_CR_STARTBRK | (~CDNS_UART_CR_STOPBRK & status),
> >   				port->membase + CDNS_UART_CR);
> >   	else {
> >   		if ((status & CDNS_UART_CR_STOPBRK) == 0)
> 
> 
> Dear reviewers,
> 
> 
> This is a kind ping to attract more attention to this small patch.
> 
> 
> The issue and corresponding fix has already been suggested back in 2016 
> on the xilinx forum [1].
> 
> 
> This is my very first patch submission to the kernel.
> 
> Though I did my best, maybe I did not follow best practices, in which 
> case I'm all ears to suggestions.

Odd, I don't see this in my queue anywhere, nor do I see any responses,
very sorry about that.  I'll try to apply it later today.

thanks,

greg k-h