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
6602a4baf4 (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>
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 3287c24088)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 03b054e969)
Signed-off-by: Mark Brown <broonie@linaro.org>
Commit e81c8f18af
"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 0d74d4a161)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 1eb207a9ec)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 acf564a8f3)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 e81c8f18af)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 5b81d55c4c)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 256aeb6487)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 6abab2d4be)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 9ee1f7d266)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 7db9af4b6e)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 7970cb770d)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 a2df4269ca)
Signed-off-by: Mark Brown <broonie@linaro.org>
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 ad42fc6c84)
Signed-off-by: Mark Brown <broonie@linaro.org>
commit b22f5126a2 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: 2bc780499a ("[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>
commit 668f9abbd4 upstream.
Commit bf6bddf192 ("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>
commit a79121d3b5 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>
commit 825600c0f2 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>
commit 6797b39e6f 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>
commit 421e08c41f 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>
commit 00a1a053eb 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>
commit 41261b6a83 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>
commit 1aa9578c1a 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>
