6 years agoMerge commit 'v3.4.5' into android-t114-3.4-rebased
Varun Wadekar [Wed, 18 Jul 2012 12:20:45 +0000]
Merge commit 'v3.4.5' into android-t114-3.4-rebased

Linux v3.4.5


Change-Id: I782e650a89665caea8aed9e5598234888dc11088
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

6 years agoARM: Tegra3: defconfig: remove dupicate entries
Varun Wadekar [Wed, 18 Jul 2012 10:32:40 +0000]
ARM: Tegra3: defconfig: remove dupicate entries

Remove the following duplicate entries:

Change-Id: Ie7541461f24cc44a3ad803d8232f12c98d04e9ba
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

6 years agoRevert "power: Add option to log time spent in suspend"
Arve Hjønnevåg [Wed, 6 Jun 2012 01:06:42 +0000]
Revert "power: Add option to log time spent in suspend"

This reverts commit 847bb6f2bc6e7c6d9c8e8a450b586a8ca3f1dba5.

6 years agoStaging: android: binder: Add some tracepoints
Arve Hjønnevåg [Thu, 24 May 2012 22:10:08 +0000]
Staging: android: binder: Add some tracepoints

Add tracepoints:
- ioctl entry and exit
- Main binder lock: lock, locked and unlock
- Command and return buffer opcodes
- Transaction: create and receive
- Transaction buffer: create and free
- Object and file descriptor transfer
- binder_update_page_range

Change-Id: Ib09ae78b0b8b75062325318e2307afd71b7c4458
Signed-off-by: Arve Hjønnevåg <arve@android.com>

6 years agoStaging: android: binder: Add some missing binder_stat_br calls
Arve Hjønnevåg [Sat, 26 May 2012 03:15:56 +0000]
Staging: android: binder: Add some missing binder_stat_br calls

Cached thread return errors, death notifications and new looper
requests were not included in the stats.

Change-Id: Iabe14b351b662d3f63009ecb3900f92fc3d72cc4
Signed-off-by: Arve Hjønnevåg <arve@android.com>

6 years agogpu: ion: fill in buffer->{dev,size} before mapping new buffers
Greg Hackmann [Tue, 5 Jun 2012 20:23:42 +0000]
gpu: ion: fill in buffer->{dev,size} before mapping new buffers

At least one map_dma() implementation (EXYNOS_CONTIG) assumes the fields
are filled in

Change-Id: I88c84dc5663df41f9aa9401b5f80fc2570f9dd95
Signed-off-by: Greg Hackmann <ghackmann@google.com>

6 years agoPM / Suspend: Print wall time at suspend entry and exit
Todd Poynor [Wed, 30 May 2012 00:33:56 +0000]
PM / Suspend: Print wall time at suspend entry and exit

Change-Id: I92f252414c013b018b9a392eae1ee039aa0e89dc
Signed-off-by: Todd Poynor <toddpoynor@google.com>

6 years agoandroid: persistent_ram: Allow specifying ecc parameters in platform data
Arve Hjønnevåg [Tue, 22 May 2012 23:33:23 +0000]
android: persistent_ram: Allow specifying ecc parameters in platform data

Change-Id: If5aaa968f6ce85ac8e18f07cca286f20f0aa6e58
Signed-off-by: Arve Hjønnevåg <arve@android.com>

6 years agoandroid: persistent_ram: Include ecc_size when calculating ecc_block
Arve Hjønnevåg [Tue, 20 Mar 2012 23:01:31 +0000]
android: persistent_ram: Include ecc_size when calculating ecc_block

Wastes less memory and allows using more memory for ecc than data.

Change-Id: I1537d28ef3e8626e2dfdc69f2e185d28b7600916
Signed-off-by: Arve Hjønnevåg <arve@android.com>

6 years agosw_sync: export sw_sync API
Erik Gilling [Wed, 16 May 2012 20:14:43 +0000]
sw_sync: export sw_sync API

Needed to let modules link against sw_sync.

Change-Id: I71d3e52677ef21b6e1ecdb84f831491be1f4fbe6
Signed-off-by: Erik Gilling <konkers@android.com>

6 years agosync: export sync API symbols
Erik Gilling [Wed, 16 May 2012 20:09:22 +0000]
sync: export sync API symbols

This is needed to allow modules to link against the sync subsystem

Change-Id: I15c1818de329f24e4113ef1d0923413b22fd0eff
Signed-off-by: Erik Gilling <konkers@android.com>

6 years agosync: allow async waits to be canceled
Erik Gilling [Tue, 15 May 2012 23:23:26 +0000]
sync: allow async waits to be canceled

In order to allow drivers to cleanly handled teardown we need to allow them
to cancel pending async waits.  To do this cleanly, we move allocation of
sync_fence_waiter to the driver calling sync_async_wait().

Change-Id: Ifcd95648be6ec07026d67f810070a4310f099989
Signed-off-by: Erik Gilling <konkers@android.com>

6 years agousb: gadget: android: Fix product name
Benoit Goby [Tue, 29 May 2012 20:57:27 +0000]
usb: gadget: android: Fix product name

Product names may contain spaces and scanf %s only matches the 1st word.
Use strlcpy instead.

Change-Id: Ie8703fea9775f7fc17fe615a42597ca3816d36b0
Signed-off-by: Benoit Goby <benoit@android.com>

6 years agogpu: ion: Get an sg_table from an ion handle
Rebecca Schultz Zavin [Wed, 23 May 2012 19:55:55 +0000]
gpu: ion: Get an sg_table from an ion handle

This patch adds an interface to return and sg_table given a
valid ion handle.

Change-Id: Icd948c60c1af0a4279f337bcd591cd39b46325e8
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>

6 years agogpu: ion: Allocate the sg_table at creation time rather than dynamically
Rebecca Schultz Zavin [Mon, 7 May 2012 23:06:32 +0000]
gpu: ion: Allocate the sg_table at creation time rather than dynamically

Rather than calling map_dma on the allocations dynamically, this patch
switches to creating the sg_table at the time the buffer is created.
This is necessary because in future updates the sg_table will be used
for cache maintenance.

Change-Id: I49aac7c6d3a5afc440d18b917ae0e73be5d3f56d
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>

6 years agogpu: ion: support begin/end and kmap/kunmap dma_buf ops
Rebecca Schultz Zavin [Fri, 27 Apr 2012 03:44:10 +0000]
gpu: ion: support begin/end and kmap/kunmap dma_buf ops

These ops were added in the 3.4 kernel.  This patch adds support
for them to ion.  Previous ion_map/unmap_kernel api is also
retained in addition to this new api.

Change-Id: I6d2db284dce12c2d8cc4e540865beee2da43bd0c
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>

6 years agogpu: ion: Use alloc_pages instead of vmalloc from the system heap
Rebecca Schultz Zavin [Mon, 30 Apr 2012 23:45:38 +0000]
gpu: ion: Use alloc_pages instead of vmalloc from the system heap

With this change the ion_system_heap will only use kernel address
space when the memory is mapped into the kernel (rare case).

Change-Id: I8702cf89ffec0bd5c337bd88d7444013d4d94bc8
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>

6 years agoion: Switch ion to use dma-buf
Rebecca Schultz Zavin [Wed, 1 Feb 2012 19:09:46 +0000]
ion: Switch ion to use dma-buf

Ion now uses dma-buf file descriptors to share
buffers with userspace.  Ion becomes a dma-buf
exporter and any driver that can import dma-bufs
can now import ion file descriptors.

Change-Id: Ia04d6d72fb301dc088eb8db6576822e9260ff332
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>

6 years agodma-buf: mmap support
Daniel Vetter [Wed, 18 Apr 2012 13:52:26 +0000]
dma-buf: mmap support

Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:

- It boils down reinventing a new rather general-purpose userspace
  synchronization interface. If we look at things like futexes, this
  is hard to get right.
- Furthermore a lot of kernel code has to interact with this
  synchronization primitive. This smells a look like the dri1 hw_lock,
  a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
  here, so we have plenty of opportunities to create funny deadlock

I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.

Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.

So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.

Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.

Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).

Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.

In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.

- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
  support could be added later.
- Extend the documentation with implementations notes for exporters
  that need to manually fake coherency.

Change-Id: Ia8f2ae5d8a1b1c87ed12ca1c89d7bf2067239ee4
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

6 years agogpu: ion: several bugfixes and enhancements of ION
KyongHo Cho [Wed, 7 Sep 2011 02:27:07 +0000]
gpu: ion: several bugfixes and enhancements of ION

1. Verifying if the size of memory allocation in ion_alloc() is aligned
by PAGE_SIZE at least. If it is not, this change makes the size to be
aligned by PAGE_SIZE.

2. Unmaps all mappings to the kernel and DMA address spaces when
destroying ion_buffer in ion_buffer_destroy(). This prevents leaks in
those virtual address spaces.

3. Makes the return value of ion_alloc() to be explicit Linux error code
when it fails to allocate a buffer.

4. Makes ion_alloc() implementation simpler. Removes 'goto' statement and
relavant call to ion_buffer_put().

5. Checks if the task is valid before calling put_task_struct() due
to failure on creating a ion client in ion_client_create().

6. Returns error when buffer allocation requested by userspace is failed.

Change-Id: I4fa9859f4a0b665fcb44e5c0da43c569732e93ae
Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>

6 years agoion: Add reserve function to ion
Rebecca Schultz Zavin [Tue, 31 Jan 2012 17:40:30 +0000]
ion: Add reserve function to ion

Rather than requiring each platform call memblock_remove or reserve
from the board file, add this to ion

Change-Id: Ie418a692c13e9e0cfe93ecc83d253d3ce860fc83
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>

6 years agoion: Switch map/unmap dma api to sg_tables
Rebecca Schultz Zavin [Mon, 30 Jan 2012 22:18:08 +0000]
ion: Switch map/unmap dma api to sg_tables

Switch these api's from scatterlists to sg_tables

Change-Id: I8b99e39633df009d472ce24704fa26af7bb50fa2
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>

6 years agousb: gadget: composite: Fix corruption when changing configuration
Benoit Goby [Wed, 16 May 2012 03:44:33 +0000]
usb: gadget: composite: Fix corruption when changing configuration

Remove the config from the configs list before releasing the spinlock.
Otherwise the other cpu might be processing a SET_CONFIGURATION that
will switch to the configuration that is being released.

Change-Id: Id4da0d0e18ead63e20cb236cd1d3e8e6d116acce
Signed-off-by: Benoit Goby <benoit@android.com>

6 years agodebug: add parameters to prevent entering debug mode on errors
Colin Cross [Thu, 17 May 2012 22:24:16 +0000]
debug: add parameters to prevent entering debug mode on errors

On non-developer devices kgdb prevents CONFIG_PANIC_TIMEOUT from
rebooting the device after a panic. Add module parameters
debug_core.break_on_exception and debug_core.break_on_panic to
allow skipping debug on panics and exceptions respectively.  Both
default to true to preserve existing behavior.

Change-Id: I75dce7263e96cee069a9750920cce83dc6f98e8c
Signed-off-by: Colin Cross <ccross@android.com>

6 years agosched/rt: fix SCHED_RR across cgroups
Colin Cross [Thu, 17 May 2012 00:22:23 +0000]
sched/rt: fix SCHED_RR across cgroups

task_tick_rt has an optimization to only reschedule SCHED_RR tasks
if they were the only element on their rq.  However, with cgroups
a SCHED_RR task could be the only element on its per-cgroup rq but
still be competing with other SCHED_RR tasks in its parent's
cgroup.  In this case, the SCHED_RR task in the child cgroup would
never yield at the end of its timeslice.  If the child cgroup
rt_runtime_us was the same as the parent cgroup rt_runtime_us,
the task in the parent cgroup would starve completely.

Modify task_tick_rt to check that the task is the only task on its
rq, and that the each of the scheduling entities of its ancestors
is also the only entity on its rq.

Change-Id: I4f5b118517f85db3570923eb2f5e4c933ece9247
Signed-off-by: Colin Cross <ccross@android.com>

6 years agosync: add poll support
Erik Gilling [Tue, 20 Mar 2012 00:28:32 +0000]
sync: add poll support

Change-Id: I294e481bba92658e6dd26f157ddbf0e9ff4ce8a5
Signed-off-by: Erik Gilling <konkers@android.com>

6 years agosw_sync: add fill_driver_data support
Erik Gilling [Fri, 16 Mar 2012 00:46:07 +0000]
sw_sync: add fill_driver_data support

Change-Id: Ib3812d282db56362d82f5ccc9a12b7d2100ab93a
Signed-off-by: Erik Gilling <konkers@android.com>

6 years agosync: add ioctl to get fence data
Erik Gilling [Fri, 16 Mar 2012 00:45:50 +0000]
sync: add ioctl to get fence data

Change-Id: I71410aef7e03a52562f7cb15b993ac8441b1fa12
Signed-off-by: Erik Gilling <konkers@android.com>

6 years agosw_sync: add debug support
Erik Gilling [Thu, 15 Mar 2012 21:23:23 +0000]
sw_sync: add debug support

Change-Id: Ibcc5fa8cb36e283cdf0e3308064876722e2675fc
Signed-off-by: Erik Gilling <konkers@android.com>

6 years agosync: add debugfs support
Erik Gilling [Thu, 15 Mar 2012 02:49:15 +0000]
sync: add debugfs support

Change-Id: I8a7ea63e454fbeee1ecf17e6c3caff7c43b24734
Signed-off-by: Erik Gilling <konkers@android.com>

6 years agosync: add timestamps to sync_pts
Erik Gilling [Thu, 15 Mar 2012 21:59:33 +0000]
sync: add timestamps to sync_pts

Change-Id: I2ad855072b86873880769a09a3176e85aa1199d7
Signed-off-by: Erik Gilling <konkers@android.com>

6 years agosw_sync: add cpu based sync driver
Erik Gilling [Wed, 18 Apr 2012 20:43:22 +0000]
sw_sync: add cpu based sync driver

Change-Id: I1042851f5e30f9fdc2f35bdad84123bcf108560f
Signed-off-by: Erik Gilling <konkers@android.com>

6 years agosync: Add synchronization framework
Erik Gilling [Tue, 13 Mar 2012 22:34:34 +0000]
sync: Add synchronization framework

not run through checkpatch yet.

Change-Id: I209f9db2824e0313f467f11ab09e5f54f0a4a6b5
Signed-off-by: Erik Gilling <konkers@android.com>

6 years agousb: otg: otg-wakelock: Fix build for 3.4
Benoit Goby [Thu, 10 May 2012 23:41:40 +0000]
usb: otg: otg-wakelock: Fix build for 3.4

Change-Id: I97e21e9e6645bf18522675039e512f85fe836794
Signed-off-by: Benoit Goby <benoit@android.com>

6 years agotrace: power: add trace_clock_set_parent
Colin Cross [Wed, 9 May 2012 23:09:50 +0000]
trace: power: add trace_clock_set_parent

Adds a new trace event to be called from clk_set_parent.  Some
cpufreq drivers, including Tegra, reparent the cpu clock to a
slower clock while the main pll is relocking, tracing
clk_set_parent allows traces to show how for long the cpu is
running slower.

Uses a separate TRACE_EVENT instead of the clock event class to
allow the event to contain string names for the child and the

Signed-off-by: Colin Cross <ccross@android.com>

6 years agonetfilter: xt_qtaguid: start tracking iface rx/tx at low level
JP Abgrall [Fri, 27 Apr 2012 19:57:39 +0000]
netfilter: xt_qtaguid: start tracking iface rx/tx at low level

qtaguid tracks the device stats by monitoring when it goes up and down,
then it gets the dev_stats().
But devs don't correctly report stats (either they don't count headers
symmetrically between rx/tx, or they count internal control messages).

Now qtaguid counts the rx/tx bytes/packets during raw:prerouting and
mangle:postrouting (nat is not available in ipv6).

The results are in
which outputs a format line (bash expansion):
  ifname  total_skb_{rx,tx}_{bytes,packets}

Added event counters for pre/post handling.
Added extra ctrl_*() pid/uid debugging.

Change-Id: Id84345d544ad1dd5f63e3842cab229e71d339297
Signed-off-by: JP Abgrall <jpa@google.com>

6 years agonetfilter: xt_IDLETIMER: Add new netlink msg type
JP Abgrall [Fri, 27 Apr 2012 06:28:35 +0000]
netfilter: xt_IDLETIMER: Add new netlink msg type

Send notifications when the label becomes active after an idle period.
Send netlink message notifications in addition to sysfs notifications.
Using a uevent with

This is backport from common android-3.0
commit: beb914e987cbbd368988d2b94a6661cb907c4d5a
with uevent support instead of a new netlink message type.

Change-Id: I31677ef00c94b5f82c8457e5bf9e5e584c23c523
Signed-off-by: Ashish Sharma <ashishsharma@google.com>
Signed-off-by: JP Abgrall <jpa@google.com>

6 years agoRevert "mmc: Set suspend/resume bus operations if CONFIG_PM_RUNTIME is used"
Colin Cross [Fri, 27 Apr 2012 21:03:41 +0000]
Revert "mmc: Set suspend/resume bus operations if CONFIG_PM_RUNTIME is used"

This reverts commit 2f4735e514e3e3ed9e55a8cd3c2c90690ee44b90.

6 years agonetfilter: xt_qtaguid: fix ipv6 protocol lookup
JP Abgrall [Tue, 17 Apr 2012 23:00:07 +0000]
netfilter: xt_qtaguid: fix ipv6 protocol lookup

When updating the stats for a given uid it would incorrectly assume
IPV4 and pick up the wrong protocol when IPV6.

Change-Id: Iea4a635012b4123bf7aa93809011b7b2040bb3d5
Signed-off-by: JP Abgrall <jpa@google.com>

6 years agonetfilter: qtaguid: initialize a local var to keep compiler happy.
JP Abgrall [Sat, 14 Apr 2012 02:22:35 +0000]
netfilter: qtaguid: initialize a local var to keep compiler happy.

There was a case that might have seemed like new_tag_stat was not
initialized and actually used.
Added comment explaining why it was impossible, and a BUG()
in case the logic gets changed.

Change-Id: I1eddd1b6f754c08a3bf89f7e9427e5dce1dfb081
Signed-off-by: JP Abgrall <jpa@google.com>

6 years agoHACK: video: tegra30: host: report "register_sets = 2" for NvRmModuleID_3D
Varun Wadekar [Tue, 17 Jul 2012 12:49:05 +0000]
HACK: video: tegra30: host: report "register_sets = 2" for NvRmModuleID_3D

Change-Id: I31936f31759d418df2bc59ab367f783ed269df1e
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

6 years agoARM: tegra: iovmm: Fix build error w/o CONFIG_IOVMM
Hiroshi DOYU [Thu, 12 Jul 2012 12:11:20 +0000]
ARM: tegra: iovmm: Fix build error w/o CONFIG_IOVMM

Update function prototype along with:

  commit 6cbf4c7465b7b70936cb422b509da0ad0829c306
  ARM: tegra: iovmm: Allow alloc_client to take struct device

Change-Id: I11d173429413ab268f6ab789d90f321e3d33de2c
Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Reviewed-on: http://git-master/r/115391
Reviewed-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
Tested-by: Rohan Somvanshi <rsomvanshi@nvidia.com>

6 years agoARM: tegra: iovmm: Make IOMMU/IOVMM selectable in Kconfig
Hiroshi DOYU [Wed, 11 Jul 2012 13:51:24 +0000]
ARM: tegra: iovmm: Make IOMMU/IOVMM selectable in Kconfig

