Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

Merge branch 'v3.10/topic/gator' of git://git.linaro.org/kernel/linux-linaro-stable into linux-linaro-lsk

Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

Merge in gator version 5.18

Merge branch 'v3.10/topic/pinctrl' of git://git.linaro.org/kernel/linux-linaro-stable into linux-linaro-lsk

gator: Add config for building the module in-tree

Signed-off-by: Jon Medhurst <tixy@linaro.org>

gator-daemon: Fix compilation error: 'sa_family_t' does not name a type

When compiling on Linaro Android we get the following error:

bionic/libc/kernel/common/linux/netlink.h:52:2: error: 'sa_family_t' does not name a type
  sa_family_t nl_family;

This is related to an issue that was fixed in Linux 3.1 by commit
6602a4baf4d1a73c (net: Make userland include of netlink.h more sane)
but it seems that the Linux headers used by bionic predate that.

Fortunately, the fix for us is simple: reorder the header file includes
so that the definition of sa_family_t from sys/socket.h is picked up
before being used by linux/netlink.h

Signed-off-by: Jon Medhurst <tixy@linaro.org>

gator: Version 5.18

Signed-off-by: Jon Medhurst <tixy@linaro.org>

Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

Merge branch 'v3.10/topic/aosp-warnings' of git://git.linaro.org/kernel/linux-linaro-stable into linux-linaro-lsk-android

net: ipv6: Fix ipv6_recv_error signature

When the ipv6 ping code was backported the code appears to have been
cherry picked from upstream without adjusting the signature of
ipv6_recv_error(). In upstream and in the cherry pick the final addr_len
parameter has been dropped but the v3.10 definition had this argument.
Adjust the definition and all callers to follow the upstream pattern.

Signed-off-by: Mark Brown <broonie@linaro.org>

net: ipv6: Add missing const to ipv6_chk_addr

The net_device used by ipv6_chk_addr is const in some users so add a
const here, fixing a warning following mainline commit 6bc19fb82d4c05
(Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) from
David S. Miller.

Signed-off-by: Mark Brown <broonie@linaro.org>

Merge branch 'v3.10/topic/configs' of git://git.linaro.org/kernel/linux-linaro-stable into linux-linaro-lsk

configs: Enable TUN by default

There some tests in LTP for TUN so make sure we get coverage.

Signed-off-by: Mark Brown <broonie@linaro.org>

Merge branch 'v3.10/topic/big.LITTLE' of git://git.linaro.org/kernel/linux-linaro-stable into linux-linaro-lsk

Merge branch 'for-lsk' of git://git.linaro.org/arm/big.LITTLE/mp into lsk-v3.10-big.LITTLE

Revert "hmp: sched: Clean up hmp_up_threshold checks into a utility fn"

This reverts commit 765aae26e6e296333c3a5f7a02360f5389dc439a.

Signed-off-by: Jon Medhurst <tixy@linaro.org>

Revert "sched: hmp: unify active migration code"

This reverts commit 0baa5811bacf15b0e76ee85ce29fedffb5136313.

Signed-off-by: Jon Medhurst <tixy@linaro.org>

Revert "hmp: Use idle pull to perform forced up-migrations"

This reverts commit aae7721f20f2520d24a149408a74f18e58f56472.

Signed-off-by: Jon Medhurst <tixy@linaro.org>

Revert "hmp: dont attempt to pull tasks if affinity doesn't allow it"

This reverts commit 5a570cfc01b06906faa8ac67ad7c0c6f278761c4.

Signed-off-by: Jon Medhurst <tixy@linaro.org>

net: ipv6: Fix ipv6_recv_error signature

When the ipv6 ping code was backported the code appears to have been
cherry picked from upstream without adjusting the signature of
ipv6_recv_error(). In upstream and in the cherry pick the final addr_len
parameter has been dropped but the v3.10 definition had this argument.
Adjust the definition and all callers to follow the upstream pattern.

Signed-off-by: Mark Brown <broonie@linaro.org>

net: ipv6: Add missing const to ipv6_chk_addr

The net_device used by ipv6_chk_addr is const in some users so add a
const here, fixing a warning following mainline commit 6bc19fb82d4c05
(Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) from
David S. Miller.

Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: utils : add support to pass config type in generic util APIs

Add support to pass the config type like GROUP or PIN when using
the utils or generic pin configuration APIs. This will make the
APIs more generic.

Added additional inline APIs such that it can be use directly as
callback for the pinctrl_ops.

Changes from V1:
- Remove separate implementation for pins and group for
  pinctrl_utils_dt_free_map and improve this function
  to support both i.e. PINS and GROUPs.

[For LSK restore the original API and add a _new() variant of the
functions for external consumption instead, maintaining the existing API
-- broonie]

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry-picked from commit 3287c24088abded9f111ca797fdd36f86912d199)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: Pass all configs to driver on pin_config_set()

When setting pin configuration in the pinctrl framework, pin_config_set() or
pin_config_group_set() is called in a loop to set one configuration at a time
for the specified pin or group.

This patch 1) removes the loop and 2) changes the API to pass the whole pin
config array to the driver.  It is now up to the driver to loop through the
configs.  This allows the driver to potentially combine configs and reduce the
number of writes to pin config registers.

All c files changed have been build-tested to verify the change compiles and
that the corresponding .o is successfully generated.

[For LSK this has been modified such that the old API is still present and
instead a new pinconf_set_bulk() callback has been added in order to avoid
breaking other users in the stable kernel -- broonie]

Signed-off-by: Sherman Yin <syin@broadcom.com>
Reviewed-by: Christian Daudt <csd@broadcom.com>
Reviewed-by: Matt Porter <matt.porter@linaro.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 03b054e9696c3cbd3d5905ec96da15acd0a2fe8d)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: add includes and ifdefs for non-DT builds

