IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
GPIO library does copy the of_node from the parent device of
the GPIO chip, there is no need to repeat this in the individual
drivers. Remove assignment here.
For the details one may look into the of_gpio_dev_init() implementation.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The lirc core already introduces gaps, so there is no need for this in
the driver.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
These struct members do not serve any purpose.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Remove superfluous messages which add no information.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The usb pid/vid can be found elsewhere, the idVendor/idProduct usb sysfs
files for example.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There is no reason to have a reset after an IR timeout.
Calling ir_raw_event_handle() twice for the same interrupt has no
affect.
Fixes: 56b0ec30c4 ("[media] rc/streamzap: fix reporting response times")
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Without this, some IR will be missing mid-stream and we might decode
something which never really occurred.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
An IR reset is only used when the IR hardware reports an error.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
An IR reset is only used when the IR hardware reports an error.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Without timeout reports, it is impossible to decode many protocols since
it is not known when the transmission ends. timeout reports are sent by
default, but can be turned off. There is no reason to turn them off, and
I cannot find any software which does this, so we can safely remove it.
This makes the ioctl LIRC_SET_REC_TIMEOUT_REPORTS a no-op.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Use DEVICE_ATTR_RO() helper macro instead of DEVICE_ATTR(), which is
simpler and more readable.
Due to the name of the read function of the sysfs attribute is normalized,
there is a natural association.
Link: https://lore.kernel.org/linux-media/20210603071009.11438-1-thunder.leizhen@huawei.com
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Using stack-allocated pointers for USB message data don't work.
This driver is almost OK with that, except for the I2C read
logic.
Fix it by using a temporary read buffer, just like on all other
calls to m920x_read().
Link: https://lore.kernel.org/all/ccc99e48-de4f-045e-0fe4-61e3118e3f74@mida.se/
Reported-by: rkardell@mida.se
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
An spi remove callback is never called with an spi_device pointer that
is NULL. Also it is only called for devices that probed successfully. As
cxd2880_spi_probe() always sets driver data, spi_get_drvdata() cannot be
NULL.
Also the return value of spi remove callbacks is ignored anyway and not
freeing resources in .remove() is a bad idea.
Link: https://lore.kernel.org/linux-media/20211012153945.2651412-8-u.kleine-koenig@pengutronix.de
Cc: Mark Brown <broonie@kernel.org>, kernel@pengutronix.de, linux-media@vger.kernel.org, linux-spi@vger.kernel.org
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
If disabling the hardware fails the driver propagates the error code to
the i2c core. However this only results in a generic error message; the
device still disappears.
So instead emit a message that better describes the actual problem than
the i2c core's "remove failed (ESOMETHING), will be ignored" and return
0 to suppress the generic message.
Link: https://lore.kernel.org/linux-media/20211026194010.109029-1-u.kleine-koenig@pengutronix.de
Cc: linux-media@vger.kernel.org, kernel@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The module currently prints only "Rafael Micro r820t successfully
identified" when successfully loaded, which might be misleading as the
module actually supports various chip types.
Link: https://lore.kernel.org/linux-media/20211119234401.271193-1-dkk089@gmail.com
Cc: linux-kernel@vger.kernel.org, Daniel Kamil Kozar <dkk089@gmail.com>
Signed-off-by: Daniel Kamil Kozar <dkk089@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Commit e955f959ac ("media: si2157: Better check for running tuner in
init") completely broke the "warm" tuner detection of the si2157 driver
due to a simple endian error: The Si2157 CRYSTAL_TRIM property code is
0x0402 and needs to be transmitted LSB first. However, it was inserted
MSB first, causing the warm detection to always fail and spam the kernel
log with tuner initialization messages each time the DVB frontend
device was closed and reopened:
[ 312.215682] si2157 16-0060: found a 'Silicon Labs Si2157-A30'
[ 312.264334] si2157 16-0060: firmware version: 3.0.5
[ 342.248593] si2157 16-0060: found a 'Silicon Labs Si2157-A30'
[ 342.295743] si2157 16-0060: firmware version: 3.0.5
[ 372.328574] si2157 16-0060: found a 'Silicon Labs Si2157-A30'
[ 372.385035] si2157 16-0060: firmware version: 3.0.5
Also, the reinitializations were observed disturb _other_ tuners on
multi-tuner cards such as the Hauppauge WinTV-QuadHD, leading to missed
or errored packets when one of the other DVB frontend devices on that
card was opened.
Fix the order of the property code bytes to make the warm detection work
again, also reducing the tuner initialization message in the kernel log
to once per power-on, as well as fixing the interference with other
tuners.
Link: https://lore.kernel.org/linux-media/trinity-2a86eb9d-6264-4387-95e1-ba7b79a4050f-1638392923493@3c-app-gmx-bap03
Fixes: e955f959ac ("media: si2157: Better check for running tuner in init")
Reported-by: Robert Schlabbach <robert_s@gmx.net>
Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The beginning part of the "existing HSV/HSL formats" table (line 7742)
reads:
.. raw:: latex
\begingroup
\tiny
\setlength{\tabcolsep}{2pt}
However, the ending part (line 7834) reads:
.. raw:: latex
\normalsize
Fix the imbalance by replacing the \normalsize with \endgroup.
Note:
Actually, the imbalance is harmless and just results in an
informative message near the bottom of userspace-api.log:
(\end occurred inside a group at level 1)
### semi simple group (level 1) entered at line 70696 (\begingroup)
### bottom level
Link: https://lore.kernel.org/linux-media/b3eeec4d-1a34-0a1a-3097-1ddea3b5f1c8@gmail.com
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Don't populate the array idx_map on the stack but instead make it
static const. Also makes the object code smaller by 16 bytes.
Link: https://lore.kernel.org/linux-media/20211129230626.549090-1-colin.i.king@gmail.com
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In function vb2_set_plane_payload, report if the given bytesused is
bigger than the buffer size, and clamp it to the buffer size.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In many places the bytesused field of struct vb2_buffer is set
directly. Replace that with the function call
vb2_set_plane_payload
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The cec_devnode struct has a lock meant to serialize access
to the fields of this struct. This lock is taken during
device node (un)registration and when opening or releasing a
filehandle to the device node. When the last open filehandle
is closed the cec adapter might be disabled by calling the
adap_enable driver callback with the devnode.lock held.
However, if during that callback a message or event arrives
then the driver will call one of the cec_queue_event()
variants in cec-adap.c, and those will take the same devnode.lock
to walk the open filehandle list.
This obviously causes a deadlock.
This is quite easy to reproduce with the cec-gpio driver since that
uses the cec-pin framework which generated lots of events and uses
a kernel thread for the processing, so when adap_enable is called
the thread is still running and can generate events.
But I suspect that it might also happen with other drivers if an
interrupt arrives signaling e.g. a received message before adap_enable
had a chance to disable the interrupts.
This patch adds a new mutex to serialize access to the fhs list.
When adap_enable() is called the devnode.lock mutex is held, but
not devnode.lock_fhs. The event functions in cec-adap.c will now
use devnode.lock_fhs instead of devnode.lock, ensuring that it is
safe to call those functions from the adap_enable callback.
This specific issue only happens if the last open filehandle is closed
and the physical address is invalid. This is not something that
happens during normal operation, but it does happen when monitoring
CEC traffic (e.g. cec-ctl --monitor) with an unconfigured CEC adapter.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: <stable@vger.kernel.org> # for v5.13 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The en/disable_irq() functions keep track of the 'depth': i.e. if
interrupts are disabled twice, then it needs to enable_irq() calls to
enable them again. The cec-pin framework didn't take this into accound
and could disable irqs multiple times, and it expected that a single
enable_irq() would enable them again.
Move all calls to en/disable_irq() to the kthread where it is easy
to keep track of the current irq state and ensure that multiple
en/disable_irq calls never happen.
If interrupts where disabled twice, then they would never turn on
again, leaving the CEC adapter in a dead state.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 865463fc03 (media: cec-pin: add error injection support)
Cc: <stable@vger.kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This field is only set, but never used. Drop it.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The only usage of the v4l2_m2m_ops structs is to pass their address to
v4l2_m2m_init() which takes a pointer to const struct v4l2_m2m_ops as
argument. Make them const to allow the compiler to put them in read-only
memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In mxb_attach(dev, info), saa7146_vv_init() is called to allocate a
new memory for dev->vv_data. saa7146_vv_release() will be called on
failure of mxb_probe(dev). There is a dereference of dev->vv_data
in saa7146_vv_release(), which could lead to a NULL pointer dereference
on failure of saa7146_vv_init().
Fix this bug by adding a check of saa7146_vv_init().
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_VIDEO_MXB=m show no new warnings,
and our static analyzer no longer warns about this code.
Fixes: 03b1930efd ("V4L/DVB: saa7146: fix regression of the av7110/budget-av driver")
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In hexium_attach(dev, info), saa7146_vv_init() is called to allocate
a new memory for dev->vv_data. In hexium_detach(), saa7146_vv_release()
will be called and there is a dereference of dev->vv_data in
saa7146_vv_release(), which could lead to a NULL pointer dereference
on failure of saa7146_vv_init() according to the following logic.
Both hexium_attach() and hexium_detach() are callback functions of
the variable 'extension', so there exists a possible call chain directly
from hexium_attach() to hexium_detach():
hexium_attach(dev, info) -- fail to alloc memory to dev->vv_data
| in saa7146_vv_init().
|
|
hexium_detach() -- a dereference of dev->vv_data in saa7146_vv_release()
Fix this bug by adding a check of saa7146_vv_init().
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_VIDEO_HEXIUM_ORION=m show no new warnings,
and our static analyzer no longer warns about this code.
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In dib8000_init(), the variable fe is not freed or passed out on the
failure of dib8000_identify(&state->i2c), which could lead to a memleak.
Fix this bug by adding a kfree of fe in the error path.
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_DVB_DIB8000=m show no new warnings,
and our static analyzer no longer warns about this code.
Fixes: 77e2c0f5d4 ("V4L/DVB (12900): DiB8000: added support for DiBcom ISDB-T/ISDB-Tsb demodulator DiB8000")
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There is no need to hold the group lock when unregistering the notifier,
but doing so triggers a warning about a possible cyclic lock dependency.
The lock warning cover the case where a subdevice is about to be bound
to the notifier at the same time as it's unregistered. The locking for
this scenario is handled in the v4l2-async framework so it's safe to
remove the lock in the driver. This match the locking logic in the
driver for when the notifier in question is registered.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The VIN driver have an internal concept of capture groups that covers
multiple instances of the driver. This is handled using the shared media
graph and a single notifier shared between all VIN instances.
This design do not work well if an individual VIN where to be unbound on
its own. The design could be improved up on to allow for this but would
require large changes in the v4l2-async framework. To avoid the
situation suppress the bind and unbind nodes in sysfs.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The v4l2-async framework's subdev notifiers do not behave correctly if a
device in the middle of the pipeline is unbound and then rebound. The
v4l2-subdevices upstream from the device being rebound gets confused as
they receive no notification of the device unbound and can't cleanup
their state and when they are rebound to the new v4l2-subdev notifier
they try to reinitialize their internal state, this may include things
as trying to create links that already exists and in some cases crash
the system, for example the adv748x.
This should be solved in the v4l2-async framework, but as a stop-gap
measure suppress the bind and unbind sysfs nodes for the rcar-csi2
driver so it can't be used to crash the system.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This change fixes two issues with the size constraints for buffers.
- There is no width alignment constraint for RGB formats. Prior to this
change they were treated as YUV and as a result were more restricted
than needed. Add a new check to differentiate between the two.
- The minimum width and height supported is 5x2, not 2x4, this is an
artifact from the driver's soc-camera days. Fix this incorrect
assumption.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
hantro_v4l2.c includes media/videobuf2-dma-sg.h, which isn't used.
And in fact, hantro doesn't use the vb2_dma_sg_memops at all, so this
is confusing. Just drop both videobuf2 headers, they are not needed here.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Before reading which slot was captured to by examining the module status
(VnMS) register, make sure something was captured at all by examining
the interrupt status register (VnINTS).
Failing this a buffer maybe completed before it was captured too.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
D1 has a unique variant of the video engine, which appears to drop the
VP8 support found on most earlier variants.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
D1 contains a video engine similar to the one in other sunxi SoCs.
Add a compatible for it.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
If the memory where ctrl_found is placed has the value of uvc_ctrl and
__uvc_find_control does not find the control we will return an invalid
index.
Fixes: 6350d6a4ed ("media: uvcvideo: Set error_idx during ctrl_commit errors")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
If mappings points to an invalid memory, we will be invalid accessing
it. Solve it by initializing the value of the variable mapping and by
changing the order in the conditional statement (to avoid accessing
mapping->id if not needed).
Fix:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN NOPTI
Fixes: 6350d6a4ed ("media: uvcvideo: Set error_idx during ctrl_commit errors")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Some uvc devices appear to require the maximum allowed USB timeout
for GET_CUR/SET_CUR requests.
So lets just bump the UVC control timeout to 5 seconds which is the
same as the usb ctrl get/set defaults:
USB_CTRL_GET_TIMEOUT 5000
USB_CTRL_SET_TIMEOUT 5000
It fixes the following runtime warnings:
Failed to query (GET_CUR) UVC control 11 on unit 2: -110 (exp. 1).
Failed to query (SET_CUR) UVC control 3 on unit 2: -110 (exp. 2).
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Never return V4L2_COLORSPACE_DEFAULT. From the standard:
"""
In the absence of this descriptor, or in the case of
“Unspecified” values within the descriptor, color matching
defaults will be assumed. The color matching defaults are
compliant with sRGB since the BT.709 transfer function and
the sRGB transfer function are very similar.
"""
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Tested-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add the missing bulk-endpoint max-packet sanity check to
uvc_video_start_transfer() to avoid division by zero in
uvc_alloc_urb_buffers() in case a malicious device has broken
descriptors (or when doing descriptor fuzz testing).
Note that USB core will reject URBs submitted for endpoints with zero
wMaxPacketSize but that drivers doing packet-size calculations still
need to handle this (cf. commit 2548288b4f ("USB: Fix: Don't skip
endpoint descriptors with maxpacket=0")).
Fixes: c0efd23292 ("V4L/DVB (8145a): USB Video Class driver")
Cc: stable@vger.kernel.org # 2.6.26
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently when the allocation of map->name fails the error exit path
does not kfree the previously allocated object map. Fix this by
setting ret to -ENOMEM and taking the free_map exit error path to
ensure map is kfree'd.
Addresses-Coverity: ("Resource leak")
Fixes: 70fa906d6f ("media: uvcvideo: Use control names from framework")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmGtOFYeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG1hUH/1bmlOYsscJ7biqd
VECr5HhTg6iRvwWUiOpU27fLuBeAM1ZdF0oLuCtzvbK2h8lfTclcHfueihK0GIvX
ci8BvwpOYfUdDUWHglgvGXqICqYch3PiBVMFiRRRkzcpZdyCFCirAynLdOeusdTU
72Fi2RBaIM+U/5UVKcTx0J9WJsvFcG97lnNX5nT3dUmuoSW4WmX+h4vIe8VYFVmd
8q1gD17hPL+ThTKcZApn7IsArU1LNEGRg0tYItgMJo8AMTvsZjwR6yQgXeyuQ0Xk
xp6pZwzABtnL9dfNJ95q1GhsJBX5T5XvAVjt2uR1ADbgh6TDApC1VBKICm1Nva7g
uT6S0yE=
=JNL8
-----END PGP SIGNATURE-----
Merge tag 'v5.16-rc4' into media_tree
Linux 5.16-rc4
* tag 'v5.16-rc4': (984 commits)
Linux 5.16-rc4
KVM: SVM: Do not terminate SEV-ES guests on GHCB validation failure
KVM: SEV: Fall back to vmalloc for SEV-ES scratch area if necessary
KVM: SEV: Return appropriate error codes if SEV-ES scratch setup fails
parisc: Mark cr16 CPU clocksource unstable on all SMP machines
parisc: Fix "make install" on newer debian releases
sched/uclamp: Fix rq->uclamp_max not set on first enqueue
preempt/dynamic: Fix setup_preempt_mode() return value
cifs: avoid use of dstaddr as key for fscache client cookie
cifs: add server conn_id to fscache client cookie
cifs: wait for tcon resource_id before getting fscache super
cifs: fix missed refcounting of ipc tcon
x86/xen: Add xenpv_restore_regs_and_return_to_usermode()
x86/entry: Use the correct fence macro after swapgs in kernel CR3
fget: check that the fd still exists after getting a ref to it
x86/entry: Add a fence for kernel entry SWAPGS in paranoid_entry()
x86/sev: Fix SEV-ES INS/OUTS instructions for word, dword, and qword
powercap: DTPM: Drop unused local variable from init_dtpm()
io-wq: don't retry task_work creation failure on fatal conditions
serial: 8250_bcm7271: UART errors after resuming from S2
...