This patch enables to replace iovmm*.ko family with
tegra-{smmu,gart}.ko if needed in kernel config. To use IOMMU as
backend engine, Enable TEGRA_IOMMU_{GART,SMMU} under IOMMU in config,
and automatically disable IOVMM.

IOVMM is equivalent to IOMMU_API. TEGRA_IOVMM_GART is equivalent to

Change-Id: I73408e927eb3f21e1db4e73700aaf415f4949166
Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Reviewed-on: http://git-master/r/115011
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>

6 years agoARM: tegra: iovmm: Replace IOVMM backend with IOMMU
Hiroshi DOYU [Tue, 10 Jul 2012 06:32:42 +0000]
ARM: tegra: iovmm: Replace IOVMM backend with IOMMU

Replace IOVMM backend functions with the standard IOMMU API
ones. Instead of modifying the actual C-files in drivers, MACROs in
iovmm.h does the all work.

Change-Id: I27dc893555ca1495588852261e3ba1e3e5619764
Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Reviewed-on: http://git-master/r/114460
Reviewed-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
Tested-by: Rohan Somvanshi <rsomvanshi@nvidia.com>

6 years agovideo: tegra: nvmap: Make IOMMU/IOVMM selectable in Kconfig
Hiroshi DOYU [Tue, 21 Feb 2012 14:47:08 +0000]
video: tegra: nvmap: Make IOMMU/IOVMM selectable in Kconfig

This patch allows nvmap to use the standard IOMMU API as its backend
engine instead of the legacy tegra IOVMM by Kconfig.

Enable TEGRA_IOMMU_{GART,SMMU} under IOMMU in config, and it
automatically disables IOVMM, instead.

Change-Id: I71112ef8072591aac4a93075623ca31c8851a960
Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Reviewed-on: http://git-master/r/114217
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>

6 years agoARM: tegra: clock: Add missed Tegra3 PERIPH_ON_APB attributes
Alex Frid [Sun, 15 Jul 2012 00:08:01 +0000]
ARM: tegra: clock: Add missed Tegra3 PERIPH_ON_APB attributes

Change-Id: I12be16dbc2614224ba852216a645d0f84c795334
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: http://git-master/r/115929
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Scott Peterson <speterson@nvidia.com>

6 years agoarm: tegra: cpu: changing cpu min. freq to 51MHz
Prem Sasidharan [Tue, 10 Jul 2012 01:30:58 +0000]
arm: tegra: cpu: changing cpu min. freq to 51MHz

Changing the CPU min. frequency to 51MHz. This helps
in bringing down the core power to 46mW.

Bug 1005275

Change-Id: I61daa59866be7baf8ebb741000904422cb095e85
Signed-off-by: Prem Sasidharan <psasidharan@nvidia.com>
(cherry picked from commit afbb34d5871b69df328d5aae37f69f25a8946514)
Reviewed-on: http://git-master/r/115452
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Wen Yi <wyi@nvidia.com>
Tested-by: Wen Yi <wyi@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>

6 years agocpufreq: protect cpufreq_stats_free_table with spinlock
Peter Boonstoppel [Fri, 2 Mar 2012 00:04:27 +0000]
cpufreq: protect cpufreq_stats_free_table with spinlock

Prevents crash on cpufreq_stat_notifier_trans when cpufreq_stats_table
has been freed due to a core being hotplugged out.

Bug 948348

Change-Id: I2640a9a23c9a79cad8c76bfefd243a07162d2004
Signed-off-by: Peter Boonstoppel <pboonstoppel@nvidia.com>
(cherry picked from commit 03070a4b0b8eb74825c99c6bbfb108ddb36a041c)
Reviewed-on: http://git-master/r/114248
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>

6 years agoarm: config: tegra3 Enable XHCI driver for USB3
Jay Agarwal [Fri, 6 Jul 2012 09:12:03 +0000]
arm: config: tegra3 Enable XHCI driver for USB3

1. Enable USB3 for both android and L4T
2. Enable R8169 for android, already enabled for L4T

Bug 956573

Change-Id: If8d7cf653a5cd2b02352ad07fee3a56c3f568d3a
Signed-off-by: Jay Agarwal <jagarwal@nvidia.com>
Reviewed-on: http://git-master/r/113856
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Krishna Thota <kthota@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>

6 years agoARM: tegra: dvfs: Update Tegra3 sdmmc dvfs tables
Alex Frid [Fri, 8 Jun 2012 21:43:35 +0000]
ARM: tegra: dvfs: Update Tegra3 sdmmc dvfs tables

Added Tegra3 sdmmc4 dvfs table and downgraded sdmmc 2/4 maximum
clock limits based on recent characterization results.

Bug 817679
Bug 841336

Change-Id: I88ddeaabf0739efc0f9c18c41cace331792d4d43
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: http://git-master/r/107780
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Pavan Kunapuli <pkunapuli@nvidia.com>
Tested-by: Pavan Kunapuli <pkunapuli@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>

6 years agoARM: tegra: p1852: Dual-display support for all SKUs
Dongfang Shi [Thu, 3 May 2012 23:40:49 +0000]
ARM: tegra: p1852: Dual-display support for all SKUs

Ported Peter's original change 86413 to main.

Add support for primary and secondary LVDS displays, and secondary HDMI display.

Add configuration for HDMI and LVDS

Support for determining which p1852 sku is in use

hdmi.c:If no edid retrieved, but there's a hardwired mode, enable it
(used to support HDMI->LVDS output on p1852 sku 2)

devices.c:added secondary display data.

Bug 977859
Bug 994011

Change-Id: Ide8fb6bf7dd873b1d50269fb98d7c1687e4d9073
Signed-off-by: Dongfang Shi <dshi@nvidia.com>
Reviewed-on: http://git-master/r/100438
Reviewed-by: Simone Willett <swillett@nvidia.com>
Tested-by: Simone Willett <swillett@nvidia.com>

6 years agopower: max17048: fix power polling at resume
Chandler Zhang [Fri, 13 Jul 2012 09:01:38 +0000]
power: max17048: fix power polling at resume

The state of charing is not correct because of the 1 sec delay.
Remove the delay to fix the issue.

Bug 1016683

Change-Id: I389970e32d34578bb1ec1f2019d78145f250a673
Signed-off-by: Chandler Zhang <chazhang@nvidia.com>
Reviewed-on: http://git-master/r/115632
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>

6 years agoarm: tegra: usb_phy: fix hsic suspend issue on xmm
Vinayak Pane [Tue, 12 Jun 2012 01:08:14 +0000]
arm: tegra: usb_phy: fix hsic suspend issue on xmm

XMM modem fails at auto-suspend on hsic. Fixing this issue
by enabling PMC sleepwalk code conditionally and only at
phy-on and phy-off routines.

Bug 991709

Signed-off-by: Vinayak Pane <vpane@nvidia.com>
Reviewed-on: http://git-master/r/109324
(cherry picked from commit 100f818a16ce97411a98ddb0e2c5c9e73a9e654a)

Change-Id: If6f92b8b36f856fa633cb411ac20dbe6e862890c
Reviewed-on: http://git-master/r/115612
Reviewed-by: Simone Willett <swillett@nvidia.com>
Tested-by: Simone Willett <swillett@nvidia.com>

6 years agohwmon: tegra: tsensor:Simplify counter calculation
Daniel Fu [Thu, 12 Jul 2012 09:30:10 +0000]
hwmon: tegra: tsensor:Simplify counter calculation

Simplify the temp to counter conversion in tsensor,
Also it can improve a little bit accuracy of temp to
counter conversion.

Change-Id: I5764334d5d94e317dd9400bc03cb5d7a64096ee0
Signed-off-by: Daniel Fu <danifu@nvidia.com>
Reviewed-on: http://git-master/r/115340
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>

6 years agoarm: tegra: sd: enable sd dpd
Wen Yi [Thu, 21 Jun 2012 04:42:13 +0000]
arm: tegra: sd: enable sd dpd

This is a WAR solution that allows for the turning on
SD DPD feature.

The original issue is that enabling SD DPD immediately after device comes
out of LP0 causes ULPI disconnect. The root cause of that is
not known.

The WAR is to delay the enabling of SD DPD for 100ms after
device comes out of LP0.

Bug 929628

Change-Id: I3c5e35ace422e5441535c2c0fe18545b53bbddc4
Signed-off-by: Wen Yi <wyi@nvidia.com>
(cherry picked from commit bffb7b917d52a3523af80db21322ec7ba5fd33f9)
Reviewed-on: http://git-master/r/113392
Reviewed-by: Simone Willett <swillett@nvidia.com>
Tested-by: Simone Willett <swillett@nvidia.com>

6 years agosdhci: tegra: enable sd dpd
Bitan Biswas [Mon, 25 Jun 2012 14:34:54 +0000]
sdhci: tegra: enable sd dpd

This is a WAR solution that allows for the turning on
SD DPD feature.

The original issue is that enabling SD DPD immediately after device comes
out of LP0 causes ULPI disconnect. The root cause of that is
not known.

The WAR is to delay the enabling of SD DPD for 100ms after
device comes out of LP0.

Bug 929628

Change-Id: I946771a8e92459464ce571295f96f197db25c061
Signed-off-by: Bitan Biswas <bbiswas@nvidia.com>
(cherry picked from commit beba2b34af7ff9313aed074342b9bb86b12620a8)
Reviewed-on: http://git-master/r/113391
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Wen Yi <wyi@nvidia.com>
Tested-by: Wen Yi <wyi@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>

6 years agoRevert "arm: tegra: power: disable all sd dpd"
Bitan Biswas [Tue, 24 Jan 2012 07:52:23 +0000]
Revert "arm: tegra: power: disable all sd dpd"

This reverts commit 8924926cdb77c6ab270867d4caef7a8cdacd11f2.

Bug 924452
Bug 929628

Signed-off-by: Bitan Biswas <bbiswas@nvidia.com>
(cherry picked from commit 142b34993404c853579864f7b7b4f320fb92a715)