Commit e81c8f18afc4fdd6e34d8c83814b8b5134dbb30f
"pinctrl: pinconf-generic: add generic APIs for mapping pinctrl node"
Added function prototypes with implicit dependencies
on other header files causing build warnings like this:

In file included from
arch/arm/mach-ux500/board-mop500-pins.c:12:0:
include/linux/pinctrl/pinconf-generic.h:142:3:
warning: 'struct device_node' declared inside parameter list [enabled
by default]
   unsigned *reserved_maps, unsigned *num_maps);
   ^
include/linux/pinctrl/pinconf-generic.h:142:3:
warning: its scope is only this definition or declaration, which is
probably not what you want [enabled by default]
include/linux/pinctrl/pinconf-generic.h:142:3:
warning: 'struct pinctrl_dev' declared inside parameter list [enabled
by default]
include/linux/pinctrl/pinconf-generic.h:145:3:
warning: 'struct device_node' declared inside parameter list [enabled
by default]
   unsigned *num_maps);
   ^
Let's just add ifdefs for non-DT systems (the actual code is
already ifdefed) and #include <linux/device.h> to get the
most important structs and forward-declare the pinctrl
core structs.

Reported-by: Olof Johansson <olof@lixom.net>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 0d74d4a161c9f9870039af414b712552c0ed6dfb)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: add utility functions for add map/configs

Some of pincontrol driver needs the utility function to create map
list. The utility function needed for adding mux, configs etc.

In place of duplicating this in each driver, add the common utility
function in common file and use from device specific driver. This will
reduce the duplicating of code across drivers.

Changes from V1:
- Add this files in this patch and add common utility APIs to here.

Changes from V2:
- Nothing in code.
- Added Reviewed by Stephen.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 1eb207a9ecaafb980704d8bc055a9a0269f62f8e)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: Adds slew-rate, input-enable/disable

This commit adds slew-rate and input-enable/disable support for pinconf
-generic.

Signed-off-by: Sherman Yin <syin@broadcom.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 8ba3f4d00078e7a49c60c0bd6298f29402c3a0a0)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: pinconf-generic: Remove ti prefix in dev_err messages

It does not make sense to show ti prefix in pinconf_generic_dt_subnode_to_map()
dev_err messages.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit acf564a8f325566628a4ee2d9403cf1688cd0796)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: pinconf-generic: add generic APIs for mapping pinctrl node

Add generic APIs to map the DT node and its sub node in pinconf generic
driver. These APIs can be used from driver to parse the DT node who
uses the pinconf generic APIs for defining their nodes.

Changes from V1:
- Add generic property for pins and functions in pinconf-generic.
- Add APIs to map the DT and subnode.
- Move common utils APIs to the pinctrl-utils from this file.
- Update the binding document accordingly.
Changes from V2:
- Rebased the pinctrl binding doc on top of Stephen's cleanup.
- Rename properties "pinctrl-pins" and "pinctrl-function" to
  "pins" and "function".

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit e81c8f18afc4fdd6e34d8c83814b8b5134dbb30f)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: remove bindings for pinconf options needing more thought

Some options currently take arguments in unspecified driver-specific units.
As pointed out by Stephen Warren, driver specific values should not be part
of generic devicetree bindings describing the hardware.

Therefore remove the critical bindings again, before they become part of
an official release.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 5b81d55c4ccf23b9de398f819571dfc8941c7b04)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: set unit for debounce time pinconfig to usec

Currently the debounce time pinconfig option uses an unspecified
"time units" unit. As pinconfig options should use SI units and a
real unit is also necessary for generic dt bindings, change it
to usec. Currently no driver is using the generic pinconfig option
for this, so the unit change is safe to do.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 256aeb648741bf095e884793862d3dfa6b1c1fb5)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: dynamically alloc temp array when parsing dt pinconf options

Allocating the temorary array in pinconf_generic_parse_dt_config on stack
might cause problems later on, when the number of options grows over time.
Therefore also allocate this array dynamically to be on the safe side.

Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 6abab2d4bec982bcefbe99201ddee5f25227daf4)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: handle zero found dt pinconfig properties better

This adds a shortcut when no valid pinconf properties are found
in the parsed dt node, to set the values immediately and return.

Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit e4a8844c04c00a1a64c6779692e1baff3851c1f7)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: clarify some dt pinconfig options

The bias-pull-* options use values > 0 to indicate that the pull should
be activated and optionally also indicate the strength of the pull.
Therefore use an default value of 1 for these options.

Split the low-power-mode option into low-power-enable and -disable.

Update the documentation to describe the param arguments better.

Reported-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 9ee1f7d266aa1e2bfeb20cb5d4ac299c8e8ef8c7)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: add function to parse generic pinconfig properties from a dt node

pinconf_generic_parse_dt_config() takes a node as input and generates an
array of generic pinconfig values from the properties of this node.

As I couldn't find a mechanism to count the number of properties of a node
the function uses internally an array to accept one of parameter and copies
the real present options to a smaller variable at its end.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 7db9af4b6e41be599e0fcd50d687138a5add428c)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: add pinconf-generic define for a pin-default pull

There exist controllers that don't support to set the pull to up or down
separately but instead automatically set the pull direction based on
embedded knowledge inside the controller, for example depending on the
selected mux function of the pin.

Therefore this patch adds another config option to use this default
pull-state for a pin where it is not possible to know or decide if the
pin will be pulled up or down.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 7970cb770dffa23cb20a36f46602e688e075f5d9)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinconf-generic: add BIAS_BUS_HOLD pinconf

