Signed-off-by: John Crispin <blogic@openwrt.org>
Signed-off-by: Ralph Hempel <ralph.hempel@lantiq.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: alan@lxorguk.ukuu.org.uk
Cc: linux-mips@linux-mips.org
Cc: linux-serial@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/2269/


Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

Commit b826291c, "drivercore/dt: add a match table pointer to struct
device" added an of_match pointer to struct device to cache the
of_match_table entry discovered at driver match time.  This was unsafe
because matching is not an atomic operation with probing a driver.  If
two or more drivers are attempted to be matched to a driver at the
same time, then the cached matching entry pointer could get
overwritten.

This patch reverts the of_match cache pointer and reworks all users to
call of_match_device() directly instead.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

Problem description:
  gsm_queue() calculate a CRC for arrived frames. As a last step of
  CRC calculation it call

    gsm->fcs = gsm_fcs_add(gsm->fcs, gsm->received_fcs);

  This work perfectly for the case of GSM0 mode as gsm->received_fcs
  contain the last piece of data required to generate final CRC.

  gsm->received_fcs is not used for GSM1 mode. Thus we put an
  additional byte to CRC calculation. As result we get a wrong CRC
  and reject incoming frame.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

If cts changes between reading the level at the cts input (USR1_RTSS)
and acking the irq (USR1_RTSD) the last edge doesn't generate an irq and
uart_handle_cts_change is called with a outdated value for cts.

The race was introduced by commit

	ceca629e ([ARM] 2971/1: i.MX uart handle rts irq)

Reported-by: Arwed Springer <Arwed.Springer@de.trumpf.com>
Tested-by: Arwed Springer <Arwed.Springer@de.trumpf.com>
Cc: stable@kernel.org # 2.6.14+
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Commit f23eb2b2 ('tty: stop using "delayed_work" in the tty layer')
ended up causing hung machines on UP with no preemption, because the
work routine to flip the buffer data to the ldisc would endlessly re-arm
itself if the destination buffer had filled up.

With the delayed work, that only caused a timer-driving polling of the
tty state every timer tick, but without the delay we just ended up with
basically a busy loop instead.

Stop the insane polling, and instead make the code that opens up the
receive room re-schedule the buffer flip work.  That's what we should
have been doing anyway.

This same "poll for tty room" issue is almost certainly also the cause
of excessive kworker activity when idle reported by Dave Jones, who also
reported "flush_to_ldisc executing 2500 times a second" back in Nov 2010:

  http://lkml.org/lkml/2010/11/30/592



which is that silly flushing done every timer tick.  Wasting both power
and CPU for no good reason.

Reported-and-tested-by: Alexander Beregalov <a.beregalov@gmail.com>
Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Cc: Greg KH <gregkh@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Dave Jones <davej@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>

The driver is initialized in a state with an unknown value by
serial_console_setup. And initialization fails.

This is caused by the initialization by sci_console_init.
This function does not seem to be necessary for the present sh-sci driver.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

Commit 906b17dc introduced a condition
where the kernel will crash unless a earlyprintk parameter is specified.

Without this parameter, sci_console_init is called during early console
setup without any port being initialized, and the kernel crashes a
little bit later when uart_set_options attemps to invoke set_termios on a
port with an ops member equal to NULL.

This patch just checks in sci_console_init that the port is properly
initialized, and aborts the early console setup if it is not.

Signed-off-by: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

It absolutely needs to be able to get at pdev_archdata members
which are sparc specific.

Signed-off-by: David S. Miller <davem@davemloft.net>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>

The UARTs may be located on different APB buses, thus have

different UART clock frequency. The system frequency is not
the same (but often) as the UART frequency, rather the APB bus
frequency that the APBUART is located at has the same
frequency, so this looks at the "freq" property instead.

Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

See Commit id 1636f8ac (sparc/of:
Move of_device fields into struct pdev_archdata), this patch
is similar to 19e4875f (of/sparc:
fix build regression from of_device changes)

Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Scripted with coccinelle.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

This is an off by one because strlen() doesn't count the null
terminator.  We strcpy() these strings into an array of size
MAX_CONFIG_LEN.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>

