3.4.24-stable review
Subsystems (29)
Greg Kroah-Hartman
maintainercover 3.4.24-stable review
This is the start of the stable review cycle for the 3.4.24 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 16 22:16:59 UTC 2012. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.24-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.4.24-rc1
Eric Dumazet <[email protected]>
rcu: Fix batch-limit size problem
Zheng Liu <[email protected]>
perf test: fix a build error on builtin-test
Dan Williams <[email protected]>
cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)
Dan Carpenter <[email protected]>
ftrace: Clear bits properly in reset_iter_read()
Sarah Sharp <[email protected]>
xhci: Extend Fresco Logic MSI quirk.
Alan Stern <[email protected]>
USB: OHCI: workaround for hardware bug: retired TDs not added to the Done Queue
Zhang Rui <[email protected]>
ACPI / video: ignore BIOS initial backlight value for HP Folio 13-2000
Rafael J. Wysocki <[email protected]>
ACPI / PNP: Do not crash due to stale pointer use during system resume
Lan Tianyu <[email protected]>
ACPI / PM: Add Sony Vaio VPCEB1S1E to nonvs blacklist.
Kamil Iskra <[email protected]>
ACPI / battery: Correct battery capacity values on Thinkpads
Greg Kroah-Hartman <[email protected]>
USB: mark uas driver as BROKEN
Markus Becker <[email protected]>
USB: cp210x: add Virtenio Preon32 device id
Peter Korsgaard <[email protected]>
usb: ftdi_sio: fixup BeagleBone A5+ quirk
Martin Teichmann <[email protected]>
USB: ftdi_sio: Add support for Newport AGILIS motor drivers
Bjørn Mork <[email protected]>
USB: option: blacklist network interface on Huawei E173
[email protected] <[email protected]>
USB: add new zte 3g-dongle's pid to option.c
Jan Beulich <[email protected]>
x86: hpet: Fix masking of MSI interrupts
Dan Carpenter <[email protected]>
telephony: ijx: buffer overflow in ixj_write_cid()
Boris Ostrovsky <[email protected]>
x86,AMD: Power driver support for AMD's family 16h processors
Marek Szyprowski <[email protected]>
mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
Jani Nikula <[email protected]>
drm/i915: do not default to 18 bpp for eDP if missing from VBT
Jani Nikula <[email protected]>
drm/i915: do not ignore eDP bpc settings from vbt
Tejun Heo <[email protected]>
workqueue: convert BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s
Peter Ujfalusi <[email protected]>
ASoC: dmaengine: Correct Makefile when sound is built as module
Paul Walmsley <[email protected]>
ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
Guennadi Liakhovetski <[email protected]>
mmc: sh-mmcif: avoid oops on spurious interrupts (second try)
Chris Ball <[email protected]>
Revert misapplied "mmc: sh-mmcif: avoid oops on spurious interrupts"
Mel Gorman <[email protected]>
tmpfs: fix shared mempolicy leak
-------------
Diffstat:
Makefile | 4 +- arch/arm/include/asm/hwcap.h | 3 +- arch/arm/include/asm/vfpmacros.h | 12 +++--- arch/arm/vfp/vfpmodule.c | 9 +++-- arch/x86/kernel/hpet.c | 4 +- drivers/acpi/battery.c | 77 ++++++++++++++++++++++++++++++++++++ drivers/acpi/sleep.c | 8 ++++ drivers/acpi/video.c | 14 +++++++ drivers/gpu/drm/i915/intel_bios.c | 11 +----- drivers/gpu/drm/i915/intel_display.c | 11 ++++++ drivers/hwmon/fam15h_power.c | 4 ++ drivers/mmc/host/sh_mmcif.c | 8 +--- drivers/pnp/pnpacpi/core.c | 3 ++ drivers/staging/telephony/ixj.c | 24 +++++------ drivers/usb/class/cdc-acm.c | 38 ++++++++++++++++++ drivers/usb/host/ohci-q.c | 19 +++++++++ drivers/usb/host/xhci-pci.c | 7 +++- drivers/usb/serial/cp210x.c | 1 + drivers/usb/serial/ftdi_sio.c | 3 +- drivers/usb/serial/ftdi_sio_ids.h | 6 +++ drivers/usb/serial/option.c | 25 ++++++++++++ drivers/usb/storage/Kconfig | 2 +- include/linux/mempolicy.h | 16 -------- kernel/rcutree.c | 14 +++---- kernel/trace/ftrace.c | 2 +- kernel/workqueue.c | 4 +- mm/dmapool.c | 31 ++++----------- mm/mempolicy.c | 22 ----------- mm/shmem.c | 26 +++++++----- sound/soc/Makefile | 5 ++- tools/perf/builtin-test.c | 38 ++++++------------ 31 files changed, 296 insertions(+), 155 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/28 tmpfs: fix shared mempolicy leak
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mel Gorman <[email protected]>
commit 18a2f371f5edf41810f6469cb9be39931ef9deb9 upstream.
This fixes a regression in 3.7-rc, which has since gone into stable.
Commit 00442ad04a5e ("mempolicy: fix a memory corruption by refcount imbalance in alloc_pages_vma()") changed get_vma_policy() to raise the refcount on a shmem shared mempolicy; whereas shmem_alloc_page() went on expecting alloc_page_vma() to drop the refcount it had acquired. This deserves a rework: but for now fix the leak in shmem_alloc_page().
Hugh: shmem_swapin() did not need a fix, but surely it's clearer to use the same refcounting there as in shmem_alloc_page(), delete its onstack mempolicy, and the strange mpol_cond_copy() and __mpol_cond_copy() - those were invented to let swapin_readahead() make an unknown number of calls to alloc_pages_vma() with one mempolicy; but since 00442ad04a5e, alloc_pages_vma() has kept refcount in balance, so now no problem.
--- include/linux/mempolicy.h | 16 ---------------- mm/mempolicy.c | 22 ---------------------- mm/shmem.c | 26 ++++++++++++++++---------- 3 files changed, 16 insertions(+), 48 deletions(-)
include/linux/mempolicy.h +0 -16
@@ -137,16 +137,6 @@ static inline void mpol_cond_put(struct__mpol_put (pol); } -extern struct mempolicy *__mpol_cond_copy (struct mempolicy *tompol, -struct mempolicy *frompol); -static inline struct mempolicy *mpol_cond_copy (struct mempolicy *tompol, -struct mempolicy *frompol) -{ -if (!frompol) -return frompol; -return __mpol_cond_copy (tompol, frompol); -} -extern struct mempolicy *__mpol_dup (struct mempolicy *pol);static inline struct mempolicy *mpol_dup (struct mempolicy *pol) {
@@ -270,12 +260,6 @@ static inline void mpol_cond_put(struct { } -static inline struct mempolicy *mpol_cond_copy (struct mempolicy *to, -struct mempolicy *from) -{ -return from; -} -static inline void mpol_get (struct mempolicy *pol) { }
mm/mempolicy.c +0 -22
@@ -2009,28 +2009,6 @@ struct mempolicy *__mpol_dup(struct mempreturn new; } -/* -* If *frompol needs [has] an extra ref, copy *frompol to *tompol , -* eliminate the * MPOL_F_* flags that require conditional ref and -* [NOTE!!!] drop the extra ref. Not safe to reference *frompol directly -* after return. Use the returned value. -* -* Allows use of a mempolicy for, e.g., multiple allocations with a single -* policy lookup, even if the policy needs/has extra ref on lookup. -* shmem_readahead needs this. -*/ -struct mempolicy *__mpol_cond_copy (struct mempolicy *tompol, -struct mempolicy *frompol) -{ -if (!mpol_needs_cond_ref (frompol)) -return frompol; - - *tompol = *frompol; - tompol->flags &= ~MPOL_F_SHARED ;/* copy doesn't need unref */ -__mpol_put (frompol); -return tompol; -} -/* Slow path of a mempolicy comparison */ bool __mpol_equal (struct mempolicy *a,struct mempolicy *b) {
mm/shmem.c +16 -10
@@ -798,24 +798,28 @@ static struct mempolicy *shmem_get_sbmpostatic struct page *shmem_swapin (swp_entry_t swap,gfp_t gfp,struct shmem_inode_info *info,pgoff_t index) { -struct mempolicy mpol, *spol;struct vm_area_struct pvma; - - spol =mpol_cond_copy (&mpol, -mpol_shared_policy_lookup (&info->policy, index)); +struct page *page;/* Create a pseudo vma that just contains the policy */ pvma.vm_start =0 ; pvma.vm_pgoff = index; pvma.vm_ops =NULL ; - pvma.vm_policy = spol; -return swapin_readahead (swap, gfp, &pvma,0 ); + pvma.vm_policy =mpol_shared_policy_lookup (&info->policy, index); + + page =swapin_readahead (swap, gfp, &pvma,0 ); + +/* Drop reference taken by mpol_shared_policy_lookup() */ +mpol_cond_put (pvma.vm_policy); + +return page; }static struct page *shmem_alloc_page (gfp_t gfp,struct shmem_inode_info *info,pgoff_t index) {struct vm_area_struct pvma; +struct page *page;/* Create a pseudo vma that just contains the policy */ pvma.vm_start =0 ;
@@ -823,10 +827,12 @@ static struct page *shmem_alloc_page(gfp pvma.vm_ops =NULL ; pvma.vm_policy =mpol_shared_policy_lookup (&info->policy, index); -/* -* alloc_page_vma() will drop the shared policy reference -*/ - return alloc_page_vma(gfp, &pvma, 0); + page =alloc_page_vma (gfp, &pvma,0 ); + +/* Drop reference taken by mpol_shared_policy_lookup() */ +mpol_cond_put (pvma.vm_policy); + + return page; }#else /* !CONFIG_NUMA */ #ifdef CONFIG_TMPFS
Greg Kroah-Hartman
maintainerPATCH 2/28 Revert misapplied "mmc: sh-mmcif: avoid oops on spurious interrupts"
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Ball <[email protected]>
commit 6984f3c31bb57cb7491dbec1be44b74bd00f4648 upstream.
This reverts commit 8464dd52d3198dd05, which was a misapplied debugging version of the patch, not the final patch itself.
--- drivers/mmc/host/sh_mmcif.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/mmc/host/sh_mmcif.c +0 -4
@@ -1191,10 +1191,6 @@ static irqreturn_t sh_mmcif_intr(int irq host->sd_error = true;dev_dbg (&host->pd->dev,"int err state = %08x\n" , state); } -if (host->state ==STATE_IDLE ) { -dev_info (&host->pd->dev,"Spurious IRQ status 0x%x" , state); -return IRQ_HANDLED ; - }if (state & ~(INT_CMD12RBE |INT_CMD12CRE )) {if (!host->dma_active)return IRQ_WAKE_THREAD ;
Greg Kroah-Hartman
maintainerPATCH 3/28 mmc: sh-mmcif: avoid oops on spurious interrupts (second try)
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guennadi Liakhovetski <[email protected]>
commit 91ab252ac5a5c3461dd6910797611e9172626aed upstream.
On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious interrupts without any active request. To prevent the Oops, that results in such cases, don't dereference the mmc request pointer until we make sure, that we are indeed processing such a request.
--- drivers/mmc/host/sh_mmcif.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/mmc/host/sh_mmcif.c +2 -2
@@ -1066,7 +1066,6 @@ static irqreturn_t sh_mmcif_irqt(int irq {struct sh_mmcif_host *host = dev_id;struct mmc_request *mrq = host->mrq; -struct mmc_data *data = mrq->data;cancel_delayed_work_sync (&host->timeout_work);
@@ -1114,13 +1113,14 @@ static irqreturn_t sh_mmcif_irqt(int irqcase MMCIF_WAIT_FOR_READ_END :case MMCIF_WAIT_FOR_WRITE_END :if (host->sd_error) - data->error =sh_mmcif_error_manage (host); + mrq->data->error =sh_mmcif_error_manage (host);break ;default :BUG (); }if (host->wait_for !=MMCIF_WAIT_FOR_STOP ) { +struct mmc_data *data = mrq->data;if (!mrq->cmd->error && data && !data->error) data->bytes_xfered = data->blocks * data->blksz;
Greg Kroah-Hartman
maintainerPATCH 4/28 ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Walmsley <[email protected]>
commit 39141ddfb63a664f26d3f42f64ee386e879b492c upstream.
After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig:
[ 3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB [ 3.915954] mmcblk0: p1 [ 4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM [ 4.093719] Modules linked in: [ 4.096954] CPU: 0 Not tainted (3.6.0-02232-g759e00b #570) [ 4.103149] PC is at vfp_reload_hw+0x1c/0x44 [ 4.107666] LR is at __und_usr_fault_32+0x0/0x8
It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so this results in an undefined instruction exception. The code didn't crash before commit 846a136 because the save and restore code was only touching d0-d15, present on all VFP.
Fix by implementing a request from Russell King to add a new HWCAP flag that affirmatively indicates the presence of the d16-d31 registers:
http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2
and some feedback from Måns to clarify the name of the HWCAP flag.
--- arch/arm/include/asm/hwcap.h | 3 ++- arch/arm/include/asm/vfpmacros.h | 12 ++++++------ arch/arm/vfp/vfpmodule.c | 9 ++++++--- 3 files changed, 14 insertions(+), 10 deletions(-)
arch/arm/include/asm/hwcap.h +2 -1
@@ -18,11 +18,12 @@#define HWCAP_THUMBEE (1 << 11)#define HWCAP_NEON (1 << 12)#define HWCAP_VFPv3 (1 << 13) -#define HWCAP_VFPv3D16 (1 << 14) +#define HWCAP_VFPv3D16 (1 << 14)/* also set for VFPv4-D16 */ #define HWCAP_TLS (1 << 15)#define HWCAP_VFPv4 (1 << 16)#define HWCAP_IDIVA (1 << 17)#define HWCAP_IDIVT (1 << 18) +#define HWCAP_VFPD32 (1 << 19)/* set if VFP has 32 regs (not 16) */ #define HWCAP_IDIV (HWCAP_IDIVA | HWCAP_IDIVT)#if defined(__KERNEL__)
arch/arm/include/asm/vfpmacros.h +6 -6
@@ -27,9 +27,9 @@#if __LINUX_ARM_ARCH__ <=6 ldr \tmp, =elf_hwcap @ may not have MVFR regs ldr \tmp, [\tmp, #0] - tst \tmp, #HWCAP_VFPv3D16 - ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31} - addne \base, \base, #32*4 @ step over unused register space + tst \tmp, #HWCAP_VFPD32 + ldcnel p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31} + addeq \base, \base, #32*4 @ step over unused register space#else VFPFMRX \tmp, MVFR0 @ Media and VFP Feature Register 0 and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
@@ -51,9 +51,9 @@#if __LINUX_ARM_ARCH__ <=6 ldr \tmp, =elf_hwcap @ may not have MVFR regs ldr \tmp, [\tmp, #0] - tst \tmp, #HWCAP_VFPv3D16 - stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31} - addne \base, \base, #32*4 @ step over unused register space + tst \tmp, #HWCAP_VFPD32 + stcnel p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31} + addeq \base, \base, #32*4 @ step over unused register space#else VFPFMRX \tmp, MVFR0 @ Media and VFP Feature Register 0 and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
arch/arm/vfp/vfpmodule.c +6 -3
@@ -701,11 +701,14 @@ static int __init vfp_init(void) elf_hwcap |= HWCAP_VFPv3;/* -* Check for VFPv3 D16. CPUs in this configuration -* only have 16 x 64bit registers. +* Check for VFPv3 D16 and VFPv4 D16. CPUs in +* this configuration only have 16 x 64bit +* registers. */ if (((fmrx (MVFR0 ) &MVFR0_A_SIMD_MASK )) ==1 ) - elf_hwcap |= HWCAP_VFPv3D16; + elf_hwcap |= HWCAP_VFPv3D16;/* also v4-D16 */ +else + elf_hwcap |= HWCAP_VFPD32; }#endif /*
Greg Kroah-Hartman
maintainerPATCH 5/28 ASoC: dmaengine: Correct Makefile when sound is built as module
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Ujfalusi <[email protected]>
commit 961a7aeafab477f63d9eef26afde9cbb8badcd0f upstream.
soc-dmaengine-pcm library need to be part of the snd-soc-core in order to be able to compile ASoC as modules when dmaengine is enabled on the platform.
--- sound/soc/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
sound/soc/Makefile +3 -2
@@ -1,8 +1,9 @@ snd-soc-core-objs := soc-core.o soc-dapm.o soc-jack.o soc-cache.o soc-utils.o snd-soc-core-objs += soc-pcm.o soc-io.o -snd-soc-dmaengine-pcm-objs := soc-dmaengine-pcm.o -obj-$(CONFIG_SND_SOC_DMAENGINE_PCM) += snd-soc-dmaengine-pcm.o +ifneq ($(CONFIG_SND_SOC_DMAENGINE_PCM),) +snd-soc-core-objs += soc-dmaengine-pcm.o +endif obj-$(CONFIG_SND_SOC) += snd-soc-core.o obj-$(CONFIG_SND_SOC) += codecs/
Greg Kroah-Hartman
maintainerPATCH 6/28 workqueue: convert BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit fc4b514f2727f74a4587c31db87e0e93465518c3 upstream.
8852aac25e ("workqueue: mod_delayed_work_on() shouldn't queue timer on 0 delay") unexpectedly uncovered a very nasty abuse of delayed_work in megaraid - it allocated work_struct, casted it to delayed_work and then pass that into queue_delayed_work().
Previously, this was okay because 0 @delay short-circuited to queue_work() before doing anything with delayed_work. 8852aac25e moved 0 @delay test into __queue_delayed_work() after sanity check on delayed_work making megaraid trigger BUG_ON().
Although megaraid is already fixed by c1d390d8e6 ("megaraid: fix BUG_ON() from incorrect use of delayed work"), this patch converts BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s so that such abusers, if there are more, trigger warning but don't crash the machine.
--- kernel/workqueue.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/workqueue.c +2 -2
@@ -1141,8 +1141,8 @@ int queue_delayed_work_on(int cpu, strucif (!test_and_set_bit (WORK_STRUCT_PENDING_BIT ,work_data_bits (work))) {unsigned int lcpu; -BUG_ON (timer_pending (timer)); -BUG_ON (!list_empty (&work->entry)); +WARN_ON_ONCE (timer_pending (timer)); +WARN_ON_ONCE (!list_empty (&work->entry));timer_stats_timer_set_start_info (&dwork->timer);
Greg Kroah-Hartman
maintainerPATCH 7/28 drm/i915: do not ignore eDP bpc settings from vbt
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jani Nikula <[email protected]>
commit 2f4f649a69a9eb51f6e98130e19dd90a260a4145 upstream.
There are laptops out there that need the eDP bpc from VBT. This is effectively a revert of
commit 4344b813f105a19f793f1fd93ad775b784648b95
Author: Daniel Vetter <[email protected]> Date: Fri Aug 10 11:10:20 2012 +0200
drm/i915: ignore eDP bpc settings from vbt
but putting the VBT check after the EDID check to see them both in dmesg if this clamps more than the EDID. We have enough history with bpc clamping to warrant the extra debug info.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47641
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56401
--- drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/gpu/drm/i915/intel_display.c +11 -0
@@ -4996,6 +4996,17 @@ static bool intel_choose_pipe_bpp_dither } } +if (intel_encoder->type ==INTEL_OUTPUT_EDP ) { +/* Use VBT settings if we have an eDP panel */ +unsigned int edp_bpc = dev_priv->edp.bpp /3 ; + +if (edp_bpc < display_bpc) { +DRM_DEBUG_KMS ("clamping display bpc (was %d) to eDP (%d)\n" , display_bpc, edp_bpc); + display_bpc = edp_bpc; + } +continue ; + } +/* * HDMI is either 12 or 8, so if the display lets 10bpc sneak * through, clamp it down. (Note: >12bpc will be caught below.)
Greg Kroah-Hartman
maintainerPATCH 8/28 drm/i915: do not default to 18 bpp for eDP if missing from VBT
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jani Nikula <[email protected]>
commit 9a30a61f3516871c5c638fd7c025fbaa11ddf7fe upstream.
commit 500a8cc466a24e2fbc4c86ef9c6467ae2ffdeb0c
Author: Zhenyu Wang <[email protected]> Date: Wed Jan 13 11:19:52 2010 +0800
drm/i915: parse eDP panel color depth from VBT block
originally introduced parsing bpp for eDP from VBT, with a default of 18 bpp if the eDP BIOS data block is not present. Turns out that default seems to break the Macbook Pro with retina display, as noted in
commit 4344b813f105a19f793f1fd93ad775b784648b95
Author: Daniel Vetter <[email protected]> Date: Fri Aug 10 11:10:20 2012 +0200
drm/i915: ignore eDP bpc settings from vbt
Since we can't ignore bpc settings from VBT completely after all, get rid of the default. Do not clamp eDP to 18 bpp by default if the eDP BDB is missing from VBT.
--- drivers/gpu/drm/i915/intel_bios.c | 11 ++--------- drivers/gpu/drm/i915/intel_display.c | 2 +- 2 files changed, 3 insertions(+), 10 deletions(-)
drivers/gpu/drm/i915/intel_bios.c +2 -9
@@ -459,12 +459,8 @@ parse_edp(struct drm_i915_private *dev_p edp =find_section (bdb,BDB_EDP );if (!edp) { -if (SUPPORTS_EDP (dev_priv->dev) && dev_priv->edp.support) { -DRM_DEBUG_KMS ("No eDP BDB found but eDP panel " -"supported, assume %dbpp panel color " -"depth.\n" , - dev_priv->edp.bpp); - } +if (SUPPORTS_EDP (dev_priv->dev) && dev_priv->edp.support) +DRM_DEBUG_KMS ("No eDP BDB found but eDP panel supported.\n" );return ; }
@@ -617,9 +613,6 @@ init_vbt_defaults(struct drm_i915_privat dev_priv->lvds_use_ssc =1 ; dev_priv->lvds_ssc_freq =intel_bios_ssc_frequency (dev,1 );DRM_DEBUG_KMS ("Set default to SSC at %dMHz\n" , dev_priv->lvds_ssc_freq); - -/* eDP data */ - dev_priv->edp.bpp =18 ; }static int __init intel_no_opregion_vbt_callback (const struct dmi_system_id *id)
drivers/gpu/drm/i915/intel_display.c +1 -1
@@ -5000,7 +5000,7 @@ static bool intel_choose_pipe_bpp_dither/* Use VBT settings if we have an eDP panel */ unsigned int edp_bpc = dev_priv->edp.bpp /3 ; -if (edp_bpc < display_bpc) { +if (edp_bpc && edp_bpc < display_bpc) {DRM_DEBUG_KMS ("clamping display bpc (was %d) to eDP (%d)\n" , display_bpc, edp_bpc); display_bpc = edp_bpc; }
Greg Kroah-Hartman
maintainerPATCH 9/28 mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Szyprowski <[email protected]>
commit 387870f2d6d679746020fa8e25ef786ff338dc98 upstream.
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless the flags provided by the caller. This causes excessive pruning of emergency memory pools without any good reason. Additionaly, on ARM architecture any driver which is using dmapools will sooner or later trigger the following error:
"ERROR: 256 KiB atomic DMA coherent pool is too small! Please increase it with coherent_pool= kernel parameter!". Increasing the coherent pool size usually doesn't help much and only delays such error, because all GFP_ATOMIC DMA allocations are always served from the special, very limited memory pool.
This patch changes the dmapool code to correctly use gfp flags provided by the dmapool caller.
--- mm/dmapool.c | 31 +++++++------------------------ 1 file changed, 7 insertions(+), 24 deletions(-)
mm/dmapool.c +7 -24
@@ -50,7 +50,6 @@ struct dma_pool { /* the pool */size_t allocation;size_t boundary;char name[32 ]; -wait_queue_head_t waitq;struct list_head pools; };
@@ -62,8 +61,6 @@ struct dma_page { /* cacheable header funsigned int offset; }; -#define POOL_TIMEOUT_JIFFIES ((100 /* msec */ * HZ) / 1000) -static DEFINE_MUTEX (pools_lock); static ssize_t
@@ -172,7 +169,6 @@ struct dma_pool *dma_pool_create(const c retval->size = size; retval->boundary = boundary; retval->allocation = allocation; -init_waitqueue_head (&retval->waitq);if (dev) {int ret;
@@ -227,7 +223,6 @@ static struct dma_page *pool_alloc_page(memset (page->vaddr,POOL_POISON_FREED , pool->allocation);#endif pool_initialise_page (pool, page); -list_add (&page->page_list, &pool->page_list); page->in_use =0 ; page->offset =0 ; }else {
@@ -315,30 +310,21 @@ void *dma_pool_alloc(struct dma_pool *pomight_sleep_if (mem_flags & __GFP_WAIT);spin_lock_irqsave (&pool->lock, flags); - restart:list_for_each_entry (page, &pool->page_list, page_list) {if (page->offset < pool->allocation) goto ready; } - page =pool_alloc_page (pool,GFP_ATOMIC ); -if (!page) { -if (mem_flags & __GFP_WAIT) { -DECLARE_WAITQUEUE (wait, current); -__set_current_state (TASK_UNINTERRUPTIBLE ); -__add_wait_queue (&pool->waitq, &wait); -spin_unlock_irqrestore (&pool->lock, flags); +/* pool_alloc_page() might sleep, so temporarily drop &pool->lock */ +spin_unlock_irqrestore (&pool->lock, flags); -schedule_timeout (POOL_TIMEOUT_JIFFIES ); + page =pool_alloc_page (pool, mem_flags); +if (!page) +return NULL ; -spin_lock_irqsave (&pool->lock, flags); -__remove_wait_queue (&pool->waitq, &wait); - goto restart; - } - retval =NULL ; - goto done; - } +spin_lock_irqsave (&pool->lock, flags); +list_add (&page->page_list, &pool->page_list); ready: page->in_use++; offset = page->offset;
@@ -348,7 +334,6 @@ void *dma_pool_alloc(struct dma_pool *po#ifdef DMAPOOL_DEBUG memset (retval,POOL_POISON_ALLOCATED , pool->size);#endif - done:spin_unlock_irqrestore (&pool->lock, flags);return retval; }
@@ -435,8 +420,6 @@ void dma_pool_free(struct dma_pool *pool page->in_use--; *(int *)vaddr = page->offset; page->offset = offset; -if (waitqueue_active (&pool->waitq)) -wake_up_locked (&pool->waitq);/* * Resist a temptation to do * if (!is_page_busy(page)) pool_free_page(pool, page);
Greg Kroah-Hartman
maintainerPATCH 10/28 x86,AMD: Power driver support for AMDs family 16h processors
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Ostrovsky <[email protected]>
commit 22e32f4f57778ebc6e17812fa3008361c05d64f9 upstream.
Add family 16h PCI ID to AMD's power driver to allow it report power consumption on these processors.
--- drivers/hwmon/fam15h_power.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/hwmon/fam15h_power.c +4 -0
@@ -31,6 +31,9 @@ MODULE_DESCRIPTION("AMD Family 15h CPU pMODULE_AUTHOR ("Andreas Herrmann <[email protected]>" );MODULE_LICENSE ("GPL" ); +/* Family 16h Northbridge's function 4 PCI ID */ +#define PCI_DEVICE_ID_AMD_16H_NB_F4 0x1534 +/* D18F3 */ #define REG_NORTHBRIDGE_CAP 0xe8
@@ -256,6 +259,7 @@ static void __devexit fam15h_power_removstatic DEFINE_PCI_DEVICE_TABLE (fam15h_power_id_table) = { {PCI_VDEVICE (AMD ,PCI_DEVICE_ID_AMD_15H_NB_F4 ) }, + {PCI_VDEVICE (AMD ,PCI_DEVICE_ID_AMD_16H_NB_F4 ) }, {} };MODULE_DEVICE_TABLE (pci, fam15h_power_id_table);
Greg Kroah-Hartman
maintainerPATCH 11/28 telephony: ijx: buffer overflow in ixj_write_cid()
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
[Not needed in 3.8 or newer as this driver is removed there. - gregkh]
We get this from user space and nothing has been done to ensure that these strings are NUL terminated.
--- drivers/staging/telephony/ixj.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-)
drivers/staging/telephony/ixj.c +12 -12
@@ -3190,12 +3190,12 @@ static void ixj_write_cid(IXJ *j)ixj_fsk_alloc (j); -strcpy (sdmf1, j->cid_send.month); -strcat (sdmf1, j->cid_send.day); -strcat (sdmf1, j->cid_send.hour); -strcat (sdmf1, j->cid_send.min); -strcpy (sdmf2, j->cid_send.number); -strcpy (sdmf3, j->cid_send.name); +strlcpy (sdmf1, j->cid_send.month,sizeof (sdmf1)); +strlcat (sdmf1, j->cid_send.day,sizeof (sdmf1)); +strlcat (sdmf1, j->cid_send.hour,sizeof (sdmf1)); +strlcat (sdmf1, j->cid_send.min,sizeof (sdmf1)); +strlcpy (sdmf2, j->cid_send.number,sizeof (sdmf2)); +strlcpy (sdmf3, j->cid_send.name,sizeof (sdmf3)); len1 =strlen (sdmf1); len2 =strlen (sdmf2);
@@ -3340,12 +3340,12 @@ static void ixj_write_cidcw(IXJ *j)ixj_pre_cid (j); } j->flags.cidcw_ack =0 ; -strcpy (sdmf1, j->cid_send.month); -strcat (sdmf1, j->cid_send.day); -strcat (sdmf1, j->cid_send.hour); -strcat (sdmf1, j->cid_send.min); -strcpy (sdmf2, j->cid_send.number); -strcpy (sdmf3, j->cid_send.name); +strlcpy (sdmf1, j->cid_send.month,sizeof (sdmf1)); +strlcat (sdmf1, j->cid_send.day,sizeof (sdmf1)); +strlcat (sdmf1, j->cid_send.hour,sizeof (sdmf1)); +strlcat (sdmf1, j->cid_send.min,sizeof (sdmf1)); +strlcpy (sdmf2, j->cid_send.number,sizeof (sdmf2)); +strlcpy (sdmf3, j->cid_send.name,sizeof (sdmf3)); len1 =strlen (sdmf1); len2 =strlen (sdmf2);
Greg Kroah-Hartman
maintainerPATCH 12/28 x86: hpet: Fix masking of MSI interrupts
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Beulich <[email protected]>
commit 6acf5a8c931da9d26c8dd77d784daaf07fa2bff0 upstream.
HPET_TN_FSB is not a proper mask bit; it merely toggles between MSI and legacy interrupt delivery. The proper mask bit is HPET_TN_ENABLE, so use both bits when (un)masking the interrupt.
--- arch/x86/kernel/hpet.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kernel/hpet.c +2 -2
@@ -431,7 +431,7 @@ void hpet_msi_unmask(struct irq_data *da/* unmask it */ cfg =hpet_readl (HPET_Tn_CFG (hdev->num)); - cfg |=HPET_TN_FSB ; + cfg |=HPET_TN_ENABLE |HPET_TN_FSB ;hpet_writel (cfg,HPET_Tn_CFG (hdev->num)); }
@@ -442,7 +442,7 @@ void hpet_msi_mask(struct irq_data *data/* mask it */ cfg =hpet_readl (HPET_Tn_CFG (hdev->num)); - cfg &= ~HPET_TN_FSB ; + cfg &= ~(HPET_TN_ENABLE |HPET_TN_FSB );hpet_writel (cfg,HPET_Tn_CFG (hdev->num)); }
Greg Kroah-Hartman
maintainerPATCH 13/28 USB: add new zte 3g-dongles pid to option.c
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "[email protected]" <[email protected]>
commit 31b6a1048b7292efff8b5b53ae3d9d29adde385e upstream.
--- drivers/usb/serial/option.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
drivers/usb/serial/option.c +22 -0
@@ -883,6 +883,10 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0126, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf5_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0128, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0135, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0136, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0137, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0139, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0142, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0143, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0144, 0xff, 0xff, 0xff) },
@@ -903,20 +907,34 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0165, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0167, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0189, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0191, 0xff, 0xff, 0xff), /* ZTE EuFi890 */ .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0196, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0197, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0199, 0xff, 0xff, 0xff), /* ZTE MF820S */ .driver_info = (kernel_ulong_t)&net_intf1_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0200, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0201, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0254, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0257, 0xff, 0xff, 0xff), /* ZTE MF821 */ .driver_info = (kernel_ulong_t)&net_intf3_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0265, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0284, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0317, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0326, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0330, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0395, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0414, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0417, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1008, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1010, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1012, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1018, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1021, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf2_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1057, 0xff, 0xff, 0xff) },
@@ -1096,6 +1114,10 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1298, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1299, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1300, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1301, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1302, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1303, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1333, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1401, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf2_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1402, 0xff, 0xff, 0xff),
Greg Kroah-Hartman
maintainerPATCH 14/28 USB: option: blacklist network interface on Huawei E173
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjørn Mork <[email protected]>
commit f36446cf9bbebaa03a80d95cfeeafbaf68218249 upstream.
The Huawei E173 will normally appear as 12d1:1436 in Linux. But the modem has another mode with different device ID and a slightly different set of descriptors. This is the mode used by Windows like this:
3Modem: USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000
Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001 Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002 PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003
All interfaces have the same ff/ff/ff class codes in this mode. Blacklisting the network interface to allow it to be picked up by the network driver.
--- drivers/usb/serial/option.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/serial/option.c +3 -0
@@ -80,6 +80,7 @@ static void option_instat_callback(struc#define OPTION_PRODUCT_GTM380_MODEM 0x7201#define HUAWEI_VENDOR_ID 0x12D1 +#define HUAWEI_PRODUCT_E173 0x140C#define HUAWEI_PRODUCT_K4505 0x1464#define HUAWEI_PRODUCT_K3765 0x1465#define HUAWEI_PRODUCT_K4605 0x14C6
@@ -552,6 +553,8 @@ static const struct usb_device_id option { USB_DEVICE(QUANTA_VENDOR_ID, QUANTA_PRODUCT_GLX) }, { USB_DEVICE(QUANTA_VENDOR_ID, QUANTA_PRODUCT_GKE) }, { USB_DEVICE(QUANTA_VENDOR_ID, QUANTA_PRODUCT_GLE) }, + { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t) &net_intf1_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4505, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t) &huawei_cdc12_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3765, 0xff, 0xff, 0xff),
Greg Kroah-Hartman
maintainerPATCH 15/28 USB: ftdi_sio: Add support for Newport AGILIS motor drivers
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Teichmann <[email protected]>
commit d7e14b375b40c04cd735b115713043b69a2c68ac upstream.
The Newport AGILIS model AG-UC8 compact piezo motor controller
(http://search.newport.com/?q=*&x2=sku&q2=AG-UC8)
is yet another device using an FTDI USB-to-serial chip. It works fine with the ftdi_sio driver when adding
options ftdi-sio product=0x3000 vendor=0x104d
to modprobe.d. udevadm reports "Newport" as the manufacturer, and "Agilis" as the product name.
--- drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio_ids.h | 6 ++++++ 2 files changed, 7 insertions(+)
drivers/usb/serial/ftdi_sio.c +1 -0
@@ -197,6 +197,7 @@ static struct usb_device_id id_table_com { USB_DEVICE(FTDI_VID, FTDI_OPENDCC_THROTTLE_PID) }, { USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GATEWAY_PID) }, { USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GBM_PID) }, + { USB_DEVICE(NEWPORT_VID, NEWPORT_AGILIS_PID) }, { USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_IOBOARD_PID) }, { USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_MINI_IOBOARD_PID) }, { USB_DEVICE(FTDI_VID, FTDI_SPROG_II) },
drivers/usb/serial/ftdi_sio_ids.h +6 -0
@@ -752,6 +752,12 @@#define TTI_VID 0x103E/* Vendor Id */ #define TTI_QL355P_PID 0x03E8/* TTi QL355P power supply */ +/* +* Newport Cooperation (www.newport.com) +*/ +#define NEWPORT_VID 0x104D +#define NEWPORT_AGILIS_PID 0x3000 +/* Interbiometrics USB I/O Board */ /* Developed for Interbiometrics by Rudolf Gugler */ #define INTERBIOMETRICS_VID 0x1209
Greg Kroah-Hartman
maintainerPATCH 16/28 usb: ftdi_sio: fixup BeagleBone A5+ quirk
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Korsgaard <[email protected]>
commit 1a88d5eee2ef2ad1d3c4e32043e9c4c5347d4fc1 upstream.
BeagleBone A5+ devices ended up getting shipped with the 'BeagleBone/XDS100V2' product string, and not XDS100 like it was agreed, so adjust the quirk to match.
For details, see the thread on the beagle list:
https://groups.google.com/forum/#!msg/beagleboard/zrFPew9_Wvo/ibWr1-eE8JwJ
--- drivers/usb/serial/ftdi_sio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/serial/ftdi_sio.c +1 -1
@@ -1811,7 +1811,7 @@ static int ftdi_8u2232c_probe(struct usbdbg ("%s" , __func__);if ((udev->manufacturer && !strcmp (udev->manufacturer,"CALAO Systems" )) || - (udev->product && !strcmp (udev->product,"BeagleBone/XDS100" ))) + (udev->product && !strcmp (udev->product,"BeagleBone/XDS100V2" )))return ftdi_jtag_probe (serial);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 17/28 USB: cp210x: add Virtenio Preon32 device id
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Markus Becker <[email protected]>
commit 356fe44f4b8ece867bdb9876b1854d7adbef9de2 upstream.
--- drivers/usb/serial/cp210x.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/serial/cp210x.c +1 -0
@@ -120,6 +120,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(0x10C4, 0x8477) }, /* Balluff RFID */ { USB_DEVICE(0x10C4, 0x85EA) }, /* AC-Services IBUS-IF */ { USB_DEVICE(0x10C4, 0x85EB) }, /* AC-Services CIS-IBUS */ + { USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */ { USB_DEVICE(0x10C4, 0x8664) }, /* AC-Services CAN-IF */ { USB_DEVICE(0x10C4, 0x8665) }, /* AC-Services OBD-IF */ { USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
Greg Kroah-Hartman
maintainerPATCH 18/28 USB: mark uas driver as BROKEN
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit fb37ef98015f864d22be223a0e0d93547cd1d4ef upstream.
As reported https://bugzilla.kernel.org/show_bug.cgi?id=51031, the UAS driver causes problems and has been asked to be not built into any of the major distributions. To prevent users from running into problems with it, and for distros that were not notified, just mark the whole thing as broken.
--- drivers/usb/storage/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/storage/Kconfig +1 -1
@@ -203,7 +203,7 @@ config USB_STORAGE_ENE_UB6250 config USB_UAS tristate "USB Attached SCSI" - depends on USB && SCSI + depends on USB && SCSI && BROKEN help The USB Attached SCSI protocol is supported by some USB storage devices. It permits higher performance by supporting
Greg Kroah-Hartman
maintainerPATCH 19/28 ACPI / battery: Correct battery capacity values on Thinkpads
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kamil Iskra <[email protected]>
commit 4000e626156935dfb626321ce09cae2c833eabbb upstream.
Add a quirk to correctly report battery capacity on 2010 and 2011 Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220) exhibit a problem where, when battery capacity reporting unit is mAh, the values being reported are wrong. Pre-2010 and 2012 models appear to always report in mWh and are thus unaffected. Also, in mid-2012 Lenovo issued a BIOS update for the 2011 models that fixes the issue (tested on x220 with a post-1.29 BIOS). No such update is available for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch the reporting unit between mAh and mWh; generally, mAh is used when a laptop is plugged in and mWh when it's unplugged, although a suspend/resume or rmmod/modprobe is needed for the switch to take effect. The values reported in mAh are *always* wrong. This does not appear to be a kernel regression; I believe that the values were never reported correctly. I tested back to kernel 2.6.34, with multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes design capacity: 2886 mAh last full capacity: 2909 mAh battery technology: rechargeable design voltage: 14800 mV design capacity warning: 145 mAh design capacity low: 13 mAh cycle count: 0 capacity granularity 1: 1 mAh capacity granularity 2: 1 mAh model number: 42T4899 serial number: 21064 battery type: LION OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend, resume), the output changes to:
present: yes design capacity: 28860 mWh last full capacity: 29090 mWh battery technology: rechargeable design voltage: 14800 mV design capacity warning: 1454 mWh design capacity low: 200 mWh cycle count: 0 capacity granularity 1: 1 mWh capacity granularity 2: 1 mWh model number: 42T4899 serial number: 21064 battery type: LION OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a factor of 10 instead of 14.8 (the design voltage of this battery)? On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those machines were released, but because the most common Thinkpad batteries are rated at 10.8V, the error (8%) is small enough that it simply hasn't been noticed or at least nobody could be bothered to look into it.
My patch works around the problem by adjusting the incorrectly reported mAh values by "10000 / design_voltage". The patch also has code to figure out if it should be activated or not. It only activates on Lenovo Thinkpads, only when the unit is mAh, and, as an extra precaution, only when the battery capacity reported through ACPI does not match what is reported through DMI (I've never encountered a machine where the first two conditions would be true but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
--- drivers/acpi/battery.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+)
drivers/acpi/battery.c +77 -0
@@ -34,6 +34,7 @@#include <linux/dmi.h> #include <linux/slab.h> #include <linux/suspend.h> +#include <asm/unaligned.h> #ifdef CONFIG_ACPI_PROCFS_POWER #include <linux/proc_fs.h>
@@ -95,6 +96,18 @@ enum {ACPI_BATTERY_ALARM_PRESENT ,ACPI_BATTERY_XINFO_PRESENT ,ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY , +/* On Lenovo Thinkpad models from 2010 and 2011, the power unit +switches between mWh and mAh depending on whether the system +is running on battery or not. When mAh is the unit, most +reported values are incorrect and need to be adjusted by +10000/design_voltage. Verified on x201, t410, t410s, and x220. +Pre-2010 and 2012 models appear to always report in mWh and +are thus unaffected (tested with t42, t61, t500, x200, x300, +and x230). Also, in mid-2012 Lenovo issued a BIOS update for +the 2011 models that fixes the issue (tested on x220 with a +post-1.29 BIOS), but as of Nov. 2012, no such update is +available for the 2010 models. */ + ACPI_BATTERY_QUIRK_THINKPAD_MAH, }; struct acpi_battery {
@@ -429,6 +442,21 @@ static int acpi_battery_get_info(structkfree (buffer.pointer);if (test_bit (ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY , &battery->flags)) battery->full_charge_capacity = battery->design_capacity; +if (test_bit (ACPI_BATTERY_QUIRK_THINKPAD_MAH , &battery->flags) && + battery->power_unit && battery->design_voltage) { + battery->design_capacity = battery->design_capacity * +10000 / battery->design_voltage; + battery->full_charge_capacity = battery->full_charge_capacity * +10000 / battery->design_voltage; + battery->design_capacity_warning = + battery->design_capacity_warning * +10000 / battery->design_voltage; +/* Curiously, design_capacity_low, unlike the rest of them, +is correct. */ +/* capacity_granularity_* equal 1 on the systems tested, so +it's impossible to tell if they would need an adjustment +or not if their values were higher. */ + }return result; }
@@ -477,6 +505,11 @@ static int acpi_battery_get_state(struct && battery->capacity_now >= 0 && battery->capacity_now <= 100) battery->capacity_now = (battery->capacity_now * battery->full_charge_capacity) /100 ; +if (test_bit (ACPI_BATTERY_QUIRK_THINKPAD_MAH , &battery->flags) && + battery->power_unit && battery->design_voltage) { + battery->capacity_now = battery->capacity_now * +10000 / battery->design_voltage; + }return result; }
@@ -586,6 +619,24 @@ static void sysfs_remove_battery(structmutex_unlock (&battery->sysfs_lock); } +static void find_battery (const struct dmi_header *dm,void *private) +{ +struct acpi_battery *battery = (struct acpi_battery *)private; +/* Note: the hardcoded offsets below have been extracted from +the source code of dmidecode. */ +if (dm->type ==DMI_ENTRY_PORTABLE_BATTERY && dm->length >=8 ) { +const u8 *dmi_data = (const u8 *)(dm +1 ); +int dmi_capacity =get_unaligned ((const u16 *)(dmi_data +6 )); +if (dm->length >=18 ) + dmi_capacity *= dmi_data[17 ]; +if (battery->design_capacity * battery->design_voltage /1000 + != dmi_capacity && + battery->design_capacity *10 == dmi_capacity) +set_bit (ACPI_BATTERY_QUIRK_THINKPAD_MAH , + &battery->flags); + } +} +/* * According to the ACPI spec, some kinds of primary batteries can * report percentage battery remaining capacity directly to OS.
@@ -611,6 +662,32 @@ static void acpi_battery_quirks(struct a battery->capacity_now = (battery->capacity_now * battery->full_charge_capacity) /100 ; } + +if (test_bit (ACPI_BATTERY_QUIRK_THINKPAD_MAH , &battery->flags)) +return ; + +if (battery->power_unit &&dmi_name_in_vendors ("LENOVO" )) { +const char *s; + s =dmi_get_system_info (DMI_PRODUCT_VERSION ); +if (s && !strnicmp (s,"ThinkPad" ,8 )) { +dmi_walk (find_battery, battery); +if (test_bit (ACPI_BATTERY_QUIRK_THINKPAD_MAH , + &battery->flags) && + battery->design_voltage) { + battery->design_capacity = + battery->design_capacity * +10000 / battery->design_voltage; + battery->full_charge_capacity = + battery->full_charge_capacity * +10000 / battery->design_voltage; + battery->design_capacity_warning = + battery->design_capacity_warning * +10000 / battery->design_voltage; + battery->capacity_now = battery->capacity_now * +10000 / battery->design_voltage; + } + } + } }static int acpi_battery_update (struct acpi_battery *battery)
Greg Kroah-Hartman
maintainerPATCH 20/28 ACPI / PM: Add Sony Vaio VPCEB1S1E to nonvs blacklist.
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lan Tianyu <[email protected]>
commit 876ab79055019e248508cfd0dee7caa3c0c831ed upstream.
Sony Vaio VPCEB1S1E does not resume correctly without acpi_sleep=nonvs, so add it to the ACPI sleep blacklist.
References: https://bugzilla.kernel.org/show_bug.cgi?id=48781
--- drivers/acpi/sleep.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/acpi/sleep.c +8 -0
@@ -508,6 +508,14 @@ static struct dmi_system_id __initdata a }, { .callback = init_nvs_nosave, + .ident = "Sony Vaio VPCEB1S1E", + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), + DMI_MATCH(DMI_PRODUCT_NAME, "VPCEB1S1E"), + }, + }, + { + .callback = init_nvs_nosave, .ident = "Sony Vaio VGN-FW520F", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
Greg Kroah-Hartman
maintainerPATCH 21/28 ACPI / PNP: Do not crash due to stale pointer use during system resume
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
commit a6b5e88c0e42093b9057856f35770966c8c591e3 upstream.
During resume from system suspend the 'data' field of struct pnp_dev in pnpacpi_set_resources() may be a stale pointer, due to removal of the associated ACPI device node object in the previous suspend-resume cycle. This happens, for example, if a dockable machine is booted in the docking station and then suspended and resumed and suspended again. If that happens, pnpacpi_build_resource_template() called from pnpacpi_set_resources() attempts to use that pointer and crashes.
However, pnpacpi_set_resources() actually checks the device's ACPI handle, attempts to find the ACPI device node object attached to it and returns an error code if that fails, so in fact it knows what the correct value of dev->data should be. Use this observation to update dev->data with the correct value if necessary and dump a call trace if that's the case (once).
We still need to fix the root cause of this issue, but preventing systems from crashing because of it is an improvement too.
References: https://bugzilla.kernel.org/show_bug.cgi?id=51071
--- drivers/pnp/pnpacpi/core.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/pnp/pnpacpi/core.c +3 -0
@@ -95,6 +95,9 @@ static int pnpacpi_set_resources(structreturn -ENODEV ; } +if (WARN_ON_ONCE (acpi_dev != dev->data)) + dev->data = acpi_dev; + ret =pnpacpi_build_resource_template (dev, &buffer);if (ret)return ret;
Greg Kroah-Hartman
maintainerPATCH 22/28 ACPI / video: ignore BIOS initial backlight value for HP Folio 13-2000
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Rui <[email protected]>
commit 129ff8f8d58297b04f47b5d6fad81aa2d08404e1 upstream.
Or else the laptop will boot with a dimmed screen.
References: https://bugzilla.kernel.org/show_bug.cgi?id=51141
--- drivers/acpi/video.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/acpi/video.c +14 -0
@@ -389,6 +389,12 @@ static int __init video_set_bqc_offset(creturn 0 ; } +static int video_ignore_initial_backlight (const struct dmi_system_id *d) +{ + use_bios_initial_backlight =0 ; +return 0 ; +} +static struct dmi_system_id video_dmi_table[]__initdata = {/* * Broken _BQC workaround http://bugzilla.kernel.org/show_bug.cgi?id=13121
@@ -433,6 +439,14 @@ static struct dmi_system_id video_dmi_ta DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 7720"), }, }, + { + .callback = video_ignore_initial_backlight, + .ident = "HP Folio 13-2000", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP Folio 13 - 2000 Notebook PC"), + }, + }, {} };
Greg Kroah-Hartman
maintainerPATCH 23/28 USB: OHCI: workaround for hardware bug: retired TDs not added to the Done Queue
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit 50ce5c0683aa83eb161624ea89daa5a9eee0c2ce upstream.
This patch (as1636) is a partial workaround for a hardware bug affecting OHCI controllers by NVIDIA at least, maybe others too. When the controller retires a Transfer Descriptor, it is supposed to add the TD onto the Done Queue. But sometimes this doesn't happen, with the result that ohci-hcd never realizes the corresponding transfer has finished. Symptoms can vary; a typical result is that USB audio stops working after a while.
The patch works around the problem by recognizing that TDs are always processed in order. Therefore, if a later TD is found on the Done Queue than all the earlier TDs for the same endpoint must be finished as well.
Unfortunately this won't solve the problem in cases where the missing TD is the last one in the endpoint's queue. A complete fix would require a signficant amount of change to the driver.
--- drivers/usb/host/ohci-q.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
drivers/usb/host/ohci-q.c +19 -0
@@ -1128,6 +1128,25 @@ dl_done_list (struct ohci_hcd *ohci)while (td) {struct td *td_next = td->next_dl_td; +struct ed *ed = td->ed; + +/* +* Some OHCI controllers (NVIDIA for sure, maybe others) +* occasionally forget to add TDs to the done queue. Since +* TDs for a given endpoint are always processed in order, +* if we find a TD on the donelist then all of its +* predecessors must be finished as well. +*/ +for (;;) { +struct td *td2; + + td2 = list_first_entry(&ed->td_list, struct td, + td_list); +if (td2 == td) +break ; +takeback_td (ohci, td2); + } +takeback_td (ohci, td); td = td_next; }
Greg Kroah-Hartman
maintainerPATCH 24/28 xhci: Extend Fresco Logic MSI quirk.
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sarah Sharp <[email protected]>
commit bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 upstream.
Ali reports that plugging a device into the Fresco Logic xHCI host with PCI device ID 1400 produces an IRQ error:
do_IRQ: 3.176 No irq handler for vector (irq -1)
Other early Fresco Logic host revisions don't support MSI, even though their PCI config space claims they do. Extend the quirk to disabling MSI to this chipset revision. Also enable the short transfer quirk, since it's likely this revision also has that quirk, and it should be harmless to enable.
04:00.0 0c03: 1b73:1400 (rev 01) (prog-if 30 [XHCI])
Subsystem: 1d5c:1000
Physical Slot: 3
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 51
Region 0: Memory at d4600000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000feeff00c Data: 41b1
Capabilities: [80] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Kernel driver in use: xhci_hcd
This patch should be backported to stable kernels as old as 2.6.36, that contain the commit f5182b4155b9d686c5540a6822486400e34ddd98 "xhci:
Disable MSI for some Fresco Logic hosts."
--- drivers/usb/host/xhci-pci.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/usb/host/xhci-pci.c +5 -2
@@ -29,6 +29,7 @@/* Device for a quirk */ #define PCI_VENDOR_ID_FRESCO_LOGIC 0x1b73#define PCI_DEVICE_ID_FRESCO_LOGIC_PDK 0x1000 +#define PCI_DEVICE_ID_FRESCO_LOGIC_FL1400 0x1400#define PCI_VENDOR_ID_ETRON 0x1b6f#define PCI_DEVICE_ID_ASROCK_P67 0x7023
@@ -58,8 +59,10 @@ static void xhci_pci_quirks(struct devic/* Look for vendor-specific quirks */ if (pdev->vendor ==PCI_VENDOR_ID_FRESCO_LOGIC && - pdev->device ==PCI_DEVICE_ID_FRESCO_LOGIC_PDK ) { -if (pdev->revision ==0x0 ) { + (pdev->device ==PCI_DEVICE_ID_FRESCO_LOGIC_PDK || + pdev->device ==PCI_DEVICE_ID_FRESCO_LOGIC_FL1400 )) { +if (pdev->device ==PCI_DEVICE_ID_FRESCO_LOGIC_PDK && + pdev->revision ==0x0 ) { xhci->quirks |=XHCI_RESET_EP_QUIRK ;xhci_dbg (xhci,"QUIRK: Fresco Logic xHC needs configure" " endpoint cmd after reset endpoint\n" );
Greg Kroah-Hartman
maintainerPATCH 25/28 ftrace: Clear bits properly in reset_iter_read()
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 70f77b3f7ec010ff9624c1f2e39a81babc9e2429 upstream.
There is a typo here where '&' is used instead of '|' and it turns the statement into a noop. The original code is equivalent to:
iter->flags &= ~((1 << 2) & (1 << 4));
--- kernel/trace/ftrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/ftrace.c +1 -1
@@ -2368,7 +2368,7 @@ static void reset_iter_read(struct ftrac { iter->pos =0 ; iter->func_pos =0 ; - iter->flags &= ~(FTRACE_ITER_PRINTALL &FTRACE_ITER_HASH ); + iter->flags &= ~(FTRACE_ITER_PRINTALL |FTRACE_ITER_HASH ); }static void *t_start (struct seq_file *m,loff_t *pos)
Greg Kroah-Hartman
maintainerPATCH 26/28 cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit ba2d8ce9db0a61505362bb17b8899df3d3326146 upstream.
Some devices (ex Nokia C7) simply don't respond at all when data is sent to some of their USB interfaces. The data gets stuck in the TTYs queue and sits there until close(2), which them blocks because closing_wait defaults to 30 seconds (even though the fd is O_NONBLOCK). This is rarely desired. Implement the standard mechanism to adjust closing_wait and let applications handle it how they want to.
See also 02303f73373aa1da19dbec510ec5a4e2576f9610 for usb_wwan.c.
--- drivers/usb/class/cdc-acm.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)
drivers/usb/class/cdc-acm.c +38 -0
@@ -788,6 +788,10 @@ static int get_serial_info(struct acm *a tmp.flags =ASYNC_LOW_LATENCY ; tmp.xmit_fifo_size = acm->writesize; tmp.baud_base =le32_to_cpu (acm->line.dwDTERate); + tmp.close_delay = acm->port.close_delay /10 ; + tmp.closing_wait = acm->port.closing_wait ==ASYNC_CLOSING_WAIT_NONE ? +ASYNC_CLOSING_WAIT_NONE : + acm->port.closing_wait /10 ;if (copy_to_user (info, &tmp,sizeof (tmp)))return -EFAULT ;
@@ -795,6 +799,37 @@ static int get_serial_info(struct acm *areturn 0 ; } +static int set_serial_info (struct acm *acm, +struct serial_struct __user *newinfo) +{ +struct serial_struct new_serial; +unsigned int closing_wait, close_delay; +int retval =0 ; + +if (copy_from_user (&new_serial, newinfo,sizeof (new_serial))) +return -EFAULT ; + + close_delay = new_serial.close_delay *10 ; + closing_wait = new_serial.closing_wait ==ASYNC_CLOSING_WAIT_NONE ? +ASYNC_CLOSING_WAIT_NONE : new_serial.closing_wait *10 ; + +mutex_lock (&acm->port.mutex); + +if (!capable (CAP_SYS_ADMIN )) { +if ((close_delay != acm->port.close_delay) || + (closing_wait != acm->port.closing_wait)) + retval = -EPERM ; +else + retval = -EOPNOTSUPP ; + }else { + acm->port.close_delay = close_delay; + acm->port.closing_wait = closing_wait; + } + +mutex_unlock (&acm->port.mutex); +return retval; +} +static int acm_tty_ioctl (struct tty_struct *tty,unsigned int cmd,unsigned long arg) {
@@ -805,6 +840,9 @@ static int acm_tty_ioctl(struct tty_strucase TIOCGSERIAL :/* gets serial port data */ rv =get_serial_info (acm, (struct serial_struct __user *) arg);break ; +case TIOCSSERIAL : + rv =set_serial_info (acm, (struct serial_struct __user *) arg); +break ; }return rv;
Greg Kroah-Hartman
maintainerPATCH 27/28 perf test: fix a build error on builtin-test
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zheng Liu <[email protected]>
commit 12f8f74b2a4d26c4facfa7ef99487cf0930f6ef7 upstream.
Recently I build perf and get a build error on builtin-test.c. The error is as following:
$ make
CC perf.o
CC builtin-test.o
cc1: warnings being treated as errors
builtin-test.c: In function ‘sched__get_first_possible_cpu’:
builtin-test.c:977: warning: implicit declaration of function ‘CPU_ALLOC’
builtin-test.c:977: warning: nested extern declaration of ‘CPU_ALLOC’
builtin-test.c:977: warning: assignment makes pointer from integer without a cast
builtin-test.c:978: warning: implicit declaration of function ‘CPU_ALLOC_SIZE’
builtin-test.c:978: warning: nested extern declaration of ‘CPU_ALLOC_SIZE’
builtin-test.c:979: warning: implicit declaration of function ‘CPU_ZERO_S’
builtin-test.c:979: warning: nested extern declaration of ‘CPU_ZERO_S’
builtin-test.c:982: warning: implicit declaration of function ‘CPU_FREE’
builtin-test.c:982: warning: nested extern declaration of ‘CPU_FREE’
builtin-test.c:992: warning: implicit declaration of function ‘CPU_ISSET_S’
builtin-test.c:992: warning: nested extern declaration of ‘CPU_ISSET_S’
builtin-test.c:998: warning: implicit declaration of function ‘CPU_CLR_S’
builtin-test.c:998: warning: nested extern declaration of ‘CPU_CLR_S’
make: *** [builtin-test.o] Error 1This problem is introduced in 3e7c439a. CPU_ALLOC and related macros are missing in sched__get_first_possible_cpu function. In 54489c18, commiter mentioned that CPU_ALLOC has been removed. So CPU_ALLOC calls in this function are removed to let perf to be built.
--- tools/perf/builtin-test.c | 38 ++++++++++++-------------------------- 1 file changed, 12 insertions(+), 26 deletions(-)
tools/perf/builtin-test.c +12 -26
@@ -1154,19 +1154,13 @@ static int test__parse_events(void)return ret; } -static int sched__get_first_possible_cpu (pid_t pid,cpu_set_t **maskp, -size_t *sizep) +static int sched__get_first_possible_cpu (pid_t pid,cpu_set_t *maskp) { -cpu_set_t *mask; -size_t size;int i, cpu =-1 , nrcpus =1024 ; realloc: - mask =CPU_ALLOC (nrcpus); - size =CPU_ALLOC_SIZE (nrcpus); -CPU_ZERO_S (size, mask); +CPU_ZERO (maskp); -if (sched_getaffinity (pid, size, mask) ==-1 ) { -CPU_FREE (mask); +if (sched_getaffinity (pid,sizeof (*maskp), maskp) ==-1 ) {if (errno ==EINVAL && nrcpus < (1024 <<8 )) { nrcpus = nrcpus <<2 ; goto realloc;
@@ -1176,19 +1170,14 @@ realloc: }for (i =0 ; i < nrcpus; i++) { -if (CPU_ISSET_S (i, size, mask)) { -if (cpu ==-1 ) { +if (CPU_ISSET (i, maskp)) { +if (cpu ==-1 ) cpu = i; - *maskp = mask; - *sizep = size; - }else -CPU_CLR_S (i, size, mask); +else +CPU_CLR (i, maskp); } } -if (cpu ==-1 ) -CPU_FREE (mask); -return cpu; }
@@ -1199,8 +1188,8 @@ static int test__PERF_RECORD(void) .freq = 10, .mmap_pages = 256, }; -cpu_set_t *cpu_mask =NULL ; -size_t cpu_mask_size =0 ; +cpu_set_t cpu_mask; +size_t cpu_mask_size =sizeof (cpu_mask);struct perf_evlist *evlist =perf_evlist__new (NULL ,NULL );struct perf_evsel *evsel;struct perf_sample sample;
@@ -1265,8 +1254,7 @@ static int test__PERF_RECORD(void) evsel->attr.sample_type |=PERF_SAMPLE_TIME ;perf_evlist__config_attrs (evlist, &opts); - err =sched__get_first_possible_cpu (evlist->workload.pid, &cpu_mask, - &cpu_mask_size); + err =sched__get_first_possible_cpu (evlist->workload.pid, &cpu_mask);if (err <0 ) {pr_debug ("sched__get_first_possible_cpu: %s\n" ,strerror (errno)); goto out_delete_evlist;
@@ -1277,9 +1265,9 @@ static int test__PERF_RECORD(void)/* * So that we can check perf_sample.cpu on all the samples. */ -if (sched_setaffinity (evlist->workload.pid, cpu_mask_size, cpu_mask) <0 ) { +if (sched_setaffinity (evlist->workload.pid, cpu_mask_size, &cpu_mask) <0 ) {pr_debug ("sched_setaffinity: %s\n" ,strerror (errno)); - goto out_free_cpu_mask; + goto out_delete_evlist; }/*
@@ -1472,8 +1460,6 @@ found_exit: } out_err:perf_evlist__munmap (evlist); -out_free_cpu_mask: -CPU_FREE (cpu_mask); out_delete_evlist:perf_evlist__delete (evlist); out:
Greg Kroah-Hartman
maintainerPATCH 28/28 rcu: Fix batch-limit size problem
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit 878d7439d0f45a95869e417576774673d1fa243f upstream.
Commit 29c00b4a1d9e27 (rcu: Add event-tracing for RCU callback invocation) added a regression in rcu_do_batch()
Under stress, RCU is supposed to allow to process all items in queue, instead of a batch of 10 items (blimit), but an integer overflow makes the effective limit being 1. So, unless there is frequent idle periods (during which RCU ignores batch limits), RCU can be forced into a state where it cannot keep up with the callback-generation rate, eventually resulting in OOM.
This commit therefore converts a few variables in rcu_do_batch() from int to long to fix this problem, along with the module parameters controlling the batch limits.
--- kernel/rcutree.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
kernel/rcutree.c +8 -8
@@ -202,13 +202,13 @@ DEFINE_PER_CPU(struct rcu_dynticks, rcu_ .dynticks = ATOMIC_INIT(1), }; -static int blimit =10 ;/* Maximum callbacks per rcu_do_batch. */ -static int qhimark =10000 ;/* If this many pending, ignore blimit. */ -static int qlowmark =100 ;/* Once only this many pending, use blimit. */ - -module_param (blimit, int,0 ); -module_param (qhimark, int,0 ); -module_param (qlowmark, int,0 ); +static long blimit =10 ;/* Maximum callbacks per rcu_do_batch. */ +static long qhimark =10000 ;/* If this many pending, ignore blimit. */ +static long qlowmark =100 ;/* Once only this many pending, use blimit. */ + +module_param (blimit, long,0 ); +module_param (qhimark, long,0 ); +module_param (qlowmark, long,0 );int rcu_cpu_stall_suppress__read_mostly ;/* 1 = suppress stall warnings. */ int rcu_cpu_stall_timeout__read_mostly =CONFIG_RCU_CPU_STALL_TIMEOUT ;
@@ -1476,7 +1476,7 @@ static void rcu_do_batch(struct rcu_stat {unsigned long flags;struct rcu_head *next, *list, **tail; -int bl, count, count_lazy; +long bl, count, count_lazy;/* If no callbacks are ready, just return.*/ if (!cpu_has_callbacks_ready_to_invoke (rdp)) {
At Fri, 14 Dec 2012 14:26:17 -0800,
Quoted 6 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.4.24 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 6 lines
Responses should be made by Sun Dec 16 22:16:59 UTC 2012. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.24-rc1.gzand the diffstat can be found below.
This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine.
- Build Machine: debian wheezy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB
- Test machine: debian wheezy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB
I reviewed the following patches and it looks good to me.
Quoted 9 lines
Zheng Liu <[email protected]>
perf test: fix a build error on builtin-testDan Carpenter <[email protected]>
ftrace: Clear bits properly inreset_iter_read()Jan Beulich <[email protected]>
x86: hpet: Fix masking of MSI interrupts
Quoted 8 lines
Marek Szyprowski <[email protected]>
mm: dmapool: use provided gfp flags for alldma_alloc_coherent()callsTejun Heo <[email protected]>
workqueue: convert BUG_ON()s in__queue_delayed_work()to WARN_ON_ONCE()sMel Gorman <[email protected]>
tmpfs: fix shared mempolicy leak
Thanks,
Satoru
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.4.24 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 16 22:16:59 UTC 2012. Anything received after that time might be too late.
Quoted 8 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.24-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
Patches applied cleanly to 3.0.y, 3.4.y, 3.6.y, and 3.7.y. Compiled and booted on the following systems:
HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
Started cross-compile tests and will report status.
-- Shuah
Quoted 19 lines · Shuah Khan
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.4.24 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun Dec 16 22:16:59 UTC 2012. Anything received after that time might be too late.
Quoted 8 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.24-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
Quoted 8 lines
Patches applied cleanly to 3.0.y, 3.4.y, 3.6.y, and 3.7.y. Compiled and booted on the following systems:
HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD GraphicsStarted cross-compile tests and will report status.
-- Shuah
Cross-compile tests:
alpha: defconfig passed on all
arm: defconfig passed on all
c6x: not applicable to 3.0.y, defconfig passed on the rest three
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig failed on 3.0.y (known issue), passed on the rest three
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all
-- Shuah