commit e6cfaf34be upstream.
proc_get_long() is passed a size_t, but then assigns it to an 'int'
variable for the length. Let's not do that, even if our IO paths are
limited to MAX_RW_COUNT (exactly because of these kinds of type errors).
So do the proper test in the rigth type.
Bug: 261488859
Reported-by: Kyle Zeng <zengyhkyle@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Icb7df4e5d9061d8a2c854b3f7cccaa753d6ea540
Signed-off-by: Lee Jones <joneslee@google.com>
commit bce9332220 upstream.
proc_skip_spaces() seems to think it is working on C strings, and ends
up being just a wrapper around skip_spaces() with a really odd calling
convention.
Instead of basing it on skip_spaces(), it should have looked more like
proc_skip_char(), which really is the exact same function (except it
skips a particular character, rather than whitespace). So use that as
inspiration, odd coding and all.
Now the calling convention actually makes sense and works for the
intended purpose.
Bug: 261488859
Reported-and-tested-by: Kyle Zeng <zengyhkyle@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Idda5e84344778ff8794bc21c981ba3da01e6a63b
Signed-off-by: Lee Jones <joneslee@google.com>
[ Upstream commit 89ff3dfac6 ]
The embedded struct cdev does not have its lifetime correctly tied to
the enclosing struct f_hidg, so there is a use-after-free if /dev/hidgN
is held open while the gadget is deleted.
This can readily be replicated with libusbgx's example programs (for
conciseness - operating directly via configfs is equivalent):
gadget-hid
exec 3<> /dev/hidg0
gadget-vid-pid-remove
exec 3<&-
Pull the existing device up in to struct f_hidg and make use of the
cdev_device_{add,del}() helpers. This changes the lifetime of the
device object to match struct f_hidg, but note that it is still added
and deleted at the same time.
Bug: 176850153
Fixes: 71adf11894 ("USB: gadget: add HID gadget driver")
Tested-by: Lee Jones <lee@kernel.org>
Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Reviewed-by: Lee Jones <lee@kernel.org>
Signed-off-by: John Keeping <john@metanate.com>
Link: https://lore.kernel.org/r/20221122123523.3068034-2-john@metanate.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I5d37ca47c5f087d5b1b303b4e8a1614ea3f50159
[ Upstream commit d7428bc26f ]
f_hid provides the OUT Endpoint as only way for receiving reports
from the host. SETUP/SET_REPORT method is not supported, and this causes
a number of compatibility problems with various host drivers, especially
in the case of keyboard emulation using f_hid.
- Some hosts do not support the OUT Endpoint and ignore it,
so it becomes impossible for the gadget to receive a report
from the host. In the case of a keyboard, the gadget loses
the ability to receive the status of the LEDs.
- Some BIOSes/UEFIs can't work with HID devices with the OUT Endpoint
at all. This may be due to their bugs or incomplete implementation
of the HID standard.
For example, absolutely all Apple UEFIs can't handle the OUT Endpoint
if it goes after IN Endpoint in the descriptor and require the reverse
order (OUT, IN) which is a violation of the standard.
Other hosts either do not initialize gadgets with a descriptor
containing the OUT Endpoint completely (like some HP and DELL BIOSes
and embedded firmwares like on KVM switches), or initialize them,
but will not poll the IN Endpoint.
This patch adds configfs option no_out_endpoint=1 to disable
the OUT Endpoint and allows f_hid to receive reports from the host
via SETUP/SET_REPORT.
Previously, there was such a feature in f_hid, but it was replaced
by the OUT Endpoint [1] in the commit 99c5150058 ("usb: gadget: hidg:
register OUT INT endpoint for SET_REPORT"). So this patch actually
returns the removed functionality while making it optional.
For backward compatibility reasons, the OUT Endpoint mode remains
the default behaviour.
- The OUT Endpoint mode provides the report queue and reduces
USB overhead (eliminating SETUP routine) on transmitting a report
from the host.
- If the SETUP/SET_REPORT mode is used, there is no report queue,
so the userspace will only read last report. For classic HID devices
like keyboards this is not a problem, since it's intended to transmit
the status of the LEDs and only the last report is important.
This mode provides better compatibility with strange and buggy
host drivers.
Both modes passed USBCV tests. Checking with the USB protocol analyzer
also confirmed that everything is working as it should and the new mode
ensures operability in all of the described cases.
Bug: 176850153
Link: https://www.spinics.net/lists/linux-usb/msg65494.html [1]
Reviewed-by: Maciej Żenczykowski <zenczykowski@gmail.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Maxim Devaev <mdevaev@gmail.com>
Link: https://lore.kernel.org/r/20210821134004.363217-1-mdevaev@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of: 89ff3dfac6 ("usb: gadget: f_hid: fix f_hidg lifetime vs cdev")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I0f5759015f17661fe4fe23a1216f1047978c79b1
and replace with PANIC_ON_WARN. The latter is needed to align with
the standard KASAN template.
The former is needed to workaround a boot issue on cuttlefish that
hasn't been root-caused yet. Likely cause is the larger text
space needed for the INLINE config.
This issue was surfaced on cuttlefish when the BL implementation
was changed to use a builtin environment 578b47ac41fe4433108.
Bug: 218315905
Change-Id: I57486f8befa720bbf49afe89c5454af8348816a5
(Backport: resolve conflicts due to missing f4693c2716 and present
d3578ba7a5, and also drop in_bpf_jit from fixup_exception the same way
5.15 backport 9c82ce5936 does it.)
Commit 91fc957c9b ("arm64/bpf: don't allocate BPF JIT programs in module
memory") restricts BPF JIT program allocation to a 128MB region to ensure
BPF programs are still in branching range of each other. However this
restriction should not apply to the aarch64 JIT, since BPF_JMP | BPF_CALL
are implemented as a 64-bit move into a register and then a BLR instruction -
which has the effect of being able to call anything without proximity
limitation.
The practical reason to relax this restriction on JIT memory is that 128MB of
JIT memory can be quickly exhausted, especially where PAGE_SIZE is 64KB - one
page is needed per program. In cases where seccomp filters are applied to
multiple VMs on VM launch - such filters are classic BPF but converted to
BPF - this can severely limit the number of VMs that can be launched. In a
world where we support BPF JIT always on, turning off the JIT isn't always an
option either.
Fixes: 91fc957c9b ("arm64/bpf: don't allocate BPF JIT programs in module memory")
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <russell.king@oracle.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Alan Maguire <alan.maguire@oracle.com>
Link: https://lore.kernel.org/bpf/1636131046-5982-2-git-send-email-alan.maguire@oracle.com
(cherry picked from commit b89ddf4cca)
Bug: 252919296
Change-Id: Iec7d0b2bba001df94c2e21fcd5883ff002111cd5
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Commit 88b7179fcd ("ANDROID: fuse: Move functions in preparation for
fuse-bpf") changed the type of these bitfields from the upstream type of
'bool' to 'int', which causes several warnings with recent versions of
clang:
/builds/linux/fs/fuse/dir.c:168:19: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
args->out_argvar = true;
^ ~~~~
/builds/linux/fs/fuse/dir.c:492:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
args.out_argvar = 1;
^ ~
/builds/linux/fs/fuse/dir.c:1649:20: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
ap.args.out_pages = true;
^ ~~~~
/builds/linux/fs/fuse/dir.c:1650:21: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
ap.args.out_argvar = true;
^ ~~~~
/builds/linux/fs/fuse/dir.c:1651:23: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
ap.args.page_zeroing = true;
^ ~~~~
5 errors generated.
When fuse_args was moved back to the internal implementation in commit
9a5023967b ("ANDROID: fuse-bpf: Use fuse_bpf_args in uapi"), the type
was not restored. Do so now to fix the warnings and reduce the delta
with upstream.
Bug: 265200230
Change-Id: I4d51f331d842a1faff9a937140f0275130e70d73
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
We currently have 3 different ways that __iommu_probe_device() may be
called, but no real guarantee that multiple callers can't tread on each
other, especially once asynchronous driver probe gets involved. It would
likely have taken a fair bit of luck to hit this previously, but commit
57365a04c9 ("iommu: Move bus setup to IOMMU device registration") ups
the odds since now it's not just omap-iommu that may trigger multiple
bus_iommu_probe() calls in parallel if probing asynchronously.
Add a lock to ensure we can't try to double-probe a device, and also
close some possible race windows to make sure we're truly robust against
trying to double-initialise a group via two different member devices.
Reported-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Fixes: 57365a04c9 ("iommu: Move bus setup to IOMMU device registration")
Link: https://lore.kernel.org/r/1946ef9f774851732eed78760a78ec40dbc6d178.1667591503.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Bug: 264326526
(cherry picked from commit 01657bc14a)
Change-Id: I51dbcdc5dc536b0e69c6187b2d7ac6a2031a305b
Signed-off-by: Luke Chang <lukechang@google.com>
In the config_ep_by_speed_and_alt function, select the corresponding
descriptor through g->speed. But some legacy or not well designed
function drivers may not support the corresponding speed. So, we can
directly display warnings instead of causing kernel panic. At the
same time, it indicates the reasons in warning message.
Reviewed-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Qihang Hu <huqihang@oppo.com>
Link: https://lore.kernel.org/r/20211110101129.462357-1-huqihang@oppo.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 16d4275920)
Bug: 259171206
Change-Id: I5ceff4871e1e7693c7a2c68264e994f39194090b
Signed-off-by: Avichal Rakesh <arakesh@google.com>
In the specification documents for the Uncompressed and MJPEG USB
Video Payloads, the field name is bmInterlaceFlags - it has been
misnamed within the kernel.
Although renaming the field does break the kernel's interface to
userspace it should be low-risk in this instance. The field is read
only and hardcoded to 0, so there was never any value in anyone
reading it. A search of the uvc-gadget application and all the
forks that I could find for it did not reveal any users either.
Fixes: cdda479f15 ("USB gadget: video class function driver")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Link: https://lore.kernel.org/r/20221206161203.1562827-1-dan.scally@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 81c25247a2)
Bug: 259171206
Change-Id: I95ad86d0c0ab097b215e1ef655beea80c2cdb570
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Since e219a712bc (usb: gadget: uvc: add v4l2 try_format api call) the
try_format function is available. With this function includes checks for
valid configurations programmed in the configfs. We use this function to
ensure to return valid values on the set_format callback.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Fixes: e219a712bc ("usb: gadget: uvc: add v4l2 try_format api call")
Link: https://lore.kernel.org/r/20221026182240.363055-1-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 181babf7b4)
Bug: 259171206
Change-Id: I404c8d01dc53dcf3b400c0f9e1888992d9f65db8
Signed-off-by: Avichal Rakesh <arakesh@google.com>
For the userspace it is needed to distinguish between requests for the
control or streaming interface. The userspace would have to parse the
configfs to know which interface index it has to compare the ctrl
requests against. Since the interface numbers are not fixed, e.g. for
composite gadgets, the interface offset depends on the setup.
The kernel has this information when handing over the ctrl request to
the userspace. This patch removes the offset from the interface numbers
and expose the default interface defines in the uapi g_uvc.h.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20221011075348.1786897-1-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d182bf156c)
Bug: 259171206
Change-Id: Ie5978ef268731e67ca72940ce6fbc7f980cb4419
Signed-off-by: Avichal Rakesh <arakesh@google.com>
If there is a transmission error the buffer will be returned too early,
causing a memory fault as subsequent requests for that buffer are still
queued up to be sent. Refactor the error handling to wait for the final
request to come in before reporting back the buffer to userspace for all
transfer types (bulk/isoc/isoc_sg). This ensures userspace knows if the
frame was successfully sent.
Fixes: e81e7f9a0e ("usb: gadget: uvc: add scatter gather support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Dan Vacura <w36195@motorola.com>
Link: https://lore.kernel.org/r/20221018215044.765044-4-w36195@motorola.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 0a0a2760b0)
Bug: 259171206
Change-Id: I9fa41c05a26c3118c6af609d18e1e447a5e4b304
Signed-off-by: Avichal Rakesh <arakesh@google.com>
With the re-use of the previous completion status in 0d1c407b1a
("usb: dwc3: gadget: Return proper request status") it could be possible
that the next frame would also get dropped if the current frame has a
missed isoc error. Ensure that an interrupt is requested for the start
of a new frame.
Fixes: fc78941d81 ("usb: gadget: uvc: decrease the interrupt load to a quarter")
Cc: <stable@vger.kernel.org>
Signed-off-by: Dan Vacura <w36195@motorola.com>
Link: https://lore.kernel.org/r/20221018215044.765044-2-w36195@motorola.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8e8e923a49)
Bug: 259171206
Change-Id: I7d1b9243b788d2fb3593c52f4fb49ba195720af6
Signed-off-by: Avichal Rakesh <arakesh@google.com>
With the patch "588b9e85609b (usb: gadget: uvc: add v4l2 enumeration api
calls)" the driver is keeping a list of configfs entries currently
configured. The list is used in uvc_v4l2 on runtime.
The driver now is giving back the list item just after it was referenced
with config_item_put. It also calls config_item_put on uvc_free, which
is the only and right place to give back the reference. This patch fixes
the issue by removing the extra config_item_put in uvc_alloc.
Fixes: 588b9e8560 (usb: gadget: uvc: add v4l2 enumeration api calls)
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220930122839.1747279-1-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3180d827c8)
Bug: 259171206
Change-Id: Idf19d732cc5b90f09311a94d5d07c6e1805043f5
Signed-off-by: Avichal Rakesh <arakesh@google.com>
When building s390 allmodconfig after commit 9b91a65230 ("usb: gadget:
uvc: increase worker prio to WQ_HIGHPRI"), the following error occurs:
In file included from ../include/linux/string.h:253,
from ../include/linux/bitmap.h:11,
from ../include/linux/cpumask.h:12,
from ../include/linux/smp.h:13,
from ../include/linux/lockdep.h:14,
from ../include/linux/rcupdate.h:29,
from ../include/linux/rculist.h:11,
from ../include/linux/pid.h:5,
from ../include/linux/sched.h:14,
from ../include/linux/ratelimit.h:6,
from ../include/linux/dev_printk.h:16,
from ../include/linux/device.h:15,
from ../drivers/usb/gadget/function/f_uvc.c:9:
In function ‘fortify_memset_chk’,
inlined from ‘uvc_register_video’ at ../drivers/usb/gadget/function/f_uvc.c:424:2:
../include/linux/fortify-string.h:301:25: error: call to ‘__write_overflow_field’ declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
301 | __write_overflow_field(p_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This points to the memset() in uvc_register_video(). It is clear that
the argument to sizeof() is incorrect, as uvc->vdev (a 'struct
video_device') is being zeroed out but the size of uvc->video (a 'struct
uvc_video') is being used as the third arugment to memset().
pahole shows that prior to commit 9b91a65230 ("usb: gadget: uvc:
increase worker prio to WQ_HIGHPRI"), 'struct video_device' and
'struct ucv_video' had the same size, meaning that the argument to
sizeof() is incorrect semantically but there is no visible issue:
$ pahole -s build/drivers/usb/gadget/function/f_uvc.o | grep -E "(uvc_video|video_device)\s+"
video_device 1400 4
uvc_video 1400 3
After that change, uvc_video becomes slightly larger, meaning that the
memset() will overwrite by 8 bytes:
$ pahole -s build/drivers/usb/gadget/function/f_uvc.o | grep -E "(uvc_video|video_device)\s+"
video_device 1400 4
uvc_video 1408 3
Fix the arugment to sizeof() so that there is no overwrite.
Cc: stable@vger.kernel.org
Fixes: e4ce9ed835 ("usb: gadget: uvc: ensure the vdev is unset")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220928201921.3152163-1-nathan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a15e17acce)
Bug: 259171206
Change-Id: Id48717e01c36fa2ace9570b97553f371e5743fc3
Signed-off-by: Avichal Rakesh <arakesh@google.com>
This patch adds support to the v4l2 VIDIOCs for enum_format,
enum_framesizes and enum_frameintervals. This way, the userspace
application can use these VIDIOCS to query the via configfs exported
frame capabilities. With thes callbacks the userspace doesn't have to
bring its own configfs parser.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220909221335.15033-4-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 588b9e8560)
Bug: 259171206
Change-Id: I26bf3a509158da6f521c2e62076ef014cf0235b8
Signed-off-by: Avichal Rakesh <arakesh@google.com>
This patch is changing the simple workqueue in the gadget driver to be
allocated as async_wq with a higher priority. The pump worker, that is
filling the usb requests, will have a higher priority and will not be
scheduled away so often while the video stream is handled. This will
lead to fewer streaming underruns.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220907215818.2670097-1-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9b91a65230)
Bug: 242344221
Change-Id: I91ffbc93e8769c3b2674134679d5f9d48b566dbd
Signed-off-by: Avichal Rakesh <arakesh@google.com>
A panic can occur if the endpoint becomes disabled and the
uvcg_video_pump adds the request back to the req_free list after it has
already been queued to the endpoint. The endpoint complete will add the
request back to the req_free list. Invalidate the local request handle
once it's been queued.
<6>[ 246.796704][T13726] configfs-gadget gadget: uvc: uvc_function_set_alt(1, 0)
<3>[ 246.797078][ T26] list_add double add: new=ffffff878bee5c40, prev=ffffff878bee5c40, next=ffffff878b0f0a90.
<6>[ 246.797213][ T26] ------------[ cut here ]------------
<2>[ 246.797224][ T26] kernel BUG at lib/list_debug.c:31!
<6>[ 246.807073][ T26] Call trace:
<6>[ 246.807180][ T26] uvcg_video_pump+0x364/0x38c
<6>[ 246.807366][ T26] process_one_work+0x2a4/0x544
<6>[ 246.807394][ T26] worker_thread+0x350/0x784
<6>[ 246.807442][ T26] kthread+0x2ac/0x320
Fixes: f9897ec0f6 ("usb: gadget: uvc: only pump video data if necessary")
Cc: stable@vger.kernel.org
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dan Vacura <w36195@motorola.com>
Link: https://lore.kernel.org/r/20220617163154.16621-1-w36195@motorola.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 96163f835e)
Bug: 242344221
Change-Id: Ib3181d5965281318619c7b78da2c334701750e14
Signed-off-by: Avichal Rakesh <arakesh@google.com>
The current limitation of possible number of requests being handled is
dependent on the gadget speed. It makes more sense to depend on the
typical frame size when calculating the number of requests. This patch
is changing this and is using the previous limits as boundaries for
reasonable minimum and maximum number of requests.
For a 1080p jpeg encoded video stream with a maximum imagesize of
e.g. 800kB with a maxburst of 8 and an multiplier of 1 the resulting
number of requests is calculated to 49.
800768 1
nreqs = ------ * -------------- ~= 49
2 (1024 * 8 * 1)
Tested-by: Dan Vacura <w36195@motorola.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220529223848.105914-2-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 87d76b5f1d)
Bug: 242344221
Change-Id: I3cf760340c9c2cde32f1c8ca9023735d0639c5fb
Signed-off-by: Avichal Rakesh <arakesh@google.com>
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>
