linux-kernel - Re: [PATCH] serial: 8250_omap: remove wait loop from Errata i202 workaround

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]

Message-ID: <c91216ec-c7e7-df7b-463-ec17c76b7bc2@linux.intel.com>
Date:   Mon, 17 Oct 2022 15:15:50 +0300 (EEST)
From:   Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
cc:     Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Tony Lindgren <tony@...mide.com>,
        Peter Hurley <peter@...leysoftware.com>,
        linux-serial <linux-serial@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] serial: 8250_omap: remove wait loop from Errata i202
 workaround

On Mon, 17 Oct 2022, Sebastian Andrzej Siewior wrote:

> On 2022-10-17 11:12:41 [+0300], Ilpo Järvinen wrote:
> > On Thu, 13 Oct 2022, Matthias Schiffer wrote:
> > 
> > > We were occasionally seeing the "Errata i202: timedout" on an AM335x
> > > board when repeatedly opening and closing a UART connected to an active
> > > sender. As new input may arrive at any time, it is possible to miss the
> > > "RX FIFO empty" condition, forcing the loop to wait until it times out.
> > 
> > I can see this problem could occur and why your patch fixes it.
> > 
> > > Nothing in the i202 Advisory states that such a wait is even necessary;
> > > other FIFO clear functions like serial8250_clear_fifos() do not wait
> > > either. For this reason, it seems safe to remove the wait, fixing the
> > > mentioned issue.
> > 
> > Checking the commit that added this driver and the loop along with it, 
> > there was no information why it would be needed there either.
> 
> I don't remember all the details but I do remember that I never hit it.
> The idea back then was to document what appears the problem and then
> once there is a reproducer address it _or_ when there is another problem
> check if it aligns with the output here (so that _this_ problem's origin
> could be this). This was part of address all known chip erratas and
> copied from omap-serial at the time so that the 8250 does not miss
> anything.
> Looking closer, this is still part of the omap-serial driver and it was
> introduced in commit
>    0003450964357 ("omap2/3/4: serial: errata i202: fix for MDR1 access")

I found that one too but it doesn't give any explanation for it either.
In fact, the wait for empty is mysteriously missing from the itemized
description of the workaround in the commit message.

> If someone found a way to trigger this output which is unrelated to the
> expected cause then this is clearly not helping nor intended.
> 
> I would prefer to keep the loop and replace the disturbing output with a
> comment describing _why_ the FIFO might remain non-empty after a flush.
> 
> In worst cases that loop causes a delay of less than 0.5ms while setting
> a baud rate so I doubt that this is causing a real problem.
> 
> Either way I would like to see Tony's ACK before this is getting removed
> as suggested in this patch.

Thanks for chimming in.

I went to do some lore searching and came across this thread (it should 
be added with Link: tag the patch regardless of its final form):
  https://lore.kernel.org/linux-omap/4BBF61FE.3060807@ti.com/


-- 
 i.