Age | Commit message (Collapse) | Author |
|
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
|
|
(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
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
Change-Id: I72edfe1faa8ecd4e0664b63a50714970249a0f54
Tracked-On: https://jira01.devtools.intel.com/browse/BP-181
Signed-off-by: Viorel Suman <viorel.suman@intel.com>
|
|
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
|
|
The patch adds the x86_64_brillo_minnowmax_defconfig.
Signed-off-by: Viorel Suman <viorel.suman@intel.com>
|
|
Signed-off-by: Viorel Suman <viorel.suman@intel.com>
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
Change-Id: I53f7b8beba60f08bd1680e16bd5be579021c11cc
Signed-off-by: Russ Weight <russell.h.weight@intel.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
'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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|