LPC32xx has "Standard" UARTs that are actually 16550A compatible but have
bigger FIFOs. Since the already supported 16X50 line still doesn't match here,
we agreed on adding a new type.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Acked-by: NAlan Cox <alan@linux.intel.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This resolves the differences between the original 8250 patch, the revised 8250 patch
and the independant clean up of the octeon driver (to use platform devices properly yay!)
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Information and a different patch provided by <donald@asix.com.tw>. We do
it a little differently to keep the modularity and to avoid playing with
RLSI.

We add a new uart bug for the parity flaw and set it in the pci matches.
If parity check is enabled then we drop the FIFO trigger to 1 as per the
Asix reference code.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now we are using the uart_8250_port this is trivial
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The old interface just copies bits over and calls the newer one.
In addition we can now pass more information.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

pbn_exsys_4055 is the same thing as pbn_b2_4_115200 so replace it with
the standard pattern.
Signed-off-by: NShawn Bohrer <shawn.bohrer@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

LPC32xx has "Standard" UARTs that are actually 16550A compatible but have
bigger FIFOs. Since the already supported 16X50 line still doesn't match here,
we agreed on adding a new type.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Acked-by: NAlan Cox <alan@linux.intel.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix kernel-doc warnings in drivers/tty/serial/8250/8250.c:

Warning(drivers/tty/serial/8250/8250.c:3128): No description found for parameter 'up'
Warning(drivers/tty/serial/8250/8250.c:3128): Excess function parameter 'port' description in 'serial8250_register_8250_port'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The support for CONFIG_MCA is being removed, since the 20
year old hardware simply isn't capable of meeting today's
software demands on CPU and memory resources.

This commit removes the MCA specific 8250 UART code.

Cc: Alan Cox <alan@linux.intel.com>
Cc: linux-serial@vger.kernel.org
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Update the 8250_em driver to support DT.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Update the 8250_em driver to correctly handle the case
where no clock is associated with the device.

The return value of clk_get() needs to be checked with
IS_ERR() to avoid NULL pointer referencing.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is V2 of the Emma Mobile 8250 platform driver.

The hardware itself has according to the data sheet
up to 64 byte FIFOs but at this point we only make
use of the 16550 compatible mode.

To support this piece of hardware the common UART
registers need to be remapped, and the access size
differences need to be handled.

The DLL and DLM registers can due to offset collision
not be remapped easily, and because of that this
driver makes use of ->dl_read() and ->dl_write()
callbacks. This in turn requires a registration
function that takes 8250-specific paramenters.

Future potential enhancements include DT support,
early platform driver console and fine grained PM.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Acked-by: NAlan Cox <alan@linux.intel.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Introduce yet another 8250 registration function.
This time it is serial8250_register_8250_port() and it
allows us to register 8250 hardware instances using struct
uart_8250_port. The new function makes it possible to
register 8250 hardware that makes use of 8250 specific
callbacks such as ->dl_read() and ->dl_write().
Signed-off-by: NMagnus Damm <damm@opensource.se>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Get rid of unused functions and macros now when
Alchemy and RM9K are converted over to callbacks.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert the 8250 RM9K support code to make
use of the new dl_read()/dl_write() callbacks.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert the 8250 Alchemy support code to make
use of the new dl_read()/dl_write() callbacks.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert serial_dl_read() and serial_dl_write() from macro
to 8250 specific callbacks. This change makes it easier to
support 8250 hardware with non-standard DLL and DLM register
configurations such as Alchemy, RM9K and upcoming Emma Mobile
UART hardware.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We noticed that we were loosing data at speed less than 2400 baud.
It turned out our (TI16750 compatible) uart with 64 byte outgoing fifo
was truncated to 16 byte (bit 5 sets fifo len) when modifying the fcr
reg.
The input code still fills the buffer with 64 bytes if I remember
correctly and thus data is lost.
Our fix was to remove whiping of the fcr content and just add the
TRIGGER_1 which we want for latency.
I can't see why this would not work on less than 2400 always, for all
uarts ...
Otherwise one would have to make sure the filling of the fifo re-checks
the current state of available fifo size (urrk).
Signed-off-by: NChristian Melki <christian.melki@ericsson.se>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The rules used to make 8250_pci "ignore" the PCH uarts are lacking pci subids
entries, preventing it to match and thus is breaking serial port support for
theses systems.

