Tell ACPI device PM code that the driver supports the device being in
non-zero ACPI D state when the driver's probe function is entered.
Also do identification on the first access of the device, whether in probe
or when starting streaming.
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Kao, Arec <arec.kao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Tell ACPI device PM code that the driver supports the device being in
non-zero ACPI D state when the driver's probe function is entered.
Also do identification on the first access of the device, whether in probe
or when starting streaming.
Signed-off-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>
Tell ACPI device PM code that the driver supports the device being in
non-zero ACPI D state when the driver's probe function is entered.
Also do identification on the first access of the device, whether in probe
or when starting streaming.
Signed-off-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>
Tell ACPI device PM code that the driver supports the device being in
non-zero ACPI D state when the driver's probe function is entered.
Also do identification on the first access of the device, whether in probe
or when starting streaming.
Signed-off-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>
Tell ACPI device PM code that the driver supports the device being in
non-zero ACPI D state when the driver's probe function is entered.
Also do identification on the first access of the device, whether in probe
or when starting streaming.
Signed-off-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>
Tell ACPI device PM code that the driver supports the device being in
non-zero ACPI D state when the driver's probe function is entered.
Also do identification on the first access of the device, whether in probe
or when starting streaming.
Signed-off-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>
If powering on the sensor failed, the entire power-off sequence was run
independently of how far the power-on sequence proceeded before the error.
This lead to disabling regulators and/or clock that was not enabled.
Fix this by disabling only clocks and regulators that were enabled
previously.
Fixes: 11c0d8fdcc ("media: i2c: Add support for the OV8865 image sensor")
Cc: stable@vger.kernel.org
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
While parsing the RAW AWB metadata, the AWB layout was missing to fully
understand which byte corresponds to which feature. Make the field names
and usage explicit, as it is used by the userspace applications.
[Sakari Ailus: Changed wording of sat_ratio field as per review comments,
fixed a whitespace issue.]
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Hyungwoo's e-mail no longer works so I presume he's left the company. Drop
Hyungwoo as maintainer on ov5670 driver and remove his e-mail from other
sensor drivers.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed tag for the immutable platform-drivers-x86-int3472 branch
This branch contains 5.16-rc1 + the pending ACPI/i2c, tps68570 platform_data
and INT3472 driver patches.
* tag 'platform-drivers-x86-int3472-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86: int3472: Deal with probe ordering issues
platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell
platform/x86: int3472: Pass tps68470_clk_platform_data to the tps68470-regulator MFD-cell
platform/x86: int3472: Add get_sensor_adev_and_name() helper
platform/x86: int3472: Split into 2 drivers
platform_data: Add linux/platform_data/tps68470.h file
i2c: acpi: Add i2c_acpi_new_device_by_fwnode() function
i2c: acpi: Use acpi_dev_ready_for_enumeration() helper
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
This device also supports ATV, as it has the same API for
setting analog TV tuning parameters.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Some tuners allow setting the bandwidth filter to 1.7MHz and
6.1 MHz. Add support for it upstream, as the narrower is the
bandwidth filter, the better.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those two delivery systems are supported by some of the si2146
tuners, but the current code is missing the setup for those.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The driver should be capable of autodetecting its type, so no
need to pass it via device driver's data.
While here, improve documentation of some of the part_id
specific code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Each chip at the si21xx TER family seems to have a different firmware,
with seems to actually be a patch against the ROM code.
Rework the code in order to use different firmware files depending
on the chip ID and rom ID.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Loading a firmware file should not be mandatory, as devices
could work with an eeprom firmware, if available.
Yet, using the eeprom firmware could lead into unpredictable
results, so the best is to warn about that.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The Si2157 (A30) is functional with the ROM firmware 3.0.5, but can also
be patched at runtime, e.g. to firmware 3.1.3. However, although a
firmware filename for its firmware patch exists, that has only been used
for the Si2177 (A30) so far (which indeed takes the binary identical
firmware patch).
Add support for downloading firmware patches into the Si2157 (A30), but
make it optional, so that initialization can succeed with and without a
firmware patch being available. Keep the use of request_firmware() for
this purpose rather than firmware_request_nowarn(), so that the warning
in the log makes users aware that it is possible to provide a firmware
for this tuner.
The firmware patch is probably also optional for other (if not all)
tuners supported by the driver, but since I do not have the others
available to test, they are kept mandatory for now to avoid regressions.
Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Split the firmware load code from si2157_init, in order to
help to add further changes at the way firmware is handled on
this device.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As the first thing this function does is to call
v4l2_device_register(), it should call v4l2_device_unregister()
if an error occurs, the same way as done at saa7146_vv_release().
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In hexium_attach(dev, info), saa7146_vv_init() is called to allocate
a new memory for dev->vv_data. saa7146_vv_release() will be called on
failure of saa7146_register_device(). There is a dereference of
dev->vv_data in saa7146_vv_release(), which could lead to a NULL
pointer dereference on failure of saa7146_vv_init().
Fix this bug by adding a check of saa7146_vv_init().
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_VIDEO_HEXIUM_GEMINI=m show no new warnings,
and our static analyzer no longer warns about this code.
Link: https://lore.kernel.org/linux-media/20211203154030.111210-1-zhou1615@umn.edu
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
I got a null-ptr-deref report:
BUG: kernel NULL pointer dereference, address: 0000000000000060
...
RIP: 0010:v4l2_ctrl_auto_cluster+0x57/0x270
...
Call Trace:
msi001_probe+0x13b/0x24b [msi001]
spi_probe+0xeb/0x130
...
do_syscall_64+0x35/0xb0
In msi001_probe(), if the creation of control for bandwidth_auto
fails, there will be a null-ptr-deref issue when it is used in
v4l2_ctrl_auto_cluster().
Check dev->hdl.error before v4l2_ctrl_auto_cluster() to fix this bug.
Link: https://lore.kernel.org/linux-media/20211026112348.2878040-1-wanghai38@huawei.com
Fixes: 93203dd6c7 ("[media] msi001: Mirics MSi001 silicon tuner driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
dvb_usb_device_init stores parts of properties at d->props
and d->desc and uses it on dvb_usb_device_exit.
Free of properties on module probe leads to use after free.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204597
The patch makes properties static instead of allocated on heap to prevent
memleak and use after free.
Also fixes s421_properties.devices initialization to have 2 element
instead of 6 copied from p7500_properties.
[mchehab: fix function call alignments]
Link: https://lore.kernel.org/linux-media/20190822104147.4420-1-vasilyev@ispras.ru
Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
Fixes: 299c7007e9 ("media: dw2102: Fix memleak on sequence of probes")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The lirc core already introduces gaps, so there is no need for this in
the driver.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
These struct members do not serve any purpose.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Remove superfluous messages which add no information.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The usb pid/vid can be found elsewhere, the idVendor/idProduct usb sysfs
files for example.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There is no reason to have a reset after an IR timeout.
Calling ir_raw_event_handle() twice for the same interrupt has no
affect.
Fixes: 56b0ec30c4 ("[media] rc/streamzap: fix reporting response times")
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Without this, some IR will be missing mid-stream and we might decode
something which never really occurred.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
An IR reset is only used when the IR hardware reports an error.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
An IR reset is only used when the IR hardware reports an error.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Without timeout reports, it is impossible to decode many protocols since
it is not known when the transmission ends. timeout reports are sent by
default, but can be turned off. There is no reason to turn them off, and
I cannot find any software which does this, so we can safely remove it.
This makes the ioctl LIRC_SET_REC_TIMEOUT_REPORTS a no-op.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
