Hamdan-Khan [Thu, 19 Mar 2026 09:35:27 +0000 (10:35 +0100)]
rust: pin-init: implement ZeroableOption for NonZero* integer types
Add a macro for implementing `ZeroableOption` for `NonZero*` types.
`Option<NonZero*>` now automatically implements `Zeroable` trait by
implementing `ZeroableOption` for `NonZero*` types, which serves as a
blanket impl.
Gary Guo [Thu, 19 Mar 2026 09:35:26 +0000 (10:35 +0100)]
rust: pin-init: doc: de-clutter documentation with fake-variadics
Currently the doc for `Zeroable` and `ZeroableOption` are filled with the
generated impl of tuples and fn pointers. Use the internal
"fake_variadics" feature to improve the rendered quality.
This makes use of an internal feature, however this is of minimal risk as
it's for documentation only, not activated during normal build, gated
behind `USE_RUSTC_FEATURES`, and can be removed at any time. This feature
is already used by serde and bevy to improve documentation quality.
For compilers that cannot use this feature, we still hide most generated
impls, and the existence of them are hinted by doc comments on the single
non-hidden impl.
Benno Lossin [Thu, 19 Mar 2026 09:35:25 +0000 (10:35 +0100)]
rust: pin-init: properly document let binding workaround
The three let bindings (in the bodies of `cast_init`, `cast_pin_init`
and the `init!` macro) are used to avoid the following compiler error in
Rust 1.78.0, 1.79.0, 1.80.0, 1.80.1, and 1.81.0 (just showing the one
for `cast_init`, the others are similar):
error[E0391]: cycle detected when computing type of opaque `cast_init::{opaque#0}`
--> src/lib.rs:1160:66
|
1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> {
| ^^^^^^^^^^^^^^^
|
note: ...which requires borrow-checking `cast_init`...
--> src/lib.rs:1160:1
|
1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...which requires const checking `cast_init`...
--> src/lib.rs:1160:1
|
1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= note: ...which requires computing whether `cast_init::{opaque#0}` is freeze...
= note: ...which requires evaluating trait selection obligation `cast_init::{opaque#0}: core::marker::Freeze`...
= note: ...which again requires computing type of opaque `cast_init::{opaque#0}`, completing the cycle
note: cycle used when computing type of `cast_init::{opaque#0}`
--> src/lib.rs:1160:66
|
1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> {
| ^^^^^^^^^^^^^^^
= note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information
Once we raise the nightly-MSRV above 1.81, we can remove this
workaround.
Gary Guo [Thu, 19 Mar 2026 09:35:24 +0000 (10:35 +0100)]
rust: pin-init: build: simplify use of nightly features
We use some features that are already stable in later versions of Rust,
but only available as unstable features in older Rust versions that the
kernel needs to support.
Instead of checking if a feature is already stable, simply enable them
and allow the warning if the feature is already stable. This avoids the
need of hardcoding whether a feature has been stabilized at a given
version.
`#[feature(...)]` is used when cfg `USE_RUSTC_FEATURES` is enabled. The
build script automatically does this when a nightly compiler is detected
or `RUSTC_BOOTSTRAP` is set.
arm64: tegra: defconfig: Drop redundant ARCH_TEGRA_foo_SOC
All CONFIG_ARCH_TEGRA_132_SOC-like symbols are now default for
ARCH_TEGRA, so drop redundant lines from defconfig. Tested with
comparing include/generated/autoconf.h.
ARM: tegra: defconfig: Drop redundant ARCH_TEGRA_foo_SOC
All CONFIG_ARCH_TEGRA_2x_SOC-like symbols are now default for
ARCH_TEGRA, so drop redundant lines from defconfigs. Tested with
comparing include/generated/autoconf.h.
soc/tegra: Make ARCH_TEGRA_SOC_FOO defaults for NVIDIA Tegra
By convention, only one globally selectable ARCH_PLATFORM is expected
for given SoC platform, defined in arch/arm64/Kconfig.platforms or
arch/arm/mach-*/Kconfig, because we target a single multi-platform
kernel image.
Platforms wanting different granularity, e.g. due to size constraints on
their devices, should be sure that globally only one ARCH_PLATFORM is
selected in defconfig. Change Tegra per-SoC Kconfig entries to default
to ARCH_TEGRA allowing removal of these per-SoC parts from defconfigs.
wifi: iwlwifi: reduce the number of prints upon firmware crash
When the firmware crashes, we print data to be able to know what
happened. The problem is that those prints became excessive as during
the course of the years, we added more data without ever removing the
prints that were no longer useful.
Instead of spamming the log with data that will not help anyone, limit
the prints to what is really needed.
Avinash Bhatt [Sat, 21 Mar 2026 17:29:18 +0000 (19:29 +0200)]
wifi: iwlwifi: mld: block EMLSR during TDLS connections
TDLS (Tunneled Direct Link Setup) requires single-link operation
for direct peer-to-peer communication, which is incompatible with
EMLSR (Enhanced Multi-Link Single Radio) mode where the radio
switches between multiple links.
Block EMLSR when the first TDLS peer is added and unblock when
the last TDLS peer is removed. The block/unblock APIs handle
exiting EMLSR and triggering link selection automatically.
wifi: iwlwifi: mld: update the TLC when we deactivate a link
We hit a problem in the channel switch flow.
We had link 0 using PHY 0, so the TLC object in the firmware is using
PHY 0.
Then we switched channel, so mac80211 / iwlmld:
* deactivated link 0
* removed PHY 0
* added PHY 1
* modified link 0 to use PHY 1
* activated link 0.
The TLC object was not updated and the firmware was unhappy that the TLC
was still trying to use PHY 0.
Fix that by letting the TLC know about the PHY context before the link
activation.
When we are de-activating a link, let the TLC know so that it'll send a
TLC configuration command with an invalid PHY context to remove the
relationship between the TLC object and the PHY that is going to be
removed.
That last part is not implemented yet in the firmware, so leave this as
a TODO for now.
Miri Korenblit [Sat, 21 Mar 2026 17:29:15 +0000 (19:29 +0200)]
wifi: iwlwifi: add a macro for max FW links
Currently we use IWL_FW_MAX_LINK_ID + 1 to indicate the maximum number
of link that the fw supports. This is a bit confusing.
Add a macro that indicates the number if maximum links that the FW
supports and use it instead.
Miri Korenblit [Sat, 21 Mar 2026 17:29:14 +0000 (19:29 +0200)]
wifi: iwlwifi: mld: always assign a fw id to a vif
We used to have a fw id assignment in iwl_mld_init_vif since all interface
types that were added to the driver was immediately added to the FW as
well.
Since NAN was introduced, this is no longer the case - the NAN interface
is not added to the fw until a local schedule is configured.
For this vif we don't assign a fw id so it is 0 by default.
But later, when the vif is removed from the driver, we think that it has
a valid fw id (0) and we point fw_id_to_vif[0] to NULL.
fw_id_to_vif[0] might actually point to another vif with a valid fw id
0. In this case, we end up messing fw_id_to_vif.
Fix this by initializing a vif with a special invalid fw id, and by
exiting iwl_mld_rm_vif early for NAN interfaces.
Miri Korenblit [Sat, 21 Mar 2026 17:29:13 +0000 (19:29 +0200)]
wifi: iwlwifi: mld: use the dedicated helper to extract a link
There is a helper, iwl_mld_fw_id_to_link_conf, that converts a fw link
id into the bss_conf structure. Use it in two more places instead of
retrieving the bss_conf directly from the fw-id-to-bss_conf mapping array.
This required changing the loop bound in iwl_mld_process_per_link_stats()
to ucode_capa.num_links, to avoid hitting a IWL_FW_CHECK for link ids
> ucode_capa.num_links and < ARRAY_SIZE(fw_id_to_bss_conf), but this
change makes sense anyway (there is no reason to iterate links that
cannot be valid).
Johannes Berg [Sat, 21 Mar 2026 17:29:12 +0000 (19:29 +0200)]
wifi: iwlwifi: add MAC context command version 4
Due to NAN additions, this command needs to grow. In iwlmvm
we just need to use the old _v3 (or v2) version, but iwlmld
needs to handle the difference and send both. Do that as a
first step towards adding NAN support.
Avinash Bhatt [Sat, 21 Mar 2026 17:29:11 +0000 (19:29 +0200)]
wifi: iwlwifi: handle NULL/ERR returns from ptp_clock_register()
ptp_clock_register() returns NULL when PTP support is disabled and may
return an ERR_PTR() on other failures. Reduce Log severity for NULL
return cases to avoid misleading errors when PTP is unavailable.
Johannes Berg [Sat, 21 Mar 2026 17:29:09 +0000 (19:29 +0200)]
wifi: iwlwifi: mld: make alloc functions not forced static
In preparation for NAN needing the link ID allocation, have
the macro not automatically make the ID allocation functions
static so we can remove that later from the link allocation
function.
Johannes Berg [Fri, 20 Mar 2026 08:09:18 +0000 (10:09 +0200)]
wifi: iwlwifi: mld: remove type argument from iwl_mld_add_sta()
This is used only in a single place, and the caller always sets
the type to STATION_TYPE_PEER right now. We need to change some
of this for NAN in the future, removing the type argument will
simplify that.
Johannes Berg [Fri, 20 Mar 2026 08:09:16 +0000 (10:09 +0200)]
wifi: iwlwifi: pcie: don't dump on reset handshake in dump
When a FW dump happens, possibly even because of a reset handshake
timeout, there's no point in attempting to dump again. Since all the
callers of the function outside the transport itself are from the FW
dump infrastructure, just split the internal function and make the
external one not dump on timeout.
Johannes Berg [Fri, 20 Mar 2026 08:09:15 +0000 (10:09 +0200)]
wifi: iwlwifi: use IWL_FW_CHECK for sync timeout
This could be a firmware issue, it didn't send all the responses
quickly enough. There are other potential issues (interrupts not
being delivered, etc.) but the FW debug data will at least give
some better information, and it's not a WARN condition anyway.
Prevent potential issues when newer BIOS revisions
are used with firmware that doesn't support them for
PER_PLATFORM_ANT_GAIN_CMD.
Without this check, the driver may attempt to use
BIOS configurations that are incompatible with the
current firmware version, leading to dropping of
command in firmware without any failure notification
to driver.
Miri Korenblit [Fri, 20 Mar 2026 08:09:13 +0000 (10:09 +0200)]
wifi: iwlwifi: validate the channels received in iwl_mcc_update_resp_v*
Check with IWL_FW_CHECK that the FW doesn't send a channel that we don't
support. Otherwise, the center frequency will be 0, leading to a
warning since is_valid_reg_rule will return false, of course.
Although the warning is verbose enough, the IWL_FW_CHECK will spare some
of the debug.
Avinash Bhatt [Fri, 20 Mar 2026 08:09:12 +0000 (10:09 +0200)]
wifi: iwlwifi: add CQM event support for per-link RSSI changes
Implement CQM RSSI threshold handling by tracking the last reported RSSI
and issuing CQM low/high events when the RSSI crosses the configured
threshold with the required hysteresis. This provides proper CQM support
and enables userspace to receive per-link RSSI notifications.
wifi: iwlwifi: fw: Add TLV support for BIOS revision of command
Add support for newer firmware API versions that support
multiple BIOS revisions. Use the new TLV provided by
firmware to determine which BIOS revision it supports.
Future patches will use this information to either
drop commands when the BIOS revision is higher than
supported or convert commands based on the command
specific implementation.
Since we are including now nvm-reg.h in img.h, this causes a
re-definition error of IWL_NUM_CHANNELS which is also defined in
eeprom.c, so rename IWL_NUM_CHANNELS to IWL_NUM_CHANNELS_V2
Johannes Berg [Fri, 20 Mar 2026 08:09:07 +0000 (10:09 +0200)]
wifi: iwlwifi: mld: support changing iftype at runtime
While the interface isn't really operating, which is already
required by mac80211, we can simply remove the MAC and add
it again to change the type. Implement this simple handling.
We could almost consider moving this to mac80211 itself, as
this kind of flow should be supportable by any device, but
for now keep it here.
wifi: iwlwifi: support PER_CHAIN_LIMIT_OFFSET_CMD v6
This includes support for UNII-9.
Store the source of the WGDS table in the firmware runtime object to be
able to pass the information to the firmware.
Prefer to use ARRAY_SIZE when we check array-length.
Make sure num_profile isn't bigger than the number of profiles we can
actually store in the firmware runtime object.
Same of the number of bands.
wifi: iwlwifi: uefi: open code the parsing of the WGDS table
We will soon add support for UNII-9 band in the WGDS table. We need to
decouple the UEFI code from the firmware runtime code.
The firmware runtime is just a software object which will need to grow
and UEFI objects need a new revision to grow. Existing systems will keep
the same UEFI objects.
Just like PPAG and SAR, stop using structures to parse the UEFI tables
since the layout depends on the revision.
The support for the new revision will be added in the next patch, for
now, just do the ground work.
wifi: iwlwifi: mld: support version 11 of REDUCE_TX_POWER_CMD
This introduces support for UNII-9.
After we increased the size of the arrays of the subbands in SAR
structure, we now support the new firmware command.
wifi: iwlwifi: uefi: support the new WRDS and EWRD tables
Those tables now have support for UNII-9 subband.
Refactor iwl_uefi_set_sar_profile to get an array of values that makes
it easier to use when the number of subbands can vary.
Revamp a bit the code that fetches the tables to ask for the smaller
table, then we can check the size of the object that we got and compare
to the expected sizes to determine what revision to expect.
Johannes Berg [Thu, 19 Mar 2026 18:48:42 +0000 (20:48 +0200)]
wifi: iwlwifi: restrict TOP reset to some devices
Due to the Bluetooth implementation needing to match, not all
devices can actually do TOP reset. Restrict it to Sc2/Sc2f or
later, with Wh RF or later.
wifi: iwlwifi: uefi: add support for PPAG table rev5
This table has another subband for UNII-9.
Add defines for the sizes of rev4 and rev5 to easily know how much data
to ask from iwl_uefi_get_verified_variable.
In case rev5 doesn't exist, fallback to rev4.
Check that the revision advertised by the fetched table matches the size
that we got.
This adds support for UNII9 which requires to add a subband.
Just increase the number of subbands that we need to read.
Replace the usage of the IWL_NUM_SUB_BANDS_VX macros in acpi.h since
those macros are defined in the firmware API and ACPI declarations have
nothing to do the firmware API.
wifi: iwlwifi: acpi: check the size of the ACPI PPAG tables
We need to make sure we don't have a buffer overflow while reading the
PPAG tables from ACPI into the firmware runtime object.
Add an ACPI specific define for the number of chains in order to
decouple the ACPI layout from the other objects.
wifi: iwlwifi: regulatory: support a new command for PPAG
Per Platform Antenna Gain is getting support for UNII-9.
Add a new version of PER_PLATFORM_ANT_GAIN_CMD.
This requires to increase the number of subbands in the firmware runtime
object.
Pass the number of subbands to iwl_bios_print_ppag to avoid printing
invalid values.
Introduce BIOS_PPAG_MAX_SUB_BANDS_NUM to avoid impacting
BIOS_SAR_MAX_SUB_BANDS_NUM which was used until now for PPAG as well.
SAR will get support for the new subband in future patches.
While at it, print the PPAG table as it was read from BIOS.
Miri Korenblit [Thu, 19 Mar 2026 09:09:23 +0000 (11:09 +0200)]
wifi: iwlwifi: mld: add support for sta command version 3
In this version, the link_id becomes a link_mask to support multiple
links that are used to communicate with the station in question.
This is needed for NAN, in which we can communicate on multiple channels
with the same station.
Also add a new STA type - NAN peer.
wifi: iwlwifi: bring iwl_fill_ppag_table to the iwlmvm
iwl_fill_ppag_table fills a command that is sent to the firmware. This
command has several versions and handling those different versions is
the responsibility of the op_mode.
wifi: iwlwifi: uefi: open code the PPAG table store operation
The structure in firmware runtime will need to grow because we're adding
a subband for UNII-9.
This means that we will soon no longer be able to just memcpy the data
from the UEFI table. The layout of the array will change.
Tediously copy the data byte-byte to make sure things get to the right
place even when we'll increase the number of subbands.
Make it easier for the uefi_cnv_var_ppag structure to grow by
simpiflying the layout it becomes an array of s8.
The layout of the structure becomes less obvious from the structure's
declaration, but then the code is more flexible.
Don't use UEFI_SAR_MAX_SUB_BANDS_NUM for the number of bands for PPAG.
Of course, SAR related structures will grow in future patches, but
decouple SAR and PPAG to make the work easier.
Ilan Peer [Thu, 19 Mar 2026 09:09:20 +0000 (11:09 +0200)]
wifi: iwlwifi: mld: Introduce scan command version 18
The FW scan logic was extended to support new channels in the
7 GHz band, as such, the scan command was modified to support
scanning more PSC channels.
Introduce scan command version 18 handling, which is different
from scan command version 17 only in the number of supported
channel configurations.
As a preparation for a new scan command version, refactor
the scan command building such that it would allow introducing
new scan command structures in a simpler way.
wifi: iwlwifi: mld: remove unused scan expire time constants
Remove the unused IWL_MLD_SCAN_EXPIRE_TIME_SEC constant from
constants.h and its corresponding IWL_MLD_SCAN_EXPIRE_TIME
macro definition from mlo.c. These definitions are no longer
referenced.
wifi: iwlwifi: uefi: decouple UEFI and firmware APIs
The APIs in uefi.h are not firmware API files nor are they pure software
objects. They really reflect a specific layout we expect to see in the
UEFI tables.
Since the UEFI objects are encoded into the BIOS, we can't use the same
values for the declaration of the UEFI objects and for the pure software
object like iwl_sar_profile in the firmware runtime object.
wifi: iwlwifi: ensure we don't read SAR values past the limit
When we fill the SAR values, we read values from the BIOS store in the
firmware runtime object and write them into the command that we send to
the firmware.
We assumed that the size of the firmware command is not longer than the
BIOS tables. This has been true until now, but this is not really safe.
We will soon have an firmware API change that will increase the size of
the table in the command and we want to make sure that we don't have a
buffer overrun when we read the firmware runtime object.
Add this safety measure.
wifi: iwlwifi: mld: add support for iwl_mcc_allowed_ap_type_cmd v2
There is a new version of this command to indicate which AP type in
UNII-9 is supported per country.
This adds support for a new UEFI table that will include that data to be
filled in the new AP type table.
Rename the uats_table field in firmware_runtime structure since it
includes now the UATS and the new UNEB table coming from UEFI.
For the same reason, rename iwl_mld_init_uats.
Marco Crivellari [Tue, 10 Feb 2026 14:33:32 +0000 (15:33 +0100)]
wifi: iwlwifi: mvm: replace use of system_wq with system_percpu_wq
This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.
Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
Marco Crivellari [Thu, 20 Nov 2025 10:08:49 +0000 (11:08 +0100)]
wifi: iwlwifi: fw: replace use of system_unbound_wq with system_dfl_wq
This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.
Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
Marco Crivellari [Thu, 20 Nov 2025 10:08:48 +0000 (11:08 +0100)]
wifi: iwlwifi: replace use of system_unbound_wq with system_dfl_wq
This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.
Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
Laurent Pinchart [Wed, 18 Mar 2026 23:59:07 +0000 (01:59 +0200)]
media: renesas: vsp1: Initialize format on all pads
The state initialization function vsp1_entity_init_state() incorrectly
leaves the last entity pad out when initializing formats due to an off
by one error. Fix it.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:06 +0000 (01:59 +0200)]
media: renesas: vsp1: Implement control events
The V4L2 API requires drivers that expose controls to implement control
notification events. This is enforced by v4l2-compliance. Add event
handling to the VSP1 entities that create controls to fix the compliance
failures.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:05 +0000 (01:59 +0200)]
media: renesas: vsp1: histo: Fix format setting
The histogram .set_fmt() handler suffers from two problems:
- When operating on the source pad, it returns correct information to
userspace, but does not store the format in the subdev state.
Subsequent calls to .get_fmt(), handled by the
vsp1_subdev_get_pad_format() helper, will not return the correct
information.
- When operating on the sink pad, it uses the
vsp1_subdev_set_pad_format(), which propagates the sink format to the
source, incorrectly overwriting the fixed source format.
The first issue could be fixed by implementing the set format operation
with vsp1_subdev_get_pad_format() on the source pad, if it wasn't that
.set_fmt() is also used to initialize the subdev state in
vsp1_entity_init_state(). The histogram would need a custom
.init_state() handler.
As the second issue would anyway overwrite the format, and therefore
requires a custom .set_fmt() implementation, fix both issues without
using the helpers.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:04 +0000 (01:59 +0200)]
media: renesas: vsp1: histo: Fix size enumeration
The histogram supports size enumeration on the sink pad only, as the
source pad outputs a metadata format. The correct error code when
enumeration is not supported is -ENOTTY, not -EINVAL. Fix it.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:03 +0000 (01:59 +0200)]
media: renesas: vsp1: histo: Fix code enumeration
The histogram media bus code enumeration does not check the index when
operating on the source pad, resulting in an infinite loop if userspace
keeps enumerating code without any loop boundary. Fix it by returning an
error for indices larger than 0 as the pad supports a single format.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:02 +0000 (01:59 +0200)]
media: renesas: vsp1: hsit: Fix size enumeration
The HSIT entity performs format conversion, which leads to incorrect
results with the vsp1_subdev_enum_frame_size() helper. Implement a
custom .enum_frame_size() handler that correctly validates the media bus
code. Size validation is identical to the helper.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:01 +0000 (01:59 +0200)]
media: renesas: vsp1: brx: Fix format propagation
The format width and height is never propagated to the BRX source pad,
leaving its initial configuration invalid. Propagate the whole format
from the first sink pad to the source pad instead of only propagating
the media bus code. This fixes compliance with the subdev format
propagation rules.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:00 +0000 (01:59 +0200)]
media: renesas: vsp1: rwpf: Fix media bus code and frame size enumeration
The RWPF can't freely convert between all input and output formats. They
support RGB <-> YUV conversion, but HSV formats can't be converted. Fix
the media bus code and frame size enumeration to take this into account
on the source pad.
Laurent Pinchart [Wed, 18 Mar 2026 23:58:59 +0000 (01:58 +0200)]
media: renesas: vsp1: rpf: Fix crop width and height clamping
The vsp1 driver doesn't enforce a minimum value on the RPF crop rectangle
width and height. Empty rectangles are accepted, leading to incorrect
hardware behaviour. Fix it by adding minimum width and height
constraints to the value clamping.
Laurent Pinchart [Wed, 18 Mar 2026 23:58:58 +0000 (01:58 +0200)]
media: renesas: vsp1: rpf: Fix crop left and top clamping
The RPF doesn't enforces the alignment constraint on the sink pad
format, which could have an odd size, possibly down to 1x1. In that
case, the upper bounds for the left and top coordinates clamping would
become negative, cast to a very large positive value. Incorrect crop
rectangle coordinates would then be incorrectly accepted.
A second issue can occur when the requested left and top coordinates are
negative. They are cast to a large unsigned value, clamped to the
maximum. While the calculation will produce valid values for the
hardware, this is not compliant with the V4L2 specification that
requires values to be adjusted to the closest valid value.
Fix both issues by switching to signed clamping, with an explicit
minimum to adjust negative values, and adjusting the clamp bounds to
avoid negative upper bounds.
Laurent Pinchart [Wed, 18 Mar 2026 23:58:57 +0000 (01:58 +0200)]
media: renesas: vsp1: Fix code checks in frame size enumeration
The media bus code passed to the .enum_frame_size() operation for the
sink pad is required to be supported by the device, but not to match the
current format. All entities that use the vsp1_subdev_enum_frame_size()
helper, as well as the SRU and UDS entities that implement the operation
manually, perform the check incorrectly.
Fix the issue by implementing the correct code check in the
vsp1_subdev_enum_frame_size(). For the SRU and UDS, to avoid duplicating
code, use the vsp1_subdev_enum_frame_size() as a base and override the
enumerated size on the source pad with entity-specific constraints.
While at it, include the missing <linux/mutex.h> as the code locks
mutexes.
Laurent Pinchart [Wed, 18 Mar 2026 23:58:56 +0000 (01:58 +0200)]
media: renesas: vsp1: Store size limits in vsp1_entity
Most entities use the vsp1_subdev_enum_frame_size() and
vsp1_subdev_set_pad_format() helper functions to implement the
corresponding subdev operations. Both helpers are given the minimum and
maximum sizes supported by the entity as arguments, requiring each
entity to implement a wrapper.
Replace the function arguments with storing the size limits in the
vsp1_entity structure. This allows dropping most of the
.enum_frame_size() and .set_fmt() wrappers in entities.
Laurent Pinchart [Wed, 18 Mar 2026 23:58:55 +0000 (01:58 +0200)]
media: renesas: vsp1: Store supported media bus codes in vsp1_entity
Most entities use the vsp1_subdev_enum_mbus_code() and
vsp1_subdev_set_pad_format() helper functions to implement the
corresponding subdev operations. Both helpers are given the list of
supported media bus codes as arguments, requiring each entity to
implement a wrapper.
Replace the function arguments with storing the supported media bus
codes in the vsp1_entity structure. This allows dropping most of the
.enum_mbus_code() wrappers from entities.
Oliver Collyer [Fri, 26 Dec 2025 06:57:18 +0000 (06:57 +0000)]
media: uvcvideo: Add support for P010 pixel format
Add support for the P010 (10-bit Y/UV 4:2:0) pixel format to the
uvcvideo driver. This format is exposed by USB capture devices such as
the Magewell USB Capture HDMI 4K Pro when capturing HDR10 content.
P010 stores 10-bit Y and interleaved UV samples in 16-bit little-endian
words, with data in the upper 10 bits and zeros in the lower 6 bits.
This requires 2 bytes per sample, so bytesperline is wWidth * 2.
V4L2_PIX_FMT_P010 was added to the V4L2 core in commit 5374d8fb75f3
("media: Add P010 video format").
Based on the community DKMS patch from awawa-dev/P010_for_V4L2.
Yogev Modlin [Sun, 26 Oct 2025 16:43:03 +0000 (18:43 +0200)]
media: uvcvideo: Add D436 and D555 cameras metadata support
Add support for Intel RealSense D436 and D555 depth cameras metadata.
These cameras use the D4XX metadata format for transmitting depth and
sensor information.
The D555 camera uses UVC protocol version 1.5, while the D436 uses
an undefined protocol version. Both cameras require the D4XX metadata
format flag to properly handle their metadata streams.
Yogev Modlin [Sun, 26 Oct 2025 16:43:02 +0000 (18:43 +0200)]
media: uvcvideo: Change comment to 'Intel RealSense'
RealSense branding is now independent of Intel. Update all driver
comments referencing "Intel" to "Intel RealSense" to reflect
current ownership. No code logic changes.
Ricardo Ribalda [Mon, 9 Mar 2026 15:01:56 +0000 (15:01 +0000)]
media: uvcvideo: Allow userspace to increase the meta buffersize
Now we have the metadata size hardcoded to 10 KiB, this is a value that
works fine for bulk cameras or frames with no extra metadata. But not
for all usecases.
We have seen some cameras that produce more metadata per frame. Eg:
Frame 1 captured (Bytes: 11154)
Frame 2 captured (Bytes: 11616)
Frame 3 captured (Bytes: 11374)
Frame 4 captured (Bytes: 11132)
Frame 5 captured (Bytes: 11594)
Frame 6 captured (Bytes: 11352)
Frame 7 captured (Bytes: 11110)
Frame 8 captured (Bytes: 11572)
Frame 9 captured (Bytes: 11308)
When this happens, the driver (correctly) marks the metadata as ERROR.
This patch let userspace set bigger buffersize via S_FMT.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20260309-uvc-metadata-dmabuf-v1-3-fc8b87bd29c5@chromium.org Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Ricardo Ribalda [Mon, 9 Mar 2026 15:01:55 +0000 (15:01 +0000)]
media: uvcvideo: uvc_queue_to_stream(): Support meta queues
The stream data structure has two queues: the metadata and the data
queues, but uvc_queue_to_stream() only supports the data queue. If we
pass the metadata queue the function will return an invalid pointer.
This patch add a parameter to the function to explicitly tell the
function which queue are we using.
Ricardo Ribalda [Mon, 9 Mar 2026 15:01:54 +0000 (15:01 +0000)]
media: uvcvideo: Enable VB2_DMABUF for metadata stream
The UVC driver has two video streams, one for the frames and another one
for the metadata. Both streams share most of the codebase, but only the
data stream declares support for DMABUF transfer mode.
I have tried the DMABUF transfer mode with CONFIG_DMABUF_HEAPS_SYSTEM
and the frames looked correct.
This patch announces the support for DMABUF for the metadata stream.
This is useful for apps/HALs that only want to support DMABUF.
Cc: stable@vger.kernel.org Fixes: 088ead2552458 ("media: uvcvideo: Add a metadata device node") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260309-uvc-metadata-dmabuf-v1-1-fc8b87bd29c5@chromium.org Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Jann Horn [Tue, 24 Mar 2026 21:35:12 +0000 (22:35 +0100)]
slab,rcu: disable KVFREE_RCU_BATCHED for strict grace period
Disable CONFIG_KVFREE_RCU_BATCHED in CONFIG_RCU_STRICT_GRACE_PERIOD builds
so that kernel fuzzers have an easier time finding use-after-free involving
kfree_rcu().
The intent behind CONFIG_RCU_STRICT_GRACE_PERIOD is that RCU should invoke
callbacks and free objects as soon as possible (at a large performance
cost) so that kernel fuzzers and such have an easier time detecting
use-after-free bugs in objects with RCU lifetime.
CONFIG_KVFREE_RCU_BATCHED is a performance optimization that queues
RCU-freed objects in ways that CONFIG_RCU_STRICT_GRACE_PERIOD can't
expedite; for example, the following testcase doesn't trigger a KASAN splat
when CONFIG_KVFREE_RCU_BATCHED is enabled:
```
struct foo_struct {
struct rcu_head rcu;
int a;
};
struct foo_struct *foo = kmalloc(sizeof(*foo),
GFP_KERNEL | __GFP_NOFAIL | __GFP_ZERO);
Jun Nie [Thu, 12 Mar 2026 08:28:12 +0000 (16:28 +0800)]
drm/msm/dpu: support plane splitting in quad-pipe case
The content of every half of screen is sent out via one interface in
dual-DSI case. The content for every interface is blended by a LM
pair in quad-pipe case, thus a LM pair should not blend any content
that cross the half of screen in this case. Clip plane into pipes per
left and right half screen ROI if topology is quad pipe case.
The clipped rectangle on every half of screen is futher handled by two
pipes if its width exceeds a limit for a single pipe.
For non-virtual-plane case, there is always one stage config to serve
a LM or LM pair. So the clipping does not occur when interating stages
in this case. The plane is mapped to 2 pipes only when width or clock
rate exceeds hardware constrain within stage check.
Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/711324/ Link: https://lore.kernel.org/r/20260312-msm-next-quad-pipe-split-v19-3-4ffa2b06c996@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tvrtko Ursulin [Tue, 24 Mar 2026 11:10:19 +0000 (11:10 +0000)]
drm/syncobj: Fix xa_alloc allocation flags
The xarray conversion blindly and wrongly replaced idr_alloc with xa_alloc
and kept the GFP_NOWAIT. It should have been GFP_KERNEL to account for
idr_preload it removed. Fix it.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: fec2c3c01f1c ("drm/syncobj: Convert syncobj idr to xarray") Reported-by: Himanshu Girotra <himanshu.girotra@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Himanshu Girotra <himanshu.girotra@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260324111019.22467-1-tvrtko.ursulin@igalia.com
Jun Nie [Thu, 12 Mar 2026 08:28:11 +0000 (16:28 +0800)]
drm/msm/dpu: Defer SSPP allocation until CRTC check
Currently, mapping plane to SSPP occurs during the plane check phase for
non-virtual plane case. The SSPP allocation and plane mapping occurs during
CRTC check phase for virtual plane case. Defer these SSPP operations until
CRTC check stage to unify the 2 cases, and ease later revisement for
quad-pipe change.
Jun Nie [Thu, 12 Mar 2026 08:28:10 +0000 (16:28 +0800)]
drm/msm/dpu: Extract plane splitting into a dedicated function
dpu_plane_atomic_check_nosspp() currently handles both plane
validation and plane splitting. For better simplicity and to
facilitate future refactoring, move the splitting logic into
its own dedicated function.
projects / thirdparty / linux.git / log
