user/sven/linux.git, branch v3.4.48

Linux 3.4.48

2013-06-07T19:50:29Z

thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR

2013-06-07T19:49:49Z

commit a4f46bb9fa84642e356898ee44b670989622f8bb upstream. In the latest V-series bios DMI_PRODUCT_VERSION does not contain the string Lenovo or Thinkpad, but is set to the model number, this causes the thinkpad_acpi module to fail to load. Recognize laptop as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo. Test on V490u ============= == After the patch == [ 1350.295757] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [ 1350.295760] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 1350.295761] thinkpad_acpi: ThinkPad BIOS H7ET21WW (1.00 ), EC unknown [ 1350.295763] thinkpad_acpi: Lenovo LENOVO, model LV5DXXX [ 1350.296086] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [ 1350.296694] thinkpad_acpi: radio switch found; radios are enabled [ 1350.296703] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode [ 1350.306466] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 1350.307082] Registered led device: tpacpi::thinklight [ 1350.307215] Registered led device: tpacpi::power [ 1350.307255] Registered led device: tpacpi::standby [ 1350.307294] Registered led device: tpacpi::thinkvantage [ 1350.308160] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [ 1350.308333] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [ 1350.312287] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input14 == Before the patch == sudo modprobe thinkpad_acpi FATAL: Error inserting thinkpad_acpi (/lib/modules/3.2.0-27-generic/kernel/drivers/platform/x86/thinkpad_acpi.ko): No such device Test on B485 ============= This patch was also test in a B485 where the thinkpad_acpi module does not have any issues loading. But, I tested it to make sure this patch does not break on already functioning models of Lenovo products. [13486.746359] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [13486.746364] thinkpad_acpi: http://ibm-acpi.sf.net/ [13486.746368] thinkpad_acpi: ThinkPad BIOS HJET15WW(1.01), EC unknown [13486.746373] thinkpad_acpi: Lenovo Lenovo LB485, model 814TR01 [13486.747300] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [13486.752435] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [13486.752883] Registered led device: tpacpi::thinklight [13486.752915] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [13486.753216] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [13486.757147] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input15 Signed-off-by: Manoj Iyer Signed-off-by: Matthew Garrett Cc: Shuduo Sang Signed-off-by: Greg Kroah-Hartman

mac80211: close AP_VLAN interfaces before unregistering all

2013-06-07T19:49:49Z

commit c8aa22db0112f640ac6631347f850879c621840b upstream. Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces") there's a bug in mac80211 when it unregisters with AP_VLAN interfaces up. If the AP_VLAN interface was registered after the AP it belongs to (which is the typical case) and then we get into this code path, unregister_netdevice_many() will crash because it isn't prepared to deal with interfaces being closed in the middle of it. Exactly this happens though, because we iterate the list, find the AP master this AP_VLAN belongs to and dev_close() the dependent VLANs. After this, unregister_netdevice_many() won't pick up the fact that the AP_VLAN is already down and will do it again, causing a crash. Signed-off-by: Johannes Berg Cc: Eric Dumazet Signed-off-by: Greg Kroah-Hartman

x86, um: Correct syscall table type attributes breaking gcc 4.8

2013-06-07T19:49:48Z

commit 9271b0b4b2044c6db06051fe60bc58cdd4f17c7c upstream. The latest GCC 4.8 does some more checking on type attributes that break the build for ARCH=um -> fill them in. Specifically, the "asmlinkage" attributes is now tested for consistency. Signed-off-by: Martin Pelikan Link: http://lkml.kernel.org/r/1339269731-10772-1-git-send-email-pelikan@storkhole.cz Acked-by: Richard Weinberger Signed-off-by: H. Peter Anvin Cc: Bernhard M. Wiedemann Signed-off-by: Greg Kroah-Hartman

iommu/amd: Workaround for ERBT1312

2013-06-07T19:49:48Z

commit d3263bc29706e42f74d8800807c2dedf320d77f1 upstream. Work around an IOMMU hardware bug where clearing the EVT_INT or PPR_INT bit in the status register may race with the hardware trying to set it again. When not handled the bit might not be cleared and we lose all future event or ppr interrupts. Reported-by: Suravee Suthikulpanit Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman

iommu/amd: Re-enable IOMMU event log interrupt after handling.

2013-06-07T19:49:35Z

commit 925fe08bce38d1ff052fe2209b9e2b8d5fbb7f98 upstream. Current driver does not clear the IOMMU event log interrupt bit in the IOMMU status register after processing an interrupt. This causes the IOMMU hardware to generate event log interrupt only once. This has been observed in both IOMMU v1 and V2 hardware. This patch clears the bit by writing 1 to bit 1 of the IOMMU status register (MMIO Offset 2020h) Signed-off-by: Suravee Suthikulpanit Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman

xen-netback: remove skb in xen_netbk_alloc_page

2013-06-07T19:49:35Z

commit 27f852282ab9a028f57da96d05c26f38c424a315 upstream. This variable is never used. Signed-off-by: Wei Liu Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

jfs: fix a couple races

2013-06-07T19:49:34Z

commit 73aaa22d5ffb2630456bac2f9a4ed9b81d0d7271 upstream. This patch fixes races uncovered by xfstests testcase 068. One race is the result of jfs_sync() trying to write a sync point to the journal after it has been frozen (or possibly in the process). Since freezing sync's the journal, there is no need to write a sync point so we simply want to return. The second involves jfs_write_inode() being called on a deleted inode. It calls jfs_flush_journal which is held up by the jfs_commit thread doing the final iput on the same deleted inode, which itself is waiting for the I_SYNC flag to be cleared. jfs_write_inode need not do anything when i_nlink is zero, which is the easy fix. Reported-by: Michael L. Semon Signed-off-by: Dave Kleikamp Signed-off-by: Greg Kroah-Hartman

xen/events: Handle VIRQ_TIMER before any other hardirq in event loop.

2013-06-07T19:49:34Z

commit bee980d9e9642e96351fa3ca9077b853ecf62f57 upstream. This avoids any other hardirq handler seeing a very stale jiffies value immediately after wakeup from a long idle period. The one observable symptom of this was a USB keyboard, with software keyboard repeat, which would always repeat a key immediately that it was pressed. This is due to the key press waking the guest, the key handler immediately runs, sees an old jiffies value, and then that jiffies value significantly updated, before the key is unpressed. Reviewed-by: David Vrabel Signed-off-by: Keir Fraser Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

m68k/mac: Fix unexpected interrupt with CONFIG_EARLY_PRINTK

2013-06-07T19:49:34Z

commit df66834a43c461de2565c45d815288ba1c0def37 upstream. The present code does not wait for the SCC to finish resetting itself before trying to initialise the device. The result is that the SCC interrupt sources become enabled (if they weren't already). This leads to an early boot crash (unexpected interrupt) given CONFIG_EARLY_PRINTK. Fix this by adding a delay. A successful reset disables the interrupt sources. Also, after the reset for channel A setup, the SCC then gets a second reset for channel B setup which leaves channel A uninitialised again. Fix this by performing the reset only once. Signed-off-by: Finn Thain Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman