linux-toradex.git/drivers/tty/serial/8250, branch v3.4.32 Linux kernel for Apalis and Colibri modules tty: 8250_dw: Fix inverted arguments to serial_out in IRQ handler 2013-01-21T19:45:26+00:00 Maxime Ripard maxime.ripard@free-electrons.com 2013-01-14T19:09:26+00:00 f6ffcce2ef152bebaeeed0cd9fd117e23a3c46ff commit 68e56cb3a068f9c30971c6117fbbd1e32918e49e upstream. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 68e56cb3a068f9c30971c6117fbbd1e32918e49e upstream.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: set correct baud_base for EXSYS EX-41092 Dual 16950 2012-10-07T15:32:25+00:00 Flavio Leitner fbl@redhat.com 2012-09-22T00:04:34+00:00 268b7d491c88845b410b2dfc84af54075db35c4d commit 26e8220adb0aec43b7acafa0f1431760eee28522 upstream. Apparently the same card model has two IDs, so this patch complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2 adding the missing one. Signed-off-by: Flavio Leitner <fbl@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 26e8220adb0aec43b7acafa0f1431760eee28522 upstream.

Apparently the same card model has two IDs, so this patch
complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2
adding the missing one.

Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8250_pci: fix pch uart matching 2012-06-01T07:18:20+00:00 Arnaud Patard apatard@hupstream.com 2012-04-25T10:17:24+00:00 0b3539aad80702d68bcc3211fb4f5779f84d9d75 commit aaa10eb1d0034eccc096f583fe308f0921617598 upstream. 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: Erwan Velu <Erwan.Velu@zodiacaerospace.com> [stable@: please apply to 3.0-stable, 3.2-stable and 3.3-stable] Signed-off-by: Arnaud Patard <apatard@hupstream.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit aaa10eb1d0034eccc096f583fe308f0921617598 upstream.

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: Erwan Velu <Erwan.Velu@zodiacaerospace.com>
[stable@: please apply to 3.0-stable, 3.2-stable and 3.3-stable]
Signed-off-by: Arnaud Patard <apatard@hupstream.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8250.c: less than 2400 baud fix. 2012-06-01T07:18:20+00:00 Christian Melki christian.melki@ericsson.se 2012-04-30T09:21:26+00:00 b4bc0181430409b4ffbac0da0a286b1ea0a91dfe commit f9a9111b540fd67db5dab332f4b83d86c90e27b1 upstream. 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: Christian Melki <christian.melki@ericsson.se> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f9a9111b540fd67db5dab332f4b83d86c90e27b1 upstream.

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: Christian Melki <christian.melki@ericsson.se>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial/8250_pci: add a "force background timer" flag and use it for the "kt" serial port 2012-04-09T17:38:30+00:00 Dan Williams dan.j.williams@intel.com 2012-04-06T18:49:50+00:00 bc02d15a3452fdf9276e8fb89c5e504a88df888a 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: Alan Cox <alan@linux.intel.com> Cc: stable <stable@vger.kernel.org> Reported-by: Nhan H Mai <nhan.h.mai@intel.com> Reported-by: Sudhakar Mamillapalli <sudhakar@fb.com> Tested-by: Nhan H Mai <nhan.h.mai@intel.com> Tested-by: Sudhakar Mamillapalli <sudhakar@fb.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg 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: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Reported-by: Nhan H Mai <nhan.h.mai@intel.com>
Reported-by: Sudhakar Mamillapalli <sudhakar@fb.com>
Tested-by: Nhan H Mai <nhan.h.mai@intel.com>
Tested-by: Sudhakar Mamillapalli <sudhakar@fb.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "serial/8250_pci: setup-quirk workaround for the kt serial controller" 2012-04-09T17:34:52+00:00 Dan Williams dan.j.williams@intel.com 2012-04-06T18:49:44+00:00 49b532f96fda23663f8be35593d1c1372c0f91e0 This reverts commit 448ac154c957c4580531fa0c8f2045816fe2f0e7. 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: Alan Cox <alan@linux.intel.com> Cc: Sudhakar Mamillapalli <sudhakar@fb.com> Reported-by: Nhan H Mai <nhan.h.mai@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This reverts commit 448ac154c957c4580531fa0c8f2045816fe2f0e7.

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: Alan Cox <alan@linux.intel.com>
Cc: Sudhakar Mamillapalli <sudhakar@fb.com>
Reported-by: Nhan H Mai <nhan.h.mai@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "serial/8250_pci: init-quirk msi support for kt serial controller" 2012-04-09T17:34:16+00:00 Dan Williams dan.j.williams@intel.com 2012-04-06T18:49:37+00:00 3579812373aba92b2f3b632bdf99329bc3c05d62 This reverts commit e86ff4a63c9fdd875ba8492577cd1ad2252f525c. 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: Alan Cox <alan@linux.intel.com> Cc: Sudhakar Mamillapalli <sudhakar@fb.com> Reported-by: Nhan H Mai <nhan.h.mai@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This reverts commit e86ff4a63c9fdd875ba8492577cd1ad2252f525c.

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: Alan Cox <alan@linux.intel.com>
Cc: Sudhakar Mamillapalli <sudhakar@fb.com>
Reported-by: Nhan H Mai <nhan.h.mai@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove all #inclusions of asm/system.h 2012-03-28T17:30:03+00:00 David Howells dhowells@redhat.com 2012-03-28T17:30:03+00:00 9ffc93f203c18a70623f21950f1dd473c9ec48cd 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: David Howells <dhowells@redhat.com> 
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: David Howells <dhowells@redhat.com>
serial: remove back and forth conversions in serial_out_sync 2012-03-09T20:47:56+00:00 Paul Gortmaker paul.gortmaker@windriver.com 2012-03-09T00:12:14+00:00 55e4016dd055e262e4b078b81c80b55386ead0f4 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: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: use serial_port_in/out vs serial_in/out in 8250 2012-03-09T20:47:56+00:00 Paul Gortmaker paul.gortmaker@windriver.com 2012-03-09T00:12:13+00:00 4fd996a14660f56a6fd92ce7c8fb167d262c994f 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: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg 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: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>