On Nov 24, 2011, at 9:26 AM, Paul Gortmaker wrote:

On 11-11-24 03:14 AM, Kumar Gala wrote:

quoted

=20
On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
=20

quoted

Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
chips seems to cause a short lived IRQ storm (/proc/interrupts
typically shows somewhere between 300 and 1500 events).  =

Unfortunately

quoted

quoted

this renders SysRQ over the serial console completely inoperable.
Testing with obvious things like ACKing the event doesn't seem to
change anything vs. a completely dumb approach of just ignoring
it and waiting for it to stop, so that is what is implemented here.
=20
Signed-off-by: Paul Gortmaker <redacted>
---
=20
This is a refresh of a patch I'd done earlier -- I've tried to make
the bug support as generic as possible to minimize having board
specific ifdef crap in 8250.c -- any suggestions on how to further
improve it are welcome.
=20
drivers/serial/8250.c      |    6 ++++++
drivers/serial/8250.h      |   20 ++++++++++++++++++++
drivers/serial/Kconfig     |   14 ++++++++++++++
include/linux/serial_reg.h |    2 ++
4 files changed, 42 insertions(+), 0 deletions(-)

=20
Did we ever decide what to do with this or trying to get it accepted =

upstream?

=20
That is an old version.  ScottW gave me the errata information
which allowed me to fix the problem in a cleaner way.
=20
http://patchwork.ozlabs.org/patch/46609/
=20
I think the above version is OK as-is; the only thing I
think we could do to improve it is to go and automatically
select the thing based on known impacted CPU types (which
could be a separate commit or commits, as various CPUs are
confirmed to have the issue.)

Seems as if we could have ->bugs passed in via plat_serial8250_port and =
than we can get the info from the device tree.

- k=