| Age | Commit message (Collapse) | Author |
|---|
|
Export the link caps and link training helpers needed by the DP link
KUnit tests.
Use test ops tables instead of exporting the helpers directly, avoiding
symbol name collisions between the i915 and xe builds of the shared
display code.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-32-imre.deak@intel.com
|
|
Initialize a reusable test context for DP link KUnit tests. Sets up
minimal device, connector, encoder, and DP structures, and seeds the
pseudo-random generator for deterministic test runs.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-31-imre.deak@intel.com
|
|
Hook the shared i915 display DP link KUnit tests into the xe display
test build.
Build the shared display test source from the i915 display test directory
when xe display support is enabled.
v2: Unchanged.
v3: Add SPDX license header. (Michał)
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260707124849.135319-2-imre.deak@intel.com
|
|
Add a separate xe KUnit config for display tests.
The existing xe .kunitconfig builds xe statically, which is suitable for
non-display xe tests. The display code can only be enabled for xe when
xe is built as a module, so add a separate display config with DRM_XE=m
and DRM_XE_DISPLAY=y.
This can be folded back into the main xe KUnit config once the display
code becomes a separate module.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-29-imre.deak@intel.com
|
|
Add a Kunit stub test module for DP link test cases.
v2: Add missing module license.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-28-imre.deak@intel.com
|
|
Add KUnit configuration for i915 and a local .kunitconfig to run the
tests.
v2: Unchanged.
v3: Remove kconfig options for kernel debug.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v2
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260707124849.135319-1-imre.deak@intel.com
|
|
Disable the link configuration that failed training when selecting
fallback parameters.
Fallback still selects the next configuration using the existing
fallback order, but now also removes the failed configuration from the
allowed set. Functionally, this only affects the case where an MST <-> SST
mode switch occurs on the same root connector: previously, a configuration
that failed training in one mode could be reused in the other mode due
to the differing config iteration orders.
The current fallback logic also sets a temporary maximum link limit
across the allowed configurations to constrain subsequent modesets. This
legacy behavior is preserved for now; it will be removed once the
fallback logic relies solely on the individually disabled configurations
to restrict the allowed set.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-26-imre.deak@intel.com
|
|
Switch the fallback loop to use the link configuration iterator to
select a fallback configuration.
This also allows unexporting and removing from the link caps interface
all the common link rate query helpers and the helpers that accept or
return a link configuration index.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-25-imre.deak@intel.com
|
|
The target maximum rate/lane count selected by the fallback logic may
exceed the current link_caps max_limits' rate/lane count, the latter of
which are used as a limit by the lookup functions when filtering allowed
configurations. To ensure the fallback search finds all relevant
candidates, temporarily reset the link_caps max_limits to the maximum
common supported capabilities.
After the fallback search completes, set the link_caps max_limits to the
configuration selected by the fallback logic, as before, determining
the allowed configurations for a subsequent modeset.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-24-imre.deak@intel.com
|
|
Remove the min/max rate and lane count fields from struct
link_config_limits after all state computation is converted to use the
configuration filter.
A simple min/max range cannot fully describe the valid configuration
set once individual configurations are disabled (for example by
fallback), as it may allow combinations that are not actually valid.
The configuration filter, on the other hand, always represents a
consistent set of valid configurations.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-23-imre.deak@intel.com
|
|
Use the link caps helper to select the maximum DP MST link configuration
for DSC computation, instead of using the separate max rate and lane
count limits, which may not form a valid configuration after individual
configs are disabled by fallback.
Also look up the maximum rate for state computation via the configuration
mask when checking the DSC hblank expansion quirk.
This is a step towards unifying configuration selection and iteration
across connector types and between compute and fallback paths.
The state computation should likely consider all allowed configurations,
as noted in the code comment; for now keep the existing DP MST DSC
behavior of selecting the maximum BW configuration determined by the MST
connector BW config iteration order.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-22-imre.deak@intel.com
|
|
Use the link caps helper to select the maximum MST link configuration
for non-DSC computation, instead of using the separate max rate and lane
count limits, which may not form a valid configuration after individual
configs are disabled by fallback.
This is a step towards unifying configuration selection and iteration
across connector types and between compute and fallback paths.
In some cases all configurations should be considered, as noted in the
code comment; for now keep the existing behavior of selecting the
maximum bandwidth configuration as determined by the MST connector's BW
config iteration order.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-21-imre.deak@intel.com
|
|
Use the link caps helper to select the maximum eDP link configuration
for DSC computation, instead of using the separate max rate and lane
count limits, which may not form a valid configuration after individual
configs are disabled by fallback.
This is a step towards unifying configuration selection and iteration
across connector types and between compute and fallback paths.
The state computation should likely consider all allowed configurations,
as noted in the code comment; for now keep the existing eDP DSC behavior
of selecting the maximum configuration determined by the eDP connector
rate / lane config iteration order.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-20-imre.deak@intel.com
|
|
Use the link caps configuration iterator for DP SST link configuration
computation for DSC mode. This is a step towards unifying configuration
selection and iteration across connector types and between compute and
fallback paths.
The iteration preserves the DP SST connector rate/lane ordering used by
the current code.
This also allows removing the now unused common rate count helper.
v2:
- Rebase on changes using a filter object instead of a mask of
configuration indices.
- Rebase on changes using an iteration object.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-19-imre.deak@intel.com
|
|
Use the link caps configuration iterator for DP SST link configuration
computation for non-DSC mode. This is a step towards unifying
configuration selection and iteration across connector types and between
compute and fallback paths.
The iteration preserves the DP SST connector rate/lane ordering used by
the current code.
This also allows removing the now unused common rate count helper.
v2:
- Rebase on changes using a filter object instead of a mask of
configuration indices.
- Rebase on changes using an iteration object.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-18-imre.deak@intel.com
|
|
Use the link caps configuration mask when applying DP compliance test
link parameters during state computation.
Preserve the legacy behavior of falling back to all configurations with
the requested lane count if the requested rate and lane count pair is
not allowed.
In case no valid configuration is found fail the modeset.
v2:
- Rebase on changes using a filter object instead of a mask of
configuration indices.
- Rebase on changes using an iteration object.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-17-imre.deak@intel.com
|
|
Query the maximum link BW configuration via the link caps interface to
compute the available TBT bandwidth. Unlike the max common link params
used so far for this, the max BW config also accounts for any forced
link parameters.
This makes the max BW link config query uniform across mode validation
and TBT BW calculation, and allows unexporting the
intel_dp_link_caps_max_common_lane_count() helper.
v2: Use the max BW link configuration, instead of the max link limits.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-16-imre.deak@intel.com
|
|
Query the maximum link BW configuration during mode validation and MST
link probing directly from intel_dp_link_caps_get_max_bw_config(),
instead of using the intel_dp_max_link_rate() and
intel_dp_max_lane_count() helpers.
This makes the max BW link config query uniform across mode validation
and TBT BW calculation, and allows unexporting the
intel_dp_max_link_rate()/intel_dp_max_lane_count() helpers.
v2: Use the max BW link configuration, instead of the max link limits.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-15-imre.deak@intel.com
|
|
Add a helper to query the link configuration among the currently allowed
configurations with the maximum link BW.
This will be used by follow-up changes to unify the max BW link config
query during mode validation and TBT BW calculation.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-14-imre.deak@intel.com
|
|
Add link_config_filter to link_config_limits to track the set of valid
link configurations during modeset state computation. Keep the existing
min/max rate and lane count limits for now, until all users are
converted to use the configuration filter.
Add the helpers required to select the maximum configuration from the
currently allowed configuration set. This will be used by follow-up
changes as well to query the maximum link configuration without having
to iterate the configurations.
v2:
- Rebase on changes using a filter object instead of a mask of
configuration indices.
- Rebase on changes using an iteration object.
v3:
- Add TODO: label to code comment about min/max link config limit
removal. (Luca)
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-13-imre.deak@intel.com
|
|
intel_engine_user.c checks CONFIG_DRM_I915_SELFTESTS before running
the engine UABI isolation check. Kconfig defines DRM_I915_SELFTEST,
without the trailing "S", and the rest of i915 uses
CONFIG_DRM_I915_SELFTEST.
Because CONFIG_DRM_I915_SELFTESTS is not backed by any Kconfig symbol,
the IS_ENABLED() test is always false. Use the existing selftest symbol
so the debug/selftest guarded path can be reached when selftests are
enabled.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the Kconfig definition and the inconsistent
guard in intel_engine_user.c.
Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20260705080225.436-1-pengpeng@iscas.ac.cn
|
|
Add a debugfs entry showing the currently allowed link configurations
in the connector's iteration order.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-12-imre.deak@intel.com
|
|
There is no need to update any maximum link information when updating
the max link limits, so drop the related noupdate postfix from the
helpers setting the max link limits.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-11-imre.deak@intel.com
|
|
Re-enable link configurations after sink capabilities change or the link
got reset before updating the link capabilities (due to an RX_CAP_CHANGED
HPD IRQ for the currently connected sink, or a new sink getting
connected).
This makes resetting the link explicitly by calling
intel_dp_link_caps_reset() subsequently redundant; keep the existing
behavior wrt. this for now, adding only a TODO: to remove the explicit
reset.
While at it add documentation for intel_dp_link_caps_update().
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-10-imre.deak@intel.com
|
|
Re-enable link configurations after the link is reset via a call
to intel_dp_link_caps_reset(), allowing a subsequent modeset to
use all the link configurations of a sink newly connected or an already
connected sink changing its capabilities.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-9-imre.deak@intel.com
|
|
Add a filter for enabled link configurations to the link capability
state.
This allows fallback code to disable only the configuration that failed
link training, instead of constraining later modesets via maximum link
rate or lane count. The code only needs to exclude the failed
configuration from the allowed set; all other supported configurations
remain available.
Use the filter when computing the allowed configuration set and when
validating maximum link limits.
Follow-up changes will switch the fallback code to disable individual
configurations through this filter.
v2:
- Rebase on changes using a filter object instead of a mask of
configuration indices.
- Track the enabled configurations instead of the disabled ones.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-8-imre.deak@intel.com
|
|
Add validation in intel_dp_link_caps_set_max_limits() to ensure that
the new maximum rate and lane count leave at least one allowed
configuration.
The validation takes disabled configurations and active forced
parameters into account. Disabled configurations are not supported yet,
so that part has no effect for now.
At the moment this validation is also performed by the link training
fallback code, but that will be removed later, leaving only the link
caps module to perform the validation added in this patch.
v2: Rebase on changes using a filter object instead of a mask of
configuration indices.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-7-imre.deak@intel.com
|
|
Add helper to select the link configuration iteration order for a
connector during state computation and fallback selection. This keeps
the connector-specific ordering policy in the link caps module.
v2: Add helper to get the order for fallback selection as well.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-6-imre.deak@intel.com
|
|
Only synchronize fbdev output to the vblank of an active CRTC. Go over
the list of CRTCs and pick the first that matches. Fixes warnings as
the one shown below
[ 77.201354] WARNING: drivers/gpu/drm/drm_vblank.c:1320 at drm_crtc_wait_one_vblank+0x194/0x1cc [drm], CPU#1: kworker/1:7/1867
[ 77.201354] omapdrm omapdrm.0: [drm] vblank wait timed out on crtc 0
This currently happens if the fbdev output is not on CRTC 0.
Atomic and non-atomic drivers require distinct code paths. As for other
fbdev operations, implement both and select the correct one at runtime.
Not finding an active CRTC is not a bug. Do not wait in this case, but
flush the display update as before.
v4:
- avoid possible deadlocks with locking context (Sashiko)
v3:
- drop excessive state validation (Jani)
- acquire plane and CRTC mutices (Sashiko)
v2:
- move look-up code into separate helper
- support drivers with legacy modesetting
v1:
- see https://lore.kernel.org/dri-devel/1c9e0e24-9c4a-4259-8700-cf9e5fd60ca3@suse.de/
Co-authored-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: d8c4bddcd8bcb ("drm/fb-helper: Synchronize dirty worker with vblank")
Tested-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Closes: https://bugs.debian.org/1138033
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260702145021.226932-1-tzimmermann@suse.de
|
|
Add helpers to iterate over the allowed and optionally filtered set of
link configurations in a given order.
Taking into account disabled configurations will be added later when
adding support for disabling configurations.
Use the BW order in descending direction by default.
v2:
- Keep the iteration state in an iteration object. (Jani)
- Use a filter object instead of exposing configuration indices. (Jani)
- Move changes adding helpers required to setup the iteration object to
this patch.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-5-imre.deak@intel.com
|
|
Add support for iterating configurations in either link rate/lane count
or lane count/link rate order. Both orders are required for DP SST
connector types: the former for computing the connector state during a
modeset, and the latter for selecting a fallback configuration after a
link training failure.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-4-imre.deak@intel.com
|
|
Factor out a helper that looks up a link configuration by index.
This provides the link configuration directly, avoiding the
indirect conversion via the packed config entry.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-3-imre.deak@intel.com
|
|
Add documentation for the DP link capabilities interface.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260701153204.4124150-2-imre.deak@intel.com
|
|
The NXP IW61x series SDIO chipset identifies itself with a base card ID
(0x0204) during the initial MMC bus scan, while the specific WLAN
function reports a different ID (0x0205).
To ensure that the MMC_QUIRK_BLKSZ_FOR_BYTE_MODE quirk is correctly
inherited by all SDIO functions (including Wi-Fi), it must be attached
to the base card ID at the core level.
Add the SDIO_DEVICE_ID_NXP_IW61X_BASE definition and apply the required
fixup in the SDIO quirk table.
Signed-off-by: Jeff Chen <jeff.chen_1@nxp.com>
|
|
mhi_ep_create_device() takes one device reference for the UL channel and
another for the DL channel after allocating the transfer device. These
references are normally released by mhi_ep_destroy_device() before the
device itself is removed.
If dev_set_name() or device_add() fails, the error path currently drops
only one reference. The remaining channel references keep the device
from being released and leave the channels associated with a device that
was never registered.
Route both failures through a common unwind path that drops the DL
channel reference, the UL channel reference, and the initial reference
from device_initialize().
Fixes: 297c77a0f273 ("bus: mhi: ep: Add support for creating and destroying MHI EP devices")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260603195142.2189386-1-dbgh9129@gmail.com
|
|
Bring forward the idea to fix the power down latency in
mhi_pm_disable_transition() further to mhi_pm_sys_error_transition()
so that the transition into system error (triggered by AT!RESET) in the
modems won't have to return only after the timeout of up to 24 seconds.
Once the device gets reset, there is no guarantee that it will send an
interrupt to indicate the state transition. So polling is the sensible
option here.
Signed-off-by: Qingtao Cao <qingtao.cao.au@gmail.com>
[mani: commit log]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Link: https://patch.msgid.link/20260603011333.3306102-2-qingtao.cao.au@gmail.com
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-linus
Jonathan writes:
IIO: 1st set of fixes for the 7.2 cycle
Usual mixed bag of recently introduced issues and much older ones.
core
- Ensure kfifo is reset before fd is allocated avoiding concurrent use of
fifo with reset.
multiple drivers
- Fix up missing Kconfig dependencies.
hid-sensors
- Add support for multibyte read as necessary precursor to...
- Fix stale or zero output when reading raw values for quaternions.
adi,adis
- Add IRQF_NO_THREAD to ensure interrupt is not pushed to the software
interrupt chip used for trigger demux in the IIO core from a thread.
bosch,bmc150
- Hardening against device returning a reserved out of range value for
how many entries are in the FIFO.
bosch,bmi160
- Add IRQF_NO_THREAD to ensure interrupt is not pushed to the software
interrupt chip used for trigger demux in the IIO core from a thread.
dynaimage,al3010
- Fix wrong scale for highest gain_range due to too many digits in the
micro part (val2).
freescale,mpl3115
- Fix unbalanced runtime pm on error in read_raw().
invensens,icm42600
- Avoid wrong divisor for fifo timestamps when using the watermark
interrupt.
- Fix timestamp accuracy loss due to excessive divisor for calculations.
kionix,kxsd9
- Fix unbalanced runtime pm on an error in write_raw().
microchip,mcp37feb02
- Fix an uninitialized reference voltage value for particular DT config.
melix,mlx90635
- Build on basis of right Kconfig symbol.
nxp,lpc32xx
- Ensure completion initialized before requesting irq. Hardening against
spurious IRQ.
nxp,saradc
- Fix a delay calculation.
sharp,gp2ap0002
- Fix unbalanced runtime pm on error in read_raw().
st,lsm6dsx
- Fix an issue seen in wild where an unplanned CPU reset can leave the
device on the wrong register page, thus leaving the driver wedged.
st,st_sensors library
- Make sure to handle a device that provides data as big endian correctly.
st,spear
- Ensure completion initialized before requesting irq. Hardening against
spurious IRQ.
taos,tsl2591
- Don't eat return from devm_request_threaded_irq() as that breaks
deferred probing.
ti,ads1119
- Fix a pm reference count leak in an error path.
ti,ads124s08
- Handle gpio look up errors correctly.
* tag 'iio-fixes-for-7.2a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (28 commits)
iio: event: Fix event FIFO reset race
iio: imu: inv_icm42600: fix timestamp clock period by using lower value
iio: light: al3010: fix incorrect scale for the highest gain range
iio: adc: nxp-sar-adc: Fix the delay calculation in nxp_sar_adc_wait_for()
iio: light: tsl2591: return actual error from probe IRQ failure
iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading
iio: imu: st_lsm6dsx: deselect shub page before reading whoami
iio: adc: ad7779: add missing 'select IIO_TRIGGERED_BUFFER' to Kconfig
iio: adc: ad4130: add missing `select IIO_TRIGGERED_BUFFER` to Kconfig
iio: adc: ti-ads124s08: Return reset GPIO lookup errors
iio: temperature: Build mlx90635 with CONFIG_MLX90635
iio: light: al3320a: add missing REGMAP_I2C to Kconfig
iio: light: al3010: add missing REGMAP_I2C to Kconfig
iio: light: al3000a: add missing REGMAP_I2C to Kconfig
iio: common: st_sensors: honour channel endianness in read_axis_data
iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ
iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ
iio: hid-sensor-rotation: Fix stale or zero output when reading raw values
HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads
iio: adc: spear: Initialize completion before requesting IRQ
...
|
|
When __efi_queue_work() times out it disables runtime services and
returns, but the kworker is still blocked inside firmware. If the
firmware eventually unblocks, efi_call_rts() would run its tail on an
efi_rts_work that the timed-out caller has long abandoned: signalling a
stale completion and clearing efi_runtime_lock_owner that may by then
belong to another caller.
If runtime services have been disabled by the time the call returns,
park the worker with efi_rts_park_worker() instead, so it never touches
efi_rts_work again or returns to the workqueue.
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Three wrappers call firmware directly instead of going through
__efi_queue_work(), and none of them check whether runtime services are
still enabled: virt_efi_set_variable_nb(),
virt_efi_query_variable_info_nb() and virt_efi_reset_system(). Once a
hang has cleared EFI_RUNTIME_SERVICES - or efi_recover_from_page_fault()
has cleared it on a firmware page fault - these paths still enter the
(possibly wedged) firmware, e.g. an EFI pstore write through the
non-blocking SetVariable() variant, in violation of UEFI's
non-reentrancy rules. reset_system() is reachable too: efi_reboot()
only gates it on the static efi_rt_services_supported() mask, which does
not track the runtime disable.
Check efi_enabled(EFI_RUNTIME_SERVICES) in each before calling into
firmware. Test it after taking efi_runtime_lock rather than before: the
bit is only ever cleared at runtime while that lock is held, so checking
it under the lock avoids racing with a concurrent timeout that clears the
bit and drops the lock.
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
When an EFI runtime service hangs in firmware, the efi_rts_wq worker is
stuck inside the call and cannot be cancelled. __efi_queue_work() then
waits on the completion forever while holding efi_runtime_lock, so every
later EFI caller is wedged until reboot; the only symptom is a "workqueue
lockup" and tasks piling up on the semaphore.
Replace wait_for_completion() with wait_for_completion_timeout() bounded
by EFI_RTS_TIMEOUT (120 seconds). On timeout, clear EFI_RUNTIME_SERVICES
and return EFI_ABORTED so later callers fail fast at the entry check
instead of each paying another 120 seconds. The wedged worker is
intentionally leaked and keeps ownership of efi_rts_work.
A worker that only starts running after the timeout would otherwise
dereference efi_rts_work.args, now pointing into the caller's freed stack
frame, and hand stale pointers to firmware. Park it with
efi_rts_park_worker() at the entry of efi_call_rts() when runtime
services are already disabled, before it touches args or enters firmware.
Known limitation: a worker already inside firmware when the timeout fires
still holds efi_rts_args pointing into the caller's stack frame; if
firmware unblocks afterwards and writes the output buffers, they land in
reused memory. Firmware hung this long rarely recovers; a follow-up could
bounce the buffers through kmalloc.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Move the EFI_RUNTIME_SERVICES check to the top of __efi_queue_work() and
return directly, so a caller that finds runtime services disabled returns
without touching the shared efi_rts_work. No functional change.
This prepares for bounding the wait, where a timeout will clear
EFI_RUNTIME_SERVICES while the leaked worker still owns efi_rts_work; a
later caller must then bail out before reinitialising it.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Convert the queue_work() failure path in __efi_queue_work() to a
goto exit instead of falling through to the wait and the
WARN_ON_ONCE(status == EFI_ABORTED) below it. A failed queue_work()
leaves the status at its initial EFI_ABORTED, so that warning would
fire even though no call ran; it is meant for a completed call that
returned EFI_ABORTED.
No change for the common (successful enqueue) path. This also prepares
__efi_queue_work() for the timeout handling added later.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
x86's efi_crash_gracefully_on_page_fault() ends in an infinite
schedule() loop so the kworker that faulted in firmware never runs
efi_rts_wq again. A later change needs the same "park this worker
forever" primitive on the runtime service timeout path, so factor the
loop into a shared efi_rts_park_worker() and call it from the x86
page-fault handler.
No functional change.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Both DP MST and UHBR SST require the audio component to use a real
cpu_transcoder (>= 0) value to identify the audio stream on a port.
For DP MST this was already handled; for UHBR SST it was not, causing
pin_eld_notify() to signal cpu_transcoder = -1 (the legacy SST sentinel)
and find_audio_state() to skip the per-transcoder entry for the UHBR
stream.
After suspend/resume or replug, the ELD lookup fails and audio goes
silent. Fix by detecting UHBR SST alongside DP MST when deciding
whether a real cpu_transcoder value must be used for audio state
addressing, in both the pin_eld_notify() signalling and the
find_audio_state() lookup paths.
--v2:
- Commit message and comment update. (Suraj)
- Change function name has_mst_transcoder. (Suraj)
- Avoid Live crtc access in find_audio_state. (Suraj)
--v3:
- Minor comment changes to avoid MST over 128b/132b confusion. (Suraj)
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260708113558.1863316-1-mitulkumar.ajitkumar.golani@intel.com
|
|
The memory allocated for mboxq using mempool_alloc() is not freed in
some of the early exit error paths. Fix that by moving the
mempool_free() call to an earlier point after last use.
Fixes: d79c9e9d4b3d ("scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Reviewed-by: Justin Tee <justin.tee@broadcom.com>
Link: https://patch.msgid.link/20260707065304.949135-1-nihaal@cse.iitm.ac.in
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
SG_GET_REQUEST_TABLE reports per-request diagnostic state through
sg_req_info::problem. The field is meant to indicate whether there is an
error to report for a completed request.
sg_fill_request_table() currently combines masked_status, host_status
and driver_status with bitwise AND. This only reports a problem when all
three status fields are non-zero at the same time. A normal target check
condition, for example, has masked_status set while host_status and
driver_status may both be zero, so the request is incorrectly reported
as clean.
Use the same condition as sg_new_read(), which sets SG_INFO_CHECK when
any of the three status fields is non-zero.
Cc: stable@vger.kernel.org
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/54B60C19F7DB8889+20260707030845.970018-1-raoxu@uniontech.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The trace events in drivers/ufs/core/ufs_trace.h were converted to take
a pointer to the hba structure as an argument for the tracepoint and
then in TP_printk() the printing of the dev_name from the ring buffer
was converted to using the dev dereferenced pointer from the hba saved
pointer.
This is not allowed as the TP_printk() is executed at the time the trace
event is read from /sys/kernel/tracing/trace file. That can happen
literally, seconds, minutes, hours, weeks, days, or even months later!
There is no guarantee that the hba pointer will still exist by the time
it is dereferenced when the "trace" file is read.
Instead, save the device name from the hba pointer at the time the
tracepoint is called and place it into the ring buffer event. Then the
TP_printk() can read the name directly from the ring buffer and remove
the possibility that it will read a freed pointer and crash the kernel.
This was detected when testing the trace event code that looks for
TP_printk() parameters doing illegal derferences[1]
[1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/
Cc: stable@vger.kernel.org
Fixes: 583e518e7100 ("scsi: ufs: core: Add hba parameter to trace events")
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260630185412.283c26c5@gandalf.local.home
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
There are several places where printing functions are being passed
parameters that have not been through endian conversion functions. Use
virtio32_to_cpu() to fix the warnings.
Fixes the following warnings from (prototype) sparse:
drivers/scsi/virtio_scsi.c:126:9: warning: incorrect type in argument 7 (different base types)
drivers/scsi/virtio_scsi.c:126:9: expected unsigned int
drivers/scsi/virtio_scsi.c:126:9: got restricted __virtio32 [usertype] sense_len
drivers/scsi/virtio_scsi.c:312:17: warning: incorrect type in argument 2 (different base types)
drivers/scsi/virtio_scsi.c:312:17: expected unsigned int
drivers/scsi/virtio_scsi.c:312:17: got restricted __virtio32 [usertype] reason
drivers/scsi/virtio_scsi.c:412:17: warning: incorrect type in argument 2 (different base types)
drivers/scsi/virtio_scsi.c:412:17: expected unsigned int
drivers/scsi/virtio_scsi.c:412:17: got restricted __virtio32 [usertype] event
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Link: https://patch.msgid.link/20260623132427.838900-1-ben.dooks@codethink.co.uk
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Pull in outstanding commits from 7.2/scsi-queue.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Compare against -EDEADLK, which is what ww_mutex_lock() actually
returns and what every other deadlock check in this file already uses.
Function regulator_lock_two() acquires two regulators via
regulator_lock_nested() -> ww_mutex_lock(). On contention,
ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop
the lock it holds and retry the acquisition in the canonical order.
However, regulator_lock_two() tests the return value against -EDEADLOCK
rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are
the same value, so the comparison happens to be correct and the bug is
invisible. But on MIPS, SPARC, and PowerPC, those two errors have
different values. The test is wrong: a genuine -EDEADLK backoff no
longer matches -EDEADLOCK, so instead of unlocking and retrying, the
code falls into WARN_ON(ret) and returns with only one of the two
regulators locked.
In practice, this is a bug only on MIPS, because the regulator core is
not built or used on the other two platforms.
In general, EDEADLK is preferred over EDEADLOCK for new code.
Fixes: cba6cfdc7c3f ("regulator: core: Avoid lockdep reports when resolving supplies")
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Link: https://patch.msgid.link/20260708235722.2953579-1-ttabi@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