Commit ddd588b5 ("oom: suppress nodes that are not allowed from
meminfo on oom kill") moved lib/show_mem.o out of lib/lib.a, which
resulted in build warnings on all architectures that implement their own
versions of show_mem():

	lib/lib.a(show_mem.o): In function `show_mem':
	show_mem.c:(.text+0x1f4): multiple definition of `show_mem'
	arch/sparc/mm/built-in.o:(.text+0xd70): first defined here

The fix is to remove __show_mem() and add its argument to show_mem() in
all implementations to prevent this breakage.

Architectures that implement their own show_mem() actually don't do
anything with the argument yet, but they could be made to filter nodes
that aren't allowed in the current context in the future just like the
generic implementation.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: James Bottomley <James.Bottomley@hansenpartnership.com>
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

put_tty_driver calls tty_driver_kref_put on its argument, and then
tty_driver_kref_put calls kref_put on the address of a field of this
argument.  kref_put checks for NULL, but in this case the field is likely
to have some offset and so the result of taking its address will not be
NULL.  Labels are added to be able to skip over the call to put_tty_driver
when the argument will be NULL.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/

)

// <smpl>
@@
expression *x;
@@

*if (x == NULL)
{ ...
* put_tty_driver(x);
  ...
  return ...;
}
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
Cc: Torben Hohn <torbenh@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Using delayed-work for tty flip buffers ends up causing us to wait for
the next tick to complete some actions.  That's usually not all that
noticeable, but for certain latency-critical workloads it ends up being
totally unacceptable.

As an extreme case of this, passing a token back-and-forth over a pty
will take two ticks per iteration, so even just a thousand iterations
will take 8 seconds assuming a common 250Hz configuration.

Avoiding the whole delayed work issue brings that ping-pong test-case
down to 0.009s on my machine.

In more practical terms, this latency has been a performance problem for
things like dive computer simulators (simulating the serial interface
using the ptys) and for other environments (Alan mentions a CP/M emulator).

Reported-by: Jef Driesen <jefdriesen@telenet.be>
Acked-by: Greg KH <gregkh@suse.de>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Add a call to of_node_put in the error handling code following a call to
of_find_compatible_node or of_find_node_by_type.

This patch also substantially reorganizes the error handling code in the
function, to that it is possible first to jump to code that frees qe_port
and then to jump to code that also puts np.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/

)

// <smpl>
@r exists@
local idexpression x;
expression E,E1,E2;
statement S;
@@

*x =
(of_find_node_by_path
|of_find_node_by_name
|of_find_node_by_phandle
|of_get_parent
|of_get_next_parent
|of_get_next_child
|of_find_compatible_node
|of_match_node
|of_find_node_by_type
|of_find_node_with_property
|of_find_matching_node
|of_parse_phandle
)(...);
...
if (x == NULL) S
<... when != x = E
*if (...) {
  ... when != of_node_put(x)
      when != if (...) { ... of_node_put(x); ... }
(
  return <+...x...+>;
|
*  return ...;
)
}
...>
(
E2 = x;
|
of_node_put(x);
)
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Timur Tabi <timur@freescale.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Default clock source for UARTs on Topcliff is external UART_CLK.
On CM-iTC USB_48MHz is used instead. After VCO2PLL and DIV
manipulations UARTs will receive 192 MHz.
Clock manipulations on Topcliff are controlled in pch_phub.c

v2: redone against the linux-next tree
v3: redone against linux/kernel/git/next/linux-next.git snapshot

Signed-off-by: Denis Turischev <denis@compulab.co.il>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This piece of code was just slightly different between the DMA
and IRQ paths, in DMA mode we surely shouldn't read more than
256 character either, so factor this out in its own function and
use for both DMA and PIO mode.

Tested on Ux500 and U300.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This adds an optional RX DMA codepath for the devices that
support this by using the apropriate burst sizes instead of
pulling single bytes.

Includes portions of code written by Russell King during
a PL08x hacking session.

This has been tested on U300 and Ux500.

Tested-by: Jerzy Kasenberg <jerzy.kasenberg@tieto.com>
Tested-by: Grzegorz Sygieda <grzegorz.sygieda@tieto.com>
Tested-by: Marcin Mielczarczyk <marcin.mielczarczyk@tieto.com>
Signed-off-by: Per Forlin <per.friden@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This fixes a particular nasty racing problem found when using
Xen hypervisor with the console (hvc) output being routed to the
serial port and the serial port receiving data when
probe_irq_off(probe_irq_on) is running.

