lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20231201114348.fec7077998136877adb030f9@hugovil.com>
Date:   Fri, 1 Dec 2023 11:43:48 -0500
From:   Hugo Villeneuve <hugo@...ovil.com>
To:     Jan Kundrát <jan.kundrat@...net.cz>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Hugo Villeneuve <hvilleneuve@...onoff.com>,
        <linux-kernel@...r.kernel.org>, <linux-serial@...r.kernel.org>
Subject: Re: [PATCH] serial: max310x: change confusing comment about Tx FIFO

On Fri, 01 Dec 2023 17:04:15 +0100
Jan Kundrát <jan.kundrat@...net.cz> wrote:

> On středa 22. listopadu 2023 18:59:56 CET, Hugo Villeneuve wrote:
> > From: Hugo Villeneuve <hvilleneuve@...onoff.com>
> >
> > The comment wording can be confusing, as txlen will return the number of
> > bytes available in the FIFO, which can be less than the maximum theoretical
> > Tx FIFO size.
> 
> This (commit) message is confusing, too, IMHO, because `txlen` is the 
> number of bytes that are currently waiting in the TX FIFO. So that number 
> is "available" for the HW UART to pick up and send, but it's not a number 
> of bytes that's "available" in the FIFO for host to push more bytes to. I 
> guess you might want to tweak that description here.

Hi Jan,
you are right, the commit message is confusing. I copied it from the
commit message of a similar patch for the sc16is7xx driver, and I
should have modified it for the max310x:

SC16IS7XX TXLVL: spaces available in TX FIFO
MAX310X TXFIFOLVL: current fill level in TX FIFO

The patch has already been applied to Greg's tty-next tree (my
understanding is that it cannot be rebased?), but at least
the comment in the code is still valid.

Thank you for the precision.

Hugo V.


> >
> > Change the comment so that it is unambiguous.
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@...onoff.com>
> > ---
> >  drivers/tty/serial/max310x.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
> > index 97e4965b73d4..f3a99daebdaa 100644
> > --- a/drivers/tty/serial/max310x.c
> > +++ b/drivers/tty/serial/max310x.c
> > @@ -780,7 +780,7 @@ static void max310x_handle_tx(struct uart_port *port)
> >  	to_send = uart_circ_chars_pending(xmit);
> >  	until_end = CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE);
> >  	if (likely(to_send)) {
> > -		/* Limit to size of TX FIFO */
> > +		/* Limit to space available in TX FIFO */
> >  		txlen = max310x_port_read(port, MAX310X_TXFIFOLVL_REG);
> >  		txlen = port->fifosize - txlen;
> >  		to_send = (to_send > txlen) ? txlen : to_send;
> >
> > base-commit: 98b1cc82c4affc16f5598d4fa14b1858671b2263
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