Add a new PIN_CONFIG_BIAS_BUS_HOLD pin configuration for a bus holder
pin mode (also known as bus keeper, or repeater). This is a weak latch
which drives the last value on a tristate bus. Another device on the bus
can drive the bus high or low before going tristate to change the value
driven by the pin.

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit a2df4269cad79635201587c5c5404f0b1cb0b05c)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinconf-generic: add drive strength to debugfs output

Add the drive strength pinconf to debugfs output (with the unit "mA").

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 73ae368cd309dae277b66444d471ac62825ee407)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: rip out the direct pinconf API

From the inception ot the pin config API there has been the
possibility to get a handle at a pin directly and configure
its electrical characteristics. For this reason we had:

int pin_config_get(const char *dev_name, const char *name,
               unsigned long *config);
int pin_config_set(const char *dev_name, const char *name,
               unsigned long config);
int pin_config_group_get(const char *dev_name,
               const char *pin_group,
               unsigned long *config);
int pin_config_group_set(const char *dev_name,
               const char *pin_group,
               unsigned long config);

After the introduction of the pin control states that will
control pins associated with devices, and its subsequent
introduction to the device core, as well as the
introduction of pin control hogs that can set up states on
boot and optionally also at sleep, this direct pin control
API is a thing of the past.

As could be expected, it has zero in-kernel users.
Let's delete this API and make our world simpler.

Reported-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit ad42fc6c84795d19972e7f7dee70fe74bec4c2d8)
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: Add void * to pinctrl_pin_desc

drv_data is added to the pinctrl_pin_desc for drivers to define additional
driver-specific per-pin data.

Signed-off-by: Sherman Yin <syin@broadcom.com>
Reviewed-by: Christian Daudt <bcm@fixthebug.org>
Reviewed-by: Matt Porter <matt.porter@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit a30d54218e0306b3b7db7df34fe70d5e86fcbbe2)
Signed-off-by: Mark Brown <broonie@linaro.org>

Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

Merge branch 'thermal-framework' into linux-linaro-lsk

For card https://cards.linaro.org/browse/CARD-1213. This framework tested
under panda ES board with few DT patches backporting.

Merge tag 'v3.10.36' into linux-linaro-lsk

This is the 3.10.36 stable release

Linux 3.10.36

netfilter: nf_conntrack_dccp: fix skb_header_pointer API usages

commit b22f5126a24b3b2f15448c3f2a254fc10cbc2b92 upstream.

Some occurences in the netfilter tree use skb_header_pointer() in
the following way ...

  struct dccp_hdr _dh, *dh;
  ...
  skb_header_pointer(skb, dataoff, sizeof(_dh), &dh);

... where dh itself is a pointer that is being passed as the copy
buffer. Instead, we need to use &_dh as the forth argument so that
we're copying the data into an actual buffer that sits on the stack.

Currently, we probably could overwrite memory on the stack (e.g.
with a possibly mal-formed DCCP packet), but unintentionally, as
we only want the buffer to be placed into _dh variable.

Fixes: 2bc780499aa3 ("[NETFILTER]: nf_conntrack: add DCCP protocol support")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm: close PageTail race

commit 668f9abbd4334e6c29fa8acd71635c4f9101caa7 upstream.

