pinctrl: sirf: add usp0_uart_nostreamctrl pin group for usp-uart without flowctrl

this patch adds the lost pin group which supports to let USP0 to simulate
a UART without hardware flow control.

Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
arm/dts: sirf: fix the pingroup name mismatch between drivers and dts

in drivers/pinctrl/sirf, pingroup name is cko0 and cko1, but in dts, they
are cko0 and cko1_rst. this patch fixes the error in dts.

Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
drm/crtc-helper: explicit DPMS on after modeset

Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.

This change has already been applied to the i915 modeset code in

commit e3de42b68478a8c95dd27520e9adead2af9477a5
Author: Imre Deak <imre.deak@intel.com>
Date:   Fri May 3 19:44:07 2013 +0200

    drm/i915: force full modeset if the connector is in DPMS OFF mode

which according to Greg KH seems to aim for a new record in most
Bugzilla: links in a commit message.

The history of this dpms forcing is pretty interesting. This patch
here is an almost-revert of

commit 811aaa55ba21ab37407018cfc01770d6b037d3fb
Author: Keith Packard <keithp@keithp.com>
Date:   Thu Feb 3 16:57:28 2011 -0800

    drm: Only set DPMS ON when actually configuring a mode

which fixed the bug of trying to dpms on disabled outputs, but
introduced the new discrepancy between an fb update only and full
modesets. The actual introduction of this goes back to

commit bf9dc102e284a5aa78c73fc9d72e11d5ccd8669f
Author: Keith Packard <keithp@keithp.com>
Date:   Fri Nov 26 10:45:58 2010 -0800

    drm: Set connector DPMS status to ON in drm_crtc_helper_set_config

And if you'd dig around in the i915 driver code there's even more fun
around forcing dpms on and losing our heads and temper of the
resulting inconsistencies. Especially the DP re-training code had tons
of funny stuff in it.

v2: So v1 totally blew up on resume on my radeon system here. After
much head-scraching I've figured out that the radeon resume functions
resumes the console system _before_ it actually restores all the
modeset state. And resuming the console systems means that fbdev doeas
an immediate ->set_par call.

Now up to this patch that ->set_par did absolutely nothing: All the
old sw state from pre-suspend was still around (since the modeset
reset wasn't done yet), which means that the set_config calls done as
a result of the ->set_par where all treated as no-ops (despite that
the real hw state was obviously something completely different).

Since v1 of this patch just added a bunch of ->dpms calls if the crtc
was enabled, those set_config calls suddenly stopped being no-ops. But
because the hw state wasn't restored the ->dpms callbacks resulted in
decent amounts of hilarity and eventual full hangs.

Since I can't review all kms drivers for such tricky ordering
constraints v2 opts for a different approach and forces a full modeset
if the connector dpms state isnt' DPMS_ON. Since the ->dpms callbacks
implemented by the modeset helpers update the connector->dpms property
we have the same effect of ensuring that the pipe is ultimately turned
on, even if we just end up updating the fb. This is the same approac
we ended up using in the intel driver.

Note that besides i915.ko only all other drivers eventually call
drm_helper_connector_dpms with the exception of vmwgfx, which does not
support dmps at all.

v3: Dave Airlie merged the broken first version of this patch, so
squash in the revert of

commit 372835a8527f85b3eff20a18c2c339e827dfd4e4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Jun 15 00:13:13 2013 +0200

    drm/crtc-helper: explicit DPMS on after modeset

Also fix up the spelling fail a bit in the commit message while at it.

Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67043
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6

Fixes for some locking issues, and fence timeouts.

* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nouveau: do not allow negative sizes for now
  drm/nouveau: add falcon interrupt handler
  drm/nouveau: use dedicated channel for async moves on GT/GF chipsets.
  drm/nouveau: bump fence timeout to 15 seconds
  drm/nouveau: do not unpin in nouveau_gem_object_del
  drm/nv50/kms: fix pin refcnt leaks
  drm/nouveau: fix some error-path leaks in fbcon handling code
  drm/nouveau: fix locking issues in page flipping paths
Thermal: Fix lockup of cpu_down()

Commit f1a18a105 "Thermal: CPU Package temperature thermal" had code
that did a get_online_cpus(), run a loop and then do a
put_online_cpus(). The problem is that the loop had an error exit that
would skip the put_online_cpus() part.

In the error exit part of the function, it also did a get_online_cpus(),
run a loop and then put_online_cpus(). The only way to get to the error
exit part is with get_online_cpus() already performed. If this error
condition is hit, the system will be prevented from taking CPUs offline.
The process taking the CPU offline will lock up hard.

Removing the get_online_cpus() removes the lockup as the hotplug CPU
refcount is back to zero.

This was bisected with ktest.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Merge tag 'drm-intel-fixes-2013-07-22' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

- fixup panel fitter readout for gen2/3 (just quitens dmesg noise)
- fix pft computations for non-autoscaled resolutions (i.e. letter/pillar
  boxing on gen2/3)
- preserve the DDI A/E lane sharing bit (Stéphane Marchesin)
- fix the "rc6 fails to work after resume" regression, big thanks to
  Konstantin Khlebnikov for the patch and debug insight about what
  actually might be going on here
- fix Oops in is_crtc_connector_off (Chris)
- sanitize shared dpll state - our new paranoid state checker tripped up
  over dirt left behind by the BIOS
- correctly restore fences, fixes the "my screen is all messed up after
  resume" regression introduced in the final 3.10 pull request
- quirk backlights harder, this time for Dell XPS13 machines to fix a
  regression (patch from Kamal Mostafa)
- 90% fix for some haswell hangs when accessing registers concurrently,
  the 100% solution is simply too invasive for -fixes and what we have
  here seems to be good enough (Chris)

* tag 'drm-intel-fixes-2013-07-22' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: fix up gt init sequence fallout
  drm/i915: Serialize almost all register access
  drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight
  drm/i915: correctly restore fences with objects attached
  drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off()
  drm/i915: Sanitize shared dpll state
  drm/i915: fix long-standing SNB regression in power consumption after resume v2
  drm/i915: Preserve the DDI_A_4_LANES bit from the bios
  drm/i915: fix pfit regression for non-autoscaled resolutions
  drm/i915: fix up readout of the lvds dither bit on gen2/3
ath10k: ATH10K should depend on HAS_DMA

If NO_DMA=y:

drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_htt_rx_ring_free':
drivers/net/wireless/ath/ath10k/htt_rx.c:113: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_htt_rx_amsdu_pop':
drivers/net/wireless/ath/ath10k/htt_rx.c:296: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:389: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `__ath10k_htt_rx_ring_fill_n':
drivers/net/wireless/ath/ath10k/htt_rx.c:146: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:150: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_htt_rx_attach':
drivers/net/wireless/ath/ath10k/htt_rx.c:474: undefined reference to `dma_alloc_coherent'
drivers/net/wireless/ath/ath10k/htt_rx.c:509: undefined reference to `dma_free_coherent'
drivers/net/wireless/ath/ath10k/htt_rx.c:514: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ath10k_htt_rx_detach':
drivers/net/wireless/ath/ath10k/htt_rx.c:220: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:228: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
MAINTAINERS: add ath10k

I forgot to add an entry to MAINTAINERS when submitting the driver.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
pch_dma: fix error return code in pch_dma_probe()

Fix to return -ENODEV when no proper base address found error
handling case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
MAINTAINERS: update ath6kl git location

The git tree is in github.com nowadays.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ASoC: core: double free in snd_soc_add_platform()

There are three callers for this function, and none of them want it to
free platform for them.  It leads to a double free.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
ARM: document DEBUG_UNCOMPRESS Kconfig option

This non-user visible option lacked any kind of documentation.  This
is quite common for non-user visible options; certian people can't
understand the point of documenting such options with help text.

However, here we have a case in point: developers don't understand the
option either, as they were thinking that when the option is not set,
the decompressor should produce no output what so ever.  This is
incorrect, as the purpose of this option is to control whether a
multiplatform kernel uses the kernel debugging macros to produce
output or not.

So let's document this via help rather than commentry to prevent others
falling into this misunderstanding.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ASoC: tegra: correct playback_dma_data setup

The errors were caused by copy/paste mistake in below commit
since v3.10:
3489d50 ASoC: tegra: Use common DAI DMA data struct

It also corrects slave_id initialization in tegra20_ac97 driver.

Signed-off-by: Richard Zhao <rizhao@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: <stable@vger.kernel.org> # 3.10
ARM: 7784/1: mm: ensure SMP alternates assemble to exactly 4 bytes with Thumb-2

Commit ae8a8b9553bd ("ARM: 7691/1: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE
and use ALT_SMP instead") added early function returns for page table
cache flushing operations on ARMv7 SMP CPUs.

Unfortunately, when targetting Thumb-2, these `mov pc, lr' sequences
assemble to 2 bytes which can lead to corruption of the instruction
stream after code patching.

This patch fixes the alternates to use wide (32-bit) instructions for
Thumb-2, therefore ensuring that the patching code works correctly.

Cc: <stable@vger.kernel.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory

When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().

At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.

This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.

The algorithm applied is:

* Default memblock_limit to arm_lowmem_limit in the absence of any other
  limit; arm_lowmem_limit is the highest memory that is mapped by
  map_lowmem().

* While walking the list of memblocks, if the start of a block is not
  aligned, 2nd-level page tables will need to be allocated to map the
  first few pages of the block. Hence, the memblock_limit must be before
  the start of the block.

* Similarly, if the end of any block is not aligned, 2nd-level page
  tables will need to be allocated to map the last few pages of the
  block. Hence, the memblock_limit must point at the end of the block,
  rounded down to section-alignment.

* The memory blocks are assumed to be sorted in address order, so the
  first unaligned block start or end is used to set the limit.

With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.

[swarren, wrote commit description, rewrote calculation of memblock_limit]

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7786/1: hyp: fix macro parameterisation

Currently, compare_cpu_mode_with_primary uses a mixture of macro
arguments and hardcoded registers, and does so incorrectly, as it
stores (__boot_cpu_mode_offset | BOOT_CPU_MODE_MISMATCH) to
(__boot_cpu_mode + &__boot_cpu_mode_offset), which could corrupt an
arbitrary portion of memory.

This patch fixes up compare_cpu_mode_with_primary to use the macro
arguments, correctly updating __boot_cpu_mode.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <cdall@cs.columbia.edu>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
mac80211: prevent the buffering or frame transmission to non-assoc mesh STA

This patch is intended to avoid the buffering to non-assoc mesh STA
and also to avoid the triggering of frame to non-assoc mesh STA which
could cause kernel panic in specific hw.

One of the examples, is kernel panic happens to ath9k if user space
inserts the mesh STA and not proceed with the SAE and AMPE, and later
the same mesh STA is detected again. The sta_state of the mesh STA remains
at IEEE80211_STA_NONE and if the ieee80211_sta_ps_deliver_wakeup is called
and subsequently the ath_tx_aggr_wakeup, the kernel panic due to
ath_tx_node_init is not called before to initialize the require data
structures.

This issue is reported by Cedric Voncken before.
http://www.spinics.net/lists/linux-wireless/msg106342.html

[<831ea6b4>] ath_tx_aggr_wakeup+0x44/0xcc [ath9k]
[<83084214>] ieee80211_sta_ps_deliver_wakeup+0xb8/0x208 [mac80211]
[<830b9824>] ieee80211_mps_sta_status_update+0x94/0x108 [mac80211]
[<83099398>] ieee80211_sta_ps_transition+0xc94/0x34d8 [mac80211]
[<8022399c>] nf_iterate+0x98/0x104
[<8309bb60>] ieee80211_sta_ps_transition+0x345c/0x34d8 [mac80211]

Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwlwifi: add DELL SKU for 5150 HMC

This SKU was missing in the list of supported devices

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

Cc: <stable@vger.kernel.org> [all versions]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
HID: Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""

This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887.

This patch re-adds the workaround introduced by 596264082f10dd4
which was reverted by 8af6c08830b1ae114.

The original patch 596264 was needed to overcome a situation where
the hid-core would drop incoming reports while probe() was being
executed.

This issue was solved by c849a6143bec520af which added
hid_device_io_start() and hid_device_io_stop() that enable a specific
hid driver to opt-in for input reports while its probe() is being
executed.

Commit a9dd22b730857347 modified hid-logitech-dj so as to use the
functionality added to hid-core. Having done that, workaround 596264
was no longer necessary and was reverted by 8af6c08.

We now encounter a different problem that ends up 'again' thwarting
the Unifying receiver enumeration. The problem is time and usb controller
dependent. Ocasionally the reports sent to the usb receiver to start
the paired devices enumeration fail with -EPIPE and the receiver never
gets to enumerate the paired devices.

With dcd9006b1b053c7b1c the problem was "hidden" as the call to the usb
driver became asynchronous and none was catching the error from the
failing URB.

As the root cause for this failing SET_REPORT is not understood yet,
-possibly a race on the usb controller drivers or a problem with the
Unifying receiver- reintroducing this workaround solves the problem.

Overall what this workaround does is: If an input report from an
unknown device is received, then a (re)enumeration is performed.

related bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649

Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: hid-logitech-dj: querying_devices was never set

Set querying_devices flag to true when we start the enumeration
process.

This was missing from the original patch. It never produced
undesirable effects as it is highly improbable to have a second
enumeration triggered while a first one was still in progress.

Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>