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] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 27 Aug 2013 07:32:17 -0700
From:	Kevin Hilman <khilman@...aro.org>
To:	gregkh@...uxfoundation.org
Cc:	jslaby@...e.cz, matts@...mtech-fastcom.com,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	David Howells <dhowells@...hat.com>,
	linux-serial@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	linux-omap <linux-omap@...r.kernel.org>
Subject: Re: [PATCH] OMAP: UART: Keep the TX fifo full when possible

Greg,

On Tue, Aug 20, 2013 at 8:57 AM, Kevin Hilman <khilman@...aro.org> wrote:
> + Felipe
>
> On Mon, Jul 8, 2013 at 3:04 AM, Alexander Savchenko
> <oleksandr.savchenko@...com> wrote:
>> From: Dmitry Fink <finik@...com>
>>
>> Current logic results in interrupt storm since the fifo
>> is constantly below the threshold level. Change the logic
>> to fill all the available spaces in the fifo as long as
>> we have data to minimize the possibilty of underflow and
>> elimiate excessive interrupts.
>>
>> Signed-off-by: Dmitry Fink <finik@...com>
>> Signed-off-by: Alexander Savchenko <oleksandr.savchenko@...com>
>
> Hmm, another OMAP serial patch that wasn't Cc'd to linux-omap where
> OMAP users might have seen it. :(
>
> I just bisected a strange problem in linux-next on OMAP3 down to this
> patch.  Reverting it fixes the problem.
>
> On OMAP3530 Beagle and Overo, after boot, doing a 'cat /proc/cpuinfo'
> was not returning to a prompt, suggesting something strange with the
> FIFO.  Hitting return gets me back to a prompt.
>
> Greg, this one should also be dropped from tty-next until it can be
> further investgated and the problem solved.

Can this one be dropped from tty-next too until it can be
investigated.  The author's ti.com addresses are bouncing, and this
has introduced a regression in -next.

Kevin

>> ---
>>  drivers/tty/serial/omap-serial.c |    3 ++-
>>  include/uapi/linux/serial_reg.h  |    1 +
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
>> index b6d1728..5c9b074 100644
>> --- a/drivers/tty/serial/omap-serial.c
>> +++ b/drivers/tty/serial/omap-serial.c
>> @@ -310,7 +310,8 @@ static void transmit_chars(struct uart_omap_port *up, unsigned int lsr)
>>                 serial_omap_stop_tx(&up->port);
>>                 return;
>>         }
>> -       count = up->port.fifosize / 4;
>> +       count = up->port.fifosize -
>> +               (serial_in(up, UART_OMAP_TXFIFO_LVL) & 0xFF);
>>         do {
>>                 serial_out(up, UART_TX, xmit->buf[xmit->tail]);
>>                 xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
>> diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
>> index e632260..97c26be 100644
>> --- a/include/uapi/linux/serial_reg.h
>> +++ b/include/uapi/linux/serial_reg.h
>> @@ -366,6 +366,7 @@
>>  #define UART_OMAP_MDR1_FIR_MODE                0x05    /* FIR mode */
>>  #define UART_OMAP_MDR1_CIR_MODE                0x06    /* CIR mode */
>>  #define UART_OMAP_MDR1_DISABLE         0x07    /* Disable (default state) */
>> +#define UART_OMAP_TXFIFO_LVL           0x1A    /* TX FIFO fullness */
>>
>>  /*
>>   * These are definitions for the Exar XR17V35X and XR17(C|D)15X
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists