With these settings, 90deg and 270deg rotation leads to inverted
vertical, fix them to have correct rotation.
Fixes: 59a635327c ("media: meson: Add M2M driver for the Amlogic GE2D Accelerator Unit")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When controls are used together with the Request API, then for
each request a v4l2_ctrl_handler struct is allocated. This contains
the controls that can be set in a request. If a control is *not* set in
the request, then the value used in the most recent previous request
must be used, or the current value if it is not found in any outstanding
requests.
The framework tried to find such a previous request and it would set
the 'req' pointer in struct v4l2_ctrl_ref to the v4l2_ctrl_ref of the
control in such a previous request. So far, so good. However, when that
previous request was applied to the hardware, returned to userspace, and
then userspace would re-init or free that request, any 'ref' pointer in
still-queued requests would suddenly point to freed memory.
This was not noticed before since the drivers that use this expected
that each request would always have the controls set, so there was
never any need to find a control in older requests. This requirement
was relaxed, and now this bug surfaced.
It was also made worse by changeset
2fae4d6aab ("media: v4l2-ctrls: v4l2_ctrl_request_complete() should always set ref->req")
which increased the chance of this happening.
The use of the 'req' pointer in v4l2_ctrl_ref was very fragile, so
drop this entirely. Instead add a valid_p_req bool to indicate that
p_req contains a valid value for this control. And if it is false,
then just use the current value of the control.
Note that VIDIOC_G_EXT_CTRLS will always return -EACCES when attempting
to get a control from a request until the request is completed. And in
that case, all controls in the request will have the control value set
(i.e. valid_p_req is true). This means that the whole 'find the most
recent previous request containing a control' idea is pointless, and
the code can be simplified considerably.
The v4l2_g_ext_ctrls_common() function was refactored a bit to make
it more understandable. It also avoids updating volatile controls
in a completed request since that was already done when the request
was completed.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 2fae4d6aab ("media: v4l2-ctrls: v4l2_ctrl_request_complete() should always set ref->req")
Fixes: 6fa6f831f0 ("media: v4l2-ctrls: add core request support")
Cc: <stable@vger.kernel.org> # for v5.9 and up
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fill fw version info into smem to be printed as part of
soc info.
Signed-off-by: Dikshita Agarwal <dikshita@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When the video usecase have macro blocks per sec which is more than
supported, keep the required bus bandwidth as the maximum supported.
Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In current video driver, frequency is calculated for all the
running video instances and check aganist maximum supported frequency.
If both calculated frequency and maximum supported frequency are same,
even then HW overload error is printed.
Fix this by printing error log only when frequency is greater than
maximum supported frequency.
Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Firmware name for venus should be qcom/vpu-1.0/venus.mdt, not
qcom/sm8250/venus.mdt.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The for-loop iterates with a u8 loop counter i and compares this
with the loop upper limit of res->resets_num which is an unsigned
int type. There is a potential infinite loop if res->resets_num
is larger than the u8 loop counter i. Fix this by making the loop
counter the same type as res->resets_num.
Addresses-Coverity: ("Infinite loop")
Fixes: 3bca43585e ("media: venus: core,pm: Add handling for resets")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
For two of the supported sensors the stv06xx driver allocates memory which
is stored in sd->sensor_priv. This memory is freed on a disconnect, but if
the probe() fails, then it isn't freed and so this leaks memory.
Add a new probe_error() op that drivers can use to free any allocated
memory in case there was a probe failure.
Thanks to Pavel Skripkin <paskripkin@gmail.com> for discovering the cause
of the memory leak.
Reported-and-tested-by: syzbot+e7f4c64a4248a0340c37@syzkaller.appspotmail.com
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Remove including <linux/version.h> that don't need it.
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Zhiqi Song <songzhiqi1@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
devm_ioremap_resource() prints error message in itself. Remove the
dev_err call to avoid redundant error message.
Signed-off-by: Muhammad Usama Anjum <musamaanjum@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add support for EDIDs consisting of one EDID block.
Related to this, improve CEC physical address handling.
Clearing the EDID caused a bug since v4l2_calc_aspect_ratio() was
called with a NULL pointer.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Only the first pad was configured, but there are 4. This causes
set_fmt to fail with -EINVAL since the passed pad is > 0.
Configure all three sink pads and the source pad.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The /** at the start indicates that these are kernel-doc comments, but
really these are just regular comments.
Replace /** by /* to avoid a large number of warnings from kernel-doc.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Suggested-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sparse reports a warning on a cast to u8 of a 16 bits constant.
drivers/media/i2c/rdacm21.c:348:62: warning: cast truncates bits
from constant value (300a becomes a)
Even if the behaviour is intended, silence the sparse warning replacing
the cast with a bitwise & operation.
Fixes: a59f853b3b ("media: i2c: Add driver for RDACM21 camera module")
Reported-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cleans up checks of "Alignment should match open parenthesis"
in iss.c:96.
Signed-off-by: Beatriz Martins de Carvalho <martinsdecarvalhobeatriz@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Do not modify imgu_pipe->nodes[inode].vdev_fmt.fmt.pix_mp, until the
format has been correctly validated.
Otherwise, even if we use a backup variable, there is a period of time
where imgu_pipe->nodes[inode].vdev_fmt.fmt.pix_mp might have an invalid
value that can be used by other functions.
Cc: stable@vger.kernel.org
Fixes: ad91849996 ("media: staging/intel-ipu3: Fix set_fmt error handling")
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
We are losing the reference to an allocated memory if try. Change the
order of the check to avoid that.
Cc: stable@vger.kernel.org
Fixes: 6d5f26f2e0 ("media: staging/intel-ipu3-v4l: reduce kernel stack usage")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fix the following coverity warning:
This greater-than-or-equal-to-zero comparison of an unsigned value is
always true. "opcode >= 0".
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Building with 'make W=1' shows many warnings -Wempty-body warnings like
drivers/media/usb/dvb-usb/vp702x-fe.c: In function 'vp702x_fe_set_frontend':
drivers/media/usb/dvb-usb/vp702x-fe.c:190:46: error: suggest braces around empty body in an 'else' statement [-Werror=empty-body]
190 | deb_fe("tuning succeeded.\n");
drivers/media/usb/dvb-usb/dtt200u.c: In function 'dtt200u_rc_query':
drivers/media/usb/dvb-usb/dtt200u.c:124:58: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
124 | deb_info("st->data: %*ph\n", 5, st->data);
drivers/media/usb/dvb-usb/m920x.c: In function 'm920x_rc_query':
drivers/media/usb/dvb-usb/m920x.c:207:58: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
207 | deb("Unknown rc key %02x\n", rc_state[1]);
Change the empty dprintk() macros to no_printk(), which avoids this
warning and adds format string checking.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Building with 'make W=1' shows many warnings -Wempty-body warnings like
drivers/media/common/b2c2/flexcop-misc.c: In function 'flexcop_determine_revision':
drivers/media/common/b2c2/flexcop-misc.c:35:85: error: suggest braces around empty body in an 'else' statement [-Werror=empty-body]
35 | deb_info("this FlexCop has the 6 basic main hardware pid filter.\n");
drivers/media/usb/b2c2/flexcop-usb.c: In function 'flexcop_usb_process_frame':
drivers/media/usb/b2c2/flexcop-usb.c:357:79: error: suggest braces around empty body in an 'else' statement [-Werror=empty-body]
357 | deb_ts("not ts packet %*ph\n", 4, b+2);
| ^
drivers/media/common/b2c2/flexcop-misc.c: In function 'flexcop_determine_revision':
drivers/media/common/b2c2/flexcop-misc.c:35:85: error: suggest braces around empty body in an 'else' statement [-Werror=empty-body]
35 | deb_info("this FlexCop has the 6 basic main hardware pid filter.\n");
| ^
Change the empty dprintk() macros to no_printk(), which avoids this
warning and adds format string checking.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The Asus PN50 has 16 byte io region for the ITE8708 in its DSDT, which
causes the probe fail. So, accept larger regions.
Link: https://www.spinics.net/lists/linux-media/msg177725.html
Cc: Nikolaos Beredimas <beredim@gmail.com>
Reported-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add the obvious compatible name to the existing IR binding, and pair
it with the existing A31 fallback compatible string, as the devices
are compatible.
On the way use enums to group all compatible devices together.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
s/Hisilicon/HiSilicon/g.
It should use capital S, according to
https://www.hisilicon.com/en/terms-of-use.
Signed-off-by: Hao Fang <fanghao11@huawei.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The zte zx platform is getting removed, so this driver is no
longer needed.
Cc: Jun Nie <jun.nie@linaro.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
syzbot reported memory leak in dvb-usb. The problem was
in invalid error handling in dvb_usb_adapter_init().
for (n = 0; n < d->props.num_adapters; n++) {
....
if ((ret = dvb_usb_adapter_stream_init(adap)) ||
(ret = dvb_usb_adapter_dvb_init(adap, adapter_nrs)) ||
(ret = dvb_usb_adapter_frontend_init(adap))) {
return ret;
}
...
d->num_adapters_initialized++;
...
}
In case of error in dvb_usb_adapter_dvb_init() or
dvb_usb_adapter_dvb_init() d->num_adapters_initialized won't be
incremented, but dvb_usb_adapter_exit() relies on it:
for (n = 0; n < d->num_adapters_initialized; n++)
So, allocated objects won't be freed.
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Reported-by: syzbot+3c2be7424cea3b932b0e@syzkaller.appspotmail.com
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add keymaps and bindings for the simple IR (NEC) remotes used with
the MeCool KII-Pro and MeCool KIII-Pro Android STB devices.
Tested-by: Drazen Spio <drazsp@gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
gcc-11 warns about the prototype not exactly matching the function
definition:
drivers/media/usb/dvb-usb/dvb-usb-remote.c:363:20: error: argument 2 of type ‘u8[5]’ {aka ‘unsigned char[5]’} with mismatched bound [-Werror=array-parameter=]
363 | u8 keybuf[5], u32 *event, int *state)
| ~~~^~~~~~~~~
In file included from drivers/media/usb/dvb-usb/dvb-usb-common.h:13,
from drivers/media/usb/dvb-usb/dvb-usb-remote.c:9:
drivers/media/usb/dvb-usb/dvb-usb.h:490:65: note: previously declared as ‘u8[]’ {aka ‘unsigned char[]’}
490 | extern int dvb_usb_nec_rc_key_to_event(struct dvb_usb_device *, u8[], u32 *, int *);
| ^~~~
Fixes: 776338e121 ("[PATCH] dvb: Add generalized dvb-usb driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
An earlier commit removed a call to lgdt3306a_spectral_inversion and
omitted to remove the error return check. The check on ret is now
redundant and can be removed.
Addresses-Coverity: ("Logically dead code")
Fixes: d4a3fa6652 ("media: dvb-frontends: lgdt3306a.c: remove dead code")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The struct v4l2_subdev_format sd_fmt cannot be static since it can be
written back by the subdev. Just have it on the stack.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
pm_runtime_get_sync() will increase the runtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
pm_runtime_get_sync() will increase the runtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The video_unregister_device already calls video_device_release,
so remove video_device_release, to avoid a double free, when removing
the module. This showed up in a repeated rmmod/insmod scenario.
Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Smatch is warning that:
drivers/media/platform/qcom/venus/hfi_venus.c:1100 venus_isr() warn: variable dereferenced before check 'hdev' (see line 1097)
The logic basically does:
hdev = to_hfi_priv(core);
with is translated to:
hdev = core->priv;
If the IRQ code can receive a NULL pointer for hdev, there's
a bug there, as it will first try to de-reference the pointer,
and then check if it is null.
After looking at the code, it seems that this indeed can happen:
Basically, the venus IRQ thread is started with:
devm_request_threaded_irq()
So, it will only be freed after the driver unbinds.
In order to prevent the IRQ code to work with freed data,
the logic at venus_hfi_destroy() sets core->priv to NULL,
which would make the IRQ code to ignore any pending IRQs.
There is, however a race condition, as core->priv is set
to NULL only after being freed. So, we need also to move the
core->priv = NULL to happen earlier.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As reported by sparse:
drivers/media/platform/qcom/venus/core.c:227:41: warning: Using plain integer as NULL pointer
drivers/media/platform/qcom/venus/core.c:228:34: warning: Using plain integer as NULL pointer
Two vars are using zero instead of NULL for pointers. Not really
an issue, but using NULL makes it clearer that the init data is
expecting a pointer.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