Commit bf6bddf1924e ("mm: introduce compaction and migration for
ballooned pages") introduces page_count(page) into memory compaction
which dereferences page->first_page if PageTail(page).

This results in a very rare NULL pointer dereference on the
aforementioned page_count(page).  Indeed, anything that does
compound_head(), including page_count() is susceptible to racing with
prep_compound_page() and seeing a NULL or dangling page->first_page
pointer.

This patch uses Andrea's implementation of compound_trans_head() that
deals with such a race and makes it the default compound_head()
implementation.  This includes a read memory barrier that ensures that
if PageTail(head) is true that we return a head page that is neither
NULL nor dangling.  The patch then adds a store memory barrier to
prep_compound_page() to ensure page->first_page is set.

This is the safest way to ensure we see the head page that we are
expecting, PageTail(page) is already in the unlikely() path and the
memory barriers are unfortunately required.

Hugetlbfs is the exception, we don't enforce a store memory barrier
during init since no race is possible.

Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Holger Kiehl <Holger.Kiehl@dwd.de>
Cc: Christoph Lameter <cl@linux.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.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>

net: mvneta: rename MVNETA_GMAC2_PSC_ENABLE to MVNETA_GMAC2_PCS_ENABLE

commit a79121d3b57e7ad61f0b5d23eae05214054f3ccd upstream.

Bit 3 of the MVNETA_GMAC_CTRL_2 is actually used to enable the PCS,
not the PSC: there was a typo in the name of the define, which this
commit fixes.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86: fix boot on uniprocessor systems

commit 825600c0f20e595daaa7a6dd8970f84fa2a2ee57 upstream.

On x86 uniprocessor systems topology_physical_package_id() returns -1
which causes rapl_cpu_prepare() to leave rapl_pmu variable uninitialized
which leads to GPF in rapl_pmu_init().

See arch/x86/kernel/cpu/perf_event_intel_rapl.c.

It turns out that physical_package_id and core_id can actually be
retreived for uniprocessor systems too.  Enabling them also fixes
rapl_pmu code.

Signed-off-by: Artem Fetishev <artem_fetishev@epam.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
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>

Input: cypress_ps2 - don't report as a button pads

commit 6797b39e6f6f34c74177736e146406e894b9482b upstream.

The cypress PS/2 trackpad models supported by the cypress_ps2 driver
emulate BTN_RIGHT events in firmware based on the finger position, as part
of this no motion events are sent when the finger is in the button area.

The INPUT_PROP_BUTTONPAD property is there to indicate to userspace that
BTN_RIGHT events should be emulated in userspace, which is not necessary
in this case.

When INPUT_PROP_BUTTONPAD is advertised userspace will wait for a motion
event before propagating the button event higher up the stack, as it needs
current abs x + y data for its BTN_RIGHT emulation. Since in the
cypress_ps2 pads don't report motion events in the button area, this means
that clicks in the button area end up being ignored, so
INPUT_PROP_BUTTONPAD actually causes problems for these touchpads, and
removing it fixes:

https://bugs.freedesktop.org/show_bug.cgi?id=76341

Reported-by: Adam Williamson <awilliam@redhat.com>
Tested-by: Adam Williamson <awilliam@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: synaptics - add manual min/max quirk for ThinkPad X240

commit 8a0435d958fb36d93b8df610124a0e91e5675c82 upstream.

This extends Benjamin Tissoires manual min/max quirk table with support for
the ThinkPad X240.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: synaptics - add manual min/max quirk

commit 421e08c41fda1f0c2ff6af81a67b491389b653a5 upstream.

The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad.
However, these new Synaptics devices report bad axis ranges.
Under Windows, it is not a problem because the Windows driver uses RMI4
over SMBus to talk to the device. Under Linux, we are using the PS/2
fallback interface and it occurs the reported ranges are wrong.

Of course, it would be too easy to have only one range for the whole
series, each touchpad seems to be calibrated in a different way.

We can not use SMBus to get the actual range because I suspect the firmware
will switch into the SMBus mode and stop talking through PS/2 (this is the
case for hybrid HID over I2C / PS/2 Synaptics touchpads).

So as a temporary solution (until RMI4 land into upstream), start a new
list of quirks with the min/max manually set.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: mousedev - fix race when creating mixed device

commit e4dbedc7eac7da9db363a36f2bd4366962eeefcc upstream.

We should not be using static variable mousedev_mix in methods that can be
called before that singleton gets assigned. While at it let's add open and
close methods to mousedev structure so that we do not need to test if we
are dealing with multiplexor or normal device and simply call appropriate
method directly.

This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=71551

Reported-by: GiulioDP <depasquale.giulio@gmail.com>
Tested-by: GiulioDP <depasquale.giulio@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: atomically set inode->i_flags in ext4_set_inode_flags()

commit 00a1a053ebe5febcfc2ec498bd894f035ad2aa06 upstream.

Use cmpxchg() to atomically set i_flags instead of clearing out the
S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the
EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race
where an immutable file has the immutable flag cleared for a brief
window of time.

Reported-by: John Sullivan <jsrhbz@kanargh.force9.co.uk>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

Merge tag 'v3.10.35' into linux-linaro-lsk

This is the 3.10.35 stable release

Linux 3.10.35

sched/autogroup: Fix race with task_groups list

commit 41261b6a832ea0e788627f6a8707854423f9ff49 upstream.

In autogroup_create(), a tg is allocated and added to the task_groups
list. If CONFIG_RT_GROUP_SCHED is set, this tg is then modified while on
the list, without locking. This can race with someone walking the list,
like __enable_runtime() during CPU unplug, and result in a use-after-free
bug.

To fix this, move sched_online_group(), which adds the tg to the list,
to the end of the autogroup_create() function after the modification.

Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1369411669-46971-2-git-send-email-gerald.schaefer@de.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

e100: Fix "disabling already-disabled device" warning

commit 2b6e0ca175fe4a20f21ba82b1e7ccc71029c4dd4 upstream.

In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and
https://bugzilla.redhat.com/show_bug.cgi?id=970480  we
received different reports of e100 throwing the following
warning:

 [<c06a0ba5>] ? pci_disable_device+0x85/0x90
 [<c044a153>] warn_slowpath_fmt+0x33/0x40
 [<c06a0ba5>] pci_disable_device+0x85/0x90
 [<f7fdf7e0>] __e100_shutdown+0x80/0x120 [e100]
 [<c0476ca5>] ? check_preempt_curr+0x65/0x90
 [<f7fdf8d6>] e100_suspend+0x16/0x30 [e100]
 [<c06a1ebb>] pci_legacy_suspend+0x2b/0xb0
 [<c098fc0f>] ? wait_for_completion+0x1f/0xd0
 [<c06a2d50>] ? pci_pm_poweroff+0xb0/0xb0
 [<c06a2de4>] pci_pm_freeze+0x94/0xa0
 [<c0767bb7>] dpm_run_callback+0x37/0x80
 [<c076a204>] ? pm_wakeup_pending+0xc4/0x140
 [<c0767f12>] __device_suspend+0xb2/0x1f0
 [<c076806f>] async_suspend+0x1f/0x90
 [<c04706e5>] async_run_entry_fn+0x35/0x140
 [<c0478aef>] ? wake_up_process+0x1f/0x40
 [<c0464495>] process_one_work+0x115/0x370
 [<c0462645>] ? start_worker+0x25/0x30
 [<c0464dc5>] ? manage_workers.isra.27+0x1a5/0x250
 [<c0464f6e>] worker_thread+0xfe/0x330
 [<c0464e70>] ? manage_workers.isra.27+0x250/0x250
 [<c046a224>] kthread+0x94/0xa0
 [<c0997f37>] ret_from_kernel_thread+0x1b/0x28
 [<c046a190>] ? insert_kthread_work+0x30/0x30

This patch removes pci_disable_device() from __e100_shutdown().
pci_clear_master() is enough.

Signed-off-by: Michele Baldessari <michele@acksyn.org>
Tested-by: Mark Harig <idirectscm@aim.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Fix resume issues on Renesas chips in Samsung laptops

commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d upstream.

Don Zickus <dzickus@redhat.com> writes:

Some co-workers of mine bought Samsung laptops that had mostly usb3 ports.
Those ports did not resume correctly (the driver would timeout communicating
and fail).  This led to frustration as suspend/resume is a common use for
laptops.

Poking around, I applied the reset on resume quirk to this chipset and the
resume started working.  Reloading the xhci_hcd module had been the temporary
workaround.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Don Zickus <dzickus@redhat.com>
Tested-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: wacom - make sure touch_max is set for touch devices

commit 1d0d6df02750b4a6f466768cbfbf860e24f4c8d4 upstream.

Old single touch Tablet PCs do not have touch_max set at
wacom_features. Since touch device at lease supports one
finger, assign touch_max to 1 when touch usage is defined
in its HID Descriptor and touch_max is not pre-defined.

Tested-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Chris Bagwell <chris@cnpbagwell.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: VMX: fix use after free of vmx->loaded_vmcs

commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56 upstream.

After free_loaded_vmcs executes, the "loaded_vmcs" structure
is kfreed, and now vmx->loaded_vmcs points to a kfreed area.
Subsequent free_loaded_vmcs then attempts to manipulate
vmx->loaded_vmcs.

Switch the order to avoid the problem.

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

Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: handle invalid root_hpa everywhere

commit 37f6a4e237303549c8676dfe1fd1991ceab512eb upstream.

Rom Freiman <rom@stratoscale.com> notes other code paths vulnerable to
bug fixed by 989c6b34f6a9480e397b.

Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: MMU: handle invalid root_hpa at __direct_map

commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9 upstream.

It is possible for __direct_map to be called on invalid root_hpa
(-1), two examples:

1) try_async_pf -> can_do_async_pf
    -> vmx_interrupt_allowed -> nested_vmx_vmexit
2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit

Then to load_vmcs12_host_state and kvm_mmu_reset_context.

Check for this possibility, let fault exception be regenerated.

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916

Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: elantech - improve clickpad detection

commit c15bdfd5b9831e4cab8cfc118243956e267dd30e upstream.

The current assumption in the elantech driver that hw version 3 touchpads
are never clickpads and hw version 4 touchpads are always clickpads is
wrong.

There are several bug reports for this, ie:
https://bugzilla.redhat.com/show_bug.cgi?id=1030802
http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux

I've spend a couple of hours wading through various bugzillas, launchpads
and forum posts to create a list of fw-versions and capabilities for
different laptop models to find a good method to differentiate between
clickpads and versions with separate hardware buttons.

Which shows that a device being a clickpad is reliable indicated by bit 12
being set in the fw_version. I've included the gathered list inside the
driver, so that we've this info at hand if we need to revisit this later.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: highbank: avoid L2 cache smc calls when PL310 is not present

commit a56a5cf1f2ec895599eace0ac6eba1e4a489e4bf upstream.

While Midway firmware handles L2 smc calls as nops, the custom smc calls
present a problem when running virtualized Midway guest. They aren't
needed so just avoid calling them.

In the process, cleanup the L2X0 ifdefs and use IS_ENABLED instead.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: move outer_cache declaration out of ifdef

commit 0b53c11d533a8f6688d73fad0baf67dd08ec1b90 upstream.

Move the outer_cache declaration of the CONFIG_OUTER_CACHE ifdef so that
outer_cache can be used inside IS_ENABLED condition.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: core: Replace direct ops->disable usage

commit 66fda75f47dc583f1c187556e9a2c082dd64f8c6 upstream.

There are many places where ops->disable is called directly. Instead we
should use _regulator_do_disable() which also handles gpio regulators.

To be able to use the wrapper function from _regulator_force_disable(),
I moved the _notifier_call_chain() call from _regulator_do_disable() to
_regulator_disable(). This way, _regulator_force_disable() can use
different flags for _notifier_call_chain() without calling it twice.

Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

p54: clamp properly instead of just truncating

commit 608cfbe4abaf76e9d732efd7ed1cfa3998163d91 upstream.

The call to clamp_t() first truncates the variable signed 8 bit and as a
result, the actual clamp is a no-op.

Fixes: 0d78156eef1d ('p54: improve site survey')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

deb-pkg: Fix cross-building linux-headers package

commit f8ce239dfc7ba9add41d9ecdc5e7810738f839fa upstream.

builddeb generates a control file that says the linux-headers package
can only be built for the build system primary architecture.  This
breaks cross-building configurations.  We should use $debarch for this
instead.

Since $debarch is not yet set when generating the control file, set
Architecture: any and use control file variables to fill in the
description.

Fixes: cd8d60a20a45 ('kbuild: create linux-headers package in deb-pkg')
Reported-and-tested-by: "Niew, Sh." <shniew@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86: bpf_jit: support negative offsets

commit fdfaf64e75397567257e1051931f9a3377360665 upstream.

Commit a998d4342337 claimed to introduce negative offset support to x86 jit,
but it couldn't be working, since at the time of the execution
of LD+ABS or LD+IND instructions via call into
bpf_internal_load_pointer_neg_helper() the %edx (3rd argument of this func)
had junk value instead of access size in bytes (1 or 2 or 4).

Store size into %edx instead of %ecx (what original commit intended to do)

Fixes: a998d4342337 ("bpf jit: Let the x86 jit handle negative offsets")
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Cc: Jan Seiffert <kaffeemonster@googlemail.com>
Cc: Eric Dumazet <edumazet@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: max98090: make REVISION_ID readable

commit e126a646f77fdd66978785cb0a3a5e46b07aee2e upstream.

The REVISION_ID register is not currently marked readable. snd_soc_read()
refuses to read the register, and hence probe() fails.

