linux-stable.git, branch v3.4.17

Linux 3.4.17

2012-10-31T17:05:17+00:00

drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13

2012-10-31T17:03:19+00:00

commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364 upstream.

This box claims to have an LVDS interface but doesn't
actually have one.

Signed-off-by: Sjoerd Simons 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

x86, mm: Use memblock memory loop instead of e820_RAM

2012-10-31T17:03:19+00:00

commit 1f2ff682ac951ed82cc043cf140d2851084512df upstream.

We need to handle E820_RAM and E820_RESERVED_KERNEL at the same time.

Also memblock has page aligned range for ram, so we could avoid mapping
partial pages.

Signed-off-by: Yinghai Lu 
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: amplc_pc236: fix invalid register access during detach

2012-10-31T17:03:19+00:00

commit aaeb61a97b7159ebe30b18a422d04eeabfa8790b upstream.

`pc236_detach()` is called by the comedi core if it attempted to attach
a device and failed.  `pc236_detach()` calls `pc236_intr_disable()` if
the comedi device private data pointer (`devpriv`) is non-null.  This
test is insufficient as `pc236_intr_disable()` accesses hardware
registers and the attach routine may have failed before it has saved
their I/O base addresses.

Fix it by checking `dev->iobase` is non-zero before calling
`pc236_intr_disable()` as that means the I/O base addresses have been
saved and the hardware registers can be accessed.  It also implies the
comedi device private data pointer is valid, so there is no need to
check it.

Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

x86: efi: Turn off efi_enabled after setup on mixed fw/kernel

2012-10-31T17:03:19+00:00

commit 5189c2a7c7769ee9d037d76c1a7b8550ccf3481c upstream.

When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off
efi_enabled once setup is done. Beyond setup, it is normally used to
determine if runtime services are available and we will have none.

This will resolve issues stemming from efivars modprobe panicking on a
32/64-bit setup, as well as some reboot issues on similar setups.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45991

Reported-by: Marko Kohtala 
Reported-by: Maxim Kammerer 
Signed-off-by: Olof Johansson 
Acked-by: Maarten Lankhorst 
Cc: Matthew Garrett 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

efi: Defer freeing boot services memory until after ACPI init

2012-10-31T17:03:18+00:00

commit 785107923a83d8456bbd8564e288a24d84109a46 upstream.

Some new ACPI 5.0 tables reference resources stored in boot services
memory, so keep that memory around until we have ACPI and can extract
data from it.

Signed-off-by: Josh Triplett 
Link: http://lkml.kernel.org/r/baaa6d44bdc4eb0c58e5d1b4ccd2c729f854ac55.1348876882.git.josh@joshtriplett.org
Signed-off-by: H. Peter Anvin 
Cc: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

x86, mm: Undo incorrect revert in arch/x86/mm/init.c

2012-10-31T17:03:18+00:00

commit f82f64dd9f485e13f29f369772d4a0e868e5633a upstream.

Commit

    844ab6f9 x86, mm: Find_early_table_space based on ranges that are actually being mapped

added back some lines back wrongly that has been removed in commit

    7b16bbf97 Revert "x86/mm: Fix the size calculation of mapping tables"

remove them again.

Signed-off-by: Yinghai Lu 
Link: http://lkml.kernel.org/r/CAE9FiQW_vuaYQbmagVnxT2DGsYc=9tNeAbdBq53sYkitPOwxSQ@mail.gmail.com
Acked-by: Jacob Shin 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, mm: Find_early_table_space based on ranges that are actually being mapped

2012-10-31T17:03:11+00:00

commit 844ab6f993b1d32eb40512503d35ff6ad0c57030 upstream.

Current logic finds enough space for direct mapping page tables from 0
to end. Instead, we only need to find enough space to cover mr[0].start
to mr[nr_range].end -- the range that is actually being mapped by
init_memory_mapping()

This is needed after 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a, to address
the panic reported here:

  https://lkml.org/lkml/2012/10/20/160
  https://lkml.org/lkml/2012/10/21/157

Signed-off-by: Jacob Shin 
Link: http://lkml.kernel.org/r/20121024195311.GB11779@jshin-Toonie
Tested-by: Tom Rini 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

Revert "ath9k_hw: Updated AR9003 tx gain table for 5GHz"

2012-10-31T17:03:03+00:00

commit 73b26df5fa1a6245d6fc982362518b620bc7c2fe upstream.

This reverts commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd.

This commit is reducing tx power by at least 10 db on some devices,
e.g. the Buffalo WZR-HP-G450H.

Signed-off-by: Felix Fietkau 
Cc: rmanohar@qca.qualcomm.com
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cpufreq / powernow-k8: Remove usage of smp_processor_id() in preemptible code

2012-10-31T17:03:03+00:00

commit e4df1cbcc1f329e53a1fff7450b2229e0addff20 upstream.

Commit 6889125b8b4e09c5e53e6ecab3433bed1ce198c9
(cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU)
causes powernow-k8 to trigger a preempt warning, e.g.:

  BUG: using smp_processor_id() in preemptible [00000000] code: cpufreq/3776
  caller is powernowk8_target+0x20/0x49
  Pid: 3776, comm: cpufreq Not tainted 3.6.0 #9
  Call Trace:
   [] debug_smp_processor_id+0xc7/0xe0
   [] powernowk8_target+0x20/0x49
   [] __cpufreq_driver_target+0x82/0x8a
   [] cpufreq_governor_performance+0x4e/0x54
   [] __cpufreq_governor+0x8c/0xc9
   [] __cpufreq_set_policy+0x1a9/0x21e
   [] store_scaling_governor+0x16f/0x19b
   [] ? cpufreq_update_policy+0x124/0x124
   [] ? _raw_spin_unlock_irqrestore+0x2c/0x49
   [] store+0x60/0x88
   [] sysfs_write_file+0xf4/0x130
   [] vfs_write+0xb5/0x151
   [] sys_write+0x4a/0x71
   [] system_call_fastpath+0x16/0x1b

Fix this by by always using work_on_cpu().

Signed-off-by: Andreas Herrmann 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman