The function uvcg_queue_next_buffer is used different than its name
suggests. The return value nextbuf is never used by any caller. This
patch reworks the function to its actual purpose, by removing the unused
code and renaming it. The function name uvcg_complete_buffer makes it
more clear that it is actually marking the current video buffer as
complete.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220402232744.3622565-2-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 61aa709ca5)
Bug: 242344221
Change-Id: I50f0995acabff20b36721d368aa9691a713381d7
Signed-off-by: Avichal Rakesh <arakesh@google.com>
The pause flag doesn't appear to serve a purpose as it is possible for
the pump worker thread to not be running when new buffers are queued.
Before the following change was introduced: "43cd0023872e usb: gadget:
uvc_video: add worker to handle the frame pumping", the pause flag
status was discarded and never returned. This masked a current issues of
the userspace receiving non-zero values (considered unsuccessful) and
prevents trace_v4l2_qbuf() from being called.
Signed-off-by: Dan Vacura <w36195@motorola.com>
Link: https://lore.kernel.org/r/20220413192402.26063-1-w36195@motorola.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit be30e35027)
Bug: 242344221
Change-Id: I5c2a67641d8a0af7a11ac43ad57b76b69bba26fc
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Add a configfs entry, "function_name", to change the iInterface field
for VideoControl. This name is used on host devices for user selection,
useful when multiple cameras are present. The default will remain "UVC
Camera".
Signed-off-by: Dan Vacura <w36195@motorola.com>
Link: https://lore.kernel.org/r/20220401160447.5919-1-w36195@motorola.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 324e4f8507)
Bug: 242344221
Change-Id: I5b4666156ce2300ae902bca2ff380560d19d3f0a
Signed-off-by: Avichal Rakesh <arakesh@google.com>
With usb3 we handle many more requests. Decrease the interrupt load by
only enabling the interrupt every quarter of the allocated requests.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
--
v1 -> v2: - edited patch description
- removed extra parantheses
- added a comment for the logic
- using unsigned int instead of int
- reinitializing req_int_count in uvcg_video_enable
v2 -> v3: -
Link: https://lore.kernel.org/r/20210628155311.16762-6-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit fc78941d81)
Bug: 242344221
Change-Id: I4b40c4bbd90b9b8ad85957a77589fb304e00a876
Signed-off-by: Avichal Rakesh <arakesh@google.com>
This patch adds support for scatter gather transfers. If the underlying
gadgets sg_supported == true, then the videeobuf2-dma-sg is used and the
encode routine maps all scatter entries to separate scatterlists for the
usb gadget.
When streaming 1080p with request size of 1024 times 3 bytes top shows a
difference of about 6.4% CPU load applying this patch:
PID USER PR NI VIRT RES %CPU %MEM TIME+ S COMMAND
64 root 0 -20 0.0m 0.0m 7.7 0.0 0:01.25 I [kworker/u5:0-uvcvideo]
83 root 0 -20 0.0m 0.0m 4.5 0.0 0:03.71 I [kworker/u5:3-uvcvideo]
307 root -51 0 0.0m 0.0m 3.8 0.0 0:01.05 S [irq/51-dwc3]
vs.
64 root 0 -20 0.0m 0.0m 5.8 0.0 0:01.79 I [kworker/u5:0-uvcvideo]
306 root -51 0 0.0m 0.0m 3.2 0.0 0:01.97 S [irq/51-dwc3]
82 root 0 -20 0.0m 0.0m 0.6 0.0 0:01.86 I [kworker/u5:1-uvcvideo]
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20210628155311.16762-5-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e81e7f9a0e)
Bug: 242344221
Change-Id: I466e3aaac60ffee4439ecf2b4583dae543e373f4
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Export find_vm_area for obtaining pages of vmalloc'ed memory, which is
required for both GXP and TPU modules.
Bug: 263839332
Change-Id: I1d6c37a5abb6012c3ff295120dd2d3cb2871c820
Signed-off-by: davidchiang <davidchiang@google.com>
-Werror still fails on some arm and arm64 code due to clang issues
(works on gcc!), so disable it when building allmodconfig builds for
now.
Hopefully the clang developers will work on this...
Bug: 199872592
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6ccc856773c40e3c0f541a1316b20e9ae3de4380
(cherry picked from commit eb57c31115)
Signed-off-by: Alistair Delva <adelva@google.com>
... but make it a config option so that broken environments can disable
it when required.
We really should always have a clean build, and will disable specific
over-eager warnings as required, if we can't fix them. But while I
fairly religiously enforce that in my own tree, it doesn't get enforced
by various build robots that don't necessarily report warnings.
So this just makes '-Werror' a default compiler flag, but allows people
to disable it for their configuration if they have some particular
issues.
Occasionally, new compiler versions end up enabling new warnings, and it
can take a while before we have them fixed (or the warnings disabled if
that is what it takes), so the config option allows for that situation.
Hopefully this will mean that I get fewer pull requests that have new
warnings that were not noticed by various automation we have in place.
Knock wood.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3fe617ccaf)
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: If981f26ebe668be7c727661fede10215c4ee5bc5
This reverts commit 7a6ea55aa0.
This hook was removed because there is no user.
But the new project needs this hook.
Bug: 263703180
Change-Id: I14e286fd6d426d4ffdb4cb440477f0fae65e980e
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
crypto_memneq() is one of the utility functions that was intentionally
included in the fips140 module, out of concerns that it would be seen as
"cryptographic" and thus would be required to be included the module for
the FIPS certification. It should not have been removed from the
module, so add it back.
Bug: 188620248
Fixes: 29c427664a ("Merge tag 'android13-5.10.149_r00' into android13-5.10")
Change-Id: I8a19dfd73390f8c1348885f97fa42d900e47b82b
Signed-off-by: Eric Biggers <ebiggers@google.com>
Hunk extracted from commit 70aacfe661
upstream.
If the sqpoll thread has died, the out condition doesn't remove the
waiting task from the waitqueue. The goto and check are not needed, just
make it a break condition after setting the error value. That ensures
that we always remove ourselves from sqo_sq_wait waitqueue.
Bug: 259534862
Reported-by: Xingyuan Mo <hdthky0@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 0f544353fe)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I453c3e23a2f0c5ce6a8dd73dac020ec6f32994ca
SPF attempts page faults without taking the mmap lock, but takes the
PTL. If there is a concurrent fast mremap (at PMD/PUD level), this
can lead to a UAF as fast mremap will only take the PTL locks at the
PMD/PUD level. SPF cannot take the PTL locks at the larger subtree
granularity since this introduces much contention in the page fault
paths.
To address the race:
1) Only try fast mremaps if there are no users of the VMA. Android
is concerned with this optimization in the context of
GC stop-the-world pause. So there are no other threads active
and this should almost always succeed.
2) Speculative faults detect ongoing fast mremaps and fallback
to conventional fault handling (taking mmap read lock).
Bug: 263177905
Change-Id: I23917e493ddc8576de19883cac053dfde9982b7f
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Splice is like read/write and should grab current->nsproxy, denoted by
IO_WQ_WORK_FILES as it refers to current->files as well
Change-Id: I94a99fdef5764e7eda5da778b5b52a150b9fe5eb
Signed-off-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 75454b4bbf)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
SPF attempts page faults without taking the mmap lock, but takes the
PTL. If there is a concurrent fast mremap (at PMD/PUD level), this
can lead to a UAF as fast mremap will only take the PTL locks at the
PMD/PUD level. SPF cannot take the PTL locks at the larger subtree
granularity since this introduces much contention in the page fault
paths.
To address the race:
1) Fast mremaps wait until there are no users of the VMA.
2) Speculative faults detect ongoing fast mremaps and fallback
to conventional fault handling (taking mmap read lock).
Since this race condition is very rare the performance impact is
negligible.
Bug: 263177905
Change-Id: If9755aa4261337fe180e3093a3cefaae8ac9ff1a
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
To enable newer version of DualSense driver, i.e. hid-playstation, we
need to set LEDS_CLASS_MULTICOLOR to "y".
Bug: 260685629
Change-Id: I52b0b1b6a061457e009b62a6bd6b66a91c8c37a2
Signed-off-by: Farid Chahla <farid.chahla@sony.com>
brightness_set_blocking() callback expects function returning int. This fixes
the follwoing build failure:
drivers/hid/hid-playstation.c: In function ‘dualsense_player_led_set_brightness’:
drivers/hid/hid-playstation.c:885:1: error: no return statement in function returning non-void [-Werror=return-type]
}
^
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Bug: 260685629
(cherry picked from commit 3c92cb4cb6)
Change-Id: Id16b960826a26ac22c1a14572444f9af29689ed6
Signed-off-by: Farid Chahla <farid.chahla@sony.com>
The DualSense player LEDs were so far not adjustable from user-space.
This patch exposes each LED individually through the LED class. Each
LED uses the new 'player' function resulting in a name like:
'inputX:white:player-1' for the first LED.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Bug: 260685629
(cherry picked from commit 8c0ab553b0)
Change-Id: I49c699a99b0b8a7bb7980560e3ea7a12faf646aa
Signed-off-by: Farid Chahla <farid.chahla@sony.com>
Player LEDs are commonly found on game controllers from Nintendo and Sony
to indicate a player ID across a number of LEDs. For example, "Player 2"
might be indicated as "-x--" on a device with 4 LEDs where "x" means on.
This patch introduces LED_FUNCTION_PLAYER1-5 defines to properly indicate
player LEDs from the kernel. Until now there was no good standard, which
resulted in inconsistent behavior across xpad, hid-sony, hid-wiimote and
other drivers. Moving forward new drivers should use LED_FUNCTION_PLAYERx.
Note: management of Player IDs is left to user space, though a kernel
driver may pick a default value.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Bug: 260685629
(cherry picked from commit 61177c088a)
Change-Id: Ie1de4d66304bb25fc2c9fcdb1ec9b7589ad9e7ac
Signed-off-by: Farid Chahla <farid.chahla@sony.com>
The DualSense lightbar has so far been supported, but it was not yet
adjustable from user space. This patch exposes it through a multi-color
LED.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Bug: 260685629
(cherry picked from commit fc97b4d6a1)
Change-Id: I48204113da804b13ad5bed2f651a5826ab5a86f7
Signed-off-by: Farid Chahla <farid.chahla@sony.com>
We have a list of valid functions, but LED names in sysfs are still
far from being consistent. Create list of "well known" LED names so we
nudge people towards using same LED names (except color) for same
functionality.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Bug: 260685629
(cherry picked from commit 09f1273064)
Change-Id: Iea12a9c230d6cd072b0f4fd4e0c616348173dd53
Signed-off-by: Farid Chahla <farid.chahla@sony.com>
