HID: remove x bit from sensor doc

Reported-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: usbhid: quirk for Formosa IR receiver

Patch to add the Formosa Industrial Computing, Inc. Infrared Receiver
[IR605A/Q] to hid-ids.h and hid-quirks.c.  This IR receiver causes about a 10
second timeout when the usbhid driver attempts to initialze the device.  Adding
this device to the quirks list with HID_QUIRK_NO_INIT_REPORTS removes the
delay.

Signed-off-by: Nicholas Santos <nicholas.santos@gmail.com>
[jkosina@suse.cz: fix ordering]
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
ASoC: fsl: fix multiple definition of init_module

With commit f2818d0 (ASoC: fsl: fix miscompilation of snd-soc-imx-pcm),
we will see the following build error when building modules with
CONFIG_SND_IMX_SOC=m in imx_v6_v7_defconfig.

  CC [M]  sound/soc/fsl/phycore-ac97.o
  LD [M]  sound/soc/fsl/snd-soc-fsl-ssi.o
  LD [M]  sound/soc/fsl/snd-soc-fsl-utils.o
  LD [M]  sound/soc/fsl/snd-soc-imx-ssi.o
  LD [M]  sound/soc/fsl/snd-soc-imx-audmux.o
  LD [M]  sound/soc/fsl/snd-soc-imx-pcm.o
sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
imx-pcm-dma.c:(.init.text+0x0): multiple definition of `init_module'
sound/soc/fsl/imx-pcm-fiq.o:imx-pcm-fiq.c:(.init.text+0x0): first defined here
sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
imx-pcm-dma.c:(.exit.text+0x0): multiple definition of `cleanup_module'
sound/soc/fsl/imx-pcm-fiq.o:imx-pcm-fiq.c:(.exit.text+0x0): first defined here
make[4]: *** [sound/soc/fsl/snd-soc-imx-pcm.o] Error 1

Instead of using bool for SND_SOC_IMX_PCM_FIQ and SND_SOC_IMX_PCM_DMA
to fix the original issue, we should completely remove SND_SOC_IMX_PCM
and have imx-pcm.o statically linked with imx-pcm-fiq.o or imx-pcm-dma.o.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
MIPS: vpe.c: Fix null pointer dereference in print arguments.

In the printk, the variable t euqals to NULL, so there is no t->index.
Use v->tc->index instead.

[ralf@linux-mips.org: Use opportunity of changing this line anyway to make
this line whitespacely correct.]

Signed-off-by: Cong Ding <dinggnu@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/4792/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: BCM47xx: Select GPIOLIB for BCMA on bcm47xx platform

The Kconfig items BCM47XX_BCMA and BCM47XX_SSB selected respectively
BCMA_DRIVER_GPIO and SSB_DRIVER_GPIO. These options depend on GPIOLIB
without explicitly selecting it so it results in a warning when GPIOLIB
is not set:

scripts/kconfig/conf --oldconfig Kconfig
warning: (BCM47XX_BCMA) selects BCMA_DRIVER_GPIO ... unmet direct
	dependencies (BCMA_POSSIBLE && BCMA && GPIOLIB)
warning: (BCM47XX_SSB) selects SSB_DRIVER_GPIO ... unmet direct
	dependencies (SSB_POSSIBLE && SSB && GPIOLIB)

which subsequently results in compile errors.

Signed-off-by: Arend van Spriel <arend@broadcom.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4759/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: BCM47xx: Enable SSB prerequisite SSB_DRIVER_PCICORE.

Split of from Arend's patch.

Signed-off-by: Arend van Spriel <arend@broadcom.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: linux-mips@linux-mips.org
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Patchwork: https://patchwork.linux-mips.org/patch/4759/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Export <asm/break.h>.

It always should have been ...

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Add struct p_format to union mips_instruction.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
efivarfs: Drop link count of the right inode

efivarfs_unlink() should drop the file's link count, not the directory's.

Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
efi, x86: Pass a proper identity mapping in efi_call_phys_prelog

Update efi_call_phys_prelog to install an identity mapping of all available
memory.  This corrects a bug on very large systems with more then 512 GB in
which bios would not be able to access addresses above not in the mapping.

The result is a crash that looks much like this.