Change-Id: I9d49703799e32d410beba18938e94e4b641eea6f
(cherry picked from commit 8de60b7a832bfbbf09e75def756379dbb2d14c3e)
Reviewed-on: http://git-master/r/113387
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Wen Yi <wyi@nvidia.com>
Tested-by: Wen Yi <wyi@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>

6 years agoarm: tegra: usb_phy: utmip remote wakeup issue
Venu Byravarasu [Fri, 29 Jun 2012 06:28:51 +0000]
arm: tegra: usb_phy: utmip remote wakeup issue

Do not clear sleep walk pointer for utmip port after remote
wakeup is detected. This should be cleared after control
is given to USB master from PMC.

Bug 999208

Change-Id: I9f498521989c6421f0043dc1b4364591d4907423
Signed-off-by: Venu Byravarasu <vbyravarasu@nvidia.com>
(cherry picked from commit e4dbecfe031cbacd4f22bbbcdf971ab11ad81ee8)
Reviewed-on: http://git-master/r/112938
Reviewed-by: Simone Willett <swillett@nvidia.com>
Tested-by: Simone Willett <swillett@nvidia.com>

6 years agovideo: tegra: fix compilation warning
Rhyland Klein [Thu, 12 Jul 2012 16:51:54 +0000]
video: tegra: fix compilation warning

Without the CONFIG_SWITCH enabled, there are multiple unused
variable warnings that get treated as error.

bug 949219

Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Change-Id: I39512367fa4bbd3b00a435d0d7a31cfede9e712f
Reviewed-on: http://git-master/r/115428
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-by: Sanjay Singh Rawat <srawat@nvidia.com>

6 years agoARM: tegra: clock: Dynamically re-lock memory pll
Alex Frid [Sun, 24 Jun 2012 01:22:13 +0000]
ARM: tegra: clock: Dynamically re-lock memory pll

So far Tegra3 EMC DFS allowed only scaling rates that can be divided
down from two fixed rate plls: memory PLLM, and peripheral PLLP. PLLM
is always running at maximum SDRAM rate set at boot time, while PLLP
rate 408MHz is fixed across all Tegra3 platforms.

This commit implements dynamic re-locking of PLLM at run time. Now
memory pll can lock either at boot rate or additional auxiliary rate
that is selected as follows: auxiliary PLLM rate must be present in
EMC DFS table, it must exactly match one of the rate steps for Tegra3
graphics bus with PLLC clock source (cbus), and must not be a proper
factor of boot PLLM rate or PLLP fixed rate.

When switching PLLM between boot and auxiliary rate, PLLC is used as
backup memory pll, and during this time cbus is locked at auxiliary
rate. In addition system bus is forced to temporarily use PLLP as
a clock source (this is necessary as sbus main clock source is PLLM
secondary divider PLLM_OUT1).

- only one auxiliary rate is supported, and it should be below PLLM
boot rate, but above half of boot rate
- dynamic re-lock is allowed only on LPDDR2 platforms
- no clock other than EMC and system bus could use PLLM as a source;
so for dynamic re-lock to work CONFIG_TEGRA_PLLM_RESTRICTED must be
selected, and VI clock (not covered by PLLM restricted configuration)
must be moved to PLLP.

Bug 1005576

Change-Id: I6177107c89c3cbe975a1d940927efa1ed0ea61ec
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: http://git-master/r/111438
Reviewed-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
Tested-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
(cherry picked from commit dc4d468a6acabfb268e7a7f44b45bb7354e9a99a)
Reviewed-on: http://git-master/r/114760
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Jihoon Bang <jbang@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>

6 years agovideo: tegra: update nvmap_alloc_handle interface for Android only
Varun Wadekar [Tue, 17 Jul 2012 04:20:46 +0000]
video: tegra: update nvmap_alloc_handle interface for Android only

Bug 1017884

Change-Id: I237cdb06f19b3ae0bf217f99ffeb705809716e12
Reported-by: Michal Pecio <mpecio@nvidia.com>
Signed-off-by: Michal Pecio <mpecio@nvidia.com>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

6 years agoLinux 3.4.5
Greg Kroah-Hartman [Mon, 16 Jul 2012 18:20:09 +0000]
Linux 3.4.5

6 years agoocfs2: fix NULL pointer dereference in __ocfs2_change_file_space()
Luis Henriques [Wed, 11 Jul 2012 21:02:10 +0000]
ocfs2: fix NULL pointer dereference in __ocfs2_change_file_space()

commit a4e08d001f2e50bb8b3c4eebadcf08e5535f02ee upstream.

As ocfs2_fallocate() will invoke __ocfs2_change_file_space() with a NULL
as the first parameter (file), it may trigger a NULL pointer dereferrence
due to a missing check.

Addresses http://bugs.launchpad.net/bugs/1006012

Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Reported-by: Bret Towe <magnade@gmail.com>
Tested-by: Bret Towe <magnade@gmail.com>
Cc: Sunil Mushran <sunil.mushran@oracle.com>
Acked-by: Joel Becker <jlbec@evilplan.org>
Acked-by: Mark Fasheh <mfasheh@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomemblock: free allocated memblock_reserved_regions later
Yinghai Lu [Wed, 11 Jul 2012 21:02:56 +0000]
memblock: free allocated memblock_reserved_regions later

commit 29f6738609e40227dabcc63bfb3b84b3726a75bd upstream.

memblock_free_reserved_regions() calls memblock_free(), but
memblock_free() would double reserved.regions too, so we could free the
old range for reserved.regions.

Also tj said there is another bug which could be related to this.

| I don't think we're saving any noticeable
| amount by doing this "free - give it to page allocator - reserve
| again" dancing.  We should just allocate regions aligned to page
| boundaries and free them later when memblock is no longer in use.

in that case, when DEBUG_PAGEALLOC, will get panic:

     memblock_free: [0x0000102febc080-0x0000102febf080] memblock_free_reserved_regions+0x37/0x39
  BUG: unable to handle kernel paging request at ffff88102febd948
  IP: [<ffffffff836a5774>] __next_free_mem_range+0x9b/0x155
  PGD 4826063 PUD cf67a067 PMD cf7fa067 PTE 800000102febd160
  CPU 0
  Pid: 0, comm: swapper Not tainted 3.5.0-rc2-next-20120614-sasha #447
  RIP: 0010:[<ffffffff836a5774>]  [<ffffffff836a5774>] __next_free_mem_range+0x9b/0x155

See the discussion at https://lkml.org/lkml/2012/6/13/469

So try to allocate with PAGE_SIZE alignment and free it later.

Reported-by: Sasha Levin <levinsasha928@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agofs: ramfs: file-nommu: add SetPageUptodate()
Bob Liu [Wed, 11 Jul 2012 21:02:35 +0000]
fs: ramfs: file-nommu: add SetPageUptodate()

commit fea9f718b3d68147f162ed2d870183ce5e0ad8d8 upstream.

There is a bug in the below scenario for !CONFIG_MMU:

 1. create a new file
 2. mmap the file and write to it
 3. read the file can't get the correct value


  sys_read() -> generic_file_aio_read() -> simple_readpage() -> clear_page()

which causes the page to be zeroed.

Add SetPageUptodate() to ramfs_nommu_expand_for_mapping() so that
generic_file_aio_read() do not call simple_readpage().

Signed-off-by: Bob Liu <lliubbo@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomm, thp: abort compaction if migration page cannot be charged to memcg
David Rientjes [Wed, 11 Jul 2012 21:02:13 +0000]
mm, thp: abort compaction if migration page cannot be charged to memcg

commit 4bf2bba3750f10aa9e62e6949bc7e8329990f01b upstream.

If page migration cannot charge the temporary page to the memcg,
migrate_pages() will return -ENOMEM.  This isn't considered in memory
compaction however, and the loop continues to iterate over all
pageblocks trying to isolate and migrate pages.  If a small number of
very large memcgs happen to be oom, however, these attempts will mostly
be futile leading to an enormous amout of cpu consumption due to the
page migration failures.

This patch will short circuit and fail memory compaction if
migrate_pages() returns -ENOMEM.  COMPACT_PARTIAL is returned in case
some migrations were successful so that the page allocator will retry.

Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodrivers/rtc/rtc-mxc.c: fix irq enabled interrupts warning
Benoît Thébaudeau [Wed, 11 Jul 2012 21:02:32 +0000]
drivers/rtc/rtc-mxc.c: fix irq enabled interrupts warning

commit b59f6d1febd6cbe9fae4589bf72da0ed32bc69e0 upstream.


  WARNING: at irq/handle.c:146 handle_irq_event_percpu+0x19c/0x1b8()
  irq 25 handler mxc_rtc_interrupt+0x0/0xac enabled interrupts
  Modules linked in:
   (unwind_backtrace+0x0/0xf0) from (warn_slowpath_common+0x4c/0x64)
   (warn_slowpath_common+0x4c/0x64) from (warn_slowpath_fmt+0x30/0x40)
   (warn_slowpath_fmt+0x30/0x40) from (handle_irq_event_percpu+0x19c/0x1b8)
   (handle_irq_event_percpu+0x19c/0x1b8) from (handle_irq_event+0x28/0x38)
   (handle_irq_event+0x28/0x38) from (handle_level_irq+0x80/0xc4)
   (handle_level_irq+0x80/0xc4) from (generic_handle_irq+0x24/0x38)
   (generic_handle_irq+0x24/0x38) from (handle_IRQ+0x30/0x84)
   (handle_IRQ+0x30/0x84) from (avic_handle_irq+0x2c/0x4c)
   (avic_handle_irq+0x2c/0x4c) from (__irq_svc+0x40/0x60)
  Exception stack(0xc050bf60 to 0xc050bfa8)
  bf60: 00000001 00000000 003c4208 c0018e20 c050a000 c050a000 c054a4c8 c050a000
  bf80: c05157a8 4117b363 80503bb4 00000000 01000000 c050bfa8 c0018e2c c000e808
  bfa0: 60000013 ffffffff
   (__irq_svc+0x40/0x60) from (default_idle+0x1c/0x30)
   (default_idle+0x1c/0x30) from (cpu_idle+0x68/0xa8)
   (cpu_idle+0x68/0xa8) from (start_kernel+0x22c/0x26c)

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Sascha Hauer <kernel@pengutronix.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodrivers/rtc/rtc-ab8500.c: use IRQF_ONESHOT when requesting a threaded IRQ
Lee Jones [Wed, 11 Jul 2012 21:02:16 +0000]
drivers/rtc/rtc-ab8500.c: use IRQF_ONESHOT when requesting a threaded IRQ

commit 3cfd16a551dc0c188160e1765168a04baf2d3198 upstream.

This driver's IRQ registration is failing because the kernel now forces
IRQs to be ONESHOT if no IRQ handler is passed.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodrivers/rtc/rtc-spear.c: fix use-after-free in spear_rtc_remove()
Devendra Naga [Wed, 11 Jul 2012 21:01:53 +0000]
drivers/rtc/rtc-spear.c: fix use-after-free in spear_rtc_remove()

commit 2a643893e50fde71d7ba84b5592ec61b467b9ab6 upstream.

`config' is freed and is then used in the rtc_device_unregister() call,
causing a kernel panic.

Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Reviewed-by: Viresh Kumar <viresh.linux@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomemory hotplug: fix invalid memory access caused by stale kswapd pointer
Jiang Liu [Wed, 11 Jul 2012 21:01:52 +0000]
memory hotplug: fix invalid memory access caused by stale kswapd pointer

commit d8adde17e5f858427504725218c56aef90e90fc7 upstream.

kswapd_stop() is called to destroy the kswapd work thread when all memory
of a NUMA node has been offlined.  But kswapd_stop() only terminates the
work thread without resetting NODE_DATA(nid)->kswapd to NULL.  The stale
pointer will prevent kswapd_run() from creating a new work thread when
adding memory to the memory-less NUMA node again.  Eventually the stale
pointer may cause invalid memory access.

An example stack dump as below. It's reproduced with 2.6.32, but latest
kernel has the same issue.

  BUG: unable to handle kernel NULL pointer dereference at (null)
  IP: [<ffffffff81051a94>] exit_creds+0x12/0x78
  PGD 0
  Oops: 0000 [#1] SMP
  last sysfs file: /sys/devices/system/memory/memory391/state
  CPU 11
  Modules linked in: cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq microcode fuse loop dm_mod tpm_tis rtc_cmos i2c_i801 rtc_core tpm serio_raw pcspkr sg tpm_bios igb i2c_core iTCO_wdt rtc_lib mptctl iTCO_vendor_support button dca bnx2 usbhid hid uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif edd ext3 mbcache jbd fan ide_pci_generic ide_core ata_generic ata_piix libata thermal processor thermal_sys hwmon mptsas mptscsih mptbase scsi_transport_sas scsi_mod
  Pid: 7949, comm: sh Not tainted #92 Tecal RH2285
  RIP: 0010:exit_creds+0x12/0x78
  RSP: 0018:ffff8806044f1d78  EFLAGS: 00010202
  RAX: 0000000000000000 RBX: ffff880604f22140 RCX: 0000000000019502
  RDX: 0000000000000000 RSI: 0000000000000202 RDI: 0000000000000000
  RBP: ffff880604f22150 R08: 0000000000000000 R09: ffffffff81a4dc10
  R10: 00000000000032a0 R11: ffff880006202500 R12: 0000000000000000
  R13: 0000000000c40000 R14: 0000000000008000 R15: 0000000000000001
  FS:  00007fbc03d066f0(0000) GS:ffff8800282e0000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000000000 CR3: 000000060f029000 CR4: 00000000000006e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Process sh (pid: 7949, threadinfo ffff8806044f0000, task ffff880603d7c600)
   ffff880604f22140 ffffffff8103aac5 ffff880604f22140 ffffffff8104d21e
   ffff880006202500 0000000000008000 0000000000c38000 ffffffff810bd5b1
   0000000000000000 ffff880603d7c600 00000000ffffdd29 0000000000000003
  Call Trace:
  Code: ff 4d 00 0f 94 c0 84 c0 74 08 48 89 ef e8 1f fd ff ff 5b 5d 31 c0 41 5c c3 53 48 8b 87 20 06 00 00 48 89 fb 48 8b bf 18 06 00 00 <8b> 00 48 c7 83 18 06 00 00 00 00 00 00 f0 ff 0f 0f 94 c0 84 c0
  RIP  exit_creds+0x12/0x78
   RSP <ffff8806044f1d78>
  CR2: 0000000000000000

[akpm@linux-foundation.org: add pglist_data.kswapd locking comments]
Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: David Rientjes <rientjes@google.com>
Reviewed-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agostaging:iio:ad7606: Re-add missing scale attribute
Lars-Peter Clausen [Tue, 5 Jun 2012 16:16:31 +0000]
staging:iio:ad7606: Re-add missing scale attribute

commit 279bf2e57c30c9a4482b2b6ede11b31c41e35e78 upstream.

Commit 50ac23be ("staging:iio:adc:ad7606 add local define for chan_spec
structures.") accidentally removed the scale info_mask flag. This patch
adds it back again.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[herton: Backported to 3.4: info_mask was not used yet with another flag]
Signed-off-by: Herton R. Krzesinski <herton@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomd/raid5: Do not add data_offset before call to is_badblock
majianpeng [Tue, 12 Jun 2012 00:31:10 +0000]
md/raid5: Do not add data_offset before call to is_badblock

commit 6c0544e255dd6582a9899572e120fb55d9f672a4 upstream.

In chunk_aligned_read() we are adding data_offset before calling
is_badblock.  But is_badblock also adds data_offset, so that is bad.

So move the addition of data_offset to after the call to

This bug was introduced by commit 31c176ecdf3563140e639
     md/raid5: avoid reading from known bad blocks.
which first appeared in 3.0.  So that patch is suitable for any
-stable kernel from 3.0.y onwards.  However it will need minor
revision for most of those (as the comment didn't appear until

Signed-off-by: majianpeng <majianpeng@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
[bwh: Backported to 3.2: ignored missing comment]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomm: Hold a file reference in madvise_remove
Andy Lutomirski [Thu, 5 Jul 2012 23:00:11 +0000]
mm: Hold a file reference in madvise_remove

commit 9ab4233dd08036fe34a89c7dc6f47a8bf2eb29eb upstream.

Otherwise the code races with munmap (causing a use-after-free
of the vma) or with close (causing a use-after-free of the struct

The bug was introduced by commit 90ed52ebe481 ("[PATCH] holepunch: fix
mmap_sem i_mutex deadlock")

Cc: Hugh Dickins <hugh@veritas.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2:
 - Adjust context
 - madvise_remove() calls vmtruncate_range(), not do_fallocate()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodrm/i915: rip out the PM_IIR WARN
Daniel Vetter [Thu, 21 Jun 2012 12:55:22 +0000]
drm/i915: rip out the PM_IIR WARN

commit 58bf8062d0b293b8e1028e5b0342082002886bd4 upstream.

After banging my head against this for the past few months, I still
don't see how this could possible race under the premise that once an
irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again
until we unmask it in PM_IMR.

Still, we have reports of this being seen in the wild. Now Bspec has
this little bit of lovely language in the PMIIR register:

Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR":

"For each bit, the IIR can store a second pending interrupt if two or
more of the same interrupt conditions occur before the first condition
is cleared. Upon clearing the interrupt, the IIR bit will momentarily
go low, then return high to indicate there is another interrupt

Now if we presume that PMIMR only prevent new interrupts from being
queued, we could easily end up masking an interrupt and clearing it,
but the 2nd pending interrupt setting the bit in PMIIR right away
again. Which leads, the next time the irq handler runs, to hitting the

Also, no bad side effects of this have ever been reported. And we've
tracked down our issues with the gpu turbo getting stuck to bogus
interrupt generation limits in th RPLIMIT register.

So let's just rip out this WARN as bogus and call it a day. The only
shallow thing here is that this 2-deep irq queue in the hw makes you
wonder how racy the windows irq handler is ...

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodrm/i915: Refactor the deferred PM_IIR handling into a single function
Chris Wilson [Sun, 15 Apr 2012 10:56:03 +0000]
drm/i915: Refactor the deferred PM_IIR handling into a single function

commit fc6826d1dcd65f3d1e9a5377678882e4e08f02be upstream.

This function, along with the registers and deferred work hander, are
all shared with SandyBridge, IvyBridge and their variants. So remove the
duplicate code into a single function.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[bwh: Backported to 3.2: adjust context; drop changes for Valley View]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agosplice: fix racy pipe->buffers uses
Eric Dumazet [Tue, 12 Jun 2012 13:24:40 +0000]
splice: fix racy pipe->buffers uses

commit 047fe3605235888f3ebcda0c728cb31937eadfe6 upstream.

Dave Jones reported a kernel BUG at mm/slub.c:3474! triggered
by splice_shrink_spd() called from vmsplice_to_pipe()

commit 35f3d14dbbc5 (pipe: add support for shrinking and growing pipes)
added capability to adjust pipe->buffers.

Problem is some paths don't hold pipe mutex and assume pipe->buffers
doesn't change for their duration.

Fix this by adding nr_pages_max field in struct splice_pipe_desc, and
use it in place of pipe->buffers where appropriate.

splice_shrink_spd() loses its struct pipe_inode_info argument.

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Tom Herbert <therbert@google.com>
Tested-by: Dave Jones <davej@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
[bwh: Backported to 3.2:
 - Adjust context in vmsplice_to_pipe()
 - Update one more call to splice_shrink_spd(), from skb_splice_bits()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agonet/wireless: ipw2x00: add supported cipher suites to wiphy initialization
Stanislav Yakovlev [Wed, 11 Apr 2012 01:44:47 +0000]
net/wireless: ipw2x00: add supported cipher suites to wiphy initialization

commit a141e6a0097118bb35024485f1faffc0d9042f5c upstream.

Driver doesn't report its supported cipher suites through cfg80211
interface. It still uses wext interface and probably will not work
through nl80211, but will at least correctly advertise supported

Bug was reported by Omar Siam.

Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomacvtap: zerocopy: validate vectors before building skb
Jason Wang [Wed, 2 May 2012 03:42:15 +0000]
macvtap: zerocopy: validate vectors before building skb

commit b92946e2919134ebe2a4083e4302236295ea2a73 upstream.

There're several reasons that the vectors need to be validated:

- Return error when caller provides vectors whose num is greater than UIO_MAXIOV.
- Linearize part of skb when userspace provides vectors grater than MAX_SKB_FRAGS.
- Return error when userspace provides vectors whose total length may exceed

Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agortl8187: ->brightness_set can not sleep
Stanislaw Gruszka [Wed, 16 May 2012 09:06:21 +0000]
rtl8187: ->brightness_set can not sleep

commit 0fde0a8cfd0ede7f310d6a681c8e5a7cb3e32406 upstream.


BUG: sleeping function called from invalid context at kernel/workqueue.c:2547
in_atomic(): 1, irqs_disabled(): 0, pid: 629, name: wpa_supplicant
2 locks held by wpa_supplicant/629:
 #0:  (rtnl_mutex){+.+.+.}, at: [<c08b2b84>] rtnl_lock+0x14/0x20
 #1:  (&trigger->leddev_list_lock){.+.?..}, at: [<c0867f41>] led_trigger_event+0x21/0x80
Pid: 629, comm: wpa_supplicant Not tainted 3.3.0-0.rc3.git5.1.fc17.i686
Call Trace:
 [<c046a9f6>] __might_sleep+0x126/0x1d0
 [<c0457d6c>] wait_on_work+0x2c/0x1d0
 [<c045a09a>] __cancel_work_timer+0x6a/0x120
 [<c045a160>] cancel_delayed_work_sync+0x10/0x20
 [<f7dd3c22>] rtl8187_led_brightness_set+0x82/0xf0 [rtl8187]
 [<c0867f7c>] led_trigger_event+0x5c/0x80
 [<f7ff5e6d>] ieee80211_led_radio+0x1d/0x40 [mac80211]
 [<f7ff3583>] ieee80211_stop_device+0x13/0x230 [mac80211]

Removing _sync is ok, because if led_on work is currently running
it will be finished before led_off work start to perform, since
they are always queued on the same mac80211 local->workqueue.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=795176

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agothp: avoid atomic64_read in pmd_read_atomic for 32bit PAE
Andrea Arcangeli [Wed, 20 Jun 2012 19:52:57 +0000]
thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE

commit e4eed03fd06578571c01d4f1478c874bb432c815 upstream.

In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding the
mmap_sem for reading, cmpxchg8b cannot be used to read pmd contents under

So instead of dealing only with "consistent" pmdvals in
pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals
where the low 32bit and high 32bit could be inconsistent (to avoid having
to use cmpxchg8b).

The only guarantee we get from pmd_read_atomic is that if the low part of
the pmd was found null, the high part will be null too (so the pmd will be
considered unstable).  And if the low part of the pmd is found "stable"
later, then it means the whole pmd was read atomically (because after a
pmd is stable, neither MADV_DONTNEED nor page faults can alter it anymore,
and we read the high part after the low part).

In the 32bit PAE x86 case, it is enough to read the low part of the pmdval
atomically to declare the pmd as "stable" and that's true for THP and no
THP, furthermore in the THP case we also have a barrier() that will
prevent any inconsistent pmdvals to be cached by a later re-read of the

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Cc: Ulrich Obergfell <uobergfe@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Larry Woodman <lwoodman@redhat.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Tested-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
Andrea Arcangeli [Tue, 29 May 2012 22:06:49 +0000]
mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition

commit 26c191788f18129af0eb32a358cdaea0c7479626 upstream.

When holding the mmap_sem for reading, pmd_offset_map_lock should only
run on a pmd_t that has been read atomically from the pmdp pointer,
otherwise we may read only half of it leading to this crash.

PID: 11679  TASK: f06e8000  CPU: 3   COMMAND: "do_race_2_panic"
 #0 [f06a9dd8] crash_kexec at c049b5ec
 #1 [f06a9e2c] oops_end at c083d1c2
 #2 [f06a9e40] no_context at c0433ded
 #3 [f06a9e64] bad_area_nosemaphore at c043401a
 #4 [f06a9e6c] __do_page_fault at c0434493
 #5 [f06a9eec] do_page_fault at c083eb45
 #6 [f06a9f04] error_code (via page_fault) at c083c5d5
    EAX: 01fb470c EBX: fff35000 ECX: 00000003 EDX: 00000100 EBP:
    DS:  007b     ESI: 9e201000 ES:  007b     EDI: 01fb4700 GS:  00e0
    CS:  0060     EIP: c083bc14 ERR: ffffffff EFLAGS: 00010246
 #7 [f06a9f38] _spin_lock at c083bc14
 #8 [f06a9f44] sys_mincore at c0507b7d
 #9 [f06a9fb0] system_call at c083becd
                         start           len
    EAX: ffffffda  EBX: 9e200000  ECX: 00001000  EDX: 6228537f
    DS:  007b      ESI: 00000000  ES:  007b      EDI: 003d0f00
    SS:  007b      ESP: 62285354  EBP: 62285388  GS:  0033
    CS:  0073      EIP: 00291416  ERR: 000000da  EFLAGS: 00000286

This should be a longstanding bug affecting x86 32bit PAE without THP.
Only archs with 64bit large pmd_t and 32bit unsigned long should be

With THP enabled the barrier() in pmd_none_or_trans_huge_or_clear_bad()
would partly hide the bug when the pmd transition from none to stable,
by forcing a re-read of the *pmd in pmd_offset_map_lock, but when THP is
enabled a new set of problem arises by the fact could then transition
freely in any of the none, pmd_trans_huge or pmd_trans_stable states.
So making the barrier in pmd_none_or_trans_huge_or_clear_bad()
unconditional isn't good idea and it would be a flakey solution.

This should be fully fixed by introducing a pmd_read_atomic that reads
the pmd in order with THP disabled, or by reading the pmd atomically
with cmpxchg8b with THP enabled.

Luckily this new race condition only triggers in the places that must
already be covered by pmd_none_or_trans_huge_or_clear_bad() so the fix
is localized there but this bug is not related to THP.

NOTE: this can trigger on x86 32bit systems with PAE enabled with more
than 4G of ram, otherwise the high part of the pmd will never risk to be
truncated because it would be zero at all times, in turn so hiding the
SMP race.

This bug was discovered and fully debugged by Ulrich, quote:

pmd_none_or_trans_huge_or_clear_bad() loads the content of edx and

    496 static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t
    497 {
    498         /* depend on compiler for an atomic pmd read */
    499         pmd_t pmdval = *pmd;

                                // edi = pmd pointer
0xc0507a74 <sys_mincore+548>:   mov    0x8(%esp),%edi
                                // edx = PTE page table high address
0xc0507a84 <sys_mincore+564>:   mov    0x4(%edi),%edx
                                // eax = PTE page table low address
0xc0507a8e <sys_mincore+574>:   mov    (%edi),%eax


Please note that the PMD is not read atomically. These are two "mov"
instructions where the high order bits of the PMD entry are fetched
first. Hence, the above machine code is prone to the following race.

-  The PMD entry {high|low} is 0x0000000000000000.
   The "mov" at 0xc0507a84 loads 0x00000000 into edx.

-  A page fault (on another CPU) sneaks in between the two "mov"
   instructions and instantiates the PMD.

-  The PMD entry {high|low} is now 0x00000003fda38067.
   The "mov" at 0xc0507a8e loads 0xfda38067 into eax.

Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Larry Woodman <lwoodman@redhat.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoath9k: fix panic caused by returning a descriptor we have queued for reuse
Tom Hughes [Wed, 27 Jun 2012 17:21:15 +0000]
ath9k: fix panic caused by returning a descriptor we have queued for reuse

commit 6bb51c70cabaadddc54a6454844eceba91a56083 upstream.

Commit 3a2923e83c introduced a bug when a corrupt descriptor
is encountered - although the following descriptor is discarded
and returned to the queue for reuse the associated frame is
also returned for processing. This leads to a panic:

BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
IP: [<ffffffffa02599a5>] ath_rx_tasklet+0x165/0x1b00 [ath9k]
Call Trace:
[<ffffffff812d7fa0>] ? map_single+0x60/0x60
[<ffffffffa028f044>] ? ath9k_ioread32+0x34/0x90 [ath9k]
[<ffffffffa0292eec>] athk9k_tasklet+0xdc/0x160 [ath9k]
[<ffffffff8105e133>] tasklet_action+0x63/0xd0
[<ffffffff8105dbc0>] __do_softirq+0xc0/0x1e0
[<ffffffff8101a873>] ? native_sched_clock+0x13/0x80
[<ffffffff815f9d5c>] call_softirq+0x1c/0x30
[<ffffffff810151f5>] do_softirq+0x75/0xb0
[<ffffffff8105df95>] irq_exit+0xb5/0xc0
[<ffffffff815fa5b3>] do_IRQ+0x63/0xe0
[<ffffffff815f0cea>] common_interrupt+0x6a/0x6a
[<ffffffff8131840a>] ? intel_idle+0xea/0x150
[<ffffffff813183eb>] ? intel_idle+0xcb/0x150
[<ffffffff814a1db9>] cpuidle_enter+0x19/0x20
[<ffffffff814a23d9>] cpuidle_idle_call+0xa9/0x240
[<ffffffff8101c4bf>] cpu_idle+0xaf/0x120
[<ffffffff815cda8e>] rest_init+0x72/0x74
[<ffffffff81cf4c1a>] start_kernel+0x3b7/0x3c4
[<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
[<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
[<ffffffff81cf444a>] x86_64_start_kernel+0x100/0x10f

Making sure bf is cleared to NULL in this case restores the
old behaviour.

Signed-off-by: Tom Hughes <tom@compton.nu>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agotg3: Apply short DMA frag workaround to 5906
Matt Carlson [Thu, 7 Jun 2012 12:56:54 +0000]
tg3: Apply short DMA frag workaround to 5906

commit b7abee6ef888117f92db370620ebf116a38e3f4d upstream.

5906 devices also need the short DMA fragment workaround.  This patch
makes the necessary change.

Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoraid5: delayed stripe fix
Shaohua Li [Tue, 3 Jul 2012 05:57:19 +0000]
raid5: delayed stripe fix

commit fab363b5ff502d1b39ddcfec04271f5858d9f26e upstream.

There isn't locking setting STRIPE_DELAYED and STRIPE_PREREAD_ACTIVE bits, but
the two bits have relationship. A delayed stripe can be moved to hold list only
when preread active stripe count is below IO_THRESHOLD. If a stripe has both
the bits set, such stripe will be in delayed list and preread count not 0,
which will make such stripe never leave delayed list.

Signed-off-by: Shaohua Li <shli@fusionio.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agogspca-core: Fix buffers staying in queued state after a stream_off
Hans de Goede [Thu, 5 Jul 2012 08:23:17 +0000]
gspca-core: Fix buffers staying in queued state after a stream_off

commit af05ef01e9cde84620c6855a8d8ab9c8a1db9009 upstream.

[Backport to linux-stable by Antonio Ospite <ospite@studenti.unina.it>]

This fixes a regression introduced by commit f7059ea and should be
backported to all supported stable kernels which have this commit.

Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomwifiex: fix wrong return values in add_virtual_intf() error cases
Bing Zhao [Wed, 4 Jul 2012 03:43:56 +0000]
mwifiex: fix wrong return values in add_virtual_intf() error cases

commit 858faa57dd9e2b91f3f870fbb1185982e42f5a2b upstream

add_virtual_intf() needs to return an ERR_PTR(), instead of NULL,
on errors, otherwise cfg80211 will crash.

Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agotracing: change CPU ring buffer state from tracing_cpumask
Vaibhav Nagarnaik [Fri, 4 May 2012 01:59:52 +0000]
tracing: change CPU ring buffer state from tracing_cpumask

commit 71babb2705e2203a64c27ede13ae3508a0d2c16c upstream.

According to Documentation/trace/ftrace.txt:


        This is a mask that lets the user only trace
        on specified CPUS. The format is a hex string
        representing the CPUS.

The tracing_cpumask currently doesn't affect the tracing state of
per-CPU ring buffers.

This patch enables/disables CPU recording as its corresponding bit in
tracing_cpumask is set/unset.

Link: http://lkml.kernel.org/r/1336096792-25373-3-git-send-email-vnagarnaik@google.com

Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Laurent Chavey <chavey@google.com>
Cc: Justin Teravest <teravest@google.com>
Cc: David Sharp <dhsharp@google.com>
Signed-off-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoiwlwifi: remove log_event debugfs file debugging is disabled
Johannes Berg [Wed, 20 Jun 2012 06:46:25 +0000]
iwlwifi: remove log_event debugfs file debugging is disabled

commit 882b7b7d11d65e8eccce738f1ce97cdfdb998f9f upstream.

When debugging is disabled, the event log functions aren't
functional in the way that the debugfs file expects. This
leads to the debugfs access crashing. Since the event log
functions aren't functional then, remove the debugfs file
when CONFIG_IWLWIFI_DEBUG is not set.

Reported-by: Lekensteyn <lekensteyn@gmail.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomac80211: fix queues stuck issue with HT bandwidth change
Johannes Berg [Wed, 27 Jun 2012 16:11:56 +0000]
mac80211: fix queues stuck issue with HT bandwidth change

No upstream commit, the buggy code was removed in 3.5 in commit
7213cf2cb0dfbb4d6b55a1da000d34338f76c0e3 and others.

Rajkumar changed code for handling channel switching in
mac80211 to stop the queues in

  commit 7cc44ed48d0ec0937c1f098642540b6c9ca38de5
  Author: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
  Date:   Fri Sep 16 15:32:34 2011 +0530

      mac80211: Fix regression on queue stop during 2040 bss change

which went into 3.2. In the 3.4 cycle, Paul's change

  commit 3117bbdb7899d43927c8ce4fe885ab7c1231c121
  Author: Paul Stewart <pstew@chromium.org>
  Date:   Tue Mar 13 07:46:18 2012 -0700

      mac80211: Don't let regulatory make us deaf

went in and changed the TX/RX enable logic, but now
the conditions for stopping and restarting the queues
were different so that now, if the AP changes between
20/40 MHz bandwidth, it can happen that we stop but
never restart the queues. This breaks the connection
and the module actually has to be reloaded to get it
back to work.

Fix this by making sure the queues are always started
when they were stopped.

Reported-by: Florian Manschwetus <manschwetus@googlemail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoNFS: hard-code init_net for NFS callback transports
Stanislav Kinsbursky [Mon, 25 Jun 2012 20:40:10 +0000]
NFS: hard-code init_net for NFS callback transports

upstream commit 12918b10d59e975fd5241eef03ef9e6d5ea3dcfe.

In case of destroying mount namespace on child reaper exit, nsproxy is zeroed
to the point already. So, dereferencing of it is invalid.
This patch hard-code "init_net" for all network namespace references for NFS
callback services. This will be fixed with proper NFS callback

Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoSUNRPC: move per-net operations from svc_destroy()
Stanislav Kinsbursky [Mon, 25 Jun 2012 20:40:09 +0000]
SUNRPC: move per-net operations from svc_destroy()

upstream commit 786185b5f8abefa6a8a16695bb4a59c164d5a071.

The idea is to separate service destruction and per-net operations,
because these are two different things and the mix looks ugly.


1) For NFS server this patch looks ugly (sorry for that). But these
place will be rewritten soon during NFSd containerization.

2) LockD per-net counter increase int lockd_up() was moved prior to
make_socks() to make lockd_down_net() call safe in case of error.

Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoSUNRPC: new svc_bind() routine introduced
Stanislav Kinsbursky [Mon, 25 Jun 2012 20:40:08 +0000]
SUNRPC: new svc_bind() routine introduced

upstream commit 9793f7c88937e7ac07305ab1af1a519225836823.

This new routine is responsible for service registration in a specified
network context.

The idea is to separate service creation from per-net operations.

Note also: since registering service with svc_bind() can fail, the
service will be destroyed and during destruction it will try to
unregister itself from rpcbind. In this case unregistration has to be

Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoLockd: pass network namespace to creation and destruction routines
Stanislav Kinsbursky [Mon, 25 Jun 2012 20:40:07 +0000]
Lockd: pass network namespace to creation and destruction routines

upstream commit e3f70eadb7dddfb5a2bb9afff7abfc6ee17a29d0.

v2: dereference of most probably already released nlm_host removed in
nlmclnt_done() and reclaimer().

These routines are called from locks reclaimer() kernel thread. This thread
works in "init_net" network context and currently relays on persence on lockd
thread and it's per-net resources. Thus lockd_up() and lockd_down() can't relay
on current network context. So let's pass corrent one into them.

Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoipheth: add support for iPad
Davide Gerhard [Mon, 25 Jun 2012 07:04:47 +0000]
ipheth: add support for iPad

commit 6de0298ec9c1edaf330b71b57346241ece8f3346 upstream.

This adds support for the iPad to the ipheth driver.
(product id = 0x129a)

Signed-off-by: Davide Gerhard <rainbow@irh.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoPCI: EHCI: fix crash during suspend on ASUS computers
Alan Stern [Mon, 9 Jul 2012 15:09:21 +0000]
PCI: EHCI: fix crash during suspend on ASUS computers

commit dbf0e4c7257f8d684ec1a3c919853464293de66e upstream.

Quite a few ASUS computers experience a nasty problem, related to the
EHCI controllers, when going into system suspend.  It was observed
that the problem didn't occur if the controllers were not put into the
D3 power state before starting the suspend, and commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers) was created to do this.

It turned out this approach messed up other computers that didn't have
the problem -- it prevented USB wakeup from working.  Consequently
commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add
NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it
reverted the earlier commit and added a whitelist of known good board

Now we know the actual cause of the problem.  Thanks to AceLan Kao for
tracking it down.

According to him, an engineer at ASUS explained that some of their
BIOSes contain a bug that was added in an attempt to work around a
problem in early versions of Windows.  When the computer goes into S3
suspend, the BIOS tries to verify that the EHCI controllers were first
quiesced by the OS.  Nothing's wrong with this, but the BIOS does it
by checking that the PCI COMMAND registers contain 0 without checking
the controllers' power state.  If the register isn't 0, the BIOS
assumes the controller needs to be quiesced and tries to do so.  This
involves making various MMIO accesses to the controller, which don't
work very well if the controller is already in D3.  The end result is
a system hang or memory corruption.

Since the value in the PCI COMMAND register doesn't matter once the
controller has been suspended, and since the value will be restored
anyway when the controller is resumed, we can work around the BIOS bug
simply by setting the register to 0 during system suspend.  This patch
(as1590) does so and also reverts the second commit mentioned above,
which is now unnecessary.

In theory we could do this for every PCI device.  However to avoid
introducing new problems, the patch restricts itself to EHCI host

Finally the affected systems can suspend with USB wakeup working

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728
Based-on-patch-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Dâniel Fraga <fragabr@gmail.com>
Tested-by: Javier Marcet <jmarcet@gmail.com>
Tested-by: Andrey Rahmatullin <wrar@wrar.name>
Tested-by: Oleksij Rempel <bug-track@fisher-privat.net>
Tested-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoxhci: Fix hang on back-to-back Set TR Deq Ptr commands.
Sarah Sharp [Thu, 21 Jun 2012 23:28:30 +0000]
xhci: Fix hang on back-to-back Set TR Deq Ptr commands.

commit 0d9f78a92ef5e97d9fe51d9215ebe22f6f0d289d upstream.

The Microsoft LifeChat 3000 USB headset was causing a very reproducible
hang whenever it was plugged in.  At first, I thought the host
controller was producing bad transfer events, because the log was filled
with errors like:

xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD

However, it turned out to be an xHCI driver bug in the ring expansion
patches.  The bug is triggered When there are two ring segments, and a
TD that ends just before a link TRB, like so:

 ______________                     _____________
|              |              ---> | setup TRB B |
 ______________               |     _____________
|              |              |    |  data TRB B |
 ______________               |     _____________
| setup TRB A  | <-- deq      |    |  data TRB B |
 ______________               |     _____________
| data TRB A   |              |    |             | <-- enq, deq''
 ______________               |     _____________
| status TRB A |              |    |             |
 ______________               |     _____________
|  link TRB    |---------------    |  link TRB   |
 _____________  <--- deq'           _____________

TD A (the first control transfer) stalls on the data phase.  That halts
the ring.  The xHCI driver moves the hardware dequeue pointer to the
first TRB after the stalled transfer, which happens to be the link TRB.

Once the Set TR dequeue pointer command completes, the function
update_ring_for_set_deq_completion runs.  That function is supposed to
update the xHCI driver's dequeue pointer to match the internal hardware
dequeue pointer.  On the first call this would work fine, and the
software dequeue pointer would move to deq'.

However, if the transfer immediately after that stalled (TD B in this
case), another Set TR Dequeue command would be issued.  That would move
the hardware dequeue pointer to deq''.  Once that command completed,
update_ring_for_set_deq_completion would run again.

The original code would unconditionally increment the software dequeue
pointer, which moved the pointer off the ring segment into la-la-land.
The while loop would happy increment the dequeue pointer (possibly
wrapping it) until it matched the hardware pointer value.

The while loop would also access all the memory in between the first
ring segment and the second ring segment to determine if it was a link
TRB.  This could cause general protection faults, although it was
unlikely because the ring segments came from a DMA pool, and would often
have consecutive memory addresses.

If nothing in that space looked like a link TRB, the deq_seg pointer for
the ring would remain on the first segment.  Thus, the deq_seg and the
software dequeue pointer would get out of sync.

When the next transfer event came in after the stalled transfer, the
xHCI driver code would attempt to convert the software dequeue pointer
into a DMA address in order to compare the DMA address for the completed
transfer.  Since the deq_seg and the dequeue pointer were out of sync,
xhci_trb_virt_to_dma would return NULL.

The transfer event would get ignored, the transfer would eventually
timeout, and we would mistakenly convert the finished transfer to no-op
TRBs.  Some kernel driver (maybe xHCI?) would then get stuck in an
infinite loop in interrupt context, and the whole machine would hang.

This patch should be backported to kernels as old as 3.4, that contain
the commit b008df60c6369ba0290fa7daa177375407a12e07 "xHCI: count free
TRBs on transfer ring"

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agousb: Add support for root hub port status CAS
Stanislaw Ledwon [Mon, 18 Jun 2012 13:20:00 +0000]
usb: Add support for root hub port status CAS

commit 8bea2bd37df08aaa599aa361a9f8b836ba98e554 upstream.

The host controller port status register supports CAS (Cold Attach
Status) bit. This bit could be set when USB3.0 device is connected
when system is in Sx state. When the system wakes to S0 this port
status with CAS bit is reported and this port can't be used by any

When CAS bit is set the port should be reset by warm reset. This
was not supported by xhci driver.

The issue was found when pendrive was connected to suspended
platform. The link state of "Compliance Mode" was reported together
with CAS bit. This link state was also not supported by xhci and

The CAS bit is defined only for xhci root hub port and it is
not supported on regular hubs. The link status is used to force
warm reset on port. Make the USB core issue a warm reset when port
is in ether the 'inactive' or 'compliance mode'. Change the xHCI driver
to report 'compliance mode' when the CAS is set. This force warm reset
on the root hub port.

This patch should be backported to stable kernels as old as 3.2, that
contain the commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset."

Signed-off-by: Stanislaw Ledwon <staszek.ledwon@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: option: Add MEDIATEK product ids
Gaosen Zhang [Thu, 5 Jul 2012 13:49:00 +0000]
USB: option: Add MEDIATEK product ids

commit aacef9c561a693341566a6850c451ce3df68cb9a upstream.

Signed-off-by: Gaosen Zhang <gaosen.zhang@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: option: add ZTE MF60
Bjørn Mork [Mon, 2 Jul 2012 17:53:55 +0000]
USB: option: add ZTE MF60

commit 8e16e33c168a6efd0c9f7fa9dd4c1e1db9a74553 upstream.

Switches into a composite device by ejecting the initial
driver CD.  The four interfaces are: QCDM, AT, QMI/wwan
and mass storage.  Let this driver manage the two serial

T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 28 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=19d2 ProdID=1402 Rev= 0.00
S:  Manufacturer=ZTE,Incorporated
S:  Product=ZTE WCDMA Technologies MSM
S:  SerialNumber=xxxxx
C:* #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: cdc-wdm: fix lockup on error in wdm_read
Bjørn Mork [Mon, 2 Jul 2012 08:33:14 +0000]
USB: cdc-wdm: fix lockup on error in wdm_read

commit b086b6b10d9f182cd8d2f0dcfd7fd11edba93fc9 upstream.

Clear the WDM_READ flag on empty reads to avoid running
forever in an infinite tight loop, causing lockups:

Jul  1 21:58:11 nemi kernel: [ 3658.898647] qmi_wwan 2-1:1.2: Unexpected error -71
Jul  1 21:58:36 nemi kernel: [ 3684.072021] BUG: soft lockup - CPU#0 stuck for 23s! [qmi.pl:12235]
Jul  1 21:58:36 nemi kernel: [ 3684.072212] CPU 0
Jul  1 21:58:36 nemi kernel: [ 3684.072355]
Jul  1 21:58:36 nemi kernel: [ 3684.072367] Pid: 12235, comm: qmi.pl Tainted: P           O 3.5.0-rc2+ #13 LENOVO 2776LEG/2776LEG
Jul  1 21:58:36 nemi kernel: [ 3684.072383] RIP: 0010:[<ffffffffa0635008>]  [<ffffffffa0635008>] spin_unlock_irq+0x8/0xc [cdc_wdm]
Jul  1 21:58:36 nemi kernel: [ 3684.072388] RSP: 0018:ffff88022dca1e70  EFLAGS: 00000282
Jul  1 21:58:36 nemi kernel: [ 3684.072393] RAX: ffff88022fc3f650 RBX: ffffffff811c56f7 RCX: 00000001000ce8c1
Jul  1 21:58:36 nemi kernel: [ 3684.072398] RDX: 0000000000000010 RSI: 000000000267d810 RDI: ffff88022fc3f650
Jul  1 21:58:36 nemi kernel: [ 3684.072403] RBP: ffff88022dca1eb0 R08: ffffffffa063578e R09: 0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072407] R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000002
Jul  1 21:58:36 nemi kernel: [ 3684.072412] R13: 0000000000000246 R14: ffffffff00000002 R15: ffff8802281d8c88
Jul  1 21:58:36 nemi kernel: [ 3684.072418] FS:  00007f666a260700(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072423] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul  1 21:58:36 nemi kernel: [ 3684.072428] CR2: 000000000270d9d8 CR3: 000000022e865000 CR4: 00000000000007f0
Jul  1 21:58:36 nemi kernel: [ 3684.072433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072438] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jul  1 21:58:36 nemi kernel: [ 3684.072444] Process qmi.pl (pid: 12235, threadinfo ffff88022dca0000, task ffff88022ff76380)
Jul  1 21:58:36 nemi kernel: [ 3684.072448] Stack:
Jul  1 21:58:36 nemi kernel: [ 3684.072458]  ffffffffa063592e 0000000100020000 ffff88022fc3f650 ffff88022fc3f6a8
Jul  1 21:58:36 nemi kernel: [ 3684.072466]  0000000000000200 0000000100000000 000000000267d810 0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072475]  0000000000000000 ffff880212cfb6d0 0000000000000200 ffff880212cfb6c0
Jul  1 21:58:36 nemi kernel: [ 3684.072479] Call Trace:
Jul  1 21:58:36 nemi kernel: [ 3684.072489]  [<ffffffffa063592e>] ? wdm_read+0x1a0/0x263 [cdc_wdm]
Jul  1 21:58:36 nemi kernel: [ 3684.072500]  [<ffffffff8110adb7>] ? vfs_read+0xa1/0xfb
Jul  1 21:58:36 nemi kernel: [ 3684.072509]  [<ffffffff81040589>] ? alarm_setitimer+0x35/0x64
Jul  1 21:58:36 nemi kernel: [ 3684.072517]  [<ffffffff8110aec7>] ? sys_read+0x45/0x6e
Jul  1 21:58:36 nemi kernel: [ 3684.072525]  [<ffffffff813725f9>] ? system_call_fastpath+0x16/0x1b
Jul  1 21:58:36 nemi kernel: [ 3684.072557] Code: <66> 66 90 c3 83 ff ed 89 f8 74 16 7f 06 83 ff a1 75 0a c3 83 ff f4

The WDM_READ flag is normally cleared by wdm_int_callback
before resubmitting the read urb, and set by wdm_in_callback
when this urb returns with data or an error.  But a crashing
device may cause both a read error and cancelling all urbs.
Make sure that the flag is cleared by wdm_read if the buffer
is empty.

We don't clear the flag on errors, as there may be pending
data in the buffer which should be processed.  The flag will
instead be cleared on the next wdm_read call.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>