This has been tested on a nanoETXexpress-TT, which has a specifici uart clock.
Tested-by: NErwan Velu <Erwan.Velu@zodiacaerospace.com>
[stable@: please apply to 3.0-stable, 3.2-stable and 3.3-stable]
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NArnaud Patard <apatard@hupstream.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit e86ff4a6 "serial/8250_pci: init-quirk msi support for kt serial
controller" introduced a regression in suspend/resume by causing msi's
to be enabled twice without an intervening disable.

00:16.3 Serial controller: Intel Corporation Patsburg KT Controller (rev 05) (prog-if 02 [16550])
       Subsystem: Intel Corporation Device 7270
       Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 72
       I/O ports at 4080 [size=8]
       Memory at d1c30000 (32-bit, non-prefetchable) [size=4K]
       Capabilities: [c8] Power Management version 3
       Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
       Kernel driver in use: serial

[  365.250523] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:16.3/msi_irqs'
[  365.250525] Modules linked in: nls_utf8 ipv6 uinput sg iTCO_wdt
  iTCO_vendor_support ioatdma dca i2c_i801 i2c_core wmi sd_mod ahci libahci isci
  libsas libata scsi_transport_sas [last unloaded: scsi_wait_scan]
[  365.250540] Pid: 9030, comm: kworker/u:1 Tainted: G        W    3.3.0-isci-3.0.213+ #1
[  365.250542] Call Trace:
[  365.250545]  [<ffffffff8115e955>] ? sysfs_add_one+0x99/0xad
[  365.250548]  [<ffffffff8102db8b>] warn_slowpath_common+0x85/0x9e
[  365.250551]  [<ffffffff8102dc96>] warn_slowpath_fmt+0x6e/0x70
[  365.250555]  [<ffffffff8115e8fa>] ? sysfs_add_one+0x3e/0xad
[  365.250558]  [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
[  365.250561]  [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
[  365.250564]  [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
[  365.250567]  [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
[  365.250570]  [<ffffffff8115e955>] sysfs_add_one+0x99/0xad
[  365.250573]  [<ffffffff8115f031>] create_dir+0x72/0xa5
[  365.250577]  [<ffffffff8115f194>] sysfs_create_dir+0xa2/0xbe
[  365.250581]  [<ffffffff81262463>] kobject_add_internal+0x126/0x1f8
[  365.250585]  [<ffffffff8126255b>] kset_register+0x26/0x3f
[  365.250588]  [<ffffffff8126275a>] kset_create_and_add+0x62/0x7c
[  365.250592]  [<ffffffff81293619>] populate_msi_sysfs+0x34/0x103
[  365.250595]  [<ffffffff81293e1c>] pci_enable_msi_block+0x1b3/0x216
[  365.250599]  [<ffffffff81303f7c>] try_enable_msi+0x13/0x17
[  365.250603]  [<ffffffff81303fb3>] pciserial_resume_ports+0x21/0x42
[  365.250607]  [<ffffffff81304041>] pciserial_resume_one+0x50/0x57
[  365.250610]  [<ffffffff81283e1a>] pci_legacy_resume+0x38/0x47
[  365.250613]  [<ffffffff81283e7d>] pci_pm_restore+0x54/0x87
[  365.250616]  [<ffffffff81283e29>] ? pci_legacy_resume+0x47/0x47
[  365.250619]  [<ffffffff8131e9e8>] dpm_run_callback+0x48/0x7b
[  365.250623]  [<ffffffff8131f39a>] device_resume+0x342/0x394
[  365.250626]  [<ffffffff8131f5b7>] async_resume+0x21/0x49

That patch has since been reverted, but by inspection it seems that
pciserial_suspend_ports() should be invoking .exit() quirks to release
resources acquired during .init().
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When using Serial Over Lan (SOL) over the virtual serial port in a Intel
management engine (ME) device, on device reset the serial FIFOs need to
be cleared to keep the FIFO indexes in-sync between the host and the
engine.

On a reset the serial device assertes BI, so using that as a cue FIFOs
are cleared.  So for this purpose a new handle_break callback has been
added.  One other problem is that the serial registers might temporarily
go to 0 on reset of this device.  So instead of using the IER register
read, if 0 returned use the ier value in uart_8250_port. This is hidden
under a custom serial_in.

Cc: Nhan H Mai <nhan.h.mai@intel.com>
Signed-off-by: NSudhakar Mamillapalli <sudhakar@fb.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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>