BUG: unable to handle kernel paging request at 000000effd870020
IP: [<0000000078bce331>] 0x78bce330
PGD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU 0
Pid: 0, comm: swapper/0 Tainted: G        W    3.8.0-rc1-next-20121224-medusa_ntz+ #2 Intel Corp. Stoutland Platform
RIP: 0010:[<0000000078bce331>]  [<0000000078bce331>] 0x78bce330
RSP: 0000:ffffffff81601d28  EFLAGS: 00010006
RAX: 0000000078b80e18 RBX: 0000000000000004 RCX: 0000000000000004
RDX: 0000000078bcf958 RSI: 0000000000002400 RDI: 8000000000000000
RBP: 0000000078bcf760 R08: 000000effd870000 R09: 0000000000000000
R10: 0000000000000000 R11: 00000000000000c3 R12: 0000000000000030
R13: 000000effd870000 R14: 0000000000000000 R15: ffff88effd870000
FS:  0000000000000000(0000) GS:ffff88effe400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000effd870020 CR3: 000000000160c000 CR4: 00000000000006b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff81614400)
Stack:
 0000000078b80d18 0000000000000004 0000000078bced7b ffff880078b81fff
 0000000000000000 0000000000000082 0000000078bce3a8 0000000000002400
 0000000060000202 0000000078b80da0 0000000078bce45d ffffffff8107cb5a
Call Trace:
 [<ffffffff8107cb5a>] ? on_each_cpu+0x77/0x83
 [<ffffffff8102f4eb>] ? change_page_attr_set_clr+0x32f/0x3ed
 [<ffffffff81035946>] ? efi_call4+0x46/0x80
 [<ffffffff816c5abb>] ? efi_enter_virtual_mode+0x1f5/0x305
 [<ffffffff816aeb24>] ? start_kernel+0x34a/0x3d2
 [<ffffffff816ae5ed>] ? repair_env_string+0x60/0x60
 [<ffffffff816ae2be>] ? x86_64_start_reservations+0xba/0xc1
 [<ffffffff816ae120>] ? early_idt_handlers+0x120/0x120
 [<ffffffff816ae419>] ? x86_64_start_kernel+0x154/0x163
Code:  Bad RIP value.
RIP  [<0000000078bce331>] 0x78bce330
 RSP <ffffffff81601d28>
CR2: 000000effd870020
---[ end trace ead828934fef5eab ]---

Cc: stable@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Nathan Zimmer <nzimmer@sgi.com>
Signed-off-by: Robin Holt <holt@sgi.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
efivarfs: Never return ENOENT from firmware

Files are created in efivarfs_create() before a corresponding variable
is created in the firmware. This leads to users being able to
read/write to the file without the variable existing in the
firmware. Reading a non-existent variable currently returns -ENOENT,
which is confusing because the file obviously *does* exist.

Convert EFI_NOT_FOUND into -EIO which is the closest thing to "error
while interacting with firmware", and should hopefully indicate to the
caller that the variable is in some uninitialised state.

Cc: Josh Boyer <jwboyer@redhat.com>
Acked-by: Jeremy Kerr <jeremy.kerr@canonical.com>
Cc: Lee, Chun-Yi <jlee@suse.com>
Cc: Andy Whitcroft <apw@canonical.com>
Reported-by: Lingzhu Xiang <lxiang@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
efivarfs: Delete dentry from dcache in efivarfs_file_write()

Unlike the unlink path that is called from the VFS layer, we need to
call d_delete() ourselves when a variable is deleted in
efivarfs_file_write().

