Junjie Cao [Thu, 12 Feb 2026 12:50:35 +0000 (20:50 +0800)]
wifi: iwlwifi: mld: fix race condition in PTP removal
iwl_mld_ptp_remove() calls cancel_delayed_work_sync() only after
ptp_clock_unregister() and clearing ptp_data state (ptp_clock,
last_gp2, wrap_counter).
This creates a race where the delayed work iwl_mld_ptp_work() can
execute between ptp_clock_unregister() and cancel_delayed_work_sync(),
observing partially cleared PTP state.
Move cancel_delayed_work_sync() before ptp_clock_unregister() to
ensure the delayed work is fully stopped before any PTP cleanup
begins.
Cc: stable@vger.kernel.org Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Junjie Cao <junjie.cao@intel.com> Link: https://patch.msgid.link/20260212125035.1345718-2-junjie.cao@intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Peter Zijlstra [Mon, 11 May 2026 11:31:13 +0000 (13:31 +0200)]
sched: Remove sched_class::pick_next_task()
The reason for pick_next_task_fair() is the put/set optimization that
avoids touching the common ancestors. However, it is possible to
implement this in the put_prev_task() and set_next_task() calls as
used in put_prev_set_next_task().
Notably, put_prev_set_next_task() is the only site that:
- calls put_prev_task() with a .next argument;
- calls set_next_task() with .first = true.
This means that put_prev_task() can determine the common hierarchy and
stop there, and then set_next_task() can terminate where put_prev_task
stopped.
Peter Zijlstra [Mon, 11 May 2026 11:31:12 +0000 (13:31 +0200)]
sched/fair: Add newidle balance to pick_task_fair()
With commit 50653216e4ff ("sched: Add support to pick functions to
take rf") removing the balance callback, the pick_task() callback is
in charge of newidle balancing.
This means pick_task_fair() should do so too. This hasn't been a
problem in practise because pick_next_task_fair() is used. However,
since we'll be removing that one shortly, make sure pick_next_task()
is up to scratch.
Peter Zijlstra [Mon, 11 May 2026 11:31:06 +0000 (13:31 +0200)]
sched: Use {READ,WRITE}_ONCE() for preempt_dynamic_mode
Robots figured out you can read and write this concurrently and got
'upset'. Gemini even noted sched_dynamic_show() can generate
'confusing' output if it observed different values during the
printing.
Andrea Righi [Fri, 22 May 2026 09:25:23 +0000 (11:25 +0200)]
sched/fair: Fix RCU usage in NOHZ exit path on CPU offline
Commit c9d93a73ce87 ("sched/fair: Drop redundant RCU read lock in NOHZ
kick path") removed the rcu_read_lock()/unlock() pair from
set_cpu_sd_state_busy() and set_cpu_sd_state_idle() on the assumption
that all callers run in a safe context for rcu_dereference_all(): IRQs
disabled or cpus_write_lock() held.
That assumption is wrong for the CPU hotplug teardown path. When CPUs
are taken offline, set_cpu_sd_state_busy() is invoked via:
The cpuhp kthread holds cpu_hotplug_lock (percpu-rwsem) but runs with
preemption and IRQs enabled. As a result, lockdep correctly reports a
suspicious RCU usage on CPU offline, e.g.:
arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel and CPSW3G
Update WIZ, gmii-sel and CPSW3G to use the J722S-specific compatible
strings, enabling SGMII support. The fallback compatibles preserve
compatibility of the updated Device Trees with older kernels.
firmware: ti_sci: Add support for restoring clock context during resume
Some DM-Firmware are not able to restore the clock rates and the
clock parents after a suspend-resume. The CLK_CONTEXT_LOST firmware
capability has been introduced to identify this characteristic.
In this case the responsibility is therefore delegated to the
ti_sci driver, which uses clk_restore_context() to trigger the
context_restore() operation for all registered clocks, including
those managed by the sci-clk. The sci-clk driver implements the
context_restore() operation to ensure rates and clock parents are
correctly restored.
Implement the restore_context() operation to restore the clock rate
and the clock parent state. The clock rate is saved in sci_clk struct
during set_rate() and recalc_rate() operations. The parent index
is saved in sci_clk struct during set_parent() operation. During
clock registration, the core retrieves each clock’s parent using
get_parent() operation to ensure the internal clock tree reflects
the actual hardware state, including any configurations made by the
bootloader. So we also save the parent index in get_parent().
Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Kendall Willis <k-willis@ti.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com> Link: https://patch.msgid.link/20260519-ti-sci-jacinto-s2r-restore-irq-v9-3-c550a8ae0f31@bootlin.com Signed-off-by: Nishanth Menon <nm@ti.com>
firmware: ti_sci: Add support for restoring IRQs during resume
Some DM-Firmware are not able to restore the IRQ context after
a suspend-resume. The IRQ_CONTEXT_LOST firmware capability has
been introduced to identify this characteristic. In this case the
responsibility is delegated to the ti_sci driver, which maintains
an internal list of all requested IRQs. This list is updated on
each set()/free() operation, and all IRQs are restored during the
resume_noirq() phase.
firmware: ti_sci: Add BOARDCFG_MANAGED mode support
In BOARDCFG_MANAGED mode, the low power mode configuration is done
statically for the DM via the boardcfg. Constraints are not supported,
and prepare_sleep() is not needed.
l1rox3 [Wed, 20 May 2026 08:12:54 +0000 (10:12 +0200)]
PM: hibernate: make LZ4 available for hibernation compression
Without this, CRYPTO_LZ4 had to be manually enabled in the config
to use LZ4 for hibernation compression. Add the select so it gets
pulled in automatically when hibernation is enabled, just like
CRYPTO_LZO already does.
Conor Dooley [Tue, 19 May 2026 09:37:25 +0000 (10:37 +0100)]
pinctrl: spacemit: move over to generic pinmux dt_node_to_map implementation
Replace the custom implementation of dt_node_to_map with
pinctrl_generic_dt_node_to_map() to demonstrate its use.
spacemit_pin_mux_config didn't provide much value in the first place,
because the group contains the information required to look up the
spacemit_pin struct corresponding to a pin, so there's no loss in
functionality as a result of the generic function carrying only the mux
data in the group's data pointer rather than having an array of
spacemit_pin_mux_config structs.
As far as I can tell spacemit_pctrl_check_power(), called during the
custom implementation of dt_node_to_map, is redundant because
the driver's implementation generate_config performs the check too.
Removing this would allow the driver to use the newly added common
function pinctrl_generic_pinmux_dt_node_to_map().
Conor Dooley [Tue, 19 May 2026 09:37:23 +0000 (10:37 +0100)]
pinctrl: add new generic groups/function creation function for pinmux
Akin to my recently added pinctrl_generic_pins_functions_dt_node_to_map(),
create an analogue that performs the same role of dynamically creating
groups at runtime for controllers using the pinmux property.
The pinmux property is freeform, so this function mandates that the
upper 16 bits contain the pin and the lower 16 bits contains the mux
setting. The group's data pointer is populated with an array of the mux
settings for each pin it contains.
Since the node parsing and subsequent pinctrl core function calls are
practically identical to the pins + functions case, other than which
properties are examined, it makes sense to extract the common code from
pinctrl_generic_pins_function_dt_node_to_map() into a generic function
that takes the case-specific devicetree parsing function as an argument.
Conor Dooley [Tue, 19 May 2026 09:37:22 +0000 (10:37 +0100)]
pinctrl: generic: change signature of pinctrl_generic_to_map() to pass void data
In order to make pinctrl_generic_to_map() usable for controllers that
use pinmux, change the functions char array pointer that it passes to
pinctrl_generic_add_group() to a void pointer. In the pinmux case this
property will contain the mux setting as a number rather than as strings
in the pins + functions case.
Add SM_THERMAL_CALIB_READ at SMC ID 0x82000047 in the command
table and implement meson_sm_get_thermal_calib(), which forwards the
tsensor_id argument to the secure monitor and returns the calibration data.
Also realign the CMD() column to improve readability.
Ronald Claveau [Fri, 24 Apr 2026 15:45:10 +0000 (17:45 +0200)]
firmware: meson: sm: Thermal calibration read via secure monitor
Add SM_THERMAL_CALIB_READ to the secure monitor command enum and
introduce meson_sm_get_thermal_calib() to allow drivers to retrieve
thermal sensor calibration data through the firmware interface.
Ronald Claveau [Fri, 24 Apr 2026 15:45:09 +0000 (17:45 +0200)]
dt-bindings: thermal: amlogic: Add support for T7
Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
Unlike existing variants which use a phandle to the ao-secure syscon,
the T7 relies on a secure monitor interface described by a phandle and
a sensor index argument.
The T7 integrates multiple thermal sensors, all accessed through the
same SMC call. The sensor index argument is required to identify which
sensor's calibration data the secure monitor should return, as a single
SM_THERMAL_CALIB_READ command serves all of them.
Introduce the amlogic,secure-monitor property as a phandle-array and
make amlogic,ao-secure or amlogic,secure-monitor conditionally required
depending on the compatible.
Daniel Lezcano [Fri, 24 Apr 2026 16:00:19 +0000 (18:00 +0200)]
thermal/drivers/tegra/soctherma: Switch to devm cooling device registration
Use devm_thermal_of_cooling_device_register() to simplify resource
management and avoid manual cleanup in error paths.
As a side effect this change has the benefit of solving an existing
issue. Before, the function tegra_soctherm_remove() only called
debugfs_remove_recursive() and never called thermal_cooling_device_unregister()
for any of the cooling devices registered here.
After the driver removal, the thermal framework's cdev list would
still hold references to thermal_cooling_device objects whose devdata
pointer (ts) pointed to memory already freed by the platform device's
devm cleanup.
With this change, the cooling device is unregistered when the driver
is removed, thus fixing the issue above.
Daniel Lezcano [Fri, 24 Apr 2026 16:00:18 +0000 (18:00 +0200)]
thermal/drivers/tegra/soctherm: Use devm_add_action_or_reset() for clock disable
Replace the manual error handling paths disabling the clocks with
devm_add_action_or_reset(). This ensures the clocks are properly
disabled on probe failure and driver removal, while simplifying the
code by removing the explicit error paths.
====================
net: enetc: Prepare for ENETC v4 VF support
This patch series refactors and extends the ENETC driver infrastructure
to prepare for upcoming ENETC v4 Virtual Function (VF) support. The main
focus is on code commonization, improved VF-PF communication, and dynamic
resource allocation.
The ENETC IP has evolved across different revisions, and the existing
driver architecture was primarily designed around v1 hardware. To support
v4 VFs efficiently, we need to share common code between PF drivers of
different IP versions while maintaining compatibility.
Key changes in this series:
1. VF-PF Messaging Infrastructure:
- Convert mailbox messages to new formats
- Use read_poll_timeout() for simplifying VF mailbox polling
- Add support for IP minor revision query via messaging
2. Code Commonization:
- Relocate SR-IOV configuration helpers to common PF code
- Move VF message handlers to dedicated enetc_msg.c
- Integrate enetc_msg.c into enetc-pf-common driver
3. CBDR (Control Buffer Descriptor Ring) Improvements:
- Align v1 CBDR API with v4 for VF driver sharing
- Add CBDR setup/teardown hooks to enetc_si_ops
4. Dynamic Resource Management:
- Dynamically allocate rxmsg based on actual VF count
- Use MADDR_TYPE constant for MAC filter array sizing
This refactoring lays the groundwork for cleanly integrating ENETC v4 VF
support in subsequent patch series, allowing code reuse between v1 and v4
PF drivers while maintaining a clean separation of version-specific
logic.
Wei Fang [Fri, 22 May 2026 09:24:38 +0000 (17:24 +0800)]
net: enetc: dynamically allocate rxmsg based on VF count
The constant ENETC_MAX_NUM_VFS is defined as 2 when enabling support for
LS1028A. This works for LS1028A because its ENETC hardware supports up
to 2 VFs. However, ENETC v4 has varying VF capabilities depending on the
SoC:
Using a fixed ENETC_MAX_NUM_VFS for memory allocation leads to
over-allocation on SoCs with fewer or no VF support. To better match
hardware capabilities and avoid unnecessary memory usage, change rxmsg
memory allocation from a fixed-size array to dynamic allocation based
on the actual VF count retrieved via pci_sriov_get_totalvfs().
Wei Fang [Fri, 22 May 2026 09:24:37 +0000 (17:24 +0800)]
net: enetc: use MADDR_TYPE for MAC filter array size
The mac_filter array in struct enetc_pf is sized as
ENETC_MAX_NUM_MAC_FLT, defined as (ENETC_MAX_NUM_VFS + 1) * MADDR_TYPE.
This resulted in an array of 6 elements (for 2 VFs), but only the first
2 entries are actually used.
The PF driver maintains MAC filters for unicast (UC) and multicast (MC)
addresses, indexed by the enum enetc_mac_addr_type (UC=0, MC=1). The
code only iterates over MADDR_TYPE (2) entries and directly accesses
mac_filter[UC] and mac_filter[MC]. The extra space allocated for
(ENETC_MAX_NUM_VFS * MADDR_TYPE) entries is never used because VF MAC
filtering is not implemented yet.
Remove the ENETC_MAX_NUM_MAC_FLT macro and size the array as
MADDR_TYPE, reducing the allocation from 6 to 2 entries. This saves 48
bytes per PF and better reflects the actual usage.
This change has no functional impact. Future VF MAC filtering support
will move mac_filter into struct enetc_si, allowing each SI (PF or VF)
to maintain its own independent filter table.
Wei Fang [Fri, 22 May 2026 09:24:36 +0000 (17:24 +0800)]
net: enetc: add generic helper to initialize SR-IOV resources
The upcoming ENETC v4 PF driver will support SR-IOV, and its logic for
initializing VF resources is identical to the existing ENETC v1 PF
implementation. To avoid code duplication across PF drivers, factor out
the common SR-IOV initialization logic into the enetc-pf-common driver.
Add enetc_init_sriov_resources() to handle:
- Querying the total number of VFs supported by the device via
pci_sriov_get_totalvfs()
- Allocating memory for the VF state array (struct enetc_vf_state)
The implementation uses devm_kcalloc() instead of kzalloc() to simplify
memory management. This automatically frees VF state memory when the PF
device is removed, eliminating the need for explicit cleanup in error
and remove paths.
Wei Fang [Fri, 22 May 2026 09:24:35 +0000 (17:24 +0800)]
net: enetc: add CBDR setup/teardown hooks to enetc_si_ops for VF support
The upcoming ENETC v4 VF will share the enetc-vf driver with the
existing v1 VF. However, ENETC v4 uses a revised CBDR (command BD ring)
setup/teardown API that differs from v1.
To support both versions in the same driver, add setup_cbdr() and
teardown_cbdr() function pointers to struct enetc_si_ops. This allows
each hardware version to register its own CBDR implementation:
Update the enetc-vf driver to call CBDR operations through si->ops
instead of directly invoking the v1 functions. This enables runtime
selection of the correct CBDR backend based on hardware version.
Changes:
- Add setup_cbdr() and teardown_cbdr() hooks to struct enetc_si_ops
- Register v1 CBDR functions in enetc_vsi_ops
- Replace direct calls with si->ops->setup_cbdr() and
si->ops->teardown_cbdr() in enetc_vf.c
Wei Fang [Fri, 22 May 2026 09:24:34 +0000 (17:24 +0800)]
net: enetc: align v1 CBDR API with v4 for VF driver sharing
The upcoming ENETC v4 VF will share the enetc-vf driver with the v1 VF.
However, ENETC v4 introduces different CBDR (command BD ring) setup and
teardown semantics that are incompatible with v1.
To support both versions in the same driver, the .setup_cbdr() and
.teardown_cbdr() hooks will be added to struct enetc_si_ops, allowing
the driver to register version-specific implementations. So refactor the
v1 CBDR functions to match the v4-style interface (taking struct enetc_si*
instead of individual parameters), enabling them to be registered via
si_ops in the subsequent patch.
Changes:
- Update enetc_setup_cbdr() and enetc_teardown_cbdr() prototypes to
take 'struct enetc_si *' as the sole parameter
- Extract parameters (dev, hw) from the enetc_si structure within the
function implementations
- ENETC_CBDR_DEFAULT_SIZE has always been used as the number of command
BDs, and there is no need to adjust the size of the command BD ring.
Therefore, ENETC_CBDR_DEFAULT_SIZE is moved into the enetc_setup_cbdr()
- Update all call sites in enetc_pf.c and enetc_vf.c
No functional changes. This prepares for adding v4-specific CBDR handling
in subsequent patches.
Wei Fang [Fri, 22 May 2026 09:24:33 +0000 (17:24 +0800)]
net: enetc: add VF-PF messaging support for IP minor revision query
For ENETC v4, different SoCs use different minor revisions, such as
i.MX95 v4.1, i.MX94 v4.3, and i.MX952 v4.6. Unlike the PF, the VF does
not have access to a global register that exposes the IP minor revision.
In the current driver model, the VF must select the appropriate driver
data based on this revision information.
To support this requirement, the VF now sends a minor revision query
message to the PF through the VSI-to-PSI mailbox mechanism. The PF
responds with the IP minor revision so that the VF can match the correct
driver data.
This patch adds PF-side support for replying to the minor revision
message and VF-side support for sending the query.
Wei Fang [Fri, 22 May 2026 09:24:32 +0000 (17:24 +0800)]
net: enetc: convert mailbox messages to new formats
On the LS1028A platform, the PF-VF mailbox was only used to update the
VF's MAC address. The original message format is minimal, lacks a clear
structure, and provides no means for the receiver to validate message
integrity, making it difficult to extend for new features.
With the introduction of i.MX ENETC v4, the interaction between PF and
VF has become significantly more complex. Typical deployments now include
scenarios where the PF is controlled by an M core while the VF is driven
by either the Linux kernel or DPDK, or where the PF is controlled by the
Linux kernel while the VF is controlled by DPDK. These heterogeneous
driver combinations require a unified and extensible message format to
ensure compatibility across different operating environments.
This patch introduces a newly defined PF-VF message structure and
converts the existing MAC-update mechanism to use the new format. The
redesigned message layout provides:
- extensibility to support future PF-VF features on ENETC v4,
- consistent framing for all message types,
- improved data integrity checking,
- a common protocol usable across Linux, M core firmware, and DPDK.
Additional PF-VF message types will be added in subsequent patches.
Note that switch to the new message format will not affect ENETC v1
(LS1028A). Due to a hardware limitation of ENETC v1, the ENETC PF and
VFs can only be controlled by the same OS. If the PF is controlled by
the Linux kernel driver, then the VFs must also be controlled by the
Linux kernel driver.
Wei Fang [Fri, 22 May 2026 09:24:30 +0000 (17:24 +0800)]
net: enetc: integrate enetc_msg.c into enetc-pf-common driver
Move enetc_msg.c from the fsl-enetc driver to the nxp-enetc-pf-common
driver so that SR-IOV mailbox handling can be shared between ENETC v1
and v4 PF drivers.
Changes:
- Move enetc_msg.o compilation from fsl-enetc to nxp-enetc-pf-common
- Export enetc_sriov_configure() with EXPORT_SYMBOL_GPL for use by
both PF drivers
The fsl-enetc driver now depends on nxp-enetc-pf-common for SR-IOV
functionality.
Wei Fang [Fri, 22 May 2026 09:24:29 +0000 (17:24 +0800)]
net: enetc: relocate SR-IOV configuration helper for common PF support
Move enetc_sriov_configure() from enetc_pf.c to enetc_msg.c to prepare
for integrating enetc_msg.c into the enetc-pf-common driver, where it
will be shared between ENETC v1 and v4 PF drivers.
Since enetc_msg_psi_init() and enetc_msg_psi_free() are now only called
from enetc_sriov_configure() within the same file, make them static.
Wei Fang [Fri, 22 May 2026 09:24:27 +0000 (17:24 +0800)]
net: enetc: use enetc_set_si_hw_addr() for setting MAC address
Replace enetc_pf_set_primary_mac_addr() with the generic
enetc_set_si_hw_addr() function. This prepares for moving
enetc_msg_pf_set_vf_primary_mac_addr() to the enetc-pf-common driver,
where it can be shared between ENETC v1 and v4 PF drivers.
Jiakai Xu [Sat, 23 May 2026 02:23:14 +0000 (02:23 +0000)]
PM: sleep: Use complete() in device_pm_sleep_init()
Replace complete_all() with complete() in device_pm_sleep_init() to allow
it to be called in atomic contexts without triggering a false-positive
WARNING from lockdep_assert_RT_in_threaded_ctx() when
CONFIG_PROVE_RAW_LOCK_NESTING is enabled.
device_pm_sleep_init() may be called during device initialization while
holding a raw_spinlock (e.g., from within device_initialize()), and
complete_all() is unsafe in atomic contexts on PREEMPT_RT kernels.
complete(), which is safe to call from any context, is sufficient here.
complete_all() sets the completion count to UINT_MAX/2 (permanently
signaled), while complete() increments it by 1. Since no threads can be
waiting during device initialization, both are functionally equivalent.
The completion is always reinitialized via reinit_completion() in
dpm_clear_async_state() before each suspend/resume cycle.
However, changing to complete() introduces a potential deadlock for
devices with no PM support (dev->power.no_pm = true). Such devices are
never added to the dpm_list and never go through dpm_clear_async_state(),
so their completion is never reinitialized. A parent device waiting on a
no_pm child across multiple suspend phases would consume the single-use
token in the first phase and block forever in the second.
Fix this by adding an early return in dpm_wait() when dev->power.no_pm is
set, since no_pm devices do not participate in system suspend/resume.
Fixes: 152e1d592071 ("PM: Prevent waiting forever on asynchronous resume after failing suspend") Signed-off-by: Jiakai Xu <xujiakai24@mails.ucas.ac.cn>
[ rjw: Subject adjustment ] Link: https://patch.msgid.link/20260523022314.2657232-1-xujiakai24@mails.ucas.ac.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
K Prateek Nayak [Sat, 23 May 2026 05:55:03 +0000 (05:55 +0000)]
cpufreq/amd-pstate-ut: Disable dynamic_epp after the mode switch
Dan reported a possible NULL pointer dereference in amd-pstate-ut.c from
static analysis and sure enough, running amd-pstate-ut in active mode
with amd_dynamic_epp=enable results in a crash as a reult of the policy
reference being set to NULL early, before disabling dynamic EPP.
Kalpana also reported seeing amd-pstate-ut error out with -EBUSY for
"amd_pstate_ut_epp" test when starting from the passive mode and
amd_dynamic_epp=enable in the command line. The reason for the failure
is that the command line enables dynamic_epp by default after the mode
switch and the modifications to EPP values are blocked when running in
dynamic EPP mode.
Solution to both problems is to toggle off dynamic_epp *after* the mode
switch when the driver grabs the policy reference again since the unit
test is in full control of the policy after that point.
The final restoration step will reset the dynamic_epp state via mode
switch based on the initial conditions of the system.
Reported-by: Kalpana Shetty <kalpana.shetty@amd.com> Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/linux-pm/ahEq0CvdBX0T7_cO@stanley.mountain/ Fixes: f9f16835d4dc ("cpufreq/amd-pstate-ut: Drop policy reference before driver switch") Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://patch.msgid.link/20260523055503.7651-1-kprateek.nayak@amd.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
drm/bridge: ite-it66121: Select HDMI or DVI mode based on sink type
The driver unconditionally sets the transmission mode to HDMI, which
leads to display output not working with DVI monitors. Check the
connector's display information sink type to identify the correct mode
to configure the bridge.
drm/bridge: ite-it66121: Move .mode_set logic to .atomic_enable
Move the existing .mode_set logic to the .atomic_enable callback. The
former is deprecated and drivers are supposed to use the latter instead.
Also, drop the struct it66121_ctx.connector field because the connector
can be accessed through the atomic state and there is no need to store
it anymore.
drm/bridge: ite-it66121: Switch to the HDMI connector helpers
Instead of open coding the HDMI AVI Infoframes buffer management, use the
helpers provided by the HDMI connector framework.
Also, add callbacks to implement HDMI Vendor Specific Infoframe and Audio
InfoFrame support. The driver was not sending these before, but they are
required when using the HDMI helpers.
These were implemented following the IT66121 Programming Guide.
====================
mv88e6xxx: Cache scratch config3 of 6352
In mv88e6352 scratch register in Global Control 2 set of registers
returns which port is attached to SERDES. This value is a pin
strapping value and is set after the switch is released from reset.
Thus, it can be cached during chip setup instead of reading the
register everytime when SERDES check is needed.
The series consist of 4 parts:
1. Add new mv88e6352_reset function as ops->reset
2. Cache the register value in this reset function
3. Refactor mv88e6352_g2_scratch_port_has_serdes to use the cached
value.
4. Remove the locks surrounding mv88e6352_g2_scratch_port_has_serdes.
Fidan Aliyeva [Thu, 21 May 2026 20:29:23 +0000 (22:29 +0200)]
mv88e6xxx: Use cached config3 in 6352 has_serdes
1. Refactor mv88e6352_g2_scratch_port_has_serdes to use the cached
scratch config3 value instead of reading it everytime.
2. Remove err<0 check from mv88e6352_phylink_get_caps as it is never
true anymore
Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com> Link: https://patch.msgid.link/20260521202924.727929-4-fidan.aliyeva.ext@ericsson.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
====================
net: mdio: realtek-rtl9300: Groundwork for multi SOC support
The Realtek Otto switch platform consist of four different series
- RTL838x aka maple : 28 port 1G Switches
- RTL839x aka cypress : 52 port 1G Switches
- RTL930x aka longan : 28 port 1G/2.5G/10G Switches
- RTL931x aka mango : 56 port 1G/2.5G/10G Switches
The existing realtek-rtl9300 MDIO driver was only designed for RTL930x
devices. The three other SOCs are not supported although they basically
incorporate a very similar MDIO controller.
This series is the first step in a multi-stage approach to also support
the missing SOCs. Device specific properties and registers are converted
into designated initializers. Based on this new devices can be added
much easier in future commits.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
====================
net: mdio: realtek-rtl9300: Link I/O functions in info structure
The MDIO controller registers of the different devices of the
Realtek Otto switch series are very similar. Nevertheless each
device will need to feed the whole command data distributed over
the controller registers slightly different.
E.g. the combined C22/command register has different field layouts.
On RTL930x bits 24-20 define the to-be-accessed C22 register number
while on RTL839x this is stored in bits 9-5.
Thus there need to be device specific read/write functions that
are called dynamically. Add them into the info structure and make
use of them where needed.
net: mdio: realtek-rtl9300: Add port mask register
MDIO controller commands work on ports. These are converted by
the driver and hardware forth and back to bus/address. For write
commands a port mask register needs to be filled. Each bit tells the
controller to which PHY the write will be issued. Setting multiple
bits allows to program multiple PHYs in one step. The driver will
not make use of this parallel write feature. But it must at least
fill the bit of the target port that it wants to write to.
Depending on the SOC type and the number of supported PHYs this is
either one or two 32 bit port mask registers. The driver currently only
supports the 28 port RTL930x SOCs. So provide only the mask register
for the lower 32 ports. Add it to the register structure and make use
of it where needed.
The MDIO data that needs to be written or read to registers of the
controller is handled by an I/O register. Add that to the register
structure and make use of it where needed.
Command issuing/status bits and C22 data share the same register. In the
future the number of places where this register is used will be:
- One generic command helper/runner for all devices that will access the
command bits of the register
- 8 device specific C22 read/write functions that will access the C22
data fields.
Thus name the register c22_data to align with the existing c45_data
register. This way all device specific helpers will have a common
view on the to-be-fed data. Add the register to the existing structure
and make use of it where needed.
The MDIO controller of the Realtek Otto switches has either 4 or 7 command
registers. This depends on the number of supported ports. These registers
are "scattered" around the MMIO block and their addresses depend on the
specific model.
Nevertheless all command registers share a common pattern:
- A mask register with one bit per addressed port
(remark: the driver internally works on ports instead of bus/address)
- A I/O data register that transfers the to be read/written data
- A C45 registers that takes devnum and regnum
- A C22 register that also includes run and status bits
(remark: this also takes the Realtek proprietary C22 PHY page)
Provide an additional structure for these command registers so it can be
reused in two places.
1. For defining the register addresses in the regmap.
2. For defining the to be read/written register data
net: mdio: realtek-rtl9300: Add pages to info structure
The Realtek ethernet MDIO controller has a proprietary paging feature
that is closely aligned with Realtek based PHYs. These PHY know "pages"
for C22 access. Those can be switched via reads/writes to register 31.
Usually the paged access must be programmed in four steps.
1. read/save page register
2. change "page" register 31
3. read/write data register (on the given page)
4. restore page register
The controller can run all this in hardware with one single request
from the driver. It is given the page, the register and the data
and takes care of all the rest. This reduces CPU load. The number
of supported pages depend on the model. This is either 4096 for low
port count SOCs (up to 28 ports) or 8192 for high port count SOCs
(up to 56 ports).
There is however one special page that allows to pass through all C22
commands directly to the PHY - without any caching. This so called raw
page is dependent of the hardware. It is the highest supported page
number minus 1.
Provide the number of supported pages as a device specific property.
This new "num_pages" aligns with the existing properties and gives
an better insight into the hardware layout than just defining the
number of the raw page. The later directly derives from that and
can be accessed with the new RAW_PAGE() macro. Make use of it where
needed.
net: mdio: realtek-rtl9300: Add ports to info structure
The ethernet MDIO controller in the Realtek Otto series has a very special
command register style. Instead of working with bus/address it works on
ethernet port numbers. For this the controller is initialized via mapping
registers that tell which port is mapped to which bus/address. Every
request to the driver is then converted as follows
1. Kernel calls driver with bus/address
2. Driver converts bus/address to port and issues command
3. Hardware maps port back to bus/address
The number of ports is different for each device. Make this configurable
by adding a property to the info structure. Switch the existing usage of
MAX_PORTS to this new property where needed.
net: mdio: realtek-rtl9300: Add device specific info structure
Device properties of the RTL930x SOCs are hardcoded into the MDIO driver.
This must be relaxed to support additional devices like the RTL838x or
RTL839x. These do not have 4 SMI buses but 1 or 2 instead.
To support multiple devices establish an info structure that contains
individual variations of each series. As a first use case add the number
of buses into this structure and use it where needed.
The Realtek ethernet MDIO driver currently only serves SOCs from the
Realtek RTL930x series. This is only one lineup of the Realtek Otto
switch series that also knows RTL838x, RTL839x, RTL931x devices.
All of these share similar hardware with comparable MMIO access logic
but have individual variations. Important to note
- Controller works on switch ports instead of buses and addresses.
- Devices incorporate additional MDIO hardware. E.g.
- an auxiliary MDIO controller for GPIO expanders [1]
- a MDIO style SerDes controller [2]
To avoid future confusion enhance the driver documentation and
function naming. Make clear what this driver is about and what
parts are generic and what parts are device specific. For this
rename the function and structure prefix as follows:
- for generic functions use otto_emdio_
- for device specific helpers use e.g. otto_emdio_9300_
This prefix naming tries to align with the watchdog timer [3].
It paves the way so that drivers for the other Realtek Otto MDIO
controllers can be added in future commits using the same naming
convention.
Remark 1: The read/write functions are kept device specific for now
because they will only fit the RTL930x SOCs. Renaming will take place
as soon as the I/O handling will be generalized.
Remark 2: The driver name "mdio-rtl9300" is kept for now.
When the system transitions from bootloader to kernel, the GPIO is
expected to keep driving high.
However, the Linux kernel first configures the pin direction and then
sets the output value. This may cause a brief low-level glitch on the
GPIO line, which can be problematic for regulator control.
By configuring the output value before switching the pin direction to
output, the glitch can be avoided.
This commit fixes the issue by swapping the configuration order.
Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
Add a module containing kunit test cases for GPIO core. The idea is to
use it to test functionalities that can't easily be tested from
user-space with kernel selftests or GPIO character device test suites
provided by the libgpiod package.
For now add test cases that verify software node based lookup and ensure
that a GPIO provider unbinding with active consumers does not cause a
crash.
Tests may want to unregister a platform device as part of the test case
logic. Using the regular platform_device_register() with kunit
assertions may result in a platform device leak or otherwise requires
cumbersome error handling. Provide a function that unregisters a
kunit-managed platform device and drops the release action from the
test's list.
====================
ip6_vti: vti6_changelink and vti6_siocdevprivate netns fixes
1/2 carries forward Eric Dumazet's Reviewed-by. Only the Fixes
tag changes there. 2/2 changes the Fixes tag and adds the
ns_capable hunk.
====================
Maoyi Xie [Thu, 21 May 2026 13:05:55 +0000 (21:05 +0800)]
ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().
After patch 1/2 in this series, vti6_update() unlinks and relinks
the tunnel through t->net. vti6_siocdevprivate() still uses
dev_net(dev) for the collision lookup. For a tunnel moved through
IFLA_NET_NS_FD, dev_net(dev) is the new netns, not t->net.
SIOCCHGTUNNEL on a migrated tunnel then runs:
net = dev_net(dev) /* migrated netns */
t = vti6_locate(net, &p1, false) /* misses target in t->net */
...
t = netdev_priv(dev)
vti6_update(t, &p1, false) /* mutates t->net's hash */
A caller in the migrated netns picks params that match a tunnel
in the creation netns. The lookup in dev_net(dev) finds nothing.
vti6_update() prepends the migrated tunnel at the head of the
creation netns hash bucket for those params. Later lookups in
the creation netns resolve to the migrated device. xfrm receive
delivers the matched packets through a device the caller controls.
Reachable from an unprivileged user namespace (unshare --user
--map-root-user --net). Cross tenant scope on container hosts.
Switch the SIOCCHGTUNNEL path on a non fallback device to use
t->net for the lookup. The lookup now matches the netns
vti6_update() operates on.
Also add ns_capable(self->net->user_ns, CAP_NET_ADMIN) before
the lookup. The check at the top of the case is against
dev_net(dev)->user_ns, which after migration is the attacker's
netns. A caller there can pick params absent from self->net,
the lookup returns NULL, t becomes self, and vti6_update()
inserts the device into the creation netns hash. The new check
requires CAP_NET_ADMIN in the creation netns user_ns too.
SIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep
dev_net(dev), which equals init_net there.
ip netns add ns1
ip netns add ns2
ip -n ns1 link add vti6_test type vti6 remote ::1 local ::2 key 7
ip -n ns1 link set vti6_test netns ns2
ip -n ns2 link set vti6_test type vti6 remote ::3 local ::4 key 9
ip netns del ns2
ip netns del ns1
[ 132.495484] ------------[ cut here ]------------
[ 132.497609] kernel BUG at net/core/dev.c:12376!
Commit 61220ab34948 ("vti6: Enable namespace changing") dropped
NETIF_F_NETNS_LOCAL from vti6 devices. A vti6 tunnel can then
move through IFLA_NET_NS_FD. After the move dev_net(dev) points
at the new netns while t->net stays at the creation netns.
vti6_changelink() and vti6_update() still use dev_net(dev) and
dev_net(t->dev). They unlink from one per netns hash and relink
into another. The creation netns is left with a stale entry.
cleanup_net() of that netns later walks freed memory.
Reachable from an unprivileged user namespace (unshare --user
--map-root-user --net). Cross tenant scope on container hosts.
hash_pointers= accepts a small set of mode strings, but the parser uses
strncmp() with the length of each valid mode. That accepts values with
trailing garbage, such as hash_pointers=autobots or
hash_pointers=nevermind, as valid aliases for auto and never.
Use strcmp() so that only the documented mode strings are accepted.
Invalid values will continue to fall back to auto through the existing
unknown-mode path.
exec_mmap() installs the new mm and then tears the old one down while
still holding exec_update_lock for writing -- and with cred_guard_mutex
held all the way to setup_new_exec():
Neither lock is needed for this. exec_update_lock only exists to make the
mm swap atomic with the later commit_creds(), so that permission-checking
readers (proc, ptrace, the futex robust list, perf, kcmp, mm_access())
never observe the new mm together with the old credentials. Those readers
all operate on task->mm, i.e. the new mm after the swap; none looks at the
detached old mm, its ->owner or signal->maxrss. cred_guard_mutex guards
credential calculation and is equally irrelevant here.
The cost is real: __mmput() runs exit_mmap() over the entire old address
space and can block in exit_aio() waiting for in-flight AIO, all while
holding exec_update_lock for writing and cred_guard_mutex. For execve() of
a large process this blocks ptrace_attach() and every exec_update_lock
reader for the duration of the teardown.
Stash the old mm in bprm->old_mm and release it from setup_new_exec()
after both locks are dropped. setup_new_exec() still runs before
setup_arg_pages() and the segment mappings, so the old address space is
freed before the new one is populated and peak memory is unchanged. The
ordering constraints are kept: old_mm's mmap_lock is still dropped in
exec_mmap() before mm_update_next_owner() (required since commit 31a78f23bac0 ("mm owner: fix race between swapoff and exit")), and
mm_update_next_owner() still precedes mmput(); both run in the execing
task's context, as mm_update_next_owner() requires.
If exec swaps the mm but fails before setup_new_exec() runs the old mm
would leak, so add a backstop in free_bprm(). The lazy-tlb case
(old_mm == NULL, e.g. kernel_execve()) has no address space to
free and is left in exec_mmap().
Merge patch series "exec: introduce task_exec_state for exec-time metadata"
Christian Brauner (Amutable) <brauner@kernel.org> says:
This series relocates the dumpable mode and the user_namespace
captured at execve() from mm_struct onto a new per-task
task_exec_state structure that stays attached to the task for its
full lifetime.
__ptrace_may_access() and several /proc owner / visibility checks
need to consult two pieces of state for any observable task,
including zombies that have already gone through exit_mm(): the
dumpable mode and the user namespace captured at execve(). Both
live on mm_struct today, which exit_mm() clears from the task long
before the task is reaped.
A reader that races with do_exit() observes task->mm == NULL and
either fails the check or falls back to init_user_ns - which denies
legitimate access to non-dumpable zombies that were running in a
nested user namespace.
mm_struct loses ->user_ns and the dumpability bits in ->flags.
MMF_DUMPABLE_BITS is reserved so MMF_DUMP_FILTER_* layout exposed via
/proc/<pid>/coredump_filter stays stable. task->user_dumpable and its
exit_mm() snapshot are removed.
task_exec_state is the privilege domain established by an execve()
[1]. Within a thread group it is shared via refcount; across thread
groups each task has its own:
- CLONE_VM siblings (thread-group members, io_uring workers)
refcount-share the parent's exec_state.
- Non-CLONE_VM clones (fork(), vfork() without CLONE_VM)
allocate a fresh exec_state inheriting the parent's dumpable
mode and user_ns.
- execve() in the child allocates a fresh instance and installs
it under task_lock + exec_update_lock via
task_exec_state_replace().
- Credential changes (setresuid, capset, ...) and
prctl(PR_SET_DUMPABLE) update dumpability on the current
task's exec_state, i.e. on the thread group's shared instance.
Behavioral change:
Kernel threads that briefly use a user mm via kthread_use_mm() no
longer inherit dumpability from the borrowed mm. Kthreads are not
ptraceable (PF_KTHREAD short-circuits __ptrace_may_access), so this
is observable only via /proc surfaces that a sufficiently privileged
reader can reach.
The dumpable flag captured at execve() is consulted by
__ptrace_may_access() and several /proc owner / visibility checks.
It lives on mm_struct today, which exit_mm() clears from the task
long before the task itself is reaped.
exec_state is anchored to the execve() that established the current
privilege domain. CLONE_VM siblings refcount-share the parent's
exec_state via copy_exec_state(); non-CLONE_VM clones allocate a
fresh exec_state inheriting the parent's dumpable mode and user_ns
reference via task_exec_state_copy(). execve() allocates a fresh
instance (via alloc_task_exec_state() in begin_new_exec()) and
installs it under task_lock + exec_update_lock with
task_exec_state_replace(). init_task uses a static instance.
The dumpable mode now lives on task->exec_state->dumpable.
task->mm->flags no longer carries dumpability; MMF_DUMPABLE_MASK is
removed, but MMF_DUMPABLE_BITS is reserved so MMF_DUMP_FILTER_* bit
positions remain stable for the /proc/<pid>/coredump_filter ABI. The
task->user_dumpable cache bit and its assignment in exit_mm() are
removed; readers go through get_dumpable(task) directly.
coredump_params gains a snapshot field cprm.dumpable, populated from
get_dumpable(current) at vfs_coredump() entry, replacing the previous
__get_dumpable(cprm->mm_flags) consumers in fs/coredump.c and
fs/pidfs.c.
The user namespace recorded at execve() is consulted by
__ptrace_may_access() and by /proc/PID/* owner derivation. Move the
captured user_ns onto task_exec_state, which stays attached to the task
past exit_mm() and across exit_files().
bprm grows a user_ns field staged in bprm_mm_init() with the caller's
user_ns, narrowed by would_dump() to the closest privileged ancestor,
and consumed by exec_mmap() via alloc_task_exec_state(bprm->user_ns).
free_bprm() releases the staging reference.
mm_struct loses ->user_ns entirely. Initializers in init-mm, efi_mm,
and the implicit one in mm_init()/dup_mm()/mm_alloc() are removed;
__mmdrop() drops the matching put_user_ns(). The kthread_use_mm()
WARN_ON_ONCE(!mm->user_ns) is no longer meaningful and goes too.
Introduce struct task_exec_state, a per-task RCU-protected structure
that holds the dumpable mode and the user namespace and stays attached
to the task for its full lifetime.
task_exec_state_rcu() is the canonical reader: asserts RCU or
task_lock is held, WARNs on a NULL state, returns the
rcu_dereference()'d pointer.
Replace the SUID_DUMP_DISABLE/USER/ROOT preprocessor constants with
enum task_dumpable. Numeric values are preserved (kernel.suid_dumpable
sysctl and prctl(PR_SET_DUMPABLE) ABI), so this is a pure rename with
no behavioral change.
Subsequent commits relocate dumpability onto a per-task structure
where the enum type will allow stronger type-checking on the new API.
Weiming Shi [Thu, 21 May 2026 08:12:01 +0000 (01:12 -0700)]
net: team: fix NULL pointer dereference in team_xmit during mode change
__team_change_mode() clears team->ops with memset() before restoring
safe dummy handlers via team_adjust_ops(). A concurrent team_xmit()
running under RCU on another CPU can read team->ops.transmit during
this window and call a NULL function pointer, crashing the kernel.
The race requires a mode change (CAP_NET_ADMIN) concurrent with
transmit on the team device.
The original code assumed that no ports means no traffic, so mode
changes could freely memset()/memcpy() the ops. AF_PACKET with
forced carrier breaks that assumption.
Prevent the race instead of making it safe: replace memset()/memcpy()
with per-field updates that never touch transmit or receive. Those
two handlers are managed solely by team_adjust_ops(), which already
installs dummies when tx_en_port_count == 0 (always true during mode
change since no ports are present). WRITE_ONCE/READ_ONCE prevent
store/load tearing on the handler pointers.
synchronize_net() before exit_op() drains in-flight readers that may
still reference old mode state from before port removal switched the
handlers to dummies.
Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Link: https://patch.msgid.link/20260521081159.1491563-3-bestswngs@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Zhengchuan Liang [Fri, 22 May 2026 09:31:55 +0000 (17:31 +0800)]
xfrm: input: hold netns during deferred transport reinjection
Transport-mode reinjection stores a struct net pointer in skb->cb and
uses it later from xfrm_trans_reinject(). That pointer must stay valid
until the deferred callback runs.
Take a netns reference when queueing deferred reinjection work and drop
it after the callback completes. Use maybe_get_net() so the queueing
path does not revive a namespace that is already being torn down.
This keeps the existing workqueue design and fixes the netns lifetime
handling in one place for all users of xfrm_trans_queue_net().
Usama Arif [Thu, 21 May 2026 10:29:26 +0000 (03:29 -0700)]
xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit
The struct pernet_operations docstring in include/net/net_namespace.h
explicitly warns against blocking RCU primitives in .exit handlers:
Exit methods using blocking RCU primitives, such as
synchronize_rcu(), should be implemented via exit_batch.
[...]
Please, avoid synchronize_rcu() at all, where it's possible.
Note that a combination of pre_exit() and exit() can
be used, since a synchronize_rcu() is guaranteed between
the calls.
xfrm_policy_fini() violates this: it calls synchronize_rcu() before
freeing the policy_bydst hash tables (so no RCU reader is mid-
traversal at free time), but runs from xfrm_net_ops.exit -- once per
namespace -- so a cleanup_net() of N namespaces pays N full RCU
grace periods serially.
Use the documented pre_exit/exit split. Move the policy flush (and
the workqueue drains it depends on) into a new .pre_exit handler;
xfrm_policy_fini() then runs in .exit and frees the hash tables
after the synchronize_rcu_expedited() that cleanup_net() guarantees
between the two phases. Providing O(1) RCU grace periods per batch
instead of O(N).
Observed on Linux 6.18 with a workload doing unshare(CLONE_NEWNET)
at ~13/sec sustained: cleanup_net() and the netns_wq rescuer kthread
both stuck in xfrm_policy_fini()'s synchronize_rcu(), >300k struct
net accumulated in the cleanup queue, Percpu in /proc/meminfo climbed
to 130+ GB on 256-CPU hosts, and memcg OOMs followed. setup_net and
__put_net counts were balanced, ruling out a refcount leak.
Fixes: 069daad4f2ae ("xfrm: Wait for RCU readers during policy netns exit") Signed-off-by: Usama Arif <usama.arif@linux.dev> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Shaomin Chen [Wed, 20 May 2026 18:07:23 +0000 (02:07 +0800)]
xfrm: iptfs: reset runtime state when cloning SAs
iptfs_clone_state() clones the IPTFS mode data with kmemdup(). This
copies runtime objects which must not be shared with the original SA,
including the embedded sk_buff_head, hrtimers, spinlock, and in-flight
reassembly/reorder state.
If xfrm_state_migrate() fails after clone_state() but before the later
init_state() call has reinitialized those fields, the cloned state can be
destroyed by xfrm_state_gc_task() with list and timer state copied from the
original SA. With queued packets this lets the clone splice and free skbs
owned by the original IPTFS queue, leading to use-after-free and
double-free reports in iptfs_destroy_state() and skb release paths.
Reinitialize the clone's runtime state before publishing it through
x->mode_data. Because clone_state() now publishes a destroyable mode_data
object before init_state(), take the mode callback module reference there.
Avoid taking it again from __iptfs_init_state() for the same object.
Len Bao [Sat, 16 May 2026 10:57:34 +0000 (10:57 +0000)]
gpiolib: Mark gpio_devt, gpiolib_initialized and gpio_stub_drv as __ro_after_init
The 'gpio_devt' and 'gpiolib_initialized' variables are initialized only
during the init phase in the 'gpiolib_dev_init' function and never
changed. So, mark these as __ro_after_init.
The 'gpio_stub_drv' variable is initialized only in the declaration and
never changed. So, this variable could be 'const', but using the
'driver_register' and 'driver_unregister' functions discards the 'const'
qualifier. Therefore, as an alternative, mark it as a __ro_after_init.
Jouni Högander [Wed, 20 May 2026 10:49:44 +0000 (13:49 +0300)]
drm/i915/psr: Use DC_OFF wake reference to block DC6 on vblank enable
We are observing following warnings:
*ERROR* power well DC_off state mismatch (refcount 0/enabled 1)
gen9_dc_off_power_well_enabled is considering target state DC_STATE_DISABLE
as DC_OFF power well being enabled. Fix this by using wakeref for the
purpose.
To achieve this we need to modify notification code as well. Currently it
is possible that PSR gets notified vblank enable/disable twice on same
status. This is currently not a problem as it is just triggering call to
intel_display_power_set_target_dc_state with same target state as a
parameter. When using wakeref this becomes a problem due to reference
counting. Fix this storing vbank status on last notification and use that
to ensure there are no more than one notification with same vblank status.
v2: ensure there is no subsequent notifications with same status
Jouni Högander [Wed, 20 May 2026 10:49:43 +0000 (13:49 +0300)]
drm/i915/psr: Block DC states on vblank enable when Panel Replay supported
Currently we are blocking DC states only when Panel Replay is enabled on
vblank enable. It may happen that Panel Replay is getting enabled when
vblank is already enabled. Fix this by blocking DC states always if Panel
Replay is supported.
While at it take care of possible dual eDP case by looping all encoders
supporting PSR.
Michał Grzelak [Thu, 16 Apr 2026 16:37:44 +0000 (18:37 +0200)]
drm/i915/aux: use polling when irqs are unavailable
PTL with physically disconnected display was observed to have 40s longer
execution time when testing xe_fault_injection@xe_guc_mmio_send_recv.
The issue has not been seen when reverting commit 40a9f77a28fa ("Revert
"drm/i915/dp: change aux_ctl reg read to polling read"").
Apparently the configuration suffers from not having AUX enabled when
using interrupts. One probable cause can be xe enabling interrupts too
late: interrupts need memory allocations which currently can't be done
before the display FB takeover is done.
As for now, use polling for AUX in case interrupts are unavailable.
Fixes: 40a9f77a28fa ("Revert "drm/i915/dp: change aux_ctl reg read to polling read"") Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260416163744.288107-1-michal.grzelak@intel.com
(cherry picked from commit 05e0550b65cd1604bd515fbc65f522bce4c10a87) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Results from decode_stacktrace.sh pointed to dereference of a file pointer
field of a i915 TTM page vector container associated with an object being
purged on eviction. That path is taken when the object is marked as no
longer needed.
Code analysis revealed a possibility of the i915 TTM page vector container
being replaced with a new instance inside a function that purges content
of the object, should it be still busy. That function is called,
indirectly via a more general function that changes the object's placement
and caching policy, before the problematic dereference, but still after
a pointer to the container is captured, rendering the pointer no longer
valid.
Fix the issue by capturing the pointer to the container only after its
potential replacement.
v2: Move the container_of() inside the if block (Sebastian),
- a simplified version of the commit description that explains briefly
why the change is necessary (Christian).
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/14882 Fixes: 7ae034590ceae ("drm/i915/ttm: add tt shmem backend") Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: stable@vger.kernel.org # v5.17+ Cc: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20260508122612.469227-2-janusz.krzysztofik@linux.intel.com
(cherry picked from commit 4462966a93eb185849b7f174f0d0de53476d00a4) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Icenowy Zheng [Mon, 25 May 2026 15:36:18 +0000 (23:36 +0800)]
drm: verisilicon: fix build failure of cursor plane code
The cursor plane patch was stalled for a too long time that the
struct drm_atomic_state parameter of atomic modeset hooks has been
changed to struct drm_atomic_commit.
Fix this by replacing the parameter's type. All helpers that retrieve
information from this struct are also changed so simply replacing the
type works.
Alexander Stein [Tue, 26 May 2026 06:35:01 +0000 (08:35 +0200)]
gpio: mxc: fix irq_high handling
If port->irq_high is -1 (fsl,imx21-gpio compatible) and gpio_idx is >= 16
enable_irq_wake() is called with -1 which is wrong.
Fixes: 5f6d1998adeb ("gpio: mxc: release the parent IRQ in runtime suspend") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260526063504.25916-1-alexander.stein@ew.tq-group.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
kho: fix order calculation for kho_unpreserve_pages()
Commit 91e74fa8b1bc ("kho: make sure preservations do not span multiple
NUMA nodes") made sure preservations from kho_preserve_pages() do not
span multiple NUMA nodes. If they do, the order is reduced and tried
again.
The same logic was not implemented for kho_unpreserve_pages(). This can
result in unpreserve calculating a different order than preserve, and
thus not actually unpreserving the pages.
Fix this by moving the order calculation logic to
__kho_preserve_pages_order() and use it from both preserve and
unpreserve paths.
Move __kho_unpreserve() down to avoid having a forward declaration. Its
users are further down in the file anyway. Also, it results in grouping
for all the page-level preservation and unpreservation functions. This
unfortunately makes the diff hard to read, but the main change in
__kho_unpreserve() is to call __kho_preserve_pages_order() instead of
open-coding the order calculation.
Fixes: 91e74fa8b1bc ("kho: make sure preservations do not span multiple NUMA nodes") Cc: stable@vger.kernel.org Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> Link: https://patch.msgid.link/20260519133332.2498092-1-pratyush@kernel.org Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
For systems with 16KB pages (e.g. arm64 with CONFIG_ARM64_16K_PAGES=y or
LoongArch), this gives a depth of 4. Since levels are 0 based, with
depth = 4 the effective top level is 3 and the top-level shift at bit 39.
The order-0 bit sits at bit 50 (KHO_ORDER_0_LOG2 = 64 - PAGE_SHIFT =
50). When inserting or reading a key, the index extracted at the top
level is:
(1 << 50) >> 39 = 2048
2048 is exactly the table size (PAGE_SIZE / sizeof(phys_addr_t) = 2048
for 16KB pages), so it wraps to 0, aliasing the order bit to index 0
and losing it silently.
On the second kernel, kho_radix_decode_key() sees a key without the
order bit, calls fls64() on the wrong bit, computes a wrong order and
thus a garbage physical address. phys_to_page() of that address faults
in kho_preserved_memory_reserve(), causing a kernel panic early in boot.
Fix by adding +1 to the DIV_ROUND_UP numerator so the formula accounts
for the order bit itself, giving depth 5 for 16KB pages. The top-level
shift becomes 50, and (1 << 50) >> 50 = 1, which is nonzero and
unambiguous. For 4KB and 64KB page sizes the depth is unchanged.
Link: https://patch.msgid.link/20260509024415.33190-1-dongtai.guo@linux.dev Fixes: 3f2ad90060f6 ("kho: adopt radix tree for preserved memory tracking") Tested-by: Kexin Liu <liukexin@kylinos.cn> Signed-off-by: George Guo <guodongtai@kylinos.cn> Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
[rppt: added actual math to the changelog] Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Alice Ryhl [Thu, 7 May 2026 11:14:42 +0000 (11:14 +0000)]
rust: kasan/kbuild: fix rustc-option when cross-compiling
The Makefile version of rustc-option currently checks whether the option
exists for the host target instead of the target actually being compiled
for. It was done this way in commit 46e24a545cdb ("rust: kasan/kbuild:
fix missing flags on first build") to avoid a circular dependency on
target.json. However, because of this, rustc-option currently does not
function when cross-compiling from x86_64 to aarch64 if
CONFIG_SHADOW_CALL_STACK is enabled. This is because KBUILD_RUSTFLAGS
contains -Zfixed-x18 under this configuration. Since that flag does not
exist on the host target, rustc-option runs into a compilation failure
every time, leading to all flags being rejected as unsupported.
To fix this, update rustc-option to pass a --target parameter so that
the host target is not used. For targets using target.json, use a
built-in target that is as close as possible to the target created with
target.json to avoid the circular dependency on target.json.
One scenario where this causes a boot failure:
* Cross-compiled from x86_64 to aarch64.
* With CONFIG_SHADOW_CALL_STACK=y
* With CONFIG_KASAN_SW_TAGS=y
* With CONFIG_KASAN_INLINE=n
Then the resulting kernel image will fail to boot when it first calls
into Rust code with a crash along the lines of "Unable to handle kernel
paging request at virtual address 0ffffffc08541796". This is because the
call threshold is not specified, so rustc will inline kasan operations,
but the kasan shadow offset is not specified, which leads to the inlined
kasan instructions being incorrect.
Note that the -Zsanitizer=kernel-hwaddress parameter itself does not
lead to a rustc-option failure despite being aarch64-specific because
RUSTFLAGS_KASAN has not yet been added to KBUILD_RUSTFLAGS when
rustc-option is evaluated by the kasan Makefile.
Cc: stable@vger.kernel.org Fixes: 46e24a545cdb ("rust: kasan/kbuild: fix missing flags on first build") Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260507-rustc-option-cross-v2-1-2f650a49c2b5@google.com
[ Edited slightly:
- Reset variable to avoid using the environment.
- Use a simply expanded variable flavor for simplicity.
- Export variable so that behavior in sub-`make`s is consistent.
This matches other variables. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Sven Schnelle [Thu, 21 May 2026 10:41:44 +0000 (12:41 +0200)]
s390/tracing: Add s390-tod clock
In order to allow comparing trace timestamps between different
systems or virtual machines on s390, add a s390-tod trace clock.
This clock just uses the returned TOD clock value from stcke
directly.
Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Heiko Carstens [Tue, 19 May 2026 06:20:42 +0000 (08:20 +0200)]
s390/zcore: Removed unused variables
allmodconfig with clang W=1 points out unused global variables:
drivers/s390/char/zcore.c:49:23: error: variable
'zcore_reipl_file' set but not used [-Werror,-Wunused-but-set-global]
drivers/s390/char/zcore.c:50:23: error: variable
'zcore_hsa_file' set but not used [-Werror,-Wunused-but-set-global]
Remove both of them, since there is no point in keeping them.
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Niklas Schnelle [Thu, 21 May 2026 11:10:44 +0000 (13:10 +0200)]
s390/configs: Enable IOMMUFD and VFIO cdev in defconfigs
Enable IOMMUFD and VFIO cdev such that PCI pass-through to QEMU/KVM can
optionally utilize native IOMMUFD. Note that because the defconfigs do
not enable IOMMUFD_VFIO_CONTAINER the default PCI pass-through using
VFIO with the existing container interface is not affected.
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Dan Carpenter [Mon, 25 May 2026 07:14:42 +0000 (10:14 +0300)]
accel/ivpu: prevent uninitialized data bug in debugfs
The simple_write_to_buffer() will only initialize data starting from
the *pos offset so if it's non-zero then the first part of the buffer
uninitialized. Really, if *pos is non-zero then this code won't work
so just check for that at the start of the function.
Fixes: 320323d2e545 ("accel/ivpu: Add debugfs interface for setting HWS priority bands") Signed-off-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/ahP24m6Mii9EDL7Q@stanley.mountain
Cássio Gabriel [Mon, 25 May 2026 14:16:09 +0000 (11:16 -0300)]
ALSA: seq: Remove arbitrary prioq insertion limit
The sequencer priority queue insertion path uses a hardcoded traversal
limit of 10000 entries. The value is intended to catch a corrupted list,
but it also becomes a real limit for valid queues.
The event pool limit is per client, while a sequencer queue can be shared
by multiple clients. A queue can therefore legitimately contain more than
10000 events. In that case, inserting an event that has to be placed past
the arbitrary limit fails with -EINVAL.
Use the queue's own cell count as the traversal bound instead. This keeps
the protection against inconsistent list accounting or cyclic lists without
rejecting valid large queues.
Manish Baing [Sat, 23 May 2026 17:32:51 +0000 (17:32 +0000)]
dt-bindings: pwm: stmpe: Drop legacy binding
The st,stmpe-pwm binding is already covered by the MFD schema
Documentation/devicetree/bindings/mfd/st,stmpe.yaml. Remove the
obsolete and redundant text binding file.
projects / thirdparty / linux.git / log
