Wire up f2fs with fscrypt direct I/O support. direct I/O with fscrypt is
only supported through blk-crypto (i.e. CONFIG_BLK_INLINE_ENCRYPTION must
have been enabled, the 'inlinecrypt' mount option must have been specified,
and either hardware inline encryption support must be present or
CONFIG_BLK_INLINE_ENCYRPTION_FALLBACK must have been enabled). Further,
direct I/O on encrypted files is only supported when I/O is aligned
to the filesystem block size (which is *not* necessarily the same as the
block device's block size).
Signed-off-by: Eric Biggers <ebiggers@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Acked-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 162255927
Link: https://lore.kernel.org/r/20200724184501.1651378-6-satyat@google.com
Change-Id: I2efde5aed559ba59f964d7d2e54f73414062daf8
Signed-off-by: Eric Biggers <ebiggers@google.com>
Wire up ext4 with fscrypt direct I/O support. Direct I/O with fscrypt is
only supported through blk-crypto (i.e. CONFIG_BLK_INLINE_ENCRYPTION must
have been enabled, the 'inlinecrypt' mount option must have been specified,
and either hardware inline encryption support must be present or
CONFIG_BLK_INLINE_ENCYRPTION_FALLBACK must have been enabled). Further,
direct I/O on encrypted files is only supported when I/O is aligned
to the filesystem block size (which is *not* necessarily the same as the
block device's block size).
fscrypt_limit_io_blocks() is called before setting up the iomap to ensure
that the blocks of each bio that iomap will submit will have contiguous
DUNs. Note that fscrypt_limit_io_blocks() is normally a no-op, as normally
the DUNs simply increment along with the logical blocks. But it's needed
to handle an edge case in one of the fscrypt IV generation methods.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 162255927
Link: https://lore.kernel.org/r/20200724184501.1651378-5-satyat@google.com
Change-Id: Ia3d869cefabdff070f4e77c46190351f6cb5d74c
Signed-off-by: Eric Biggers <ebiggers@google.com>
Set bio crypt contexts on bios by calling into fscrypt when required.
No DUN contiguity checks are done - callers are expected to set up the
iomap correctly to ensure that each bio submitted by iomap will not have
blocks with incontiguous DUNs by calling fscrypt_limit_io_blocks()
appropriately.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Bug: 162255927
Link: https://lore.kernel.org/r/20200724184501.1651378-4-satyat@google.com
Change-Id: I34bd73001d53c854b5905799d3a9c31762914763
Signed-off-by: Eric Biggers <ebiggers@google.com>
Set bio crypt contexts on bios by calling into fscrypt when required,
and explicitly check for DUN continuity when adding pages to the bio.
(While DUN continuity is usually implied by logical block contiguity,
this is not the case when using certain fscrypt IV generation methods
like IV_INO_LBLK_32).
Signed-off-by: Eric Biggers <ebiggers@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 162255927
Link: https://lore.kernel.org/r/20200724184501.1651378-3-satyat@google.com
Change-Id: I57ff74185004371c01ec35d806b0749583375c58
Signed-off-by: Eric Biggers <ebiggers@google.com>
The upstream version of the direct I/O on encrypted files patch series
missed exporting this function, which is needed if ext4 is built as a
module.
Bug: 162255927
Fixes: 0ea0eb628fee ("FROMLIST: fscrypt: Add functions for direct I/O support")
Change-Id: Ib827b4743423c7446436a47fcf95b255466288a3
Signed-off-by: Satya Tangirala <satyat@google.com>
Introduce fscrypt_dio_supported() to check whether a direct I/O request
is unsupported due to encryption constraints.
Also introduce fscrypt_limit_io_blocks() to limit how many blocks can be
added to a bio being prepared for direct I/O. This is needed for
filesystems that use the iomap direct I/O implementation to avoid DUN
wraparound in the middle of a bio (which is possible with the
IV_INO_LBLK_32 IV generation method). Elsewhere fscrypt_mergeable_bio()
is used for this, but iomap operates on logical ranges directly, so
filesystems using iomap won't have a chance to call fscrypt_mergeable_bio()
on every block added to a bio. So we need this function which limits a
logical range in one go.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Co-developed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Bug: 162255927
Link: https://lore.kernel.org/r/20200724184501.1651378-2-satyat@google.com
Change-Id: I1dbd4f382d510d9b779d5e44a77fadf7040cf077
Signed-off-by: Eric Biggers <ebiggers@google.com>
Revert the direct I/O support for encrypted files so that we can bring
in the latest version of the patches from the mailing list. This is
needed because in v5.5 and later, the ext4 support (via fs/iomap/) is
broken as-is -- not only is the second call to fscrypt_limit_dio_pages()
in the wrong place, but bios can exceed the intended nr_pages limit due
to multipage bvecs. In order to fix this we need the v6 patches which
make fs/ext4/ handle the limiting instead of fs/iomap/.
On android-mainline, this fixes a failure in vts_kernel_encryption_test
(specifically, FBEPolicyTest#TestAesEmmcOptimizedPolicy) when run on a
device that uses the inlinecrypt mount option on ext4 (e.g. db845c).
Bug: 162255927
Bug: 171462575
Change-Id: I0da753dc9e0e7bc8d84bbcadfdfcdb9328cdb8d8
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
fw_devlink.strict makes sure all the iommus and dmas probe before their
consumers. Without this, some consumers could probe before the
iommus/dmas and function without iommu/dma capability.
For Android, if an iommu/dma is listed as a supplier for a device tree
node, we assume the driver for the iommu/dma exists and will be loaded.
Bug: 181264536
Signed-off-by: Saravana Kannan <saravanak@google.com>
Change-Id: I36e69269eb16fbedb8f7efc48e8b0b20c66a765f
When commit 1852ebd135 ("of: irq: make a stub for of_irq_parse_one()")
added a stub for of_irq_parse_one() it set the return value to 0. Return
value of 0 in this instance means the call succeeded and the out_irq
pointer was filled with valid data. So, fix it to return an error value.
Fixes: 1852ebd135 ("of: irq: make a stub for of_irq_parse_one()")
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210210200050.4106032-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8c0381f55b)
Bug: 181264536
Change-Id: I6acb8dfa39f1af04f8c2125434d4fa7969ca77d1
This allows fw_devlink to recognize clock provider drivers that don't
use the device-driver model to initialize the device. fw_devlink will
use this information to make sure consumers of such clock providers
aren't indefinitely blocked from probing, waiting for the power domain
device to appear and bind to a driver.
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210205222644.2357303-9-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3c9ea42802)
Bug: 181264536
Change-Id: Ib63b6420968cc356c8c4420d8f8538616eccf253
This allows fw_devlink to recognize power domain drivers that don't use
the device-driver model to initialize the device. fw_devlink will use
this information to make sure consumers of such power domain aren't
indefinitely blocked from probing, waiting for the power domain device
to appear and bind to a driver.
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210205222644.2357303-8-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit bab2d712ee)
Bug: 181264536
Change-Id: I31f01b54642bfa395b282c03b9d2ddd4ff69b8f9
This allows fw_devlink to recognize irqdomain drivers that don't use the
device-driver model to initialize the device. fw_devlink will use this
information to make sure consumers of such irqdomain aren't indefinitely
blocked from probing, waiting for the irqdomain device to appear and
bind to a driver.
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210205222644.2357303-7-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ed1054a02a)
Bug: 181264536
Change-Id: I9e97c4b27d09f7ab60b1a3bc67c360e550d8bab0
Device links only work between devices that use the driver core to match
and bind a driver to a device. So, add an API for frameworks to let the
driver core know that a fwnode has been initialized by a driver without
using the driver core.
Then use this information to make sure that fw_devlink doesn't make the
consumers wait indefinitely on suppliers that'll never bind to a driver.
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210205222644.2357303-6-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 74c782cff7)
Bug: 181264536
Change-Id: Ie3cccda6ae82bc3edfd138200bdca1a72316cb02
During the initial parsing of firmware by fw_devlink, fw_devlink might
infer that some supplier firmware nodes would get populated as devices.
But the inference is not always correct. This patch tries to logically
detect and fix such mistakes as boot progresses or more devices probe.
fw_devlink makes a fundamental assumption that once a device binds to a
driver, it will populate (i.e: add as struct devices) all the child
firmware nodes that could be populated as devices (if they aren't
populated already).
So, whenever a device probes, we check all its child firmware nodes. If
a child firmware node has a corresponding device populated, we don't
modify the child node or its descendants. However, if a child firmware
node has not been populated as a device, we delete all the fwnode links
where the child node or its descendants are suppliers. This ensures that
no other device is blocked on a firmware node that will never be
populated as a device. We also mark such fwnodes as NOT_DEVICE, so that
no new fwnode links are created with these nodes as suppliers.
Fixes: e590474768 ("driver core: Set fw_devlink=on by default")
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210205222644.2357303-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9528e0d9c1)
Bug: 181264536
Change-Id: I76f38f22cb11b85a8b6104c131924357d5254640
Dmitry reported[1] boot error messages caused by
commit 4731210c09 ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default").
gpio-1022 (cpu-pwr-req-hog): hogged as input
max77620-pinctrl max77620-pinctrl: pin gpio4 already requested by max77620-pinctrl; cannot claim for gpiochip1
max77620-pinctrl max77620-pinctrl: pin-4 (gpiochip1) status -22
max77620-pinctrl max77620-pinctrl: could not request pin 4 (gpio4) from group gpio4 on device max77620-pinctrl
gpio_stub_drv gpiochip1: Error applying setting, reverse things back
gpio_stub_drv: probe of gpiochip1 failed with error -22
This happens because when we try to probe a device, driver core calls
into pinctrl to set up the pins. However, if the GPIO DT node already
has a proper device created and probed, trying to probe the gpio_device
with a stub driver makes the pins be claimed twice. pinctrl doesn't like
this and throws an error.
So, this patch makes sure the gpio_stub_drv doesn't match with a
gpio_device if it's not the primary device for the fwnode.
[1] - https://lore.kernel.org/lkml/544ad0e4-0954-274c-8e77-866aaa5661a8@gmail.com/
Fixes: 4731210c09 ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default")
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210205020730.1746354-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ced2af4195)
Bug: 181264536
Change-Id: I2004a6c3a71900bbab75a95d436c79cd29e5b4b9
There are multiple instances of GPIO device tree nodes of the form:
foo {
compatible = "acme,foo";
...
gpio0: gpio0@xxxxxxxx {
compatible = "acme,bar";
...
gpio-controller;
};
gpio1: gpio1@xxxxxxxx {
compatible = "acme,bar";
...
gpio-controller;
};
...
}
bazz {
my-gpios = <&gpio0 ...>;
}
Case 1: The driver for "foo" populates struct device for these gpio*
nodes and then probes them using a driver that binds with "acme,bar".
This driver for "acme,bar" then registers the gpio* nodes with gpiolib.
This lines up with how DT nodes with the "compatible" property are
typically converted to struct devices and then registered with driver
core to probe them. This also allows the gpio* devices to hook into all
the driver core capabilities like runtime PM, probe deferral,
suspend/resume ordering, device links, etc.
Case 2: The driver for "foo" doesn't populate struct devices for these
gpio* nodes before registering them with gpiolib. Instead it just loops
through its child nodes and directly registers the gpio* nodes with
gpiolib.
Drivers that follow case 2 cause problems with fw_devlink=on. This is
because fw_devlink will prevent bazz from probing until there's a struct
device that has gpio0 as its fwnode (because bazz lists gpio0 as a GPIO
supplier). Once the struct device is available, fw_devlink will create a
device link with gpio0 device as the supplier and bazz device as the
consumer. After this point, since the gpio0 device will never bind to a
driver, the device link will prevent bazz device from ever probing.
Finding and refactoring all the instances of drivers that follow case 2
will cause a lot of code churn and it is not something that can be done
in one shot. In some instances it might not even be possible to refactor
them cleanly. Examples of such instances are [1] [2].
This patch works around this problem and avoids all the code churn by
simply setting the fwnode of the gpio_device and creating a stub driver
to bind to the gpio_device. This allows all the consumers to continue
probing when the driver follows case 2.
[1] - https://lore.kernel.org/lkml/20201014191235.7f71fcb4@xhacker.debian/
[2] - https://lore.kernel.org/lkml/e28e1f38d87c12a3c714a6573beba6e1@kernel.org/
Fixes: e590474768 ("driver core: Set fw_devlink=on by default")
Cc: Marc Zyngier <maz@kernel.org>
Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210122193600.1415639-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4731210c09)
Bug: 181264536
Change-Id: Ibf379aa8daae91abdc7b6e7684c9c2668efba039
Sometimes, firmware can have cyclic dependencies between devices. But
one or more of those dependencies in the cycle are false dependencies
that don't affect the probing of the device.
fw_devlink can detect some of these false dependencies using logic. But
when it can't, we don't want to block probing of the devices in this
cyclic dependency.
So, instead of using normal device links for the devices in this cycle,
we need to switch to SYNC_STATE_ONLY device links between these devices.
This is so that sync_state() callback correctness is still maintained
while we allow these device to probe.
This is functionally similar to switching to fw_devlink=permissive just
for the devices in the cycle.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201218031703.3053753-5-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b0e2fa4f61)
Bug: 181264536
Change-Id: I79e604495b71acd13a83231c76af06e035176c1f
This flag can never be added to a device link that already exists and
doesn't have the flag set. It can only be added when a device link is
created for the first time or it can be maintained if the device link
already has the it set.
This flag will be used for marking device links created ONLY by
inferring dependencies from data and NOT from explicit action by device
drivers/frameworks. This will be useful in the future when we need to
deal with cycles in dependencies inferred from firmware.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201218031703.3053753-3-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4b9bbb29ba)
Bug: 181264536
Change-Id: Ibcaef9e50f25027f35b1d47ee935b538fffb9c87
There's insufficient logging when device links or fw_devlink (waiting to
create device links) cause probe deferrals. This makes it hard to debug
devices not getting probed. So, add debug logs to make it easy to debug.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201218031703.3053753-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1f0dfa0545)
Bug: 181264536
Change-Id: Ia8978a22888018c9bbb4ca542a29a25c1d473386
Devices with plenty of RAM may benefit from THP usage. Enable THP while
setting CONFIG_TRANSPARENT_HUGEPAGE_MADVISE require explicit opt-in for
the feature by default in sysfs.
Bug: 179484689
Bug: 179223738
Signed-off-by: Collin Fijalkovich <cfijalkovich@google.com>
Change-Id: If85765daba3817dac38e7bf29530acfaed1d50a3
If the no_hash_pointers command line parameter is set, then
printk("%p") will print pointers as unhashed, which is useful for
debugging purposes. This change applies to any function that uses
vsprintf, such as print_hex_dump() and seq_buf_printf().
A large warning message is displayed if this option is enabled.
Unhashed pointers expose kernel addresses, which can be a security
risk.
Also update test_printf to skip the hashed pointer tests if the
command-line option is set.
Signed-off-by: Timur Tabi <timur@kernel.org>
Acked-by: Petr Mladek <pmladek@suse.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Marco Elver <elver@google.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20210214161348.369023-4-timur@kernel.org
(cherry picked from commit 5ead723a20)
Bug: 181049978
Change-Id: I06c5cfdc0b4c12f38c9109179f27bf2b54ac57e8
Signed-off-by: Chris Goldsworthy <cgoldswo@codeaurora.org>
Export is_dma_buf_file function which will be used
by the minidump module to get dmabuf info.
Bug: 180978053
Change-Id: Ic8f7dd4f0a620839ab19f52841e9a6541515133c
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
Export zone_watermark_ok and its friends so that modules
can use it to determine if zone watermarks are ok in the system.
Bug: 140294230
Change-Id: I958961150cf0c6db318f3e0daf1543ced00a9aab
Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
The DualSense features 5 player LEDs below its touchpad, which are
meant as player id indications. The LEDs are configured with a
player ID determined by an ID allocator, which assign player ids
to ps_device instances.
This patch is a combination of the following original patches
minus use of LED framework APIs:
- HID: playstation: add DualSense player LEDs support.
- HID: playstation: DualSense set LEDs to default player id.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Barnabás Pőcze <pobrn@protonmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Change-Id: I2a9ef9949bb82df18247a14e64cb8c54e9b3924c
(cherry picked from commit 949aaccda0)
Signed-off-by: Kim Low <kim-huei.low@sony.com>
The DualSense controller has a built-in microphone exposed as an
audio device over USB (or HID using Bluetooth). A dedicated
button on the controller handles mute, but software has to configure
the device to mute the audio stream.
This patch captures the mute button and schedules an output report
to mute/unmute the audio stream as well as toggle the mute LED.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Barnabás Pőcze <pobrn@protonmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Change-Id: I6fce08b0b28c1cf41c682a2ff5655f00d7a52843
(cherry picked from commit c26e48b150)
Signed-off-by: Kim Low <kim-huei.low@sony.com>
The comparison of value with the array size ps_gamepad_hat_mapping
appears to be off-by-one. Fix this by using >= rather than > for the
size comparison.
Addresses-Coverity: ("Out-of-bounds read")
Fixes: bc2e15a9a0 ("HID: playstation: initial DualSense USB support.")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Change-Id: I24f4c7f8d48ab8ff1d117d33c7914b8d2e4292f8
(cherry picked from commit 50ab1ffd7c)
Signed-off-by: Kim Low <kim-huei.low@sony.com>
The ret variable in ps_battery_get_property is set in an error path,
but never actually returned. Change the function to return ret.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Change-Id: Ieeaff4d249a6ee6d02eb4746f9fe502c91c6f40a
(cherry picked from commit 5fb5255124)
Signed-off-by: Kim Low <kim-huei.low@sony.com>
Retrieve DualSense hardware and firmware information using a vendor
specific feature report. Report the data through sysfs and also
report using hid_info as there can be signficant differences between
versions.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Barnabás Pőcze <pobrn@protonmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Change-Id: I9a8e338d1a9726510194a4d41911dda8bb6371fc
(cherry picked from commit 0b25b55d34)
Signed-off-by: Kim Low <kim-huei.low@sony.com>
The DualSense features a haptics system based on voicecoil motors,
which requires PCM data (or special HID packets using Bluetooth). There
is no appropriate API yet in the Linux kernel to expose these. The
controller also provides a classic rumble feature for backwards
compatibility. Expose this classic rumble feature using the FF framework.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Barnabás Pőcze <pobrn@protonmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Change-Id: Ia4d664c4a1dedbadce6baf54962595616265eb4f
(cherry picked from commit 51151098d7)
Signed-off-by: Kim Low <kim-huei.low@sony.com>
This patch adds support for the DualSense when operating in Bluetooth mode.
The device has the same behavior as the DualShock 4 in that by default it
sends a limited input report (0x1), but after requesting calibration data,
it switches to an extended input report (report 49), which adds data for
touchpad, motion sensors, battery and more.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Barnabás Pőcze <pobrn@protonmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Change-Id: I6ba3eb018f9938b71bb63cb70b26e4acdcfb788a
(cherry picked from commit 799b2b533a)
Signed-off-by: Kim Low <kim-huei.low@sony.com>
The DualSense features an accelerometer and gyroscope. The data is
embedded into the main HID input reports. Expose both sensors through
through a separate evdev node.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Barnabás Pőcze <pobrn@protonmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Change-Id: I27909fb116a56be52cc12336dc34ca8b4189423e
(cherry picked from commit 402987c5d9)
Signed-off-by: Kim Low <kim-huei.low@sony.com>
Implement support for PlayStation DualSense gamepad in USB mode.
Support features include buttons and sticks, which adhere to the
Linux gamepad spec.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Barnabás Pőcze <pobrn@protonmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Change-Id: I7cf496f9b6f721cdd3e79387caa86b2ccc6378fb
(cherry picked from commit bc2e15a9a0)
Signed-off-by: Kim Low <kim-huei.low@sony.com>
Some rt tasks undergo sync wakeup. Currently, these tasks will be placed
on other, often sleeping or otherwise idle CPUs, which can lead to
unnecessary power hits.
Bug: 157906395
Change-Id: I48864d0847bbe4f7813c842032880ad3f3b8b06b
Signed-off-by: J. Avila <elavila@google.com>
A vendor defined driver uses strncpy_from_user in an ioctl.
Bug: 181111492
Change-Id: Ie6b6ac32b0097337dc9ef307a3f5e13a0bc91229
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
Signed-off-by: Giuliano Procida <gprocida@google.com>