Specifically the bug manifests itself with:

[    4.470693] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[    4.470693] IP: [<ffffffff810a8c65>] handle_IRQ_event+0xe/0xc9
..snip..
[    4.470693] Call Trace:
[    4.470693]  <IRQ>
[    4.470693]  [<ffffffff810aa645>] handle_percpu_irq+0x3c/0x69
[    4.470693]  [<ffffffff8123cda7>] __xen_evtchn_do_upcall+0xfd/0x195
[    4.470693]  [<ffffffff810308cf>] ? xen_restore_fl_direct_end+0x0/0x1
[    4.470693]  [<ffffffff8123d873>] xen_evtchn_do_upcall+0x32/0x47
[    4.470693]  [<ffffffff81034dfe>] xen_do_hypervisor_callback+0x1e/0x30
[    4.470693]  <EOI>
[    4.470693]  [<ffffffff8100922a>] ? hypercall_page+0x22a/0x1000
[    4.470693]  [<ffffffff8100922a>] ? hypercall_page+0x22a/0x1000
[    4.470693]  [<ffffffff810301c5>] ? xen_force_evtchn_callback+0xd/0xf
[    4.470693]  [<ffffffff810308e2>] ? check_events+0x12/0x20
[    4.470693]  [<ffffffff81030889>] ? xen_irq_enable_direct_end+0x0/0x7
[    4.470693]  [<ffffffff810ab0a0>] ? probe_irq_on+0x8f/0x1d7
[    4.470693]  [<ffffffff812b105e>] ? serial8250_config_port+0x7b7/0x9e6
[    4.470693]  [<ffffffff812ad66c>] ? uart_add_one_port+0x11b/0x305

The bug is trigged by three actors working together:
 A). serial_8250_config_port calling
	probe_irq_off(probe_irq_on())
     wherein all of the IRQ handlers are being started and shut off.
     The functions utilize the sleep functions so the minimum time
     they are run is 120 msec.
 B). Xen hypervisor receiving on the serial line any character and
     setting the bits in the event channel - during this 120 msec timeframe.
 C). The hvc API makes a call to 'request_irq' (and hence setting desc->action
     to a valid value), much much later - when user space opens
     /dev/console (hvc_open). To make the console usable during bootup,
     the Xen HVC implementation sets the IRQ chip (and correspondingly
     the event channel) much earlier. The IRQ chip handler that is used
     is the handle_percpu_irq (aaca4964)

Back to the issue. When A) is being called it ends up calling the
xen_percpu_chip's chip->startup twice and chip->shutdown once. Those
are set to the default_startup and mask_irq (events.c) respectivly.
If (and this seems to depend on what serial concentrator you use), B)
gets data from the serial port it sets in the event channel a pending bit.
When A) calls chip->startup(), the masking of the pending bit, and
unmasking of the event channel mask, and also setting of the upcall_pending
flag is done (since there is data present on the event channel).
If before the 120 msec has elapsed, any IRQ handler (Xen IRQ has one
IRQ handler, which checks the event channels bitmap to figure which one
to call) is called we end up calling the handle_percpu_irq. The
handle_percpu_irq calls desc->action (which is NULL) and we blow up.

Caveats: I could only reproduce this on 2.6.32 pvops. I am not sure
why this is not showing up on 2.6.38 kernel.

The probe_irq_on/off has code to disable poking specific IRQ lines. This is
done by using the set_irq_noprobe() and then we do not have to
worry about the handle_percpu_irq being called before the IRQ action
handler has been installed.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

* the GSM 07.10 specification says in 5.4.3.1 that
'both stations shall set the P bit to 0'
  thanks to Alan Cox for finding this explanation in the spec

* without this fix, on Telit & Sim.com modems, opening a new DLC
randomly fails. Not setting PF bit of the control byte gives a
reliable behaviour on these modems.

Signed-off-by: Eric Bénard <eric@eukrea.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This driver supports UART-DM HW on MSM platforms. It uses the on
chip DMA to drive data transfers and has optional support for UART
power management independent of Linux suspend/resume and wakeup
from Rx.

The driver was originally developed by Google. It is functionally
equivalent to the version available at:
http://android.git.kernel.org/?p=kernel/experimental.git


