serial: sh-sci: Kill off all of the SCI/SCIF special casing.

This was added at a time when the compiler did a less than stellar job of
optimizing out dead code. These days this tends to be less of a concern,
so kill it all off.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Input: i8042 - add Blue FB5601 to noloop exception table

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Input: psmouse - add support for Elantech touchpads

This is version 5 of the driver. Relative mode support has been
dropped (users wishing to use touchpad in relative mode can use
standard PS/2 protocol emulation done in hardware). The driver
supports both original version of Elantech protocol and the newer
one used by touchpads installed in EeePC.

Signed-off-by: Arjan Opmeer <arjan@opmeer.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Revert "HID: Invert HWHEEL mappings for some Logitech mice"

This reverts commit 740f370dc61dc478d891d7d47660bb3ae39ddb4f.

It turned out to be correct in the first place: a positive value should
be sent when the wheel is moved to the right, and a negative value when
moved to the left. This is the behavior expected by the Xorg evdev
driver. I must have had a remapping somewhere else in my system when
originally testing this. Testing on another system shows that the
unpatched kernel is correct.

Here is a bug report from Mandriva that brought the problem to my
attention:

    https://qa.mandriva.com/show_bug.cgi?id=44309#c19

Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: add support for another Gyration remote control

There is a slightly different Gyration remote control, which
requires the quirks we already have in place for the 0x0002 PID,
plus KEY_MEDIA mapping is different.

Reported-by: Marc Randolph <mrand@pobox.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: fix hidraw_exit section mismatch

hidraw_exit() marked as __exit is called from __init function
from HID core. Remove the section placement from that function.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
pcmcia: IRQ_TYPE_EXCLUSIVE is long obsoleted

Switch more drivers to dynamic sharing after checking their IRQ handlers
use dev_id and are robust

Signed-off-by: Alan Cox <alan@redhat.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
pcmcia: Whine harder about use of EXCLUSIVE

The exclusive IRQ line support is a legacy and any remaining drivers that
cannot share interrupts need tidying up so whine harder about them.

Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
fdomain_cs: Sort out modules with duplicate description

The PCMCIA one provides its own description so in PCMCIA mode we should use
that.

Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Merge branch 'linus' into tracing-v28-for-linus-v3

Conflicts:
	init/main.c
	kernel/module.c
	scripts/bootgraph.pl
HID: Remove "default m" for Thrustmaster and Zeroplus

No reason at all to make these obscure drivers default m

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: quirk for OLED devices present in ASUS G50/G70/G71

The new revision of OLED device (0x0b05/0x175b) found in ASUS G50/G70/G71
should be ignored the same way we currently do for 0x1726, so that asus_oled
driver can make use of the device.

Reported-by: Costin Grigoras <costin.grigoras@cern.ch>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
ftrace: do not enclose logic in WARN_ON

In ftrace, logic is defined in the WARN_ON_ONCE, which can become a
nop with some configs. This patch fixes it.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
ftrace: release functions from hash

The x86 architecture uses a static recording of mcount caller locations
and is not affected by this patch.

For architectures still using the dynamic ftrace daemon, this patch is
critical. It removes the race between the recording of a function that
calls mcount, the unloading of a module, and the ftrace daemon updating
the call sites.

This patch adds the releasing of the hash functions that the daemon uses
to update the mcount call sites. When a module is unloaded, not only
are the replaced call site table update, but now so is the hash recorded
functions that the ftrace daemon will use.

Again, architectures that implement MCOUNT_RECORD are not affected by
this (which currently only x86 has).

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
ftrace: fix depends

A lot of tracers have HAVE_FTRACE as a dependent config where it
really should not. The HAVE_FTRACE is a misnomer (soon to be fixed)
and describes if the architecture has the function tracer (mcount)
implemented. The ftrace infrastructure is implemented in all archs.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
ftrace: rename FTRACE to FUNCTION_TRACER

Due to confusion between the ftrace infrastructure and the gcc profiling
tracer "ftrace", this patch renames the config options from FTRACE to
FUNCTION_TRACER.  The other two names that are offspring from FTRACE
DYNAMIC_FTRACE and FTRACE_MCOUNT_RECORD will stay the same.

This patch was generated mostly by script, and partially by hand.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
ftrace: rename the ftrace tracer to function

To avoid further confusion between the ftrace infrastructure and the
function tracer. This patch renames the "ftrace" function tracer
to "function".

Now in available_tracers, instead of "ftrace" there will be "function".

This makes more sense, since people will not know exactly what the
"ftrace" tracer does.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
ftrace: stack tracer only record when on stack

The stack trace API does not record if the stack is not on the current
task's stack. That is, if the stack is the interrupt stack or NMI stack,
the output does not show. Also, the size of those stacks are not
consistent with the size of the thread stack, this makes the calculation
of the stack size usually bogus.

This all confuses the stack tracer. I unfortunately do not have time to
fix all these problems, but this patch does record the worst stack when
the stack pointer is on the tasks stack (instead of bogus numbers).

The patch simply returns if the stack pointer is not on the task's stack.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
md: use sysfs_notify_dirent to notify changes to md/array_state

Now that we have sysfs_notify_dirent, use it to notify changes
to md/array_state.
As sysfs_notify_dirent can be called in atomic context, we can
remove the delayed notify and the MD_NOTIFY_ARRAY_STATE flag.

Signed-off-by: NeilBrown <neilb@suse.de>
md: use sysfs_notify_dirent to notify changes to md/dev-xxx/state

The 'state' file for a device reports, for example, when the device
has failed.  Changes should be reported to userspace ASAP without
the possibility of blocking on low-memory.  sysfs_notify does
have that possibility (as it takes a mutex which can be held
across a kmalloc) so use sysfs_notify_dirent instead.

Signed-off-by: NeilBrown <neilb@suse.de>