aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-03-10net: wireless: bcmdhd: check packet length for event messagesHEADmastermainPatrick Tjin
Check the datalen field is less than the size of packet received from the network. Signed-off-by: Patrick Tjin <pattjin@google.com> Bug: 27335472 [fixes CVE-2016-0802] Signed-off-by: Kees Cook <keescook@chromium.org> Change-Id: I4fdbbe5218c1d34f928069237382c7f9ecb3b25f
2016-03-10net: wireless: bcmdhd: Do not print out device name on invalid lengthPatrick Tjin
(cherry picked from commit b149dd5d22c3e4c2faab0bb934a018888ff99ef3) Signed-off-by: Patrick Tjin <pattjin@google.com> Bug: 27335848 [fixes CVE-2016-0801] Signed-off-by: Kees Cook <keescook@chromium.org> Change-Id: I04297d425d6422b2d5d5e4ffbf07328758a270c7
2016-03-10bcmdhd: Add checks for stack buffer overflowsdataanddreams
These two checks prevent exploitable buffer overflows in two scenarios. 1. Long WPS_ID_DEVICE_NAME in WPS info elements 2. Invalid SSID determined in certain scan results Bug: 27335848 [fixes CVE-2016-0801] Signed-off-by: Kees Cook <keescook@chromium.org> Change-Id: I2d7bc6c707c3d06f5a5ece9458c8731fe009ce52
2016-03-04UPSTREAM: ALSA: usb-audio: avoid freeing umidi object twiceKees Cook
The 'umidi' object will be free'd on the error path by snd_usbmidi_free() when tearing down the rawmidi interface. So we shouldn't try to free it in snd_usbmidi_create() after having registered the rawmidi interface. Found by KASAN. Signed-off-by: Andrey Konovalov <andreyknvl@gmail.com> Acked-by: Clemens Ladisch <clemens@ladisch.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Bug: 27300729 (cherry picked from commit 07d86ca93db7e5cdf4743564d98292042ec21af7) Signed-off-by: Kees Cook <keescook@google.com> Change-Id: I1513b39a837a76959b61fb3309185067b7e9c49d
2016-02-29x86: configs: minnowboard: Turn off kdevtmpfsMihai Serban
Turn off kdevtmpfs because it is causing a race condition between kdevtmpfs node creation and selinux labeling. BUG=27399088 Change-Id: Ib4bcd1427d842220d0f73cabbbdb6ed5491a677e Signed-off-by: Dwane Pottratz <dwane.pottratz@intel.com> Signed-off-by: Mihai Serban <mihai.serban@intel.com>
2016-02-05minnowboard: Disable MINIGZIP. Sync with Edisonbrillo-m10-releasebrillo-m10-devViorel Suman
Disable MINIGZIP so product build will pass for minnowboard. CONFIG_HAVE_KERNEL_LZ4 removed and CONFIG_KERNEL_GZIP enabled so all options are now in sync with Edison. BUG=none Change-Id: I089cdaeb01d1f08d5e1aabf6f0e60c2eeb1b5042 Signed-off-by: Mihai Serban <mihai.serban@intel.com> Signed-off-by: Viorel Suman <viorel.suman@intel.com>
2016-01-22Rename [minnowmax] to [minnowboard]Viorel Suman
Change-Id: I72edfe1faa8ecd4e0664b63a50714970249a0f54 Tracked-On: https://jira01.devtools.intel.com/browse/BP-181 Signed-off-by: Viorel Suman <viorel.suman@intel.com>
2016-01-21UPSTREAM: KEYS: Fix keyring ref leak in join_session_keyring()Yevgeny Pats
This fixes CVE-2016-0728. If a thread is asked to join as a session keyring the keyring that's already set as its session, we leak a keyring reference. This can be tested with the following program: #include <stddef.h> #include <stdio.h> #include <sys/types.h> #include <keyutils.h> int main(int argc, const char *argv[]) { int i = 0; key_serial_t serial; serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING, "leaked-keyring"); if (serial < 0) { perror("keyctl"); return -1; } if (keyctl(KEYCTL_SETPERM, serial, KEY_POS_ALL | KEY_USR_ALL) < 0) { perror("keyctl"); return -1; } for (i = 0; i < 100; i++) { serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING, "leaked-keyring"); if (serial < 0) { perror("keyctl"); return -1; } } return 0; } If, after the program has run, there something like the following line in /proc/keys: 3f3d898f I--Q--- 100 perm 3f3f0000 0 0 keyring leaked-keyring: empty with a usage count of 100 * the number of times the program has been run, then the kernel is malfunctioning. If leaked-keyring has zero usages or has been garbage collected, then the problem is fixed. Reported-by: Yevgeny Pats <yevgeny@perception-point.io> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Don Zickus <dzickus@redhat.com> Acked-by: Prarit Bhargava <prarit@redhat.com> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: James Morris <james.l.morris@oracle.com> Bug: 26692844 (cherry picked from commit 23567fd052a9abb6d67fe8e7a9ccdd9800a540f2) Signed-off-by: Kees Cook <keescook@google.com> Change-Id: I8bc21ef67cef0fbb0ff3b0ebf770882591cdf615
2016-01-07Add x86_64_brillo_minnowmax_defconfigViorel Suman
The patch adds the x86_64_brillo_minnowmax_defconfig. Signed-off-by: Viorel Suman <viorel.suman@intel.com>
2016-01-07Disable -Werror optionViorel Suman
Signed-off-by: Viorel Suman <viorel.suman@intel.com>
2016-01-07SQUASHME! [VPG]: drm/i915: Unpin GGTT vma of the batch_obj at the end of ↵Ankitprasad Sharma
execbuffer SQUASHME! - This patch should be squashed into the following existing patch: Author: John Harrison <John.C.Harrison@Intel.com> Date: Wed Apr 9 13:03:34 2014 +0100 Change-Id: I5e1c77639ce526ab2401b0323186c518bf13da0a FOR_UPSTREAM [VPG]: drm/i915: Split i915_dem_do_execbuffer() in half Some of the pwrite calls on the batch buffer were failing, due to the associated GGTT vma marked as pinned. To update the batch buffer, 3D UMD uses the pwrite interface and for that KMD decides to use the pwrite-fast method. The pwrite-fast method tries to update object pages through the GTT mapping, to avoid the overhead of cache flushing, for that it first binds the object in the Aperture space(256 MB region). This leads to a rebinding if the object is mapped outside the Aperture space and that fails if the vma is marked as pinned resulting in an unsuccessful pwrite call. This GGTT vma pinning of batch buffer is happening from the execbuffer path. In the secure parsing mode, the batch buffer is being pinned in GGTT apart from being pinned to PPGTT. The PPGTT vma is unpinned at the end of execbuffer but the GGTT vma is unpinned when the Scheduler removes the corresponding request from its queue on the completion. This pinning of GGTT vma for extra duration has been causing some of the pwrite calls to fail for the batch buffer. While unbinding any vma (PPGTT/GGTT), the KMD checks whether the object associated with the vma is active or not and not whether the vma itself is part of the corresponding vm’s active list or not. So while unbinding the GGTT vma also, KMD will have to wait for the object to become inactive, if only the PPGTT vma was linked in the active list and the object was marked as active. So the unpinning of GGTT vma for the batch bufer can also be safely performed at the end of execbuffer, as the object is already marked as active and the associated PPGTT vma is also moved to the corresponding vm's active list. That's how it was being done initially in the Upstream patch from Daniel Vetter, before the advent of Scheduler. This issue is so far seen only on VLV. On CHV, batch buffer is not being pinned in GGTT due to some issue with Full PPGTT mode. On BXT, the UMD provided batch buffer is not being submitted to the Hw, rather KMD is copying the contents to its own internal pool of batch buffers, which are then pinned in GGTT and submitted to Hw, so the pwrite calls from the UMD actually operates on the set of batch buffers, allocated by UMD, hence no conflict. Tracked-On: https://jira01.devtools.intel.com/browse/OAM-4364 Change-Id: Ic1b2170054d283253262c521e454279ad2c01bc4 Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com> Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-on: https://android.intel.com:443/430383
2016-01-07power: axp288: fg 100% capacity at full charg stAndrew Kim
it stays under 99% at fully charged state. Hence it's required to set 100% capacity Signed-off-by: Andrew Kim <andrew.kim@intel.com>
2016-01-07x86: configs: add debug_diffconfigEric Ernst
This diffconfig is intended to be used at build time in conjunction with coho's x86_64_defconfig to generate a config for debug builds, and should replace the use of x86_64_debug_defconfig. Change-Id: I3fec9df07dd583796c2c4537d1369e40290a9023 Tracked-On: https://jira01.devtools.intel.com/browse/OAM-5220 Signed-off-by: Eric Ernst <eric.ernst@intel.com>
2016-01-07Update netfilter configuration for Mgeoffroy.weisenhorn
Android Marshmallow add a new subcommand to ndc strict, this needs to activate following netfilter extensions :Connmark, owner , u32 Change-Id: I21f6491367afb3a4dea56f1c4c343e314a2fe822 Tracked-On: https://jira01.devtools.intel.com/browse/OAM-1043 Signed-off-by: geoffroy.weisenhorn <weisenhorn.geoffroy@intel.com>
2016-01-07config: enable debug_info kernel config for cohoImougar, JacquesX
Change-Id: Iddca1a3bc3bbe7a338e1816f40565247dc3ceefc Signed-off-by: Imougar, JacquesX <jaquesx.imougar@intel.com> Tracked-On: https://jira01.devtools.intel.com/browse/OAM-756 Conflicts: arch/x86/configs/x86_64_debug_defconfig
2016-01-07BYT: Create defconfig files for BayTrailRuss Weight
Change-Id: I53f7b8beba60f08bd1680e16bd5be579021c11cc Signed-off-by: Russ Weight <russell.h.weight@intel.com>
2016-01-07BACKPORT: iio: Export userspace IIO headersDaniel Baluta
After UAPI header file split [1] all user-kernel interfaces were placed under include/uapi/. This patch moves IIO user specific API from: * include/linux/iio/events.h => include/uapi/linux/iio/events.h * include/linux/types.h => include/uapi/linux/types.h Now there is no need for nasty tricks to compile userspace programs (e.g iio_event_monitor). Just installing the kernel headers with make headers_install command does the job. [1] http://lwn.net/Articles/507794/ Change-Id: I57f57f83d25a2716a3fb0722e68841049f32ff7b Signed-off-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-01-07BACKPORT: i2c / ACPI: Assign IRQ for devices that have GpioInt automaticallyMika Westerberg
Following what DT already does. If the device does not have ACPI Interrupt resource but instead it has one or more GpioInt resources listed below it, we take the first GpioInt resource, convert it to suitable Linux IRQ number and pass it to the driver instead. This makes drivers simpler because the don't need to care about GPIOs at all if only thing they need is interrupt. Change-Id: I2c72cd5512c161ed44a27c92882c961fede6183f Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: i2c / ACPI: Use 0 to indicate that device does not have interrupt ↵Mika Westerberg
assigned This is the convention used in most parts of the kernel including DT counterpart of I2C slave enumeration. To make things consistent do the same for ACPI I2C slave enumeration path as well. Change-Id: I963d36cfc560bea43bdac7b0abd3784af3aac89d Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: gpio / ACPI: Add support for retrieving GpioInt resources from a ↵Mika Westerberg
device ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter is used to describe that a given device interrupt line is connected to a specific GPIO pin. Typical ACPI _CRS entry for such device looks like below: Name (_CRS, ResourceTemplate () { I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.PCI0.I2C6", 0x00, ResourceConsumer) GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO0", 0x00, ResourceConsumer) { 0x004B } GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000, "\\_SB.GPO0", 0x00, ResourceConsumer) { 0x004C } }) Currently drivers need to request a GPIO corresponding to the right GpioInt and then translate that to Linux IRQ number. This adds unnecessary lines of boiler-plate code. We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to of_irq_get(). This function translates given GpioInt resource under the device in question to the suitable Linux IRQ number. Change-Id: Iea462c47e1328c49a7abe6bb9c24cccd1c1ed0e7 Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: gpio: Fix gpio direction flags not getting setAdrian Hunter
GPIO direction flags are not getting set because an 'if' statement is the wrong way around. Tracked-On: Change-Id: I1147f483d66550fa0d27eab11057e07ffadbb65e Cc: Stable <stable@vger.kernel.org> # 3.15+ Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-01-07BACKPORT: gpio: Make the vararg hacks not pass magic valuesOlliver Schinagl
Right now, in consumer.h, there's some vararg hacks that pass 0 as the flags. What actually is passed however is GPIOD_ASIS, which naturally is also 0. Using the define/enum rather then the magic 0 makes it the define more readable to a passer by. Change-Id: I67970c8dd919701f0d6a923d6f08467e3a118319 Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: gpio: move varargs hack outside #ifdef GPIOLIBLinus Walleij
commit 39b2bbe3d715cf5013b5c48695ccdd25bd3bf120 "gpio: add flags argument to gpiod_get*() functions" added a dynamic flags argument to all the GPIOD getter functions, however this did not cover the stubs so when people used gpiod stubs to compile out descriptor code, compilation failed. Solve this by: - Also rename all the stub functions __gpiod_* - Moving the vararg hack outside of #ifdef CONFIG_GPIOLIB so these will always be available. Change-Id: Ief7f3bdbdb8f5b6c9b22c3bac71cd0d8b5b92808 Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: gpio: move GPIOD flags outside #ifdefLinus Walleij
The GPIOD flags are defined inside the #ifdef CONFIG_GPIOLIB switch, making the gpiolib stubs fail if these flags are used by a consumer. This is not correct: the stubs should compile fine without GPIOLIB. Change-Id: Ib38281ba11d8840a9130d142dfe576817091b0b6 Reported-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: gpio: add flags argument to gpiod_get*() functionsAlexandre Courbot
The huge majority of GPIOs have their direction and initial value set right after being obtained by one of the gpiod_get() functions. The integer GPIO API had gpio_request_one() that took a convenience flags parameter allowing to specify an direction and value applied to the returned GPIO. This feature greatly simplifies client code and ensures errors are always handled properly. A similar feature has been requested for the gpiod API. Since setting the direction of a GPIO is so often the very next action done after obtaining its descriptor, we prefer to extend the existing functions instead of introducing new functions that would raise the number of gpiod getters to 16 (!). The drawback of this approach is that all gpiod clients need to be updated. To limit the pain, temporary macros are introduced that allow gpiod_get*() to be called with or without the extra flags argument. They will be removed once all consumer code has been updated. Change-Id: I9cb24ca5e734dbefa422bde84c73fd6ff952e1ef Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mark Brown <broonie@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: gpio: Add helpers for optional GPIOsThierry Reding
Introduce gpiod_get_optional() and gpiod_get_index_optional() helpers that make it easier for drivers to handle optional GPIOs. Currently in order to handle optional GPIOs, a driver needs to special case error handling for -ENOENT, such as this: gpio = gpiod_get(dev, "foo"); if (IS_ERR(gpio)) { if (PTR_ERR(gpio) != -ENOENT) return PTR_ERR(gpio); gpio = NULL; } if (gpio) { /* set up GPIO */ } With these new helpers the above is reduced to: gpio = gpiod_get_optional(dev, "foo"); if (IS_ERR(gpio)) return PTR_ERR(gpio); if (gpio) { /* set up GPIO */ } While at it, device-managed variants of these functions are also provided. Change-Id: Ia62444ead2f07252a24462542dd8cd59f0cfced0 Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: gpio: Add missing device-managed documentationThierry Reding
Add the GPIO-related device-managed functions to the list of functions in Documentation/driver-model/devres.txt. Change-Id: I5733a4941419c143156258de3a8c7327097b0208 Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: of: add functions to count number of elements in a propertyHeiko Stuebner
The need to know the number of array elements in a property is a common pattern. To prevent duplication of open-coded implementations add a helper static function that also centralises strict sanity checking and DTB format details, as well as a set of wrapper functions for u8, u16, u32 and u64. Change-Id: I4f5cf7b9674ae56e56dc1471bfbe11f1aabcc4e3 Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Heiko Stuebner <heiko.stuebner@bqreaders.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Grant Likely <grant.likely@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: leds: leds-gpio: Fix multiple instances registration without ↵Fabio Estevam
'label' property Since commit a43f2cbbb009f96 ("leds: leds-gpio: Make use of device property API") it is no longer possible to register multiple gpio leds without passing the 'label' property. According to Documentation/devicetree/bindings/leds/common.txt: "Optional properties for child nodes: - label : The label for this LED. If omitted, the label is taken from the node name (excluding the unit address)." So retrieve the node name when the 'label' property is absent to keep the old behaviour and fix this regression. Change-Id: I41a274ae46cf24d76ec5be6ee3b54ee39fc922c5 Fixes: a43f2cbbb009 (leds: leds-gpio: Make use of device property API) Reported-by: Jean-Michel Hautbois <jean-michel.hautbois@vodalys.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Grant Likely <grant.likely@linaro.org> Acked-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: leds: leds-gpio: Fix legacy GPIO number caseGeert Uytterhoeven
In the legacy case, led_dat->gpiod is initialized correctly, but overwritten later by template->gpiod, which is NULL, causing leds-gpio to fail with: gpiod_direction_output: invalid GPIO leds-gpio: probe of leds-gpio failed with error -22 Move the initialization of led_dat->gpiod from template->gpiod up, and always use led_dat->gpiod later, to fix this. Change-Id: I70486fac1b7b910419f8274e4dd3c0b332aec1af Fixes: 5c51277a9ababfa4 (leds: leds-gpio: Add support for GPIO descriptors) Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: ACPI / property: Drop size_prop from acpi_dev_get_property_reference()Rafael J. Wysocki
The size_prop argument of the recently added function acpi_dev_get_property_reference() is not used by the only current caller of that function and is very unlikely to be used at any time going forward. Namely, for a property whose value is a list of items each containing a references to a device object possibly accompanied by some integers, the number of items in the list can always be computed as the number of elements of type ACPI_TYPE_LOCAL_REFERENCE in the property package. Thus it should never be necessary to provide an additional "cells" property with a value equal to the number of items in that list. It also should never be necessary to provide a "cells" property specifying how many integers are supposed to be following each reference. For this reason, drop the size_prop argument from acpi_dev_get_property_reference() and update its caller accordingly. Change-Id: I489fb647c0de6c22788a85688ce7ce596deb3f3d Link: http://marc.info/?l=linux-kernel&m=141511255610556&w=2 Suggested-by: Grant Likely <grant.likely@linaro.org> Acked-by: Grant Likely <grant.likely@linaro.org> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: leds: leds-gpio: Convert gpio_blink_set() to use GPIO descriptorsMika Westerberg
Commit 21f2aae91e902aad ("leds: leds-gpio: Add support for GPIO descriptors") already converted most of the driver to use GPIO descriptors. What is still missing is the platform specific hook gpio_blink_set() and board files which pass legacy GPIO numbers to this driver in platform data. In this patch we handle the former and convert gpio_blink_set() to take GPIO descriptor instead. In order to do this we convert the existing four users to accept GPIO descriptor and translate it to legacy GPIO number in the platform code. This effectively "pushes" legacy GPIO number usage from the driver to platforms. Also add comment to the remaining block describing that it is legacy code path and we are getting rid of it eventually. Change-Id: I970962afec062304c841dafd2147aacaff642f8b Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: ACPI / GPIO: Document ACPI GPIO mappings APIRafael J. Wysocki
Document the previously introduced method that can be used by device drivers to provide the GPIO subsystem with mappings between GPIO names (connection IDs) and GpioIo()/GpioInt() resources in _CRS. Change-Id: I33625a5d3316ba5be10b352d6ac0dda71eba0957 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: net: rfkill: gpio: Add default GPIO driver mappings for ACPIMika Westerberg
The driver uses devm_gpiod_get_index(..., index) so that the index refers directly to the GpioIo resource under the ACPI device. The problem with this is that if the ordering changes we get wrong GPIOs. With ACPI 5.1 _DSD we can now use names instead to reference GPIOs analogous to Device Tree. However, we still have systems out there that do not provide _DSD at all. These systems must be supported as well. Luckily we now have acpi_dev_add_driver_gpios() that can be used to provide mappings for systems where _DSD is not provided and still take advantage of _DSD if it exists. This patch changes the driver to create default GPIO mappings if we are running on ACPI system. While there we can drop the indices completely and use devm_gpiod_get() with name instead. Change-Id: I72c28c64a2dcf93075fb2fdf5889564c31b1ddf9 Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: John W. Linville <linville@tuxdriver.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: ACPI / GPIO: Driver GPIO mappings for ACPI GPIOsRafael J. Wysocki
Provide a way for device drivers using GPIOs described by ACPI GpioIo resources in _CRS to tell the GPIO subsystem what names (connection IDs) to associate with specific GPIO pins defined in there. To do that, a driver needs to define a mapping table as a NULL-terminated array of struct acpi_gpio_mapping objects that each contain a name, a pointer to an array of line data (struct acpi_gpio_params) objects and the size of that array. Each struct acpi_gpio_params object consists of three fields, crs_entry_index, line_index, active_low, representing the index of the target GpioIo()/GpioInt() resource in _CRS starting from zero, the index of the target line in that resource starting from zero, and the active-low flag for that line, respectively. Next, the mapping table needs to be passed as the second argument to acpi_dev_add_driver_gpios() that will register it with the ACPI device object pointed to by its first argument. That should be done in the driver's .probe() routine. On removal, the driver should unregister its GPIO mapping table by calling acpi_dev_remove_driver_gpios() on the ACPI device object where that table was previously registered. Included are fixes from Mika Westerberg. Change-Id: I2d4b3ce095b237c65faefde97f9b6f141d0edac5 Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: input: gpio_keys_polled: Make use of device property APIAaron Lu
Make use of device property API in this driver so that both OF based system and ACPI based system can use this driver. Change-Id: I0f93640cb66446dcb9194e9ff9eba18208e3e788 Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: leds: leds-gpio: Make use of device property APIRafael J. Wysocki
Make use of device property API in this driver so that both OF and ACPI based system can use the same driver. This change contains material from Max Eliaser and Mika Westerberg. Change-Id: Ib3fe53909f9ba2c7d559afa83ffcb0891fd9c33e Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Bryan Wu <cooloney@gmail.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: gpio: Support for unified device properties interfaceMika Westerberg
Some drivers need to deal with only firmware representation of its GPIOs. An example would be a GPIO button array driver where each button is described as a separate firmware node in device tree. Typically these child nodes do not have physical representation in the Linux device model. In order to help device drivers to handle such firmware child nodes we add dev[m]_get_named_gpiod_from_child() that takes a child firmware node pointer as its second argument (the first one is the parent device itself), finds the GPIO using whatever is the underlying firmware method, and requests the GPIO properly. Change-Id: I128f9012b8b95f356cc0767ebcd30ae4bca5224d Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: Driver core: Unified interface for firmware node propertiesRafael J. Wysocki
Add new generic routines are provided for retrieving properties from device description objects in the platform firmware in case there are no struct device objects for them (either those objects have not been created yet or they do not exist at all). The following functions are provided: fwnode_property_present() fwnode_property_read_u8() fwnode_property_read_u16() fwnode_property_read_u32() fwnode_property_read_u64() fwnode_property_read_string() fwnode_property_read_u8_array() fwnode_property_read_u16_array() fwnode_property_read_u32_array() fwnode_property_read_u64_array() fwnode_property_read_string_array() in analogy with the corresponding functions for struct device added previously. For all of them, the first argument is a pointer to struct fwnode_handle (new type) that allows a device description object (depending on what platform firmware interface is in use) to be obtained. Add a new macro device_for_each_child_node() for iterating over the children of the device description object associated with a given device and a new function device_get_child_node_count() returning the number of a given device's child nodes. The interface covers both ACPI and Device Trees. Change-Id: I242df346525a885bddf4ebde44bcae4fca36db21 Suggested-by: Grant Likely <grant.likely@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: input: gpio_keys_polled: Add support for GPIO descriptorsAaron Lu
GPIO descriptors are the preferred way over legacy GPIO numbers nowadays. Convert the driver to use GPIO descriptors internally but still allow passing legacy GPIO numbers from platform data to support existing platforms. Change-Id: I7f9701d24f277f8d686f2ff8b84682552e367616 Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: Input: gpio_keys_polled - convert to devm-* APIAlexander Shiyan
Replace existing resource handling in the driver with managed device resources, this ensures more consistent error values and simplifies error handling paths: kzalloc -> devm_kzalloc gpio_request_one -> devm_gpio_request_one input_allocate_polled_device -> devm_input_allocate_polled_device Change-Id: I05e28358ba3ad6ba21b9f9b78e6de35971eb9e44 Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: leds: leds-gpio: Add support for GPIO descriptorsMika Westerberg
GPIO descriptors are the preferred way over legacy GPIO numbers nowadays. Convert the driver to use GPIO descriptors internally but still allow passing legacy GPIO numbers from platform data to support existing platforms. Change-Id: Ifc7995600ea32f1c79d0637ab8c3cf8db2e49646 Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Bryan Wu <cooloney@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: gpio: sch: Consolidate core and resume banksMika Westerberg
This is actually a single device with two sets of identical registers, which just happen to start from a different offset. Instead of having separate GPIO chips created we consolidate them to be single GPIO chip. In addition having a single GPIO chip allows us to handle ACPI GPIO translation in the core in a more generic way, since the two GPIO chips share the same parent ACPI device. Change-Id: I4314b6f8cdaf6e52d355a8b29ff93364528d5c8e Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: gpio / ACPI: Add support for _DSD device propertiesMika Westerberg
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and other things as well) returned by _CRS. Previously we were only able to use integer index to find the corresponding GPIO, which is pretty error prone if the order changes. With _DSD we can now query GPIOs using name instead of an integer index, like the below example shows: // Bluetooth device with reset and shutdown GPIOs Device (BTH) { Name (_HID, ...) Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {15} GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {27, 31} }) Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }}, Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }}, } }) } The format of the supported GPIO property is: Package () { "name", Package () { ref, index, pin, active_low }} ref - The device that has _CRS containing GpioIo()/GpioInt() resources, typically this is the device itself (BTH in our case). index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero. pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero. active_low - If 1 the GPIO is marked as active_low. Since ACPI GpioIo() resource does not have field saying whether it is active low or high, the "active_low" argument can be used here. Setting it to 1 marks the GPIO as active low. In our Bluetooth example the "reset-gpio" refers to the second GpioIo() resource, second pin in that resource with the GPIO number of 31. This patch implements necessary support to gpiolib for extracting GPIOs using _DSD device properties. Change-Id: I15e493bfb76c752c0dff1526eaae945325ee4e9f Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: misc: at25: Make use of device property APIMika Westerberg
Make use of device property API in this driver so that both DT and ACPI based systems can use this driver. In addition we hard-code the name of the chip to be "at25" for the reason that there is no common mechanism to fetch name of the firmware node. The only existing user (arch/arm/boot/dts/phy3250.dts) uses the same name so it should continue to work. Change-Id: I3bf9066ebfd439f4b6ca348e3e12b29e7f76fc1b Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: ACPI: Allow drivers to match using Device Tree compatible propertyMika Westerberg
We have lots of existing Device Tree enabled drivers and allocating separate _HID for each is not feasible. Instead we allocate special _HID "PRP0001" that means that the match should be done using Device Tree compatible property using driver's .of_match_table instead if the driver is missing .acpi_match_table. If there is a need to distinguish from where the device is enumerated (DT/ACPI) driver can check dev->of_node or ACPI_COMPATION(dev). Change-Id: I0a3ce9df31447725c9c46152d0c432d07e76bb51 Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: Driver core: Unified device properties interface for platform firmwareRafael J. Wysocki
Add a uniform interface by which device drivers can request device properties from the platform firmware by providing a property name and the corresponding data type. The purpose of it is to help to write portable code that won't depend on any particular platform firmware interface. The following general helper functions are added: device_property_present() device_property_read_u8() device_property_read_u16() device_property_read_u32() device_property_read_u64() device_property_read_string() device_property_read_u8_array() device_property_read_u16_array() device_property_read_u32_array() device_property_read_u64_array() device_property_read_string_array() The first one allows the caller to check if the given property is present. The next 5 of them allow single-valued properties of various types to be retrieved in a uniform way. The remaining 5 are for reading properties with multiple values (arrays of either numbers or strings). The interface covers both ACPI and Device Trees. This change set includes material from Mika Westerberg and Aaron Lu. Change-Id: I0dafade9aa0b1ee73d2616c53cc3aee66801c44e Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07BACKPORT: ACPI: Add support for device specific propertiesMika Westerberg
Device Tree is used in many embedded systems to describe the system configuration to the OS. It supports attaching properties or name-value pairs to the devices it describe. With these properties one can pass additional information to the drivers that would not be available otherwise. ACPI is another configuration mechanism (among other things) typically seen, but not limited to, x86 machines. ACPI allows passing arbitrary data from methods but there has not been mechanism equivalent to Device Tree until the introduction of _DSD in the recent publication of the ACPI 5.1 specification. In order to facilitate ACPI usage in systems where Device Tree is typically used, it would be beneficial to standardize a way to retrieve Device Tree style properties from ACPI devices, which is what we do in this patch. If a given device described in ACPI namespace wants to export properties it must implement _DSD method (Device Specific Data, introduced with ACPI 5.1) that returns the properties in a package of packages. For example: Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"name1", <VALUE1>}, Package () {"name2", <VALUE2>}, ... } }) The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301 and is documented in the ACPI 5.1 companion document called "_DSD Implementation Guide" [1], [2]. We add several helper functions that can be used to extract these properties and convert them to different Linux data types. The ultimate goal is that we only have one device property API that retrieves the requested properties from Device Tree or from ACPI transparent to the caller. [1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm [2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf Change-Id: Ia017170f209f1148c9e2bf9cfcd9a297ebd9da1d Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Robert Dolca <robert.dolca@intel.com>
2016-01-07input: only send a syn event when needed in input_dev_release_keysTing Li
On input_dev_release_keys, even if there is no key need to release, it still send a spurious SYN evnet. In this case, if user poll the event device with EPOLLWAKEUP enable, there will always be wakeup event to stop system enter suspend Tracked-On: https://jira01.devtools.intel.com/browse/OAM-105 Tracked-On: https://jira01.devtools.intel.com/browse/OAM-78 Change-Id: I2210491f2e89992debcf40ae7b2b60f2e0060b58 Signed-off-by: Ting Li <ting.li@intel.com>
2016-01-07SQUASHME! [VPG]: drm/i915: Change permissions for i915_videostatus nodePraveen Paneri
The permissions shouldn't have been granted to others and should have been granted only to the user. SQUASHME! - This patch should be squashed into the following existing patch: Author: sudheer gurram <sudheer.gurram@intel.com> Change-Id: I30a18d01f5735546c80ac5660b45c0419771ed98 MUST_REBASE [VPG]: drm/i915: Fix for the gamma curve issue Following patch enables DPST in video playback scenarios based on a setting, which is passed from user mode process(CoreU) Tracked-On: https://jira01.devtools.intel.com/browse/OAM-2284 Change-Id: I23f6e66bf186ad894df9d616e57c03bea09f3113 Signed-off-by: Praveen Paneri <praveen.paneri@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-26 19:06:31 +0000