the differences being:
1) Remove wakelocks and change unsupported DMA API.
2) Replace clock selection register codes by macros.
3) Fix checkpatch errors and add inline documentation.
4) Add runtime PM hooks for active power state transitions.
5) Handle error path and cleanup resources if required.

CC: Nick Pelly <npelly@google.com>
Signed-off-by: Sankalp Bose <sankalpb@codeaurora.org>
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The current tty_audit_add_data code:

        do {
                size_t run;

                run = N_TTY_BUF_SIZE - buf->valid;
                if (run > size)
                        run = size;
                memcpy(buf->data + buf->valid, data, run);
                buf->valid += run;
                data += run;
                size -= run;
                if (buf->valid == N_TTY_BUF_SIZE)
                        tty_audit_buf_push_current(buf);
        } while (size != 0);

If the current buffer is full, kernel will then call tty_audit_buf_push_current
to empty the buffer. But if we disabled audit at the same time, tty_audit_buf_push()
returns immediately if audit_enabled is zero.  Without emptying the buffer.
With obvious effect on tty_audit_add_data() that ends up spinning in that loop,
copying 0 bytes at each iteration and attempting to push each time without any effect.
Holding the lock all along.

Suggested-by: Alexander Viro <aviro@redhat.com>
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

S3 sleep invokes the shutdown callback of the sh-sci driver, which
suspends the clocks until they are reactivated by a call to startup.
However, before the latter is invoked, sci_set_termios may be called on
the port by uart_resume_port. In such cases it will endlessly wait for
the TEND bit to raise, which will never happen since the clocks are
disabled.

This patch ensures that clocks are enabled when ports registers are
manipulated within sci_set_termios.

Signed-off-by: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

The HVCS driver, for those who don't know, is a driver for the "server" side
of the IBM virtual terminal mechanism allowing Linux partitions to act as
terminal servers under IBM PowerVM hypervisor. It's almost never used on
the field at the moment.

However, it's part of our configs, and in its current incarnation, will
allocate the tty driver & major (with 64 minors) and create a kernel thread
whether it's used or not, ie, whether the hypervisor did put a virtual
terminal server device node in the partition or not (or whether running on
a pseries machine or not even).

This in turns causes modern distro's udev's to start trying to open all
those 64 minors at boot, which, since they aren't linked to anything,
causes the driver to spew errors in the kernel log for each of them.

Not nice.

This moves all that initialization to a function which is now only called
the first time a terminal server virtual IO device is actually probed
(that is almost never).

There's still a _LOT_ of cleanup that can be done in this driver, some
simple (almost all printk's statements in there shall either just be
removed or in some case turned into better written & more informative
messages, including using the dev_* variants etc...). This is left as
an exercise for whoever actually cares about that driver.

One could also try to be smart and dispose of all the tty related
resources when the last instance of the VIO server device
is removed (Hotplug anybody ?).

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

These were missed the last time I cleaned this up
globally, because of code moving around or new code
getting merged.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Advertise the possibility to use this driver with device tree if
CONFIG_OF is set.

Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

With the recent switch of the (currently still out-of-tree) Nios2 Linux
port to devicetree we want to be able to retrieve the resources and
properties from dts.

The old method to retrieve resources and properties from platform data
is still supported.

Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

Get rid of users of of_platform_driver in drivers/serial.  The
of_platform_{,un}register_driver functions are going away, so the
users need to be converted to using the platform_bus_type directly.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>

of_platform_driver is getting removed, and a single platform_driver
can now support both devicetree and non-devicetree use cases.  This
patch merges the two driver registrations.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>

fmvj18x_cs:add new id
           Toshiba lan&modem multifuction card (model name:IPC5010A)

Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>

flush_scheduled_work() in tty_exit() doesn't seem to target any
specific work.  If it was to flush work items used in tty generic
layer, they're already flushed properly during tty release.

flush_scheduled_work() is going away.  Remove the seemingly redundant
usage.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

There is no need to test for a device_type property in ns8250
compatible serial ports.  device_type is an OpenFirmware property that
is not required when using the flattened tree representation.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Make Primecell driver probe functions take a const pointer to their
ID tables.  Drivers should never modify their ID tables in their
probe handler.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Currently, auto-flow control setting processing is not set correctly.
This patch fixes the issue.

Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Currently, uart clock is not set correctly.
This patch fixes the issue.

Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

For easy to understad which port the message is out,
replace pr_xxx with dev_xxx.

Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>