Fixes: d4807ad2c4c0 ("regmap: Check readable regs in _regmap_read")
[exposed the bug, by checking for readability]
Fixes: 685e42154dcf ("ASoC: Replace max98090 Device Driver")
[left out this register from the readable list]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

libceph: resend all writes after the osdmap loses the full flag

commit 9a1ea2dbff11547a8e664f143c1ffefc586a577a upstream.

With the current full handling, there is a race between osds and
clients getting the first map marked full. If the osd wins, it will
return -ENOSPC to any writes, but the client may already have writes
in flight. This results in the client getting the error and
propagating it up the stack. For rbd, the block layer turns this into
EIO, which can cause corruption in filesystems above it.

To avoid this race, osds are being changed to drop writes that came
from clients with an osdmap older than the last osdmap marked full.
In order for this to work, clients must resend all writes after they
encounter a full -> not full transition in the osdmap. osds will wait
for an updated map instead of processing a request from a client with
a newer map, so resent writes will not be dropped by the osd unless
there is another not full -> full transition.

This approach requires both osds and clients to be fixed to avoid the
race. Old clients talking to osds with this fix may hang instead of
returning EIO and potentially corrupting an fs. New clients talking to
old osds have the same behavior as before if they encounter this race.

Fixes: http://tracker.ceph.com/issues/6938
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

libceph: block I/O when PAUSE or FULL osd map flags are set

commit d29adb34a94715174c88ca93e8aba955850c9bde upstream.

The PAUSEWR and PAUSERD flags are meant to stop the cluster from
processing writes and reads, respectively. The FULL flag is set when
the cluster determines that it is out of space, and will no longer
process writes.  PAUSEWR and PAUSERD are purely client-side settings
already implemented in userspace clients. The osd does nothing special
with these flags.

When the FULL flag is set, however, the osd responds to all writes
with -ENOSPC. For cephfs, this makes sense, but for rbd the block
layer translates this into EIO.  If a cluster goes from full to
non-full quickly, a filesystem on top of rbd will not behave well,
since some writes succeed while others get EIO.

Fix this by blocking any writes when the FULL flag is set in the osd
client. This is the same strategy used by userspace, so apply it by
default.  A follow-on patch makes this configurable.

__map_request() is called to re-target osd requests in case the
available osds changed.  Add a paused field to a ceph_osd_request, and
set it whenever an appropriate osd map flag is set.  Avoid queueing
paused requests in __map_request(), but force them to be resent if
they become unpaused.

Also subscribe to the next osd map from the monitor if any of these
flags are set, so paused requests can be unblocked as soon as
possible.

Fixes: http://tracker.ceph.com/issues/6079
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: cx18: check for allocation failure in cx18_read_eeprom()

commit e351bf25fa373a3de0be2141b962c5c3c27006a2 upstream.

It upsets static checkers when we don't check for allocation failure.  I
moved the memset() of "tv" earlier so we don't use uninitialized data on
error.
Fixes: 1d212cf0c2d8 ('[media] cx18: struct i2c_client is too big for stack')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: dw2102: some missing unlocks on error

commit 324ed533bf0b23c309b805272c4ffcc5d51493a6 upstream.

