The "KT" serial port has another use case for a "received break" quirk,
so before adding another special case to the 8250 core take this
opportunity to push such quirks out of the core and into a uart_port op.

Stephen says:
"If the callback function is to no longer live in 8250.c itself,
 arch/arm/mach-tegra/devices.c isn't logically a good place to put it,
 and that file will be going away once we get rid of all the board files
 and move solely to device tree."

...so since 8250_pci.c houses all the quirks for pci serial devices this
quirk is similarly housed in of_serial.c.  Once the open firmware
conversion completes the infrastructure details
(include/linux/of_serial.h, and the export) can all be removed to make
this self contained to of_serial.c.

Cc: Nhan H Mai <nhan.h.mai@intel.com>
Cc: Colin Cross <ccross@android.com>
Cc: Olof Johansson <olof@lixom.net>
[stephen: kill CONFIG_SERIAL_TEGRA in favor just using CONFIG_ARCH_TEGRA]
Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NSudhakar Mamillapalli <sudhakar@fb.com>
Reported-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Tested-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Workaround dropped notifications in the iir register.  Register reads
coincident with new interrupt notifications sometimes result in this
device clearing the interrupt event without reporting it in the read
data.

The serial core already has a heuristic for determining when a device
has an untrustworthy iir register.  In this case when we apriori know
that the iir is faulty use a flag (UPF_BUG_THRE) to bypass the test and
force usage of the background timer.

[stable: 3.3.x]
Acked-by: NAlan Cox <alan@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Reported-by: NNhan H Mai <nhan.h.mai@intel.com>
Reported-by: NSudhakar Mamillapalli <sudhakar@fb.com>
Tested-by: NNhan H Mai <nhan.h.mai@intel.com>
Tested-by: NSudhakar Mamillapalli <sudhakar@fb.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 448ac154.

The semantic of UPF_IIR_ONCE is only guaranteed to workaround the race
condition in the kt serial's iir register if the only source of
interrupts is THRE (fifo-empty) events.  An modem status event at the
wrong time can again cause an iir read to drop the 'empty' status
leading to a hang.  So, revert this in preparation for using the
existing "I don't trust my iir register" workaround in the 8250 core
(UART_BUG_THRE).

[stable: 3.3.x]
Cc: stable <stable@vger.kernel.org>
Acked-by: NAlan Cox <alan@linux.intel.com>
Cc: Sudhakar Mamillapalli <sudhakar@fb.com>
Reported-by: NNhan H Mai <nhan.h.mai@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit e86ff4a6.

This tried to enforce the semantics of one interrupt per iir read of the
THRE (transmit-hold empty) status, but events from other sources
(particularly modem status) defeat this guarantee.

This change also broke 8250_pci suspend/resume support as
pciserial_resume_ports() re-runs .init() quirks, but does not run
.exit() quirks in pciserial_suspend_ports() leading to reports like:

  sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:16.3/msi_irqs'

...and a subsequent crash.  The mismatch of init/exit at suspend/resume
seems like a bug in its own right.

[stable: 3.3.x]
Cc: stable <stable@vger.kernel.org>
Acked-by: NAlan Cox <alan@linux.intel.com>
Cc: Sudhakar Mamillapalli <sudhakar@fb.com>
Reported-by: NNhan H Mai <nhan.h.mai@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove all #inclusions of asm/system.h preparatory to splitting and killing
it.  Performed with the following command:

perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`
Signed-off-by: NDavid Howells <dhowells@redhat.com>

The two callers to serial_out_sync() have a struct port right
there in scope, but then pass in a struct 8250_port which then
is locally resolved back to a struct port.

Delete the needless back and forth and just pass in the struct
port directly.  Rename the function to have "_port" in its
name, so the name <--> args relationship is consistent with the
other serial_in/out vs serial_port_in/out function classes.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The serial_in and serial_out helpers are expecting to operate
on an 8250_port struct.  These in turn go after the contained
normal port struct which actually has the actual in/out accessors.

But what is happening in some cases, is that a function is passed
in a port struct, and it runs container_of to get the 8250_port
struct, and then it uses serial_in/out helpers on that.  But when
you do, it goes full circle, since it jumps back inside the 8250_port
to find the contained port struct (which we already knew!).

So, if we are operating in a scope where we know the struct port,
then use the serial_port_in/out helpers and avoid the bouncing
around.  If we don't have the struct port handy, and it isn't
worth making a local for it, then just leave things as-is which
uses the serial_in/out helpers that will resolve the 8250_port
onto the struct port.

Mostly, gcc figures this out on its own -- so this doesn't bring to
the table any revolutionary runtime delta.  However, it is somewhat
misleading to always hammer away on 8250 structs, when the actual
underlying property isn't at all 8250 specific -- and this change
makes that clear.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The serial_8250_port struct contains within a serial_port struct
and many times one or the other, or both are in scope within
functions via a passed in arg, or via container_of.

However there are a lot of cases where we have access directly
to the port pointer, but yet go through the parent 8250_port
structure instead to get it.  These should just use the port
struct directly.

Similarly there are cases where it makes sense (from a code
cleanliness point of view) to declare a local for the port
struct, so we aren't going through the parent 8250_port struct
repeatedly to get to it.

We get a small reduction in text size, but it appears that
gcc was smart enough to internally be doing most of this
already, so the readability improvement is the larger gain.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These might have worked some magic with an ancient gcc back in
1992, but "objdump --disassemble" on gcc 4.6 on x86-64 shows
identical output before and after this commit.  Send the casts
and their hysterical rasins to the bitbucket.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently 8250.c has serial_in and serial_out as shortcuts
to doing the port I/O.  They are implemented as macros a
ways down in the file.  This isn't by accident, but is
implicitly required, so cpp doesn't mangle other instances
of the common string "serial_in", as it exists as a field
in the port struct itself.

The above mangling avoidance violates the principle of least
surprise, and it also prevents the shortcuts from being
relocated up to the top of file, or into 8250.h -- either
being a better location than the current one.

Move them to 8250.h so other 8250-like drivers can also use
the shortcuts, and in the process, make the conflicting
names go away by using static inlines instead of macros.
The object file size remains unchanged with this modification.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is the last traces of pausing I/O that we had back some
twenty years ago.  Probably was only required for 8MHz ISA
cards running "on the edge" at 12MHz.  Anyway it hasn't been
in use for years, so lets just bury it for good.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are multiple users of this file from different source
paths now, and rather than have ../ paths in include statements,
just move the file to the linux header dir.
Suggested-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 9bef3d41

	"serial: group all the 8250 related code together"

inadvertently swept up the m32r driver in the move, because
it had comments mentioning 8250 registers within it.  However
these are only there by nature of the driver being based off
the 8250 source code -- the hardware itself does not actually
have any relation to the original 8250 style UARTs.
Reported-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On sparc, there is a build failure:

drivers/tty/serial/8250/8250.c:48:21: error: suncore.h: No such file or directory
drivers/tty/serial/8250/8250.c:3275: error: implicit declaration of function 'sunserial_register_minors'
drivers/tty/serial/8250/8250.c:3305: error: implicit declaration of function 'sunserial_unregister_minors'

this is due to commit 9bef3d41
(serial: group all the 8250 related code together) moved these files
into 8250/ subdirectory, but forgot to change the reference
to drivers/tty/serial/suncore.h.

Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NWANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The drivers/tty/serial dir is already getting rather busy.
Relocate the 8250 related drivers to their own subdir to
reduce the clutter.

Note that sunsu.c is not included in this move -- it is
8250-like hardware, but it does not use any of the existing
infrastructure -- and does not depend on SERIAL_8250.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>