summaryrefslogtreecommitdiff
path: root/drivers/media/i2c
AgeCommit message (Collapse)AuthorFilesLines
2024-03-27media: tc358743: register v4l2 async device only after successful setupAlexander Stein1-3/+4
[ Upstream commit 87399f1ff92203d65f1febf5919429f4bb613a02 ] Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Fixes: 4c5211a10039 ("[media] tc358743: register v4l2 asynchronous subdevice") Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240110090111.458115-1-alexander.stein@ew.tq-group.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-08media: ccs: Correctly initialise try compose rectangleSakari Ailus1-1/+1
[ Upstream commit 724ff68e968b19d786870d333f9952bdd6b119cb ] Initialise the try sink compose rectangle size to the sink compose rectangle for binner and scaler sub-devices. This was missed due to the faulty condition that lead to the compose rectangles to be initialised for the pixel array sub-device where it is not relevant. Fixes: ccfc97bdb5ae ("[media] smiapp: Add driver") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20media: i2c: max9286: Fix some redundant of_node_put() callsChristophe JAILLET1-2/+0
[ Upstream commit 0822315e46b400f611cba1193456ee6a5dc3e41d ] This is odd to have a of_node_put() just after a for_each_child_of_node() or a for_each_endpoint_of_node() loop. It should already be called during the last iteration. Remove these calls. Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19media: ov2680: Fix regulators being left enabled on ov2680_power_on() errorsHans de Goede1-2/+6
[ Upstream commit 84b4bd7e0d98166aa32fd470e672721190492eae ] When the ov2680_power_on() "sensor soft reset failed" path is hit during probe() the WARN() about putting an enabled regulator at drivers/regulator/core.c:2398 triggers 3 times (once for each regulator), filling dmesg with backtraces. Fix this by properly disabling the regulators on ov2680_power_on() errors. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19media: ov2680: Fix vflip / hflip set functionsHans de Goede1-38/+12
[ Upstream commit d5d08ad330c9ccebc5e066fda815423a290f48b0 ] ov2680_vflip_disable() / ov2680_hflip_disable() pass BIT(0) instead of 0 as value to ov2680_mod_reg(). While fixing this also: 1. Stop having separate enable/disable functions for hflip / vflip 2. Move the is_streaming check, which is unique to hflip / vflip into the ov2680_set_?flip() functions. for a nice code cleanup. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19media: ov2680: Fix ov2680_bayer_order()Hans de Goede1-19/+14
[ Upstream commit 50a7bad4e0a37d7018ab6fe843dd84bc6b2ecf72 ] The index into ov2680_hv_flip_bayer_order[] should be 0-3, but ov2680_bayer_order() was using 0 + BIT(2) + (BIT(2) << 1) as max index, while the intention was to use: 0 + 1 + 2 as max index. Fix the index calculation in ov2680_bayer_order(), while at it also just use the ctrl values rather then reading them back using a slow i2c-read transaction. This also allows making the function void, since there now are no more i2c-reads to error check. Note the check for the ctrls being NULL is there to allow adding an ov2680_fill_format() helper later, which will call ov2680_set_bayer_order() during probe() before the ctrls are created. [Sakari Ailus: Change all users of ov2680_set_bayer_order() here] Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19media: ov2680: Remove auto-gain and auto-exposure controlsHans de Goede1-144/+17
[ Upstream commit 7b5a42e6ae71927359ea67a2c22570ba97fa4059 ] Quoting the OV2680 datasheet: "3.2 exposure and gain control In the OV2680, the exposure time and gain are set manually from an external controller. The OV2680 supports manual gain and exposure control only for normal applications, no auto mode." And indeed testing with the atomisp_ov2680 fork of ov2680.c has shown that auto-exposure and auto-gain do not work. Note that the code setting the auto-exposure flag was broken, callers of ov2680_exposure_set() were directly passing !!ctrls->auto_exp->val as "bool auto_exp" value, but ctrls->auto_exp is a menu control with: enum v4l2_exposure_auto_type { V4L2_EXPOSURE_AUTO = 0, V4L2_EXPOSURE_MANUAL = 1, ... So instead of passing !!ctrls->auto_exp->val they should have been passing ctrls->auto_exp->val == V4L2_EXPOSURE_AUTO, iow the passed value was inverted of what it should have been. Also remove ov2680_g_volatile_ctrl() since without auto support the gain and exposure controls are not volatile. This also fixes the control values not being properly applied in ov2680_mode_set(). The 800x600 mode register-list also sets gain, exposure and vflip overriding the last set ctrl values. ov2680_mode_set() does call ov2680_gain_set() and ov2680_exposure_set() but did this before writing the mode register-list, so these values would still be overridden by the mode register-list. Add a v4l2_ctrl_handler_setup() call after writing the mode register-list to restore all ctrl values. Also remove the ctrls->gain->is_new check from ov2680_gain_set() so that the gain always gets restored properly. Last since ov2680_mode_set() now calls v4l2_ctrl_handler_setup(), remove the v4l2_ctrl_handler_setup() call after ov2680_mode_restore() since ov2680_mode_restore() calls ov2680_mode_set(). Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19media: i2c: ov2680: Set V4L2_CTRL_FLAG_MODIFY_LAYOUT on flipsDave Stevenson1-0/+2
[ Upstream commit 66274280b2c745d380508dc27b9a4dfd736e5eda ] The driver changes the Bayer order based on the flips, but does not define the control correctly with the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag. Add the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Stable-dep-of: 7b5a42e6ae71 ("media: ov2680: Remove auto-gain and auto-exposure controls") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19media: ov5640: Enable MIPI interface in ov5640_set_power_mipi()Marek Vasut1-2/+2
[ Upstream commit 98cb72d3b9c5e03b10fa993752ecfcbd9c572d8c ] Set OV5640_REG_IO_MIPI_CTRL00 bit 2 to 1 instead of 0, since 1 means MIPI CSI2 interface, while 0 means CPI parallel interface. In the ov5640_set_power_mipi() the interface should obviously be set to MIPI CSI2 since this functions is used to power up the sensor when operated in MIPI CSI2 mode. The sensor should not be in CPI mode in that case. This fixes a corner case where capturing the first frame on i.MX8MN with CSI/ISI resulted in corrupted frame. Fixes: aa4bb8b8838f ("media: ov5640: Re-work MIPI startup sequence") Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> # [Test on imx6q] Signed-off-by: Marek Vasut <marex@denx.de> Tested-by: Jai Luthra <j-luthra@ti.com> # [Test on bplay, sk-am62] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19media: i2c: tvp5150: check return value of devm_kasprintf()Claudiu Beznea1-0/+4
[ Upstream commit 26ce7054d804be73935b9268d6e0ecf2fbbc8aef ] devm_kasprintf() returns a pointer to dynamically allocated memory. Pointer could be NULL in case allocation fails. Check pointer validity. Identified with coccinelle (kmerr.cocci script). Fixes: 0556f1d580d4 ("media: tvp5150: add input source selection of_graph support") Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19media: ad5820: Drop unsupported ad5823 from i2c_ and of_device_id tablesHans de Goede1-2/+0
[ Upstream commit f126ff7e4024f6704e6ec0d4137037568708a3c7 ] The supported ad5820 and ad5821 VCMs both use a single 16 bit register which is written by sending 2 bytes with the data directly after sending the i2c-client address. The ad5823 OTOH has a more typical i2c / smbus device setup with multiple 8 bit registers where the first byte send after the i2c-client address is the register address and the actual data only starts from the second byte after the i2c-client address. The ad5823 i2c_ and of_device_id-s was added at the same time as the ad5821 ids with as rationale: """ Some camera modules also refer that AD5823 is a replacement of AD5820: https://download.kamami.com/p564094-OV8865_DS.pdf """ The AD5823 may be an electrical and functional replacement of the AD5820, but from a software pov it is not compatible at all and it is going to need its own driver, drop its id from the ad5820 driver. Fixes: b8bf73136bae ("media: ad5820: Add support for ad5821 and ad5823") Cc: Pavel Machek <pavel@ucw.cz> Cc: Ricardo Ribalda Delgado <ribalda@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-17media: max9286: Free control handlerLaurent Pinchart1-0/+1
[ Upstream commit bfce6a12e5ba1edde95126aa06778027f16115d4 ] The control handler is leaked in some probe-time error paths, as well as in the remove path. Fix it. Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-22media: m5mols: fix off-by-one loop termination errorLinus Torvalds1-1/+1
[ Upstream commit efbcbb12ee99f750c9f25c873b55ad774871de2a ] The __find_restype() function loops over the m5mols_default_ffmt[] array, and the termination condition ends up being wrong: instead of stopping when the iterator becomes the size of the array it traverses, it stops after it has already overshot the array. Now, in practice this doesn't likely matter, because the code will always find the entry it looks for, and will thus return early and never hit that last extra iteration. But it turns out that clang will unroll the loop fully, because it has only two iterations (well, three due to the off-by-one bug), and then clang will end up just giving up in the middle of the loop unrolling when it notices that the code walks past the end of the array. And that made 'objtool' very unhappy indeed, because the generated code just falls off the edge of the universe, and ends up falling through to the next function, causing this warning: drivers/media/i2c/m5mols/m5mols.o: warning: objtool: m5mols_set_fmt() falls through to next function m5mols_get_frame_desc() Fix the loop ending condition. Reported-by: Jens Axboe <axboe@kernel.dk> Analyzed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Analyzed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/linux-block/CAHk-=wgTSdKYbmB1JYM5vmHMcD9J9UZr0mn7BOYM_LudrP+Xvw@mail.gmail.com/ Fixes: bc125106f8af ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP") Cc: HeungJun, Kim <riverful.kim@samsung.com> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17media: ov5640: Fix analogue gain controlPaul Elder1-1/+1
[ Upstream commit afa4805799c1d332980ad23339fdb07b5e0cf7e0 ] Gain control is badly documented in publicly available (including leaked) documentation. There is an AGC pre-gain in register 0x3a13, expressed as a 6-bit value (plus an enable bit in bit 6). The driver hardcodes it to 0x43, which one application note states is equal to x1.047. The documentation also states that 0x40 is equel to x1.000. The pre-gain thus seems to be expressed as in 1/64 increments, and thus ranges from x1.00 to x1.984. What the pre-gain does is however unspecified. There is then an AGC gain limit, in registers 0x3a18 and 0x3a19, expressed as a 10-bit "real gain format" value. One application note sets it to 0x00f8 and states it is equal to x15.5, so it appears to be expressed in 1/16 increments, up to x63.9375. The manual gain is stored in registers 0x350a and 0x350b, also as a 10-bit "real gain format" value. It is documented in the application note as a Q6.4 values, up to x63.9375. One version of the datasheet indicates that the sensor supports a digital gain: The OV5640 supports 1/2/4 digital gain. Normally, the gain is controlled automatically by the automatic gain control (AGC) block. It isn't clear how that would be controlled manually. There appears to be no indication regarding whether the gain controlled through registers 0x350a and 0x350b is an analogue gain only or also includes digital gain. The words "real gain" don't necessarily mean "combined analogue and digital gains". Some OmniVision sensors (such as the OV8858) are documented as supoprting different formats for the gain values, selectable through a register bit, and they are called "real gain format" and "sensor gain format". For that sensor, we have (one of) the gain registers documented as 0x3503[2]=0, gain[7:0] is real gain format, where low 4 bits are fraction bits, for example, 0x10 is 1x gain, 0x28 is 2.5x gain If 0x3503[2]=1, gain[7:0] is sensor gain format, gain[7:4] is coarse gain, 00000: 1x, 00001: 2x, 00011: 4x, 00111: 8x, gain[7] is 1, gain[3:0] is fine gain. For example, 0x10 is 1x gain, 0x30 is 2x gain, 0x70 is 4x gain (The second part of the text makes little sense) "Real gain" may thus refer to the combination of the coarse and fine analogue gains as a single value. The OV5640 0x350a and 0x350b registers thus appear to control analogue gain. The driver incorrectly uses V4L2_CID_GAIN as V4L2 has a specific control for analogue gain, V4L2_CID_ANALOGUE_GAIN. Use it. If registers 0x350a and 0x350b are later found to control digital gain as well, the driver could then restrict the range of the analogue gain control value to lower than x64 and add a separate digital gain control. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11media: i2c: ov7670: 0 instead of -EINVAL was returnedHans Verkuil1-1/+1
[ Upstream commit 6a4c664539e6de9b32b65ddcf767ec1bcc1d7f8a ] If the media bus is unsupported, then return -EINVAL. Instead it returned 'ret' which happened to be 0. This fixes a smatch warning: ov7670.c:1843 ov7670_parse_dt() warn: missing error code? 'ret' Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 01b8444828fc ("media: v4l2: i2c: ov7670: Implement OF mbus configuration") Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11media: i2c: imx219: Fix binning for RAW8 captureJai Luthra1-8/+49
[ Upstream commit ef86447e775fb1f2ced00d4c7fff2c0a1c63f165 ] 2x2 binning works fine for RAW10 capture, but for RAW8 1232p mode it leads to corrupted frames [1][2]. Using the special 2x2 analog binning mode fixes the issue, but causes artefacts for RAW10 1232p capture. So here we choose the binning mode depending upon the frame format selected. As both binning modes work fine for 480p RAW8 and RAW10 capture, it can share the same code path as 1232p for selecting binning mode. [1] https://forums.raspberrypi.com/viewtopic.php?t=332103 [2] https://github.com/raspberrypi/libcamera-apps/issues/281 Fixes: 22da1d56e982 ("media: i2c: imx219: Add support for RAW8 bit bayer format") Signed-off-by: Jai Luthra <j-luthra@ti.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11media: i2c: imx219: Split common registers from mode tablesAdam Ford1-147/+59
[ Upstream commit 8508455961d5a9e8907bcfd8dcd58f19d9b6ce47 ] There are four modes, and each mode has a table of registers. Some of the registers are common to all modes, so create new tables for these common registers to reduce duplicate code. Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Stable-dep-of: ef86447e775f ("media: i2c: imx219: Fix binning for RAW8 capture") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11media: i2c: imx219: remove redundant writesSameer Puri1-2/+0
[ Upstream commit fbef89886da6d7735d20fdde16a1ee6ed6c6ab56 ] These writes to 0x162, 0x163 already appear earlier in the struct for the 1920x1080 mode and do not need to be repeated. Signed-off-by: Sameer Puri <purisame@spuri.io> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Stable-dep-of: ef86447e775f ("media: i2c: imx219: Fix binning for RAW8 capture") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11media: i2c: ov772x: Fix memleak in ov772x_probe()Yuan Can1-2/+1
[ Upstream commit 7485edb2b6ca5960205c0a49bedfd09bba30e521 ] A memory leak was reported when testing ov772x with bpf mock device: AssertionError: unreferenced object 0xffff888109afa7a8 (size 8): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 8 bytes): 80 22 88 15 81 88 ff ff ."...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 [<00000000a9f2159d>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff888119825c00 (size 256): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 32 bytes): 00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^...... 10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev] [<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 The reason is that if priv->hdl.error is set, ov772x_probe() jumps to the error_mutex_destroy without doing v4l2_ctrl_handler_free(), and all resources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() are leaked. Fixes: 1112babde214 ("media: i2c: Copy ov772x soc_camera sensor driver") Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11media: ov5675: Fix memleak in ov5675_init_controls()Shang XiaoJing1-1/+3
[ Upstream commit dd74ed6c213003533e3abf4c204374ef01d86978 ] There is a kmemleak when testing the media/i2c/ov5675.c with bpf mock device: AssertionError: unreferenced object 0xffff888107362160 (size 16): comm "python3", pid 277, jiffies 4294832798 (age 20.722s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000abe7d67c>] __kmalloc_node+0x44/0x1b0 [<000000008a725aac>] kvmalloc_node+0x34/0x180 [<000000009a53cd11>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<0000000055b46db0>] ov5675_probe+0x38b/0x897 [ov5675] [<00000000153d886c>] i2c_device_probe+0x28d/0x680 [<000000004afb7e8f>] really_probe+0x17c/0x3f0 [<00000000ff2f18e4>] __driver_probe_device+0xe3/0x170 [<000000000a001029>] driver_probe_device+0x49/0x120 [<00000000e39743c7>] __device_attach_driver+0xf7/0x150 [<00000000d32fd070>] bus_for_each_drv+0x114/0x180 [<000000009083ac41>] __device_attach+0x1e5/0x2d0 [<0000000015b4a830>] bus_probe_device+0x126/0x140 [<000000007813deaf>] device_add+0x810/0x1130 [<000000007becb867>] i2c_new_client_device+0x386/0x540 [<000000007f9cf4b4>] of_i2c_register_device+0xf1/0x110 [<00000000ebfdd032>] of_i2c_notify+0xfc/0x1f0 ov5675_init_controls() won't clean all the allocated resources in fail path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to prevent memleak. Fixes: bf27502b1f3b ("media: ov5675: Add support for OV5675 sensor") Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11media: ov2740: Fix memleak in ov2740_init_controls()Shang XiaoJing1-1/+3
[ Upstream commit 2d899592ed7829d0d5140853bac4d58742a6b8af ] There is a kmemleak when testing the media/i2c/ov2740.c with bpf mock device: unreferenced object 0xffff8881090e19e0 (size 16): comm "51-i2c-ov2740", pid 278, jiffies 4294781584 (age 23.613s) hex dump (first 16 bytes): 00 f3 7c 0b 81 88 ff ff 80 75 6a 09 81 88 ff ff ..|......uj..... backtrace: [<000000004e9fad8f>] __kmalloc_node+0x44/0x1b0 [<0000000039c802f4>] kvmalloc_node+0x34/0x180 [<000000009b8b5c63>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<0000000038644056>] ov2740_probe+0x37d/0x84f [ov2740] [<0000000092489f59>] i2c_device_probe+0x28d/0x680 [<000000001038babe>] really_probe+0x17c/0x3f0 [<0000000098c7af1c>] __driver_probe_device+0xe3/0x170 [<00000000e1b3dc24>] device_driver_attach+0x34/0x80 [<000000005a04a34d>] bind_store+0x10b/0x1a0 [<00000000ce25d4f2>] drv_attr_store+0x49/0x70 [<000000007d9f4e9a>] sysfs_kf_write+0x8c/0xb0 [<00000000be6cff0f>] kernfs_fop_write_iter+0x216/0x2e0 [<0000000031ddb40a>] vfs_write+0x658/0x810 [<0000000041beecdd>] ksys_write+0xd6/0x1b0 [<0000000023755840>] do_syscall_64+0x38/0x90 [<00000000b2cc2da2>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ov2740_init_controls() won't clean all the allocated resources in fail path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to prevent memleak. Fixes: 866edc895171 ("media: i2c: Add ov2740 image sensor driver") Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11media: max9286: Fix memleak in max9286_v4l2_register()Shang XiaoJing1-0/+1
[ Upstream commit 8636c5fc7658c7c6299fb8b352d24ea4b9ba99e2 ] There is a kmemleak when testing the media/i2c/max9286.c with bpf mock device: kmemleak: 5 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0xffff88810defc400 (size 256): comm "python3", pid 278, jiffies 4294737563 (age 31.978s) hex dump (first 32 bytes): 28 06 a7 0a 81 88 ff ff 00 fe 22 12 81 88 ff ff (........."..... 10 c4 ef 0d 81 88 ff ff 10 c4 ef 0d 81 88 ff ff ................ backtrace: [<00000000191de6a7>] __kmalloc_node+0x44/0x1b0 [<000000002f4912b7>] kvmalloc_node+0x34/0x180 [<0000000057dc4cae>] v4l2_ctrl_new+0x325/0x10f0 [videodev] [<0000000026030272>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000f0d9ea2f>] max9286_probe+0x76e/0xbff [max9286] [<00000000ea8f6455>] i2c_device_probe+0x28d/0x680 [<0000000087529af3>] really_probe+0x17c/0x3f0 [<00000000b08be526>] __driver_probe_device+0xe3/0x170 [<000000004382edea>] driver_probe_device+0x49/0x120 [<000000007bde528a>] __device_attach_driver+0xf7/0x150 [<000000009f9c6ab4>] bus_for_each_drv+0x114/0x180 [<00000000c8aaf588>] __device_attach+0x1e5/0x2d0 [<0000000041cc06b9>] bus_probe_device+0x126/0x140 [<000000002309860d>] device_add+0x810/0x1130 [<000000002827bf98>] i2c_new_client_device+0x359/0x4f0 [<00000000593bdc85>] of_i2c_register_device+0xf1/0x110 max9286_v4l2_register() calls v4l2_ctrl_new_std(), but won't free the created v412_ctrl when fwnode_graph_get_endpoint_by_id() failed, which causes the memleak. Call v4l2_ctrl_handler_free() to free the v412_ctrl. Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-01-14media: i2c: ad5820: Fix error pathRicardo Ribalda1-5/+5
[ Upstream commit 9fce241660f37d9e95e93c0ae6fba8cfefa5797b ] Error path seems to be swaped. Fix the order and provide some meaningful names. Fixes: bee3d5115611 ("[media] ad5820: Add driver for auto-focus coil") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-06-09media: ov7670: remove ov7670_power_off from ov7670_removeDongliang Mu1-1/+0
[ Upstream commit 5bf19572e31375368f19edd2dbb2e0789518bb99 ] In ov7670_probe, it always invokes ov7670_power_off() no matter the execution is successful or failed. So we cannot invoke it agiain in ov7670_remove(). Fix this by removing ov7670_power_off from ov7670_remove. Fixes: 030f9f682e66 ("media: ov7670: control clock along with power") Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08media: video/hdmi: handle short reads of hdmi info frame.Tom Rix3-3/+3
[ Upstream commit 4a92fc6e55da5b87cecb572275deaff6ac9dd27e ] Calling hdmi_infoframe_unpack() with static sizeof(buffer) skips all the size checking done later in hdmi_infoframe_unpack(). A better value is the amount of data read into buffer. Fixes: 480b8b3e42c3 ("video/hdmi: Pass buffer size to infoframe unpack functions") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18media: TDA1997x: handle short reads of hdmi info frame.Tom Rix1-4/+4
[ Upstream commit 48d219f9cc667bc6fbc3e3af0b1bfd75db94fce4 ] Static analysis reports this representative problem tda1997x.c:1939: warning: 7th function call argument is an uninitialized value The 7th argument is buffer[0], which is set in the earlier call to io_readn(). When io_readn() call to io_read() fails with the first read, buffer[0] is not set and 0 is returned and stored in len. The later call to hdmi_infoframe_unpack()'s size parameter is the static size of buffer, always 40, so a short read is not caught in hdmi_infoframe_unpacks()'s checking. The variable len should be used instead. Zero initialize buffer to 0 so it is in a known start state. Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver") Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18media: mt9p031: Fix corrupted frame after restarting streamDirk Bender1-1/+27
[ Upstream commit 0961ba6dd211a4a52d1dd4c2d59be60ac2dc08c7 ] To prevent corrupted frames after starting and stopping the sensor its datasheet specifies a specific pause sequence to follow: Stopping: Set Pause_Restart Bit -> Set Restart Bit -> Set Chip_Enable Off Restarting: Set Chip_Enable On -> Clear Pause_Restart Bit The Restart Bit is cleared automatically and must not be cleared manually as this would cause undefined behavior. Signed-off-by: Dirk Bender <d.bender@phytec.de> Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18media: ir-kbd-i2c: improve responsiveness of hauppauge zilog receiversSean Young1-0/+1
commit c73ba202a851c0b611ef2c25e568fadeff5e667f upstream. 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: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18media: TDA1997x: fix tda1997x_query_dv_timings() return valueKrzysztof Hałasa1-2/+3
[ Upstream commit 7dee1030871a48d4f3c5a74227a4b4188463479a ] Correctly propagate the tda1997x_detect_std error value. Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18media: imx258: Limit the max analogue gain to 480Umang Jain1-1/+1
[ Upstream commit f809665ee75fff3f4ea8907f406a66d380aeb184 ] The range for analog gain mentioned in the datasheet is [0, 480]. The real gain formula mentioned in the datasheet is: Gain = 512 / (512 – X) Hence, values larger than 511 clearly makes no sense. The gain register field is also documented to be of 9-bits in the datasheet. Certainly, it is enough to infer that, the kernel driver currently advertises an arbitrary analog gain max. Fix it by rectifying the value as per the data sheet i.e. 480. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18media: imx258: Rectify mismatch of VTS valueLaurent Pinchart1-1/+1
[ Upstream commit 51f93add3669f1b1f540de1cf397815afbd4c756 ] The frame_length_lines (0x0340) registers are hard-coded as follows: - 4208x3118 frame_length_lines = 0x0c50 - 2104x1560 frame_length_lines = 0x0638 - 1048x780 frame_length_lines = 0x034c The driver exposes the V4L2_CID_VBLANK control in read-only mode and sets its value to vts_def - height, where vts_def is a mode-dependent value coming from the supported_modes array. It is set using one of the following macros defined in the driver: #define IMX258_VTS_30FPS 0x0c98 #define IMX258_VTS_30FPS_2K 0x0638 #define IMX258_VTS_30FPS_VGA 0x034c There's a clear mismatch in the value for the full resolution mode i.e. IMX258_VTS_30FPS. Fix it by rectifying the macro with the value set for the frame_length_lines register as stated above. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-15media: TDA1997x: enable EDID supportKrzysztof Hałasa1-0/+1
[ Upstream commit ea3e1c36e38810427485f06c2becc1f29e54521d ] Without this patch, the TDA19971 chip's EDID is inactive. EDID never worked with this driver, it was all tested with HDMI signal sources which don't need EDID support. Signed-off-by: Krzysztof Halasa <khalasa@piap.pl> Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver") Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19media: subdev: disallow ioctl for saa6588/davinciArnd Bergmann1-2/+2
commit 0a7790be182d32b9b332a37cb4206e24fe94b728 upstream. The saa6588_ioctl() function expects to get called from other kernel functions with a 'saa6588_command' pointer, but I found nothing stops it from getting called from user space instead, which seems rather dangerous. The same thing happens in the davinci vpbe driver with its VENC_GET_FLD command. As a quick fix, add a separate .command() callback pointer for this driver and change the two callers over to that. This change can easily get backported to stable kernels if necessary, but since there are only two drivers, we may want to eventually replace this with a set of more specialized callbacks in the long run. Fixes: c3fda7f835b0 ("V4L/DVB (10537): saa6588: convert to v4l2_subdev.") Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-14media: tc358743: Fix error return code in tc358743_probe_of()Zhen Lei1-0/+1
[ Upstream commit a6b1e7093f0a099571fc8836ab4a589633f956a8 ] When the CSI bps per lane is not in the valid range, an appropriate error code -EINVAL should be returned. However, we currently do not explicitly assign this error code to 'ret'. As a result, 0 was incorrectly returned. Fixes: 256148246852 ("[media] tc358743: support probe from device tree") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14media: rc: i2c: Fix an error messageChristophe JAILLET1-2/+2
[ Upstream commit 9c87ae1a0dbeb5794957421157fd266d38a869b4 ] 'ret' is known to be 1 here. In fact 'i' is expected instead. Store the return value of 'i2c_master_recv()' in 'ret' so that the error message print the correct error code. Fixes: acaa34bf06e9 ("media: rc: implement zilog transmitter") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14media: I2C: change 'RST' to "RSET" to fix multiple build errorsRandy Dunlap5-17/+17
[ Upstream commit 8edcb5049ac29aa3c8acc5ef15dd4036543d747e ] The use of an enum named 'RST' conflicts with a #define macro named 'RST' in arch/mips/include/asm/mach-rc32434/rb.h. The MIPS use of RST was there first (AFAICT), so change the media/i2c/ uses of RST to be named 'RSET'. 'git grep -w RSET' does not report any naming conflicts with the new name. This fixes multiple build errors: arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ drivers/media/i2c/s5c73m3/s5c73m3.h:356:2: note: in expansion of macro 'RST' 356 | RST, | ^~~ ../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ ../drivers/media/i2c/s5k6aa.c:180:2: note: in expansion of macro 'RST' 180 | RST, | ^~~ ../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ ../drivers/media/i2c/s5k5baf.c:238:2: note: in expansion of macro 'RST' 238 | RST, | ^~~ and some others that I have trimmed. Fixes: cac47f1822fc ("[media] V4L: Add S5C73M3 camera driver") Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor") Fixes: 7d459937dc09 ("[media] Add driver for Samsung S5K5BAF camera sensor") Fixes: bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX sensor") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Sangwook Lee <sangwook.lee@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14media: i2c: ov2659: Use clk_{prepare_enable,disable_unprepare}() to set ↵Dillon Min1-6/+18
xvclk on/off [ Upstream commit 24786ccd9c80fdb05494aa4d90fcb8f34295c193 ] On some platform(imx6q), xvclk might not switch on in advance, also for power save purpose, xvclk should not be always on. so, add clk_prepare_enable(), clk_disable_unprepare() in driver side to set xvclk on/off at proper stage. Add following changes: - add 'struct clk *clk;' in 'struct ov2659 {}' - enable xvclk in ov2659_power_on() - disable xvclk in ov2659_power_off() Signed-off-by: Dillon Min <dillon.minfei@gmail.com> Acked-by: Lad Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14media: i2c: imx219: Balance runtime PM use-countLad Prabhakar1-15/+17
[ Upstream commit dd90caa0111e178b52b21e56364bc2244a3973b3 ] Move incrementing/decrementing runtime PM count to imx219_start_streaming()/imx219_stop_streaming() functions respectively. This fixes an issue of unbalanced runtime PM count in resume callback error path where streaming is stopped and runtime PM count is left unbalanced. Fixes: 1283b3b8f82b9 ("media: i2c: Add driver for Sony IMX219 sensor") Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14media: i2c: imx219: Move out locking/unlocking of vflip and hflip controls ↵Lad Prabhakar1-6/+13
from imx219_set_stream [ Upstream commit 745d4612d2c853c00abadbf69799c8aee7f99c39 ] Move out locking/unlocking of vflip and hflip controls from imx219_set_stream() to the imx219_start_streaming()/ imx219_stop_streaming() respectively. This fixes an issue in resume callback error path where streaming is stopped and the controls are left in locked state. Fixes: 1283b3b8f82b9 ("media: i2c: Add driver for Sony IMX219 sensor") Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11media: i2c: adv7842: fix possible use-after-free in adv7842_remove()Yang Yingliang1-1/+1
[ Upstream commit 4a15275b6a18597079f18241c87511406575179a ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11media: i2c: tda1997: Fix possible use-after-free in tda1997x_remove()Yang Yingliang1-1/+1
[ Upstream commit 7f820ab5d4eebfe2d970d32a76ae496a6c286f0f ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11media: i2c: adv7511-v4l2: fix possible use-after-free in adv7511_remove()Yang Yingliang1-1/+1
[ Upstream commit 2c9541720c66899adf6f3600984cf3ef151295ad ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11media: adv7604: fix possible use-after-free in adv76xx_remove()Yang Yingliang1-1/+1
[ Upstream commit fa56f5f1fe31c2050675fa63b84963ebd504a5b3 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11media: tc358743: fix possible use-after-free in tc358743_remove()Yang Yingliang1-1/+1
[ Upstream commit 6107a4fdf8554a7aa9488bdc835bb010062fa8a9 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04media: i2c: max9286: fix access to unallocated memoryTomi Valkeinen1-1/+1
commit e88ccf09e79cf33cac40316ba69c820d9eebc82b upstream. The asd allocated with v4l2_async_notifier_add_fwnode_subdev() must be of size max9286_asd, otherwise access to max9286_asd->source will go to unallocated memory. Fixes: 86d37bf31af6 ("media: i2c: max9286: Allocate v4l2_async_subdev dynamically") Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Cc: stable@vger.kernel.org # v5.10+ Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04media: i2c: ov5670: Fix PIXEL_RATE minimum valueJacopo Mondi1-1/+2
[ Upstream commit dc1eb7c9c290cba52937c9a224b22a400bb0ffd7 ] The driver currently reports a single supported value for V4L2_CID_PIXEL_RATE and initializes the control's minimum value to 0, which is very risky, as userspace might accidentally use it as divider when calculating the time duration of a line. Fix this by using as minimum the only supported value when registering the control. Fixes: 5de35c9b8dcd1 ("media: i2c: Add Omnivision OV5670 5M sensor support") Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30media: tvp5150: Fix wrong return value of tvp5150_parse_dt()Zhang Xiaoxu1-0/+1
[ Upstream commit eb08c48132a1f594478ab9fa2b6ee646c3513a49 ] If of_graph_get_endpoint_by_regs() return NULL, it will return 0 rather than an errno, because we doesn't initialize the return value. Fixes: 0556f1d580d4 ("media: tvp5150: add input source selection of_graph support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30media: i2c: imx219: Selection compliance fixesHans Verkuil1-8/+9
[ Upstream commit 1ed36ecd1459b653cced8929bfb37dba94b64c5d ] To comply with the intended usage of the V4L2 selection target when used to retrieve a sensor image properties, adjust the rectangles returned by the imx219 driver. The top/left crop coordinates of the TGT_CROP rectangle were set to (0, 0) instead of (8, 8) which is the offset from the larger physical pixel array rectangle. This was also a mismatch with the default values crop rectangle value, so this is corrected. Found with v4l2-compliance. While at it, add V4L2_SEL_TGT_CROP_BOUNDS support: CROP_DEFAULT and CROP_BOUNDS have the same size as the non-active pixels are not readable using the selection API. Found with v4l2-compliance. [reword commit message, use macros for pixel offsets] Fixes: e6d4ef7d58aa7 ("media: i2c: imx219: Implement get_selection") Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30media: rdacm20: Enable GPIO1 explicitlyJacopo Mondi1-2/+11
[ Upstream commit 7fe1d4453fb6bf103d668a19d957a7b2fc21887c ] The MAX9271 GPIO1 line that controls the sensor reset is by default enabled after a serializer chip reset. As rdacm20 does not go through an explicit serializer reset, make sure GPIO1 is enabled to make the camera module driver more robust. Fixes: 34009bffc1c6 ("media: i2c: Add RDACM20 driver") Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30media: max9271: Fix GPIO enable/disableJacopo Mondi1-4/+4
[ Upstream commit 909a0a189c677307edd461e21fd962784370d27f ] Fix GPIO enable/disable operations which wrongly read the 0x0f register to obtain the current mask of the enabled lines instead of using the correct 0x0e register. Also fix access to bit 0 of the register which is marked as reserved. Fixes: 34009bffc1c6 ("media: i2c: Add RDACM20 driver") Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>