- 09 Apr, 2021 16 commits
-
-
Andre Przywara authored
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>
-
Hao Fang authored
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:
-
Arnd Bergmann authored
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:
-
Pavel Skripkin authored
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:
-
Christian Hewitt authored
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:
-
Arnd Bergmann authored
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: 776338e1 ("[PATCH] dvb: Add generalized dvb-usb driver") Signed-off-by: -
Colin Ian King authored
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: d4a3fa66 ("media: dvb-frontends: lgdt3306a.c: remove dead code") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Hans Verkuil authored
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:
-
Dinghao Liu authored
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:
-
Dinghao Liu authored
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:
-
Mirela Rabulea authored
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:
-
Yang Yingliang authored
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:
-
Yang Yingliang authored
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:
-
Yang Yingliang authored
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:
-
Yang Yingliang authored
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:
-
Yang Yingliang authored
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:
-
- 08 Apr, 2021 2 commits
-
-
Mauro Carvalho Chehab authored
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 authored
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:
-
- 07 Apr, 2021 2 commits
-
-
Mauro Carvalho Chehab authored
The file name: Documentation/devicetree/bindings/media/i2c/ov2680.yaml should be, instead: Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml. Update its cross-reference accordingly. Fixes: 57226cd8 ("media: dt-bindings: ov2680: convert bindings to yaml") Reviewed-by:
Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
The file name: Documentation/devicetree/bindings/media/i2c/rdacm2x-gmsl.yaml should be, instead: Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml. Update its cross-reference accordingly. Fixes: 34009bff ("media: i2c: Add RDACM20 driver") Fixes: e9f81768 ("media: dt-bindings: media: i2c: Add bindings for IMI RDACM2x") Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
- 06 Apr, 2021 20 commits
-
-
Sylwester Nawrocki authored
Fixes scripts/kernel-doc warnings: s5p_mfc_common.h:343: warning: Function parameter or member 'fw_buf' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'mem_size' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'mem_base' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'mem_bitmap' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'mem_virt' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'dma_base' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'watchdog_timer' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'fw_get_done' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'risc_on' not described in 's5p_mfc_dev' s5p_mfc_common.h:714: warning: Function parameter or member 'src_bufs_cnt' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'dst_bufs_cnt' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'pb_count' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'force_frame_type' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'slice_mode' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'slice_size' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'frame_tag' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'scratch_buf_size' not described in 's5p_mfc_ctx' Reported-by:
Hans verkuil <hverkuil@xs4all.nl> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Sylwester Nawrocki authored
Fixes scripts/kernel-doc warnings: fimc-is.h:286: warning: Function parameter or member 'fw' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'memory' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'f_w' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'isp' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'sensor' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'setfile' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'ctrl_handler' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'irq' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'sensor_index' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'i2h_cmd' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'h2i_cmd' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'fd_header' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'config' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'config_index' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'is_p_region' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'is_dma_p_region' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'is_shared_region' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'af' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'debugfs_entry' not described in 'fimc_is' The f_w field is unused so remove it. Reported-by:
-
Hans Verkuil authored
If the EDID has an odd number of blocks (usually just 1, but the same problem occurs with 3 blocks), then VIDIOC_G_EDID reported 2 (or 4) blocks. Fix this. Signed-off-by:
-
Hans Verkuil authored
While the adv7604/11/12 hardware supported EDIDs up to 4 blocks, the driver didn't. This patch adds support for this. It also improves support for EDIDs that do not have a Source Physical Address: in that case the spa location is set to the first byte of the second block, and the 'physical address' is just the two bytes at that location. This is per the suggestion in the adv76xx documentation for such EDIDs. Tested with an adv7604 and adv7612. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Hans Verkuil authored
For the adv7604 the hotplug detect pin is controlled through gpio pins from the SoC, but the adv7611 and adv7612 control the hotplug detect pin themselves. But the driver had no support for this, so the HPD was always high, even when changing the EDID. Add proper support for this to the driver. Tested with an adv7612. Signed-off-by:
-
Daniel Almeida authored
According to the v4l2 api, it is allowed to skip setting a control if its contents haven't changed for performance reasons: userspace should only update the controls that changed from last frame rather then updating them all. Still some ancient code that checks for mandatory controls has been left in this driver. Remove it. Fixes: cd33c830 ("media: rkvdec: Add the rkvdec driver") Signed-off-by:
Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
-
Geert Uytterhoeven authored
The i.MX8 QXP/QM integrated JPEG encoder/decoder is only present on Freescale/NXP i.MX8 QXP and QM SoCs. Hence add a dependency on ARCH_MXC, to prevent asking the user about this driver when configuring a kernel without i.MX8 support. Drop the "default m" (which means "default y" if CONFIG_MODULES is not enabled), as merely enabling CONFIG_COMPILE_TEST should not enable additional code. Fixes: 2db16c6e ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Wan Jiabing authored
struct em28xx is declared at 219th line. The declaration here is unnecessary. Remove it. Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
-
Wan Jiabing authored
struct cx231xx is declared at 146th line. The declaration here is unnecessary. Remove it. Signed-off-by:
-
Yang Yingliang authored
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
Yang Yingliang authored
There is an error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by:
-
Yang Yingliang authored
There is an error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
-
Yang Yingliang authored
There is an error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by:
-
Yang Yingliang authored
There is an error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Hans Verkuil authored
The rx-arb-lost error injection command only works with <op> set to 'any'. Explicitly say so in the usage message. Also use [] to indicate that the <poll> argument is optional. Signed-off-by:
-
Fabio Estevam authored
i.MX is a DT-only platform, so of_match_ptr() can be safely removed. Remove the unneeded of_match_ptr(). Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'tw68_risc_buffer()' (tw68-risc.c) GFP_KERNEL can be used because this function is only called from a vb2_ops buf_prepare function. The call chain is: tw68_video_qops.buf_prepare (tw68-video.c) --> tw68_buf_prepare (tw68-video.c) --> tw68_risc_buffer @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'tw686x_audio_dma_alloc()' (tw686x-audio.c) GFP_KERNEL can be used because it is only called from a probe function and no spinlock is taken in the between. The call chain is: tw686x_probe (tw686x-core.c) --> tw686x_audio_init (tw686x-audio.c) --> tw686x_audio_dma_alloc (tw686x-audio.c) When memory is allocated in 'tw686x_memcpy_dma_alloc()' and in 'tw686x_sg_dma_alloc()' (tw686x-video.c) GFP_KERNEL can be used because these functions are .alloc functions from a tw686x_dma_ops structure. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: -
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'cx23885_risc_buffer()' GFP_KERNEL can be used because this function is only called from a vb2_ops buf_prepare function. The call chain is: cx23885_video_qops.buf_prepare (cx23885-video.c) --> buffer_prepare (cx23885-video.c) --> cx23885_risc_buffer When memory is allocated in 'cx23885_risc_databuffer()' GFP_KERNEL can be used because this function is only called from a function that already uses GFP_KERNEL or from a vb2_ops buf_prepare function. The call chains are: snd_cx23885_hw_params (cx23885-alsa.c) --> use GFP_KERNEL --> cx23885_risc_databuffer cx23885_qops.buffer_prepare (cx23885-417.c) or dvb_qops.buffer_prepare (cx23885-dvb.c) --> cx23885_buf_prepare --> cx23885_risc_databuffer When memory is allocated in 'cx23885_risc_vbibuffer()' GFP_KERNEL can be used because this function is only called from a vb2_ops buf_prepare function. The call chains are: cx23885_vbi_qops.buffer_prepare (cx23885-vbi.c) --> cx23885_risc_vbibuffer @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: -
Irui Wang authored
MTK H264 Encoder(VENC_SYS) and VP8 Encoder(VENC_LT_SYS) are two independent hardware instance. They have their owner interrupt, register mapping, and special clocks. This patch separates them into two devices. This is a preparing patch for adding device_link between the larbs and venc-device. It's mainly for fixing the problem: https://lkml.org/lkml/2019/9/3/316Acked-by:
Tiffany Lin <tiffany.lin@mediatek.com> Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by:
Maoguang Meng <maoguang.meng@mediatek.com> Signed-off-by:
Irui Wang <irui.wang@mediatek.com> Signed-off-by:
-