Failure to do so means we can access a stale struct efivar_entry when
reading/writing the file, which can result in the following oops,

  [   59.978216] general protection fault: 0000 [#1] SMP
  [   60.038660] CPU 9
  [   60.040501] Pid: 1001, comm: cat Not tainted 3.7.0-2.fc19.x86_64 #1 IBM System x3550 M3 -[7944I21]-/69Y4438
  [   60.050840] RIP: 0010:[<ffffffff810d5d1e>]  [<ffffffff810d5d1e>] __lock_acquire+0x5e/0x1bb0
  [   60.059198] RSP: 0018:ffff880270595ce8  EFLAGS: 00010046
  [   60.064500] RAX: 0000000000000046 RBX: 0000000000000002 RCX: 0000000000000000
  [   60.071617] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 6b6b6b6b6b6b6b83
  [   60.078735] RBP: ffff880270595dd8 R08: 0000000000000002 R09: 0000000000000000
  [   60.085852] R10: 6b6b6b6b6b6b6b83 R11: 0000000000000000 R12: 0000000000000000
  [   60.092971] R13: ffff88027170cd20 R14: 0000000000000000 R15: 0000000000000000
  [   60.100091] FS:  00007fc0c8ff3740(0000) GS:ffff880277000000(0000) knlGS:0000000000000000
  [   60.108164] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [   60.113899] CR2: 0000000001520000 CR3: 000000026d594000 CR4: 00000000000007e0
  [   60.121016] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  [   60.128135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  [   60.135254] Process cat (pid: 1001, threadinfo ffff880270594000, task ffff88027170cd20)
  [   60.143239] Stack:
  [   60.145251]  ffff880270595cf8 ffffffff81021da3 ffff880270595d08 ffffffff81021e19
  [   60.152714]  ffff880270595d38 ffffffff810acdb5 ffff880200000168 0000000000000086
  [   60.160175]  ffff88027170d5e8 ffffffff810d25ed ffff880270595d58 ffffffff810ace7f
  [   60.167638] Call Trace:
  [   60.170088]  [<ffffffff81021da3>] ? native_sched_clock+0x13/0x80
  [   60.176085]  [<ffffffff81021e19>] ? sched_clock+0x9/0x10
  [   60.181389]  [<ffffffff810acdb5>] ? sched_clock_cpu+0xc5/0x120
  [   60.187211]  [<ffffffff810d25ed>] ? trace_hardirqs_off+0xd/0x10
  [   60.193121]  [<ffffffff810ace7f>] ? local_clock+0x6f/0x80
  [   60.198513]  [<ffffffff810d2f6f>] ? lock_release_holdtime.part.26+0xf/0x180
  [   60.205465]  [<ffffffff810d7b57>] ? lock_release_non_nested+0x2e7/0x320
  [   60.212073]  [<ffffffff815638bb>] ? efivarfs_file_write+0x5b/0x280
  [   60.218242]  [<ffffffff810d7f41>] lock_acquire+0xa1/0x1f0
  [   60.223633]  [<ffffffff81563971>] ? efivarfs_file_write+0x111/0x280
  [   60.229892]  [<ffffffff8118b47c>] ? might_fault+0x5c/0xb0
  [   60.235287]  [<ffffffff816f1bf6>] _raw_spin_lock+0x46/0x80
  [   60.240762]  [<ffffffff81563971>] ? efivarfs_file_write+0x111/0x280
  [   60.247018]  [<ffffffff81563971>] efivarfs_file_write+0x111/0x280
  [   60.253103]  [<ffffffff811d307f>] vfs_write+0xaf/0x190
  [   60.258233]  [<ffffffff811d33d5>] sys_write+0x55/0xa0
  [   60.263278]  [<ffffffff816fbd19>] system_call_fastpath+0x16/0x1b
  [   60.269271] Code: 41 0f 45 d8 4c 89 75 f0 4c 89 7d f8 85 c0 0f 84 09 01 00 00 8b 05 a3 f9 ff 00 49 89 fa 41 89 f6 41 89 d3 85 c0 0f 84 12 01 00 00 <49> 8b 02 ba 01 00 00 00 48 3d a0 07 14 82 0f 44 da 41 83 fe 01
  [   60.289431] RIP  [<ffffffff810d5d1e>] __lock_acquire+0x5e/0x1bb0
  [   60.295444]  RSP <ffff880270595ce8>
  [   60.298928] ---[ end trace 1bbfd41a2cf6a0d8 ]---

Cc: Josh Boyer <jwboyer@redhat.com>
Acked-by: Jeremy Kerr <jeremy.kerr@canonical.com>
Cc: Lee, Chun-Yi <jlee@suse.com>
Cc: Andy Whitcroft <apw@canonical.com>
Reported-by: Lingzhu Xiang <lxiang@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
x86-32: Start out cr0 clean, disable paging before modifying cr3/4

Patch

  5a5a51db78e x86-32: Start out eflags and cr4 clean

... made x86-32 match x86-64 in that we initialize %eflags and %cr4
from scratch.  This broke OLPC XO-1.5, because the XO enters the
kernel with paging enabled, which the kernel doesn't expect.

Since we no longer support 386 (the source of most of the variability
in %cr0 configuration), we can simply match further x86-64 and
initialize %cr0 to a fixed value -- the one variable part remaining in
%cr0 is for FPU control, but all that is handled later on in
initialization; in particular, configuring %cr0 as if the FPU is
present until proven otherwise is correct and necessary for the probe
to work.

To deal with the XO case sanely, explicitly disable paging in %cr0
before we muck with %cr3, %cr4 or EFER -- those operations are
inherently unsafe with paging enabled.

NOTE: There is still a lot of 386-related junk in head_32.S which we
can and should get rid of, however, this is intended as a minimal fix
whereas the cleanup can be deferred to the next merge window.

Reported-by: Andres Salomon <dilinger@queued.net>
Tested-by: Daniel Drake <dsd@laptop.org>
Link: http://lkml.kernel.org/r/50FA0661.2060400@linux.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
ASoC: wm_adsp: Release firmware on error

This patch correctly releases the firmware if the magic string in the
firmware header does not match.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Merge remote-tracking branch 'asoc/fix/arizona' into tmp
Merge remote-tracking branch 'asoc/fix/core' into tmp
Merge remote-tracking branch 'asoc/fix/fsl' into tmp
Merge remote-tracking branch 'asoc/fix/lrg' into tmp
Merge remote-tracking branch 'asoc/fix/wm2200' into tmp
MIPS: PNX833x: Fix comment.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>