- 20 Apr, 2018 30 commits
-
-
Niklas Söderlund authored
On Gen3 the max supported width and height will be different from Gen2. Move the limits to the struct rvin_info to prepare for Gen3 support. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Niklas Söderlund authored
When Gen3 support is added to the driver more than model ID will be different for the different SoCs. To avoid a lot of if statements in the code create a struct rvin_info to store this information. While we are at it rename the poorly chosen enum which contains the different model IDs from chip_id to model_id. Also sort the compatible string entries and make use of of_device_get_match_data() which will always work as the driver is DT only, so there's always a valid match. Signed-off-by:
-
Niklas Söderlund authored
In preparation for Gen3 support move the subdevice initialization and clean up from rvin_v4l2_{register,unregister}() directly to the async callbacks. This simplifies the addition of Gen3 support as the rvin_v4l2_register() can be shared for both Gen2 and Gen3 while direct subdevice control are only used on Gen2. While moving this code drop a large comment which is copied from the framework documentation and fold rvin_mbus_supported() into its only caller. Also move the initialization and cleanup code to separate functions to increase readability. Signed-off-by: -
Niklas Söderlund authored
If the video device was registered by the complete() callback it should be unregistered when a device is unbound from the driver. Protect from printing an uninitialized video device node name by adding a check in rvin_v4l2_unregister() to identify that the video device is registered. Signed-off-by:
-
Niklas Söderlund authored
The functions to register and unregister the hardware and video device where poorly named from the start. Rename them to better describe their intended function. Signed-off-by:
-
Niklas Söderlund authored
Document the devicetree bindings for the CSI-2 inputs available on Gen3. There is a need to add a custom property 'renesas,id' and to define which CSI-2 input is described in which endpoint under the port@1 node. This information is needed since there are a set of predefined routes between each VIN and CSI-2 block. This routing table will be kept inside the driver but in order for it to act on it it must know which VIN and CSI-2 is which. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Fabrizio Castro authored
Add compatible strings for r8a7743 and r8a7745. No driver change is needed as "renesas,rcar-gen2-vin" will activate the right code. However, it is good practice to document compatible strings for the specific SoC as this allows SoC specific changes to the driver if needed, in addition to document SoC support and therefore allow checkpatch.pl to validate compatible string values. Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Biju Das <biju.das@bp.renesas.com> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
Fabrizio Castro authored
Change the sorting of the part numbers from descending to ascending to match with other documentation. Signed-off-by:
-
Ryder Lee authored
The usage of of_device_get_match_data() reduce the code size a bit. Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Acked-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Andi Shyti authored
Because I will be leaving Samsung soon, update my e-mail to the etezian.org mail. Cc: Andi Shyti <andi@etezian.org> Signed-off-by:
Andi Shyti <andi.shyti@samsung.com> Signed-off-by:
-
Sean Young authored
The HVR 1300 has a Z8F0811 IR device, which can do both IR transmit and receive. The transmit part was not probed. Signed-off-by:
-
Sean Young authored
mceusb devices have a default timeout of 100ms, but this can be changed. Signed-off-by:
-
Sean Young authored
The last usb packet with IR data will end with 0x80 (MCE_IRDATA_TRAILER). If we reset the decoder state at this point, IR decoding can fail. Signed-off-by:
-
Sean Young authored
The MCE keyboard sends both key down and key up events. We have a timeout handler mce_kbd_rx_timeout() in case the keyup event is never received; however, this may race with new key down events from occurring. The race is that key down scancode arrives and key down events are generated. The timeout handler races this and generates key up events straight afterwards. Since the keyboard generates scancodes every 100ms, most likely the keys will be repeated 100ms later, and now we have new key down events and the user sees duplicate key presses. Reported-by:
Matthias Reichl <hias@horus.com> Signed-off-by:
-
Sean Young authored
There is nothing to sync in this code path. Reported-by:
-
Sean Young authored
The MCE Remote sends a 0 scancode when keys are released. If this is not received or decoded, then keys can get "stuck"; the keyup event is not sent since the input_sync() is missing from the timeout handler. Cc: stable@vger.kernel.org Signed-off-by:
-
Sean Young authored
If two keys are pressed, then both keys are encoded in the scancode. This makes the mce keyboard more responsive. Signed-off-by:
-
Sean Young authored
The mce keyboard repeats pressed keys every 100ms. If the IR timeout is set to less than that, we send key up events before the repeat arrives, so we have key up/key down for each IR repeat. The keyboard ends any sequence with a 0 scancode, in which case all keys are cleared so there is no need to run the timeout timer: it only exists for the case that the final 0 was not received. Signed-off-by:
-
Sean Young authored
Each IR protocol has its own repeat period. We can minimise the keyup timer to be the protocol period + IR timeout. This makes keys less "sticky" and makes IR more reactive and nicer to use. This feature was previously attempted in commit d57ea877 ("media: rc: per-protocol repeat period"), but that did not take the IR timeout into account, and had to be reverted. Signed-off-by:
-
Sean Young authored
Since the kernel now modifies the timeout, make it possible to retrieve the current value. Signed-off-by:
-
Sean Young authored
The longer the IR timeout, the longer the rc device waits until delivering the trailing space. So, by reducing this timeout, we reduce the delay for the last scancode to be delivered. Note that the lirc daemon disables all protocols, in which case we revert back to the default value. Signed-off-by:
-
Sean Young authored
On the raspberry pi, we might have two lirc devices; one for sending and one for receiving. This change makes it much more apparent which one is which. Signed-off-by:
-
Koji Matsuoka authored
In Video Pixel/Line Pre-Clip Register, the setting value can be set in 1 line unit, but it can only be specified as a multiple of 4 by v4l_bound_align_image function(). So correct that it can be specified in 1 line unit with this patch. Signed-off-by:
Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Acked-by:
Hans Verkuil <hansverk@cisco.com> Signed-off-by:
-
Colin Ian King authored
Setting v with the CEC_PIN_EVENT_FL_DROPPED is incorrect, instead ev should be set with this bit. Fix this. Detected by CoverityScan, CID#1467974 ("Extra high-order bits") Fixes: 6ec1cbf6 ("media: cec: improve CEC pin event handling") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Kai-Heng Feng authored
User reports AverMedia DVD EZMaker 7 can be driven by VIDEO_GRABBER. Add the device to the id_table to make it work. BugLink: https://bugs.launchpad.net/bugs/1620762 Cc: stable@vger.kernel.org Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Suman Anna authored
The OMAP3 ISP driver manages its MMU mappings through the IOMMU-aware ARM DMA backend. The current code creates a dma_iommu_mapping and attaches this to the ISP device, but never detaches the mapping in either the probe failure paths or the driver remove path resulting in an unbalanced mapping refcount and a memory leak. Fix this properly. Reported-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Suman Anna <s-anna@ti.com> Tested-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
This file does a lot of non-trivial struff. Document it using kernel-doc markups where needed and improve the comments inside do_video_ioctl(). Reviewed-by:
-
Mauro Carvalho Chehab authored
Making the cast right for get_user/put_user is not trivial, as it needs to ensure that the types are the correct ones. Improve it by using macros. Tested with vivid with: $ sudo modprobe vivid no_error_inj=1 $ v4l2-compliance-32bits -a -s10 >32bits && v4l2-compliance-64bits -a -s10 > 64bits && diff -U0 32bits 64bits --- 32bits 2018-04-17 11:18:29.141240772 -0300 +++ 64bits 2018-04-17 11:18:40.635282341 -0300 @@ -1 +1 @@ -v4l2-compliance SHA : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 32 bits +v4l2-compliance SHA : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 64 bits Using the latest version of v4l-utils with this patch applied: https://patchwork.linuxtv.org/patch/48746/Reviewed-by:
-
Mauro Carvalho Chehab authored
In the past, "up" were an acronym for "user pointer" and "kp" for "kernel pointer". However, since commit a1dfb4c4 ("media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"), both are now __user pointers. So, the usage of "kp" is really misleading there. So, rename both to just "p32" and "p64" everywhere it occurs, in order to make peace with this file's namespace. There are two exceptions to "up/kp" nomenclature: at alloc_userspace() and at do_video_ioctl(). There, a new userspace pointer were allocated, in order to store the 64 bits version of the ioctl. Those were called as "up_native", with is, IMHO, an even worse name, as "native" could mislead of being the arguments that were filled from userspace. I almost renamed it to just "p64", but, after thinking more about that, it sounded better to call it as "new_p64", as this makes clearer that this is the data structure that was allocated inside this file in order to be used to pass/retrieve data when calling the 64-bit ready file->f_op->unlocked_ioctl() function. Suggested-by:
Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by:
-
Mauro Carvalho Chehab authored
Smatch report several issues with bad __user annotations: drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect type in argument 1 (different address spaces) drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: expected void [noderef] <asn:1>*uptr drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: got void *<noident> drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: warning: incorrect type in argument 1 (different address spaces) drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: expected void const volatile [noderef] <asn:1>*<noident> drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: got struct v4l2_plane [noderef] <asn:1>**<noident> drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: warning: incorrect type in argument 1 (different address spaces) drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: expected void [noderef] <asn:1>*uptr drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: got void *[assigned] base drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: warning: incorrect type in assignment (different address spaces) drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: expected struct v4l2_ext_control [noderef] <asn:1>*kcontrols drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: got struct v4l2_ext_control *<noident> drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: warning: incorrect type in assignment (different address spaces) drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: expected unsigned char [usertype] *__pu_val drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: got void [noderef] <asn:1>* drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: warning: incorrect type in argument 1 (different address spaces) drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: expected void [noderef] <asn:1>*uptr drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: got void *[assigned] edid Fix them. Reviewed-by:
-
- 18 Apr, 2018 1 commit
-
-
Mauro Carvalho Chehab authored
Instead of +=, the rule had :=, with actually disables build of everything else. Fixes: 58757984 ("media: si470x: allow build both USB and I2C at the same time") Reported-by:
Daniel Scheller <d.scheller.oss@gmail.com> Signed-off-by:
-
- 17 Apr, 2018 9 commits
-
-
Daniel Scheller authored
The check for a valid ptr in ddb_io->dma isn't really necessary since only devices that do data transport using DMA are supported by the driver, and all previous initialisation code (through input_init(), output_init() and dma_init(), has_dma is always true as it's set in ddb_probe() during driver load) guarantees the ptr is set. As a side effect, this silences these sparse warnings (albeit them being false positives as ddb_io->dma won't change in these functions so the condition always equals to the same result): drivers/media/pci/ddbridge/ddbridge-core.c:495:9: warning: context imbalance in 'ddb_output_start' - different lock contexts for basic block drivers/media/pci/ddbridge/ddbridge-core.c:510:9: warning: context imbalance in 'ddb_output_stop' - different lock contexts for basic block drivers/media/pci/ddbridge/ddbridge-core.c:525:9: warning: context imbalance in 'ddb_input_stop' - different lock contexts for basic block drivers/media/pci/ddbridge/ddbridge-core.c:560:9: warning: context imbalance in 'ddb_input_start' - different lock contexts for basic block Signed-off-by:Daniel Scheller <d.scheller@gmx.net> Signed-off-by:
-
Mauro Carvalho Chehab authored
As warned by smatch: drivers/media/pci/mantis/mantis_uart.c:105 mantis_uart_work() warn: this loop depends on readl() succeeding If something goes wrong at readl(), the logic will stay there inside an IRQ code forever. This is not the nicest thing to do :-) So, add a timeout there, preventing staying inside the IRQ for more than 10ms. Signed-off-by: -
Mauro Carvalho Chehab authored
As warned by smatch: drivers/media/rc/st_rc.c:110 st_rc_rx_interrupt() warn: this loop depends on readl() succeeding If something goes wrong at readl(), the logic will stay there inside an IRQ code forever. This is not the nicest thing to do :-) So, add a timeout there, preventing staying inside the IRQ for more than 10ms. Acked-by:
Patrice Chotard <patrice.chotard@st.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
On smatch, this warning is trigged: drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c:324 __bo_take_off_handling() error: we previously assumed 'bo->prev' could be null (see line 314) Because it can't properly analize the truth table for the above function. So, add an explicit check for the final condition there. Signed-off-by: -
Mauro Carvalho Chehab authored
The __user annotations at the compat32 code is not right: drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18: expected void *base drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23: expected unsigned int [usertype] *xcoords_y drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23: expected unsigned int [usertype] *ycoords_y drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24: expected unsigned int [usertype] *xcoords_uv drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24: expected unsigned int [usertype] *ycoords_uv drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29: expected unsigned int [usertype] *effective_width drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29: expected unsigned int [usertype] *effective_width drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19: expected struct v4l2_framebuffer *frame drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29: expected unsigned short *calb_grp_values drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:701:39: warning: cast removes address space of expression drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21: warning: incorrect type in argument 1 (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21: expected void const volatile [noderef] <asn:1>*<noident> drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21: got unsigned int [usertype] *src drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43: expected struct atomisp_shading_table *shading_table drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44: warning: incorrect type in argument 1 (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44: expected void [noderef] <asn:1>*to drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44: got struct atomisp_shading_table *shading_table drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41: expected struct atomisp_morph_table *morph_table drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44: warning: incorrect type in argument 1 (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44: expected void [noderef] <asn:1>*to drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44: got struct atomisp_morph_table *morph_table drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40: expected struct atomisp_dvs2_coefficients *dvs2_coefs drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44: warning: incorrect type in argument 1 (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44: expected void [noderef] <asn:1>*to drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44: got struct atomisp_dvs2_coefficients *dvs2_coefs drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46: expected struct atomisp_dvs_6axis_config *dvs_6axis_config drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46: got void [noderef] <asn:1>* drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44: warning: incorrect type in argument 1 (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44: expected void [noderef] <asn:1>*to drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44: got struct atomisp_dvs_6axis_config *dvs_6axis_config drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17: expected struct atomisp_sensor_ae_bracketing_lut_entry *lut drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17: got void [noderef] <asn:1>* Signed-off-by: -
Mauro Carvalho Chehab authored
There are two functions used externally: drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:866:6: warning: symbol 'atomisp_do_compat_ioctl' was not declared. Should it be static? drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:1110:6: warning: symbol 'atomisp_compat_ioctl32' was not declared. Should it be static? whose include header is missing. Add it. Signed-off-by: -
Mauro Carvalho Chehab authored
The logic at get_atomisp_parameters32() is broken, as pointed by smatch: drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:21: warning: dereference of noderef expression drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:744:60: warning: dereference of noderef expression drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:763:21: warning: dereference of noderef expression drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:770:60: warning: dereference of noderef expression drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:21: warning: dereference of noderef expression drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:795:60: warning: dereference of noderef expression drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:812:21: warning: dereference of noderef expression drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:819:60: warning: dereference of noderef expression It tries to access userspace data directly, without calling get_user(). That should generate OOPS. Thankfully, the right logic is already there (although commented out). Signed-off-by: -
Mauro Carvalho Chehab authored
As warned by smatch: drivers/media/v4l2-core/v4l2-compat-ioctl32.c:879 put_v4l2_ext_controls32() warn: check for integer overflow 'count' The access_ok() logic should check for too big arrays too. Cc: stable@vger.kernel.org Signed-off-by: -
Mauro Carvalho Chehab authored
The omap/omap3 and viu drivers are for 32 bit platforms only. There, a pointer has 32 bits. Now that those drivers build for 64 bits with COMPILE_TEST, they produce the following warnings: drivers/media/platform/omap/omap_vout_vrfb.c: In function 'omap_vout_allocate_vrfb_buffers': drivers/media/platform/omap/omap_vout_vrfb.c:57:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] memset((void *) vout->smsshado_virt_addr[i], 0, ^ drivers/media/platform/fsl-viu.c: In function 'viu_setup_preview': drivers/media/platform/fsl-viu.c:753:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] reg_val.field_base_addr = (u32)dev->ovbuf.base; ^ drivers/media/platform/omap/omap_vout.c: In function 'omap_vout_get_userptr': drivers/media/platform/omap/omap_vout.c:209:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] *physp = virt_to_phys((void *)virtp); ^ drivers/media/platform/omap3isp/ispccdc.c: In function 'ccdc_config': drivers/media/platform/omap3isp/ispccdc.c:738:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (__force void __user *)fpc.fpcaddr, ^ Add some typecasts to remove those warnings when building for 64 bits. Signed-off-by:
-