We recently introduced some new error paths but the unlocks are missing.
Fixes: 0065a79a8698 ('[media] dw2102: Don't use dynamic static allocation')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: cxusb: unlock on error in cxusb_i2c_xfer()

commit 1cdbcc5db4e6d51ce9bb1313195167cada9aa6e9 upstream.

We recently introduced some new error paths which are missing their
unlocks.
Fixes: 64f7ef8afbf8 ('[media] cxusb: Don't use dynamic static allocation')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tracing: Fix array size mismatch in format string

commit 87291347c49dc40aa339f587b209618201c2e527 upstream.

In event format strings, the array size is reported in two locations.
One in array subscript and then via the "size:" attribute. The values
reported there have a mismatch.

For e.g., in sched:sched_switch the prev_comm and next_comm character
arrays have subscript values as [32] where as the actual field size is
16.

name: sched_switch
ID: 301
format:
        field:unsigned short common_type;       offset:0;       size:2; signed:0;
        field:unsigned char common_flags;       offset:2;       size:1; signed:0;
        field:unsigned char common_preempt_count;       offset:3;       size:1;signed:0;
        field:int common_pid;   offset:4;       size:4; signed:1;

        field:char prev_comm[32];       offset:8;       size:16;        signed:1;
        field:pid_t prev_pid;   offset:24;      size:4; signed:1;
        field:int prev_prio;    offset:28;      size:4; signed:1;
        field:long prev_state;  offset:32;      size:8; signed:1;
        field:char next_comm[32];       offset:40;      size:16;        signed:1;
        field:pid_t next_pid;   offset:56;      size:4; signed:1;
        field:int next_prio;    offset:60;      size:4; signed:1;

After bisection, the following commit was blamed:
92edca0 tracing: Use direct field, type and system names

This commit removes the duplication of strings for field->name and
field->type assuming that all the strings passed in
__trace_define_field() are immutable. This is not true for arrays, where
the type string is created in event_storage variable and field->type for
all array fields points to event_storage.

Use __stringify() to create a string constant for the type string.

Also, get rid of event_storage and event_storage_mutex that are not
needed anymore.

also, an added benefit is that this reduces the overhead of events a bit more:

   text    data     bss     dec     hex filename
8424787 2036472 1302528 11763787         b3804b vmlinux
8420814 2036408 1302528 11759750         b37086 vmlinux.patched

Link: http://lkml.kernel.org/r/1392349908-29685-1-git-send-email-vnagarnaik@google.com
Cc: Laurent Chavey <chavey@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>

ALSA: compress: Pass through return value of open ops callback

commit 749d32237bf39e6576dd95bfdf24e4378e51716c upstream.

The snd_compr_open function would always return 0 even if the compressed
ops open function failed, obviously this is incorrect. Looks like this
was introduced by a small typo in:

commit a0830dbd4e42b38aefdf3fb61ba5019a1a99ea85
ALSA: Add a reference counter to card instance

This patch returns the value from the compressed op as it should.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

Merge branch 'for-lsk' of git://git.linaro.org/arm/big.LITTLE/mp into linux-linaro-lsk

Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

Conflicts:
arch/arm/include/asm/hardware/coresight.h

Merge branch 'v3.10/topic/configs' of git://git.linaro.org/kernel/linux-linaro-stable into linux-linaro-lsk

Merge branch 'v3.10/topic/arm64-be' of git://git.linaro.org/kernel/linux-linaro-stable into linux-linaro-lsk

thermal: debug: add debug statement for core and step_wise

To ease debugging thermal problem, add these dynamic debug statements
so that user do not need rebuild kernel to see these info.

Based on a patch from Zhang Rui for debugging on bugzilla:
https://bugzilla.kernel.org/attachment.cgi?id=98671

A sample output after we turn on dynamic debug with the following cmd:
is like:

[  355.147627] update_temperature: thermal thermal_zone0: last_temperature=52000, current_temperature=55000
[  355.147636] thermal_zone_trip_update: thermal thermal_zone0: Trip1[type=1,temp=79000]:trend=2,throttle=0
[  355.147644] get_target_state: thermal cooling_device8: cur_state=0
[  355.147647] thermal_zone_trip_update: thermal cooling_device8: old_target=-1, target=-1
[  355.147652] get_target_state: thermal cooling_device7: cur_state=0
[  355.147655] thermal_zone_trip_update: thermal cooling_device7: old_target=-1, target=-1
[  355.147660] get_target_state: thermal cooling_device6: cur_state=0
[  355.147663] thermal_zone_trip_update: thermal cooling_device6: old_target=-1, target=-1
[  355.147668] get_target_state: thermal cooling_device5: cur_state=0
[  355.147671] thermal_zone_trip_update: thermal cooling_device5: old_target=-1, target=-1
[  355.147678] thermal_zone_trip_update: thermal thermal_zone0: Trip2[type=0,temp=90000]:trend=1,throttle=0
[  355.147776] get_target_state: thermal cooling_device0: cur_state=0
[  355.147783] thermal_zone_trip_update: thermal cooling_device0: old_target=-1, target=-1
[  355.147792] thermal_zone_trip_update: thermal thermal_zone0: Trip3[type=0,temp=80000]:trend=1,throttle=0
[  355.147845] get_target_state: thermal cooling_device1: cur_state=0
[  355.147849] thermal_zone_trip_update: thermal cooling_device1: old_target=-1, target=-1
[  355.147856] thermal_zone_trip_update: thermal thermal_zone0: Trip4[type=0,temp=70000]:trend=1,throttle=0
[  355.147904] get_target_state: thermal cooling_device2: cur_state=0
[  355.147908] thermal_zone_trip_update: thermal cooling_device2: old_target=-1, target=-1
[  355.147915] thermal_zone_trip_update: thermal thermal_zone0: Trip5[type=0,temp=60000]:trend=1,throttle=0
[  355.147963] get_target_state: thermal cooling_device3: cur_state=0
[  355.147967] thermal_zone_trip_update: thermal cooling_device3: old_target=-1, target=-1
[  355.147973] thermal_zone_trip_update: thermal thermal_zone0: Trip6[type=0,temp=55000]:trend=1,throttle=1
[  355.148022] get_target_state: thermal cooling_device4: cur_state=0
[  355.148025] thermal_zone_trip_update: thermal cooling_device4: old_target=-1, target=1
[  355.148036] thermal_cdev_update: thermal cooling_device4: zone0->target=1
[  355.169279] thermal_cdev_update: thermal cooling_device4: set to state 1

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
(cherry picked from commit 06475b556cb4863cf1dcace9b2d21dac1fc74daf)

Signed-off-by: Alex Shi <alex.shi@linaro.org>
Conflicts:
drivers/thermal/step_wise.c

MAINTAINERS: add thermal bindings entry in thermal domain

After discussion and agreement of thermal device tree bindings,
it is desirable to properly maintain thermal bindings for
existing and upcoming devices.

As original author of thermal device tree bindings, I am
volunteering to maintain them. This then adds and entry
for device tree bindings under thermal domain.

Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
(cherry picked from commit 1beabfbea3a8648575afe04f6f3ddf107c240fb0)

Signed-off-by: Alex Shi <alex.shi@linaro.org>

hwmon: tmp102: expose to thermal fw via DT nodes

This patch adds to tmp102 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the tmp102 DT node. Otherwise, the driver behavior
will be the same.

Note: This patch has also been reviewed by Jean D. He has
requested to perform a wider inspection of possible
users of thermal and hwmon interaction API. On the other
hand, the change on this patch is acceptable on first
step of overall code change.

Cc: Jean Delvare <khali@linux-fr.org>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
(cherry picked from commit 6a027523f30f1cc90037686e6a682d15c6a555d6)

Signed-off-by: Alex Shi <alex.shi@linaro.org>

hwmon: lm75: expose to thermal fw via DT nodes

This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.

Note: This patch has also been reviewed by Jean D. He has
requested to perform a wider inspection of possible
users of thermal and hwmon interaction API. On the other
hand, the change on this patch is acceptable on first
step of overall code change.

Cc: Jean Delvare <khali@linux-fr.org>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
(cherry picked from commit 22e731838b0e337fed5f16c67aa0b954028dfe93)

Signed-off-by: Alex Shi <alex.shi@linaro.org>

thermal: cpu_cooling: introduce of_cpufreq_cooling_register

This patch introduces an API to register cpufreq cooling device
based on device tree node.

The registration via device tree node differs from normal
registration due to the fact that it is needed to fill
the device_node structure in order to be able to match
the cooling devices with trip points.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
(cherry picked from commit 39d99cff76bf2992fd6dd4b1fc62da139e62e90c)

Signed-off-by: Alex Shi <alex.shi@linaro.org>
Conflicts:
drivers/thermal/Kconfig
drivers/thermal/cpu_cooling.c

thermal: core: introduce thermal_of_cooling_device_register

This patch adds a new API to allow registering cooling devices
in the thermal framework derived from device tree nodes.

This API links the cooling device with the device tree node
so that binding with thermal zones is possible, given
that thermal zones are pointing to cooling device
device tree nodes.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
(cherry picked from commit a116b5d44f144586ef03a93f14ddc63f4a85e906)

Signed-off-by: Alex Shi <alex.shi@linaro.org>
Conflicts:
drivers/thermal/thermal_core.c

thermal: introduce device tree parser

This patch introduces a device tree bindings for
describing the hardware thermal behavior and limits.
Also a parser to read and interpret the data and feed
it in the thermal framework is presented.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Note that, in order to be able to have control
on the sensor registration on the DT thermal zone,
it was required to allow changing the thermal zone
.get_temp callback. For this reason, this patch
also removes the 'const' modifier from the .ops
field of thermal zone devices.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
(cherry picked from commit 4e5e4705bf69ea450f58fc709ac5888f321a9299)

Signed-off-by: Alex Shi <alex.shi@linaro.org>

drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional

When registering a new thermal_device, the thermal framework
will always add a hwmon sysfs interface.

This patch adds a flag to make this behavior optional. Now
when registering a new thermal device, the caller can
optionally inform if hwmon interface is desirable. This can
be done by means of passing a thermal_zone_params.no_hwmon == true.

In order to keep same behavior as of today, all current
calls will by default create the hwmon interface.

Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-acpi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: Zhang Rui <rui.zhang@intel.com>
Suggested-by: Wei Ni <wni@nvidia.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
(cherry picked from commit ccba4ffd9eff6120a20cc7656458ac554aec4b0c)

Signed-off-by: Alex Shi <alex.shi@linaro.org>

thermal: hwmon: move hwmon support to single file

In order to improve code organization, this patch
moves the hwmon sysfs support to a file named
thermal_hwmon. This helps to add extra support
for hwmon without scrambling the code.

In order to do this move, the hwmon list head is now
using its own locking. Before, the list used
the global thermal locking. Also, some minor changes
in the code were required, as recommended by checkpatch.pl.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
(cherry picked from commit 0dd88793aacd7c91b9724be7b618bb3f7c25befe)

Signed-off-by: Alex Shi <alex.shi@linaro.org>

thermal: allow registering without .get_temp

This patch changes the thermal core driver to allow
registration of thermal zones without the .get_temp callback.

The idea behind this change is to allow lazy registration
of sensor callbacks.

The thermal zone will be disabled whenever the ops
does not contain a .get_temp callback. The sysfs interface
will be returning -EINVAL on any temperature read operation.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
(cherry picked from commit 81bd4e1cebed5efb85bd94a15342ee4d6965a416)

Signed-off-by: Alex Shi <alex.shi@linaro.org>

Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android

Merge tag 'v3.10.34' into linux-linaro-lsk

This is 3.10.34 stable release

hmp: dont attempt to pull tasks if affinity doesn't allow it

When looking for a task to be idle-pulled, don't consider tasks
where the affinity does not allow that task to be placed on the
target CPU. Also ensure that tasks with restricted affinity
do not block selecting other unrestricted busy tasks.

Use the knowledge of target CPU more effectively in idle pull
by passing to hmp_get_heaviest_task when we know it, otherwise
only checking for general affinity matches with any of the CPUs
in the bigger HMP domain.

We still need to explicitly check affinity is allowed in idle pull
since if we find no match in hmp_get_heaviest_task we will return
the current one, which may not be affine to the new CPU despite
having high enough load. In this case, there is nothing to move.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

hmp: Use idle pull to perform forced up-migrations

When a normal forced up-migration takes place we stop the task to
be migrated while the target CPU becomes available. This delay can
range from 80us to 1500us on TC2 if the target CPU is in a deep idle
state.

Instead, interrupt the target CPU and ask it to pull a task.
This lets the current eligible task continue executing on the
original CPU while the target CPU wakes. Use a pinned timer to
prevent the pulling CPU going back into power-down with pending
up-migrations.

If we trigger for a nohz kick, it doesn't matter about triggering
for an idle pull since the idle_pull flag will be set when we
execute the softirq and we'll still do the idle pull.

If the target CPU is busy, we will not pull any tasks.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

sched: hmp: unify active migration code

The HMP active migration code is functionally identical to the CFS
active migration code apart from one flag check. Share the code
and make the flag check optional.

Two wrapper functions allow the flag check to be present or not.

Thanks to tixy@linaro.org for pointing out the build break and a
good solution in an earlier version.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

hmp: sched: Clean up hmp_up_threshold checks into a utility fn

In anticipation of modifying the up_threshold handling, make all
instances use the same utility fn to check if a task is eligible
for up-migration. This also removes the previous difference in
threshold comparison where up-migration used '!<threshold' and
idle pull used '>threshold' to decide up-migration eligibility.
Make them both use '!<threshold' instead for consistency, although
this is unlikely to change any results.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

Linux 3.10.34