HID: roccat: fix modules interdependencies

hid-roccat-kone calls the hid-roccat module interfaces,
so the former should depend on or select the latter to prevent
build errors, like:

hid-roccat-kone.c:(.text+0x133ed2): undefined reference to `roccat_report_event'
hid-roccat-kone.c:(.text+0x133fa8): undefined reference to `roccat_disconnect'
hid-roccat-kone.c:(.text+0x1353be): undefined reference to `roccat_connect'

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Revert "drm/i915: Don't enable pipe/plane/VCO early (wait for DPMS on)."

This reverts commit cfecde435dda78248d6fcdc424bed68d5db6be0b.

The commit was first created as an attempt to fix LVDS initialiazation
on Ironlake. Testing revealed that it didn't fix that, but it was
assumed to still be correct anyway.

Subsequent testing has revealed that this commit has caused other
regressions:

  * Change in VBlank interrupt frequency causing 60% 3D performance regression
    http://bugs.freedesktop.org/show_bug.cgi?id=27698

  * Black screen on G45
    http://bugs.freedesktop.org/show_bug.cgi?id=27733

So revert this buggy code for now to revisit later when we can fix
actual bugs without causing these regressions.

Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
drm/i915: Move non-phys cursors into the GTT

Cursors need to be in the GTT domain when being accessed by the GPU.
Previously this was a fortuitous byproduct of userspace using pwrite()
to upload the image data into the cursor. The redundant clflush was
removed in commit 9b8c4a and so the image was no longer being flushed
out of the caches into main memory. One could also devise a scenario
where the cursor was rendered by the GPU, prior to being attached as the
cursor, resulting in similar corruption due to the missing MI_FLUSH.

Fixes:

  Bug 28335 - Cursor corruption caused by commit 9b8c4a0b21
  https://bugs.freedesktop.org/show_bug.cgi?id=28335

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Eric Anholt <eric@anholt.net>
HID: check for HID_QUIRK_IGNORE during probing

While the hardcoded ignore list is checked in hid_add_device(), the
user supplied ignore flags are not. Thus, the IGNORE quirk (0x0004)
cannot be used to stop usbhid from binding devices like iBuddy, which
has been recently removed from the ignore list due to product ID
conflict.

This patch adds the user quirk check to hid_add_device(), and makes
hid_add_device() return -ENODEV when HID_QUIRK_IGNORE bit is set.

HID_QUIRK_NO_IGNORE still takes precedence over HID_QUIRK_IGNORE.

With the patch, iBuddy works properly using libusb when the following
option is added to modprobe.d:

options usbhid quirks=0x1130:0x0002:0x0004

Signed-off-by: Jindrich Makovicka <makovick@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
drm/i915: Use RSEN instead of HTPLG for tfp410 monitor detection.

Presence detection of a digital monitor seems not to be reliable using
the HTPLG bit.

Dave Müller <dave.mueller@gmx.ch>
drm/i915/gen4: Fix interrupt setup ordering

Unmask, then enable interrupts, then enable interrupt sources; matches
PCH ordering.  The old way (sources, enable, unmask) gives a window
during which interrupt conditions would appear in ISR but would never
reach IIR and thus never raise an IRQ.  Since interrupts only trigger
on rising edges in ISR, this would lead to conditions where (for
example) output hotplugging would never fire an interrupt because it
was already stuck on in ISR.

Also, since we know IIR and PIPExSTAT have been cleared during
irq_preinstall, don't clear them again during irq_postinstall, nothing
good can come of that.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Input: pcf8574_keypad - fix off by one in pcf8574_kp_irq_handler()

If nextstate == ARRAY_SIZE(lp->btncode), then we read one past the end of
the array on the next line.

This fixes a smatch warning:
drivers/input/misc/pcf8574_keypad.c +74 pcf8574_kp_irq_handler(8)
	error: buffer overflow 'lp->btncode' 17 <= 17

Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
sh: remove duplicated #include

Remove duplicated #include('s) in
  arch/sh/boards/mach-ecovec24/setup.c

Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
sh: Fix up IORESOURCE_PCI_FIXED usage in pcibios_fixup_device_resources().

pcibios_fixup_device_resources() presently skips over resources flagged
with IORESOURCE_PCI_FIXED, which is a remnant of the old PCI-auto code.
The only user for this at present is the Dreamast GAPSPCI code which
can't tolerate any adjustments to the BARs, but a combination of the
IORESOURCE_PCI_FIXED and zeroed out hose offsets does the right thing for
this case already, so we simply kill off the special casing.

Reported-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
x86: use __ASSEMBLY__ rather than __ASSEMBLER__

As Ingo pointed out in a separate patch, we should be using __ASSEMBLY__.
Make that the case in pgtable headers.

Signed-off-by: Andres Salomon <dilinger@queued.net>
LKML-Reference: <20100605114042.35ac69c1@dev.queued.net>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Input: ad7877 - fix spi word size to 16 bit

With no word size given in the users platform data, a generic spi host
controller driver will assume a default word size of eight bit. This
causes transmission to be performed bytewise, which will fail on little
endian machines for sure. Failure on big endian depends on usage
of slave select to mark word boundaries.

Anyway, ad7877 is specified to work with 16 bit per word, so
unconditionally set the word size accordingly. Flag an error where 16
bit per word is not available.

Signed-off-by: Oskar Schirmer <os@emlix.com>
Signed-off-by: Daniel Glöckner <dg@emlix.com>
Signed-off-by: Oliver Schneidewind <osw@emlix.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
sched: Fix PROVE_RCU vs cpu_cgroup

PROVE_RCU has a few issues with the cpu_cgroup because the scheduler
typically holds rq->lock around the css rcu derefs but the generic
cgroup code doesn't (and can't) know about that lock.

Provide means to add extra checks to the css dereference and use that
in the scheduler to annotate its users.

The addition of rq->lock to these checks is correct because the
cgroup_subsys::attach() method takes the rq->lock for each task it
moves, therefore by holding that lock, we ensure the task is pinned to
the current cgroup and the RCU derefence is valid.

That leaves one genuine race in __sched_setscheduler() where we used
task_group() without holding any of the required locks and thus raced
with the cgroup code. Solve this by moving the check under the
appropriate lock.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
omap iommu: Fix Memory leak

The memory allocated for sgt structure is not freed on error
when sg_alloc_table is called in sgtable_alloc().

Signed-off-by: Satish Kumar <x0124230@ti.com>
Signed-off-by: Manjunatha GK <manjugk@ti.com>
Cc: Vimal Singh <vimal.newwork@gmail.com>
Signed-off-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: Tony Lindgen <tony@atomide.com>
omap: fix build failure due to missing include dma-mapping.h

Fixes following error,

CC      arch/arm/mach-omap2/usb-ehci.o
arch/arm/mach-omap2/usb-ehci.c:263: error: implicit declaration of function
'DMA_BIT_MASK'
arch/arm/mach-omap2/usb-ehci.c:263: error: initializer element is not constant
make[1]: *** [arch/arm/mach-omap2/usb-ehci.o] Error 1

Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
omap: Stalker board: switch over to gpio_set_debounce

Commit 48feb337475a arm: omap: switch over to gpio_set_debounce caused
"undefined reference to omap_set_gpio_debounce" build error.

The fix is to use the generic gpiolib function.

Cc: Felipe Balbi <felipe.balbi@nokia.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ipvs: Add missing locking during connection table hashing and unhashing

The code that hashes and unhashes connections from the connection table
is missing locking of the connection being modified, which opens up a
race condition and results in memory corruption when this race condition
is hit.

Here is what happens in pretty verbose form:

CPU 0					CPU 1
------------				------------
An active connection is terminated and
we schedule ip_vs_conn_expire() on this
CPU to expire this connection.

					IRQ assignment is changed to this CPU,
					but the expire timer stays scheduled on
					the other CPU.

					New connection from same ip:port comes
					in right before the timer expires, we
					find the inactive connection in our
					connection table and get a reference to
					it. We proper lock the connection in
					tcp_state_transition() and read the
					connection flags in set_tcp_state().

ip_vs_conn_expire() gets called, we
unhash the connection from our
connection table and remove the hashed
flag in ip_vs_conn_unhash(), without
proper locking!

					While still holding proper locks we
					write the connection flags in
					set_tcp_state() and this sets the hashed
					flag again.

ip_vs_conn_expire() fails to expire the
connection, because the other CPU has
incremented the reference count. We try
to re-insert the connection into our
connection table, but this fails in
ip_vs_conn_hash(), because the hashed
flag has been set by the other CPU. We
re-schedule execution of
ip_vs_conn_expire(). Now this connection
has the hashed flag set, but isn't
actually hashed in our connection table
and has a dangling list_head.

					We drop the reference we held on the
					connection and schedule the expire timer
					for timeouting the connection on this
					CPU. Further packets won't be able to
					find this connection in our connection
					table.

					ip_vs_conn_expire() gets called again,
					we think it's already hashed, but the
					list_head is dangling and while removing
					the connection from our connection table
					we write to the memory location where
					this list_head points to.

The result will probably be a kernel oops at some other point in time.

This race condition is pretty subtle, but it can be triggered remotely.
It needs the IRQ assignment change or another circumstance where packets
coming from the same ip:port for the same service are being processed on
different CPUs. And it involves hitting the exact time at which
ip_vs_conn_expire() gets called. It can be avoided by making sure that
all packets from one connection are always processed on the same CPU and
can be made harder to exploit by changing the connection timeouts to
some custom values.

Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
Cc: stable@kernel.org
Acked-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Patrick McHardy <kaber@trash.net>
genirq: Deal with desc->set_type() changing desc->chip

The set_type() function can change the chip implementation when the
trigger mode changes. That might result in using an non-initialized
irq chip when called from __setup_irq() or when called via
set_irq_type() on an already enabled irq. 

The set_irq_type() function should not be called on an enabled irq,
but because we forgot to put a check into it, we have a bunch of users
which grew the habit of doing that and it never blew up as the
function is serialized via desc->lock against all users of desc->chip
and they never hit the non-initialized irq chip issue.

The easy fix for the __setup_irq() issue would be to move the
irq_chip_set_defaults(desc->chip) call after the trigger setting to
make sure that a chip change is covered.

But as we have already users, which do the type setting after
request_irq(), the safe fix for now is to call irq_chip_set_defaults()
from __irq_set_trigger() when desc->set_type() changed the irq chip.

It needs a deeper analysis whether we should refuse to change the chip
on an already enabled irq, but that'd be a large scale change to fix
all the existing users. So that's neither stable nor 2.6.35 material.

Reported-by: Esben Haabendal <eha@doredevelopment.dk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Cc: stable@kernel.org
Input: sysrq - fix "stuck" SysRq mode

This shoud fix the problem with SysRq mode staying half-way enabled
and interfereing with normal PrtScrn operation after user presses ALT
for the first time.

Reported-and-tested-by: Éric Piel <E.A.B.Piel@tudelft.nl>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
x86, irq: Rename gsi_end gsi_top, and fix off by one errors

When I introduced the global variable gsi_end I thought gsi_end on
io_apics was one past the end of the gsi range for the io_apic.  After
it was pointed out the the range on io_apics was inclusive I changed
my global variable to match.  That was a big mistake.  Inclusive
semantics without a range start cannot describe the case when no gsi's
are allocated.  Describing the case where no gsi's are allocated is
important in sfi.c and mpparse.c so that we can assign gsi numbers
instead of blindly copying the gsi assignments the BIOS has done as we
do in the acpi case.

To keep from getting the global variable confused with the gsi range
end rename it gsi_top.

To allow describing the case where no gsi's are allocated have gsi_top
be one place the highest gsi number seen in the system.

This fixes an off by one bug in sfi.c:
Reported-by: jacob pan <jacob.jun.pan@linux.intel.com>

This fixes the same off by one bug in mpparse.c:

This fixes an off unreachable by one bug in acpi/boot.c:irq_to_gsi
Reported-by: Yinghai <yinghai.lu@oracle.com>

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
LKML-Reference: <m17hm9jre7.fsf_-_@fess.ebiederm.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
ARM: reduce defconfigs

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>