- 30 Sep, 2021 40 commits
-
-
Evgeny Novikov authored
devm_add_action_or_reset() can suddenly invoke amd_mp2_pci_remove() at registration that will cause NULL pointer dereference since corresponding data is not initialized yet. The patch moves initialization of data before devm_add_action_or_reset(). Found by Linux Driver Verification project (linuxtesting.org). [jkosina@suse.cz: rebase] Signed-off-by:
Evgeny Novikov <novikov@ispras.ru> Acked-by:
Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
Joshua-Dickens authored
Add the new PIDs to wacom_wac.c to support the new models in the Intuos series. [jkosina@suse.cz: fix changelog] Signed-off-by:
Joshua Dickens <joshua.dickens@wacom.com> Reviewed-by:
Ping Cheng <ping.cheng@wacom.com> Signed-off-by:
-
Mizuho Mori authored
Apple Magic Keyboard(JIS)'s Logical Maximum and Usage Maximum are wrong. Below is a report descriptor. 0x05, 0x01, /* Usage Page (Desktop), */ 0x09, 0x06, /* Usage (Keyboard), */ 0xA1, 0x01, /* Collection (Application), */ 0x85, 0x01, /* Report ID (1), */ 0x05, 0x07, /* Usage Page (Keyboard), */ 0x15, 0x00, /* Logical Minimum (0), */ 0x25, 0x01, /* Logical Maximum (1), */ 0x19, 0xE0, /* Usage Minimum (KB Leftcontrol), */ 0x29, 0xE7, /* Usage Maximum (KB Right GUI), */ 0x75, 0x01, /* Report Size (1), */ 0x95, 0x08, /* Report Count (8), */ 0x81, 0x02, /* Input (Variable), */ 0x95, 0x05, /* Report Count (5), */ 0x75, 0x01, /* Report Size (1), */ 0x05, 0x08, /* Usage Page (LED), */ 0x19, 0x01, /* Usage Minimum (01h), */ 0x29, 0x05, /* Usage Maximum (05h), */ 0x91, 0x02, /* Output (Variable), */ 0x95, 0x01, /* Report Count (1), */ 0x75, 0x03, /* Report Size (3), */ 0x91, 0x03, /* Output (Constant, Variable), */ 0x95, 0x08, /* Report Count (8), */ 0x75, 0x01, /* Report Size (1), */ 0x15, 0x00, /* Logical Minimum (0), */ 0x25, 0x01, /* Logical Maximum (1), */ here is a report descriptor which is parsed one in kernel. see sys/kernel/debug/hid/<dev>/rdesc 05 01 09 06 a1 01 85 01 05 07 15 00 25 01 19 e0 29 e7 75 01 95 08 81 02 95 05 75 01 05 08 19 01 29 05 91 02 95 01 75 03 91 03 95 08 75 01 15 00 25 01 06 00 ff 09 03 81 03 95 06 75 08 15 00 25 [65] 05 07 19 00 29 [65] 81 00 95 01 75 01 15 00 25 01 05 0c 09 b8 81 02 95 01 75 01 06 01 ff 09 03 81 02 95 01 75 06 81 03 06 02 ff 09 55 85 55 15 00 26 ff 00 75 08 95 40 b1 a2 c0 06 00 ff 09 14 a1 01 85 90 05 84 75 01 95 03 15 00 25 01 09 61 05 85 09 44 09 46 81 02 95 05 81 01 75 08 95 01 15 00 26 ff 00 09 65 81 02 c0 00 Position 64(Logical Maximum) and 70(Usage Maximum) are 101. Both should be 0xE7 to support JIS specific keys(ろ, Eisu, Kana, |) support. position 117 is also 101 but not related(it is Usage 65h). There are no difference of product id between JIS and ANSI. They are same 0x0267. Signed-off-by:
Mizuho Mori <morimolymoly@gmail.com> Signed-off-by:
-
F.A.Sulaiman authored
Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver. The problem is the driver assumes the device must have an input report but some malicious devices violate this assumption. So this patch checks hid_device's input is non empty before it's been used. Reported-by: syzbot+07efed3bc5a1407bd742@syzkaller.appspotmail.com Signed-off-by:
F.A. SULAIMAN <asha.16@itfac.mrt.ac.lk> Reviewed-by:
Pavel Skripkin <paskripkin@gmail.com> Signed-off-by:
-
Cai Huoqing authored
remove it because SPDX-License-Identifier is already used Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Cai Huoqing authored
remove it because SPDX-License-Identifier is already used Signed-off-by:
-
Cai Huoqing authored
remove it because SPDX-License-Identifier is already used Signed-off-by:
-
Cai Huoqing authored
remove it because SPDX-License-Identifier is already used Signed-off-by:
-
Cai Huoqing authored
remove it because SPDX-License-Identifier is already used Signed-off-by:
-
Rajat Asthana authored
Syzkaller reported a warning called "rcu detected stall in dummy_timer". The error seems to be an error in mceusb_dev_recv(). In the case of -EPROTO error, the routine immediately resubmits the URB. Instead it should return without resubmitting URB. Reported-by: syzbot+4d3749e9612c2cfab956@syzkaller.appspotmail.com Signed-off-by:
Rajat Asthana <rajatasthana4@gmail.com> Signed-off-by:
-
Pavel Skripkin authored
Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized mutex. The problem was in wrong mutex_init() location. Previous mutex_init(&state->msg_lock) call was in ->init() function, but dvb_usbv2_init() has this order of calls: dvb_usbv2_init() dvb_usbv2_adapter_init() dvb_usbv2_adapter_frontend_init() props->frontend_attach() props->init() Since mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach() internally we need to initialize state->msg_lock before frontend_attach(). To achieve it, ->probe() call added to all mxl111sf_* devices, which will simply initiaize mutex. Reported-and-tested-by: syzbot+5ca0bf339f13c4243001@syzkaller.appspotmail.com Fixes: 85722118 ("[media] mxl111sf: convert to new DVB USB") Signed-off-by:
-
jing yangyang authored
./drivers/media/rc/meson-ir-tx.c:398:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
jing yangyang <jing.yangyang@zte.com.cn> Signed-off-by:
-
Sean Young authored
This causes the same urb to resubmitted continuously, hogging up a cpu. Signed-off-by:
-
Sean Young authored
After sending the start transmit command, the device is supposed to respond with the length of the buffer which can be sent. There might be some residual ir data there. Signed-off-by:
-
Sean Young authored
A value of 25 means firmware version 2.5. Signed-off-by:
-
Sean Young authored
The IR receiver has two issues: - Sometimes there is no response to a button press - Sometimes a button press is repeated when it should not have been Hanging the polling interval fixes this behaviour. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994050 Cc: stable@vger.kernel.org Suggested-by:
Joaquín Alberto Calderón Pozo <kini_calderon@hotmail.com> Signed-off-by:
-
Eugen Hristev authored
The runtime enabling of the ISPCK (internally clocks the pipeline inside the ISC) has to be done after the pm_runtime for the ISC dev has been started. After the commit by Mauro: the ISC failed to probe with the error: atmel-sama5d2-isc f0008000.isc: failed to enable ispck: -13 atmel-sama5d2-isc: probe of f0008000.isc failed with error -13 This is because the enabling of the ispck is done too early in the probe, and the PM runtime returns invalid request. Thus, moved this clock enabling after pm_runtime_idle is called. The ISPCK is required only for sama5d2 type of ISC. Thus, add a bool inside the isc struct that is platform dependent. For the sama7g5-isc, the enabling of the ISPCK is wrong and does not make sense. Removed it from the sama7g5 probe. In sama7g5-isc, there is only one clock, the MCK, which also clocks the internal pipeline of the ISC. Adapted the clk_prepare and clk_unprepare to request the runtime PM for both clocks (MCK and ISPCK) in case of sama5d2-isc, and the single clock (MCK) in case of sama7g5-isc. Fixes: dd97908e ("media: atmel: properly get pm_runtime") Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Hans Verkuil authored
Fix a bunch of kernel-doc warnings: drivers/staging/media/meson/vdec/esparser.h:22: warning: Function parameter or member 'core' not described in 'esparser_queue_eos' drivers/staging/media/meson/vdec/esparser.h:22: warning: Function parameter or member 'data' not described in 'esparser_queue_eos' drivers/staging/media/meson/vdec/esparser.h:22: warning: Function parameter or member 'len' not described in 'esparser_queue_eos' drivers/staging/media/meson/vdec/esparser.h:28: warning: Function parameter or member 'work' not described in 'esparser_queue_all_src' drivers/staging/media/meson/vdec/vdec.h:92: warning: Function parameter or member 'vdec_hevcf_clk' not described in 'amvdec_core' drivers/staging/media/meson/vdec/vdec.h:92: warning: Function parameter or member 'vdev_dec' not described in 'amvdec_core' drivers/staging/media/meson/vdec/vdec.h:92: warning: Function parameter or member 'lock' not described in 'amvdec_core' drivers/staging/media/meson/vdec/vdec.h:141: warning: Function parameter or member 'resume' not described in 'amvdec_codec_ops' drivers/staging/media/meson/vdec/vdec.h:274: warning: Function parameter or member 'lock' not described in 'amvdec_session' drivers/staging/media/meson/vdec/vdec.h:274: warning: Function parameter or member 'sequence_out' not described in 'amvdec_session' drivers/staging/media/meson/vdec/vdec.h:274: warning: Function parameter or member 'num_dst_bufs' not described in 'amvdec_session' drivers/staging/media/meson/vdec/vdec.h:274: warning: Function parameter or member 'changed_format' not described in 'amvdec_session' drivers/staging/media/meson/vdec/vdec.h:274: warning: Function parameter or member 'last_offset' not described in 'amvdec_session' drivers/staging/media/meson/vdec/vdec.h:274: warning: Function parameter or member 'wrap_count' not described in 'amvdec_session' drivers/staging/media/meson/vdec/vdec.h:274: warning: Function parameter or member 'fw_idx_to_vb2_idx' not described in 'amvdec_session' drivers/staging/media/meson/vdec/vdec_helpers.h:59: warning: Function parameter or member 'tc' not described in 'amvdec_add_ts' drivers/staging/media/meson/vdec/vdec_helpers.h:59: warning: Function parameter or member 'flags' not described in 'amvdec_add_ts' Signed-off-by:
-
Colin Ian King authored
Currently a call to snd_card_new that fails will set card with a NULL pointer, this causes a null pointer dereference on the error cleanup path when card it passed to snd_card_free. Fix this by adding a new error exit path that does not call snd_card_free and exiting via this new path. Addresses-Coverity: ("Explicit null dereference") Fixes: 9e44d632 ("[media] cx23885: Add ALSA support") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Kees Cook authored
The "card" string only holds 31 characters (and the terminating NUL). In order to avoid truncation, use a shorter card description instead of the current result, "Trident TVMaster TM5600/6000/60". Suggested-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Kees Cook authored
The "card" string only holds 31 characters (and the terminating NUL). In order to avoid truncation, use a shorter card description instead of the current result, "Silicon Labs Si470x FM Radio Re". Suggested-by:
-
Kees Cook authored
The "card" string only holds 31 characters (and the terminating NUL). In order to avoid truncation, use a shorter card description instead of the current result, "Texas Instruments Wl1273 FM Rad". Suggested-by:
-
Arnd Bergmann authored
Without this, I see a randconfig link failure: aarch64-linux-ld: drivers/media/platform/rcar_drif.o: in function `rcar_drif_remove': rcar_drif.c:(.text+0x2a8): undefined reference to `v4l2_async_notifier_unregister' aarch64-linux-ld: rcar_drif.c:(.text+0x2b0): undefined reference to `v4l2_async_notifier_cleanup' aarch64-linux-ld: drivers/media/platform/rcar_drif.o: in function `rcar_drif_sdr_probe': rcar_drif.c:(.text+0x1444): undefined reference to `v4l2_async_notifier_init' aarch64-linux-ld: rcar_drif.c:(.text+0x14a0): undefined reference to `v4l2_async_notifier_register' aarch64-linux-ld: rcar_drif.c:(.text+0x14d8): undefined reference to `v4l2_async_notifier_cleanup' aarch64-linux-ld: rcar_drif.c:(.text+0x15a8): undefined reference to `__v4l2_async_notifier_add_fwnode_subdev' I could not easily figure out when this was introduced, as this code has not changed in a while but I only saw the problem recently. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Pedro Terra authored
Modify the scaler subdevice to accept setting the resolution of the source pad (previously the source resolution would always be 3 times the sink for both dimensions). Now any resolution can be set at src (even smaller ones) and the sink video will be scaled to match it. Test example: With the vimc module up (using the default vimc topology) media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Scaler":0[fmt:RGB888_1X24/640x480]' media-ctl -d platform:vimc -V '"Scaler":0[crop:(100,50)/400x150]' media-ctl -d platform:vimc -V '"Scaler":1[fmt:RGB888_1X24/300x700]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=300,height=700 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=10 -z platform:vimc -d "RGB/YUV Capture" \ --stream-to=test.raw The result will be a cropped stream that can be checked with the command ffplay -loglevel warning -v info -f rawvideo -pixel_format rgb24 \ -video_size "300x700" test.raw Co-developed-by:
Gabriela Bittencourt <gabrielabittencourt00@gmail.com> Signed-off-by:
Gabriel Francisco Mandaji <gfmandaji@gmail.com> Signed-off-by:
Pedro Terra <pedro@terraco.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Niklas Söderlund authored
When adding an internal scratch buffer to improve buffer handling when stopping it was also erroneously used when syncing at capture start. This led to that the first three buffers captured were always dropped as they were captured in the scratch buffer instead of in a buffer provided by the user. Allow the hardware to be given user provided buffers when preparing for capture in the stopped state. This still allows the driver to sync with the hardware and always completes the buffers to user-space in the correct order as no buffers are completed before the sync is complete. This change improves the driver as buffers are completed and given to the user three frames earlier than before. The change also fixes a warning produced by v4l2-compliance, warn: v4l2-test-buffers.cpp(448): got sequence number 3, expected 0 [hverkuil: fixed some typos in the Subject and the log message] Signed-off-by: -
Colin Ian King authored
The pointer t is being assigned a value that is never read, it is being updated later on inside the for-loop. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Ondrej Jirman authored
Previously it was possible, but a recent fix for uninitialized `ret` variable broke this behavior. v4l2_fh_is_singular_file() check is there just to determine whether the power needs to be enabled, and it's not a failure if it returns false. Fixes: ba913911 ("media: sun6i-csi: add a missing return code") Signed-off-by:
Ondrej Jirman <megous@megous.com> Reviewed-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
-
Martin Kepplinger authored
Some tools like v4l2-compliance let users select a media device based on the bus_info string which can be quite convenient. Use a unique string for that. This also fixes the following v4l2-compliance warning: warn: v4l2-test-media.cpp(52): empty bus_info Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Reviewed-by:
-
Martin Kepplinger authored
Even if model and bus_info currently both are 32 bytes large, use the correct array size for bus_info. Signed-off-by:
-
zhaoxiao authored
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately. Signed-off-by:
zhaoxiao <long870912@gmail.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Randy Dunlap authored
Fix the build errors reported by the kernel test robot by selecting V4L2_ASYNC: mips-linux-ld: drivers/media/i2c/ths8200.o: in function `ths8200_remove': ths8200.c:(.text+0x1ec): undefined reference to `v4l2_async_unregister_subdev' mips-linux-ld: drivers/media/i2c/ths8200.o: in function `ths8200_probe': ths8200.c:(.text+0x404): undefined reference to `v4l2_async_register_subdev' Fixes: ed29f894 ("media: i2c: ths8200: support asynchronous probing") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Lad Prabhakar <prabhakar.csengg@gmail.com> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Ezequiel Garcia authored
Update the media drivers I maintain to use my personal mail address. Signed-off-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Cai Huoqing authored
'linux-renesas-soc' is the mailing list for renesas SOC driver, so add it to renesas JPU driver info. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Dan Carpenter authored
This driver takes "osd_xres" and "osd_yres" as module parameters and caps the upper bounds but it doesn't cap the lower bounds. Obviously the admin is not going to enter negative resolutions but the possibility makes static analysis more difficult. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Cai Huoqing authored
Use usb_get_dev() to increment the reference count of the usb device structure in order to avoid releasing the structure while it is still in use. And use usb_put_dev() to decrement the reference count and thus, when it will be equal to 0 the structure will be released. Signed-off-by:
-
Cai Huoqing authored
Remove including <linux/version.h> that don't need it. Signed-off-by:
-
Seongyong Park authored
MLX90640 should ideally be working without a frame skip. In short, if a frame is skipped, then half of a frame loses correction information, having no way to retrieve its original compensation. This patch improves the timing in three ways: 1) Replaced schedule_timeout_interruptible() to usleep_range() The former "only ensures that it will sleep for at least schedule_delay (if not interrupted)", as pointed out by mchehab. As a result, the frame rate could lag behind than the actual capability of the hardware (Raspberry Pi would show a few Hz slower than set value) 2) Calculation based on us, not jiffies Jiffies usually has resolution of 100Hz, and possibly even cruder. MLX90640 can go up to 64Hz frame rate, which does not make sense to calculate the interval with aforementioned resolution. 3) Interval calculation based on the last frame's end time Using the start time of the current frame will probably make tiny bit of drift every time. This made more sense when I didn't realize 1), but it still makes sense without adding virtually any complexity, so this stays in. Signed-off-by:
Seongyong Park <euphoriccatface@gmail.com> Acked-by:
Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by:
-
Deepak R Varma authored
Several trivial code reformatting changes done according to the coding style guidelines. These changes improves code organisation and readability and also 4 address many chackpatch error, warning and check complaints. Signed-off-by:
Deepak R Varma <drv@mailo.com> Signed-off-by:
-
Sergey Senozhatsky authored
This adds support for the new noncontiguous DMA API, which requires allocators to have two execution branches: one for the current API, and one for the new one. Signed-off-by:
Sergey Senozhatsky <senozhatsky@chromium.org> Acked-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
