Debug log the chip ID after successfully identifying the chip, this is
useful to see if the identification is done on probe() time or if it is
delayed till the first stream on.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
We should put/leave the sensor in reset when requesting the GPIO, after
requesting it there are 2 possible scenarios and having the GPIO driven
low is no good in either scenario:
1. The sensor was in ACPI D0 before probe() runs, in this case
ov08x40_power_on() + ov08x40_identify_module() will run immediately
after requesting the GPIO and ov08x40_power_on() starts with driving
the GPIO high. So if the GPIO was already high it will very shortly
be driven low, more of a spike to low then actually properly be driven
low. Which may leave the sensor in a confused state.
If we request the GPIO to be high at request time then power_on() will
driver it high again (no-op) and then sleep for 1-2 ms, so no spike.
2. The sensor was in ACPI D3 / off before probe(), in this case probe()
leaves the sensor alone. But when the sensor is off its reset line
should be driven high not low.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
When the vblank v4l2 control is set, it does not get written to the
hardware unless exposure is also changed. Change the behavior such that
the vblank is written immediately when the control is set, as setting
the vblank without changing the exposure is a valid use case (such as
for changing the frame rate).
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Add #define's for the "AEC MANUAL" (0x3503) register and its
values/flags. Use those in the registers single usage within the
`common_regs` struct.
All values are based on the OV9281 datasheet v1.01 (09.18.2015).
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The imx219_get_binning() function currently returns two separate pieces
of information, the return value is the binning mode enum, and the bin_h
and bin_v references are updated with whether to perform binning in
horizontal and vertical dimensions.
It is simpler to combine both of these pieces of information, and
directly update the bin_h and bin_v references with the register value
that we will write to the sensor, which includes if the binning is
digital or analog mode, thus allowing us to remove the superfluous
binning mode enum.
This is only a style change for the driver, with no functionality
updated.
Suggested-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Link: https://lore.kernel.org/linux-media/ubuuob7mb3o5bxoumrxv4rufutgk3lvdmdery6d3bfc6rytfti@tcchhlechzzp/
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The imx283_runtime_suspend and imx283_runtime_resume functions
simply call imx283_power_off and imx283_power_on, respectively.
Since these functions do not add any additional logic, they are
unnecessary and can be removed.
Signed-off-by: Tarang Raval <tarang.raval@siliconsignals.io>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Use syscon_regmap_lookup_by_phandle_args() which is a wrapper over
syscon_regmap_lookup_by_phandle() combined with getting the syscon
argument. Except simpler code this annotates within one line that given
phandle has arguments, so grepping for code would be easier.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
It's no longer practical for the OMAP IOMMU driver to trick
arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the
same tactic as other IOMMU API users on 32-bit ARM and explicitly kick
the arch code's dma_iommu_mapping out of the way to avoid problems.
Fixes: 4720287c7b ("iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()")
Cc: stable@vger.kernel.org
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Sicelo A. Mhlongo <absicsz@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The bus_info in v4l2_capability of IPU6 isys v4l2_dev is missing.
The driver didn't set the dev_parent of v4l2_dev, its parent is set
to its parent auxdev which is neither platform nor PCI device, thus
media_set_bus_info() will not set the bus_info of v4l2_capability, then
`v4l2-ctl --all` cannot show the bus_info.
This patch fixes it by setting the dev_parent of video_device and v4l2
framework can detect the device type and set the bus_info instead.
Fixes: 3c1dfb5a69 ("media: intel/ipu6: input system video nodes and buffer queues")
Cc: stable@vger.kernel.org
Signed-off-by: Hidenori Kobayashi <hidenorik@chromium.org>
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The uvc_driver structure used to contain more fields, but those got
removed in commit ba2fa99668 ("[media] uvcvideo: Hardcode the
index/selector relationship for XU controls"). The structure is now just
a wrapper around usb_driver. Drop it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Actions UVC05 is a HDMI to USB dongle that implements the UVC protocol.
When the device suspends, its firmware seems to enter a weird mode when it
does not produce more frames.
Add the device to the quirk list to disable autosuspend.
Bus 001 Device 007: ID 1de1:f105 Actions Microelectronics Co. Display
capture-UVC05
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 [unknown]
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x1de1 Actions Microelectronics Co.
idProduct 0xf105 Display capture-UVC05
bcdDevice 4.09
iManufacturer 1 Actions Micro
iProduct 2 Display capture-UVC05
iSerial 3 -1005308387
bNumConfigurations 1
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20241210-uvc-hdmi-suspend-v1-1-01f5dec023ea@chromium.org
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
sfr->buf_size is in shared memory and can be modified by malicious user.
OOB write is possible when the size is made higher than actual sfr data
buffer. Cap the size to allocated size for such cases.
Cc: stable@vger.kernel.org
Fixes: d96d3f30c0 ("[media] media: venus: hfi: add Venus HFI files")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
qsize represents size of shared queued between driver and video
firmware. Firmware can modify this value to an invalid large value. In
such situation, empty_space will be bigger than the space actually
available. Since new_wr_idx is not checked, so the following code will
result in an OOB write.
...
qsize = qhdr->q_size
if (wr_idx >= rd_idx)
empty_space = qsize - (wr_idx - rd_idx)
....
if (new_wr_idx < qsize) {
memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while
reading and writing packets into the queue.
Cc: stable@vger.kernel.org
Fixes: d96d3f30c0 ("[media] media: venus: hfi: add Venus HFI files")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
words_count denotes the number of words in total payload, while data
points to payload of various property within it. When words_count
reaches last word, data can access memory beyond the total payload. This
can lead to OOB access. With this patch, the utility api for handling
individual properties now returns the size of data consumed. Accordingly
remaining bytes are calculated before parsing the payload, thereby
eliminates the OOB access possibilities.
Cc: stable@vger.kernel.org
Fixes: 1a73374a04 ("media: venus: hfi_parser: add common capability parser")
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
There is a possibility that init_codecs is invoked multiple times during
manipulated payload from video firmware. In such case, if codecs_count
can get incremented to value more than MAX_CODEC_NUM, there can be OOB
access. Reset the count so that it always starts from beginning.
Cc: stable@vger.kernel.org
Fixes: 1a73374a04 ("media: venus: hfi_parser: add common capability parser")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The visl driver supports both frame and slice mode, with and without a
start-code. But, the range and default for these enum controls was not
set, which currently limits the decoder to enums with a value of 0. Fix
this by setting the decoder mode and start code controls for both the
H.264 and HEVC codecs.
Fixes: 0c078e310b ("media: visl: add virtual stateless decoder driver")
Cc: stable@vger.kernel.org
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
When we obtain a reference to of a platform_device, we need to release
it via put_device.
Found by cocci:
./platform/nuvoton/npcm-video.c:1677:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
./platform/nuvoton/npcm-video.c:1684:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
./platform/nuvoton/npcm-video.c:1690:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
./platform/nuvoton/npcm-video.c:1694:1-7: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
Instead of manually calling put_device, use the __free macros.
Cc: stable@vger.kernel.org
Fixes: 46c15a4ff1 ("media: nuvoton: Add driver for NPCM video capture and encoding engine")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Make sure all the code paths call of_node_put().
Instead of manually calling of_node_put, use the __free macros/helpers.
Cc: stable@vger.kernel.org
Fixes: 46c15a4ff1 ("media: nuvoton: Add driver for NPCM video capture and encoding engine")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The register that enables selecting a test-pattern to be outputted in
free-run mode (FREE_RUN_PAT_SEL[2:0]) is only available on adv7280 based
devices, not the adv7180 based ones.
Add a flag to mark devices that are capable of generating test-patterns,
and those that are not. And only register the control on supported
devices.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The reason why this passed unnoticed is that most infotainment systems
use frequencies near enough the middle (50MHz) where both sets work.
Fixes: 0ab13674a9 ("media: pci: mgb4: Added Digiteq Automotive MGB4 driver")
Cc: stable@vger.kernel.org
Signed-off-by: Martin Tůma <martin.tuma@digiteqautomotive.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
netup_eeprom_write() was added in 2009 by
commit b45c0551f9 ("V4L/DVB (10797): Add EEPROM code for NetUP Dual
DVB-S2 CI card.")
but has remained unused.
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The variable enable is being assigned a value that is never read
afterwards. The assignment is redundant and can be removed.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
In tc358746_link_validate() an attempt is made to get the state lock of the
subdev, but since this is already held by the calling function
v4l2_subdev_link_validate(), this leads to a deadlock.
Another problem is that this function queries the link frequency of the
source device. Since some image sensors use the lock of the v4l2 control
handler as a state lock, which is already held at this point, a deadlock
can also occur here.
Move the calculation of the FIFO size from tc358746_link_validate() to
tc358746_apply_misc_config() to avoid the deadlocks mentioned.
Signed-off-by: Matthias Fend <matthias.fend@emfend.at>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
