The Google Moxie device uses the same approach as the Google Brask
which enables the HDMI CEC via the cros-ec-cec driver.
Signed-off-by: Ken Lin <kenlin5@quanta.corp-partner.google.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Convert to use devm_kmemdup_array() and while at it, make the size robust
against type changes.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Convert to use devm_kmemdup_array() and while at it, make the size robust
against type changes.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Enumerate only the available (as given by the input source) timings, not
all theoretically possible.
Signed-off-by: Martin Tůma <martin.tuma@digiteqautomotive.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
To restrict the returned resolution due to Nuvoton SoC hardware
limitations.
Signed-off-by: Michael Chang <zhang971090220@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Fix the issue when start_frame and detect_resolution
functions are executed at the same time, which may cause driver
stops capturing due to status of no video signal error.
Signed-off-by: Michael Chang <zhang971090220@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The Google Dirks device uses the same approach as the Google Brask
which enables the HDMI CEC via the cros-ec-cec driver.
Signed-off-by: Kells Ping <kellsping@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Always generate the resolution change event when the HW reports it and only
discard the streaming termination in case the new resolution is the same as
the old one. The old logic prevented events on
"no signal" -> "valid resolution" transitions as VIDIOC_QUERY_DV_TIMINGS
never updates the timings when there is no signal present.
Signed-off-by: Martin Tůma <martin.tuma@digiteqautomotive.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
syzbot reported a uninit-value in cxusb_i2c_xfer. [1]
Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()
succeeds and rlen is greater than 0, the read operation of usb_bulk_msg()
will be executed to read rlen bytes of data from the dvb device into the
rbuf.
In this case, although rlen is 1, the write operation failed which resulted
in the dvb read operation not being executed, and ultimately variable i was
not initialized.
[1]
BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]
BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196
cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]
cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196
__i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1
i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315
i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343
i2c_master_send include/linux/i2c.h:109 [inline]
i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183
do_loop_readv_writev fs/read_write.c:848 [inline]
vfs_writev+0x963/0x14e0 fs/read_write.c:1057
do_writev+0x247/0x5c0 fs/read_write.c:1101
__do_sys_writev fs/read_write.c:1169 [inline]
__se_sys_writev fs/read_write.c:1166 [inline]
__x64_sys_writev+0x98/0xe0 fs/read_write.c:1166
x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Reported-by: syzbot+526bd95c0ec629993bf3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=526bd95c0ec629993bf3
Tested-by: syzbot+526bd95c0ec629993bf3@syzkaller.appspotmail.com
Fixes: 22c6d93a73 ("[PATCH] dvb: usb: support Medion hybrid USB2.0 DVB-T/analogue box")
Cc: stable@vger.kernel.org
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
pcim_iomap_table() and pcim_iomap_regions() have been deprecated.
pcim_iomap_regions(), furthermore, has so far wrongly been passed the
device's name instead of the driver's name, which makes that function's
debug prints useless.
Replace the deprecated function with pcim_iomap_region().
Define the driver name globally and use it where appropriate.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
pcim_iomap_table() and pcim_iomap_regions() have been deprecated.
Replace them with pcim_iomap_region().
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
pcim_iomap_table() and pcim_iomap_regions() have been deprecated.
Replace them with pcim_iomap_region().
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Tested-by: Akihiro Tsukada <tskd08@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Fix gcc8 warning:
drivers/media/cec/usb/extron-da-hd-4k-plus/extron-da-hd-4k-plus.c:1014:44: warning: 'DCEC' directive output may be truncated writing 4 bytes into a region of size between 0 and 53 [-Wformat-truncation=]
Resizing the 'buf' and 'cmd' arrays fixed the warning.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Gcc8 is convinced that we do not have enough space in dot_id_input_bin.
Extend the variable 17 bytes which is just used for debugging.
drivers/staging/media/atomisp/pci/runtime/debug/src/ia_css_debug.c:1336:9: warning: '(pipe' directive output may be truncated writing 5 bytes into a region of size between 1 and 74 [-Wformat-truncation=]
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
There is nothing a driver author can do fix in the driver to make the
global constants match. Since the assertion can be verified at build
time, don't return EINVAL at runtime for it.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Add 3 more common resolution for webcams. This is required to increase
the test coverage of unit tests based on vivid.
Co-developed-by: Hidenori Kobayashi <hidenorik@chromium.org>
Signed-off-by: Hidenori Kobayashi <hidenorik@chromium.org>
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Tested-by: Hidenori Kobayashi <hidenorik@chromium.org> # v4l2-compliance,
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Since commit f0b4a2c037 ("media: vivid: Extend FPS rates offered by
simulated webcam") we do not require twice as many intervals as sizes. In
fact, now we have 13 intervals and 6 sizes.
Fix the comment.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Add some basic info about the HW/driver + contact info.
Signed-off-by: Martin Tůma <martin.tuma@digiteqautomotive.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
pvr2_std_create_enum() has been unused since 2012's
commit c0bb609fdc ("[media] pvrusb2: Get rid of obsolete code for video
standard enumeration")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
When output encoded buffer size provided by userspace
is insufficient with current encoding parameters, it
leads to RET_ENC_BUFFER_FULL interrupt which was not
handled in IRQ handler.
On handling of RET_ENC_BUFFER_FULL interrupt leads to
NAL_ABORT command from host to risc which in turn leads
to RET_NAL_ABORT interrupt. On receiving RET_NAL_ABORT
driver clears workbit and VB2 queues for cleaner closing
of MFC instance.
When user encounters "Call on DQBUF after unrecoverable
error", userspace should close fd and restart with larger
output encoder buffer size.
Signed-off-by: Aakarsh Jain <aakarsh.jain@samsung.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Add support for the mulitiplaner API. The device can now act as
either a multi-planar or a single-planar device depending on a module
parameter, similar to the way vivid behaves.
Multiplanar support was added by implementing the appropate
try/get/set mplane functions, and by modifying the queue_setup() and
buf_prepare() functions to handle multiple planes. Implementation
was inspired by vivid.
Signed-off-by: Matthew Majewski <mattwmajewski@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Clean up vidioc_try_fmt with the following changes:
1. remove unsused vim2m_fmt parameter
2. use clamp() macro to restrain width/height bounds
3. use ALIGN() macro to align width/height
4. use v4l2_fill_pixfmt to set bytesperline/sizeimage
Signed-off-by: Matthew Majewski <mattwmajewski@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Add missing RGBR entry in the v4l2_format_info[] table.
RGBR has identical format information to RGBP, as it is a
big endian variant of RGB-5-6-5 pixel encoding according to the
description in videodev2.h.
Signed-off-by: Matthew Majewski <mattwmajewski@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
With commit dcbb01fbb7 ("x86/pci: Remove old STA2x11 support"), the
STA2X11 Video Input Port driver is not needed and cannot be built anymore.
Remove the driver and its reference in media documentation.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The current is_x86_event has to go through the hybrid_pmus list to find
the matched pmu, then check if it's a X86 PMU and a X86 event. It's not
necessary.
The X86 PMU has a unique type ID on a non-hybrid machine, and a unique
capability type. They are good enough to do the check.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20250424134718.311934-5-kan.liang@linux.intel.com
According to the throttling mechanism, the pmu interrupts number can not
exceed the max_samples_per_tick in one tick. But this mechanism is
ineffective when max_samples_per_tick=1, because the throttling check is
skipped during the first interrupt and only performed when the second
interrupt arrives.
Perhaps this bug may cause little influence in one tick, but if in a
larger time scale, the problem can not be underestimated.
When max_samples_per_tick = 1:
Allowed-interrupts-per-second max-samples-per-second default-HZ ARCH
200 100 100 X86
500 250 250 ARM64
...
Obviously, the pmu interrupt number far exceed the user's expect.
Fixes: e050e3f0a7 ("perf: Fix broken interrupt rate throttling")
Signed-off-by: Qing Wang <wangqing7171@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20250405141635.243786-3-wangqing7171@gmail.com
The counter backwards may be observed in the PMI handler when
counters-snapshotting some non-precise events in the freq mode.
For the non-precise events, it's possible the counters-snapshotting
records a positive value for an overflowed PEBS event. Then the HW
auto-reload mechanism reset the counter to 0 immediately. Because the
pebs_event_reset is cleared in the freq mode, which doesn't set the
PERF_X86_EVENT_AUTO_RELOAD.
In the PMI handler, 0 will be read rather than the positive value
recorded in the counters-snapshotting record.
The counters-snapshotting case has to be specially handled. Since the
event value has been updated when processing the counters-snapshotting
record, only needs to set the new period for the counter via
x86_pmu_set_period().
Fixes: e02e9b0374 ("perf/x86/intel: Support PEBS counters snapshotting")
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20250424134718.311934-6-kan.liang@linux.intel.com
The PEBS counters snapshotting group also requires a group flag in the
leader. The leader must be a X86 event.
Fixes: e02e9b0374 ("perf/x86/intel: Support PEBS counters snapshotting")
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20250424134718.311934-3-kan.liang@linux.intel.com
A warning in intel_pmu_lbr_counters_reorder() may be triggered by below
perf command.
perf record -e "{cpu-clock,cycles/call-graph="lbr"/}" -- sleep 1
It's because the group is mistakenly treated as a branch counter group.
The hw.flags of the leader are used to determine whether a group is a
branch counters group. However, the hw.flags is only available for a
hardware event. The field to store the flags is a union type. For a
software event, it's a hrtimer. The corresponding bit may be set if the
leader is a software event.
For a branch counter group and other groups that have a group flag
(e.g., topdown, PEBS counters snapshotting, and ACR), the leader must
be a X86 event. Check the X86 event before checking the flag.
The patch only fixes the issue for the branch counter group.
The following patch will fix the other groups.
There may be an alternative way to fix the issue by moving the hw.flags
out of the union type. It should work for now. But it's still possible
that the flags will be used by other types of events later. As long as
that type of event is used as a leader, a similar issue will be
triggered. So the alternative way is dropped.
Fixes: 3374491619 ("perf/x86/intel: Support branch counters logging")
Closes: https://lore.kernel.org/lkml/20250412091423.1839809-1-luogengkun@huaweicloud.com/
Reported-by: Luo Gengkun <luogengkun@huaweicloud.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20250424134718.311934-2-kan.liang@linux.intel.com
Update chip data using dev_get_drvdata(dev->parent) to fix
NULL pointer deref in acp_i2s_set_tdm_slot.
Fixes: cd60dec899 ("ASoC: amd: acp: Refactor TDM slots selction based on acp revision id")
Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Link: https://patch.msgid.link/20250425060144.1773265-2-venkataprasad.potturu@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
imx_card_parse_of() allocs 2 components for CPU/Platform (A)
static int imx_card_parse_of(...)
{
...
for_each_child_of_node(...) {
dlc = devm_kzalloc(...);
...
link->cpus = &dlc[0];
(A) link->platforms = &dlc[1];
}
...
}
The link might be used as DPCM backend, in such case, link->plaforms
will be not used. The driver overwrite it as Dummy DAI (B).
} else if (!strncmp(link->name, "HiFi-ASRC-BE", 12)) {
/* DPCM backend */
link->no_pcm = 1;
link->platforms->of_node = NULL;
(B) link->platforms->name = "snd-soc-dummy";
}
If it was not used for generic DMAEngine, we can just remove it.
By this patch, created dlc (A) will be just wasted, but it won't leak.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87cydfr1z6.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For some SPI flash memory operations, dummy bytes are not mandatory. For
example, in Winbond SPINAND flash memory devices, the `write_cache` and
`update_cache` operation variants have zero dummy bytes. Calculating the
duration for SPI memory operations with zero dummy bytes causes
a divide error when `ncycles` is calculated in the
spi_mem_calc_op_duration().
Add changes to skip the 'ncylcles' calculation for zero dummy bytes.
Following divide error is fixed by this change:
Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI
...
? do_trap+0xdb/0x100
? do_error_trap+0x75/0xb0
? spi_mem_calc_op_duration+0x56/0xb0
? exc_divide_error+0x3b/0x70
? spi_mem_calc_op_duration+0x56/0xb0
? asm_exc_divide_error+0x1b/0x20
? spi_mem_calc_op_duration+0x56/0xb0
? spinand_select_op_variant+0xee/0x190 [spinand]
spinand_match_and_init+0x13e/0x1a0 [spinand]
spinand_manufacturer_match+0x6e/0xa0 [spinand]
spinand_probe+0x357/0x7f0 [spinand]
? kernfs_activate+0x87/0xd0
spi_mem_probe+0x7a/0xb0
spi_probe+0x7d/0x130
Fixes: 226d6cb3cb ("spi: spi-mem: Estimate the time taken by operations")
Suggested-by: Krishnamoorthi M <krishnamoorthi.m@amd.com>
Co-developed-by: Akshata MukundShetty <akshata.mukundshetty@amd.com>
Signed-off-by: Akshata MukundShetty <akshata.mukundshetty@amd.com>
Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
Link: https://patch.msgid.link/20250424121333.417372-1-Raju.Rangoju@amd.com
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Microsemi Ocelot/Jaguar2, Renesas RZ/N1 and T-HEAD TH1520
SoC-specific compatibles, which eventually fallback to the
generic DW ssi compatible, it's better to combine them in single entry
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Zixian Zeng <sycamoremoon376@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250425-sfg-spi-v6-1-2dbe7bb46013@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Building DTB overlays from .dts files is no longer supported.
Update the documentation to reflect this.
Fixes: 81d362732b ("kbuild: Disallow DTB overlays to built from .dts named source files")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Andrew Davis <afd@ti.com>
Reviewed-by: Yanteng Si <siyanteng@loongson.cn>
Link: https://lore.kernel.org/r/ebce4d9591dd0259a636196dda31d40901dc04b0.1738752288.git.geert+renesas@glider.be
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Since commit 8700a7ea55 (serial: 8250_omap: Drop
pm_runtime_irq_safe()), all the serial8250_rpm_*() functions are used
solely in 8250_port.
Unexport them.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20250425111315.1036184-7-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uart_get_icount() and uart_carrier_raised() open code
uart_port_ref_lock(). Use the helper instead.
The difference is we use _irqsave() variants of a spinlock now. But
that's "safer" than _irq().
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20250425111315.1036184-6-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uart_port_lock() and uart_port_unlock() are (at the same time) defined
as:
* functions in include/linux/serial_core.h
* macros in drivers/tty/serial/serial_core.c
The former are sane uart port lock wrappers.
The latter _lock() does something completely different: it inspects
a uart_state, obtains a uart_port from it, and increases its reference
count. And if that all succeeded, the port is locked too.
Similarly, the _unlock() counterpart first unlocks and then decrements
the refcount too.
This state is REALLY CONFUSING.
So rename the latter (local .c macros):
* uart_port_lock() -> uart_port_ref_lock(), and
* uart_port_unlock() -> uart_port_unlock_deref().
Now, the forbidden while-at-it part: convert from a macro to an inline
-- do it here as the passed 'flags' have to be pointer to ulong now. So
we avoid doubled changes on identical LOCs.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20250425111315.1036184-5-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The inline-defined constants look weird. Instead, define a proper enum
for them and type uart_port::iotype as that enum. This allows for proper
checking in switch-case labels (somewhere, a default or UPIO_UNKNOWN
label needs to be added/handled).
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20250425111315.1036184-4-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
guard()s and scoped_guard()s express more clearly what is protected by
locks. And also makes the code cleaner as it can return immediately in
case of short returns.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20250425111315.1036184-3-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty_throttle_safe() and tty_unthrottle_safe can be made less convoluted
using guard()s. Switch them.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20250425111315.1036184-2-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
