| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On the MS Surface Pro 11 soc_button_array probing races with the GPIO
driver probing. If soc_button_array wins the race then gpiod_get() returns
EPROBE_DEFER, which should normally take care of retrying later, but
the soc_button_array code deliberately ignores EPROBE_DEFER causing it
to fail its probe() which causes the volume and power buttons to now work.
The ignoring of EPROBE_DEFER is there to deal with a problem specific to
older Bay Trail (BYT) and Cherry Trail (CHT) tablets which often use this
driver. Modify the error handling to only ignore EPROBE_DEFER on BYT and
CHT platforms and propagate EPROBE_DEFER normally on other platforms.
Fixes: bcf059578980 ("Input: soc_button_array - partial revert of support for newer surface devices")
Cc: stable@vger.kernel.org
Reported-by: Sergey Lebedev <lsa.uz@pm.me>
Closes: https://lore.kernel.org/lkml/20260830141355.55898-1-lsa.uz@pm.me/
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Tested-by: Sergey Lebedev <lsa.uz@pm.me>
Link: https://patch.msgid.link/20260909093934.29411-1-johannes.goede@oss.qualcomm.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
The description of commit bfb34eced559 ("mtd: rawnand: qcom: avoid writing
to obsolete register") says this:
"QPIC_EBI2_ECC_BUF_CFG register got obsolete from QPIC V2.0 onwards.
Avoid writing this register if QPIC version is V2.0 or newer."
Although the referenced commit is related to the 'qcom-nandc' driver,
however the hardware supported by the current driver is also based on
QPIC v2.0 so we should avoid writing that register here as well.
Remove the register writing code to avoid undefined behaviour.
Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Md Sadre Alam <md.alam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260909-qpic-snand-avoid-ebi2-reg-write-v1-1-9b1b1466cc75@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On the Acer Aspire Go 15 (AG15-42P), the internal keyboard drops out
~5 seconds after boot on both Linux and Linux-LTS kernels. Keystrokes on
the built-in keyboard stop registering while the trackpad and external
keyboards remain functional.
Testing confirms that booting with the i8042.reset kernel parameter
resolves the issue and keeps the internal keyboard responsive.
Add SERIO_QUIRK_RESET_ALWAYS to i8042_dmi_quirk_table for the Acer
Aspire AG15-42P to automatically apply this quirk on boot.
Signed-off-by: Chris Sommers <chris.sommers@icloud.com>
Link: https://patch.msgid.link/20260907182723.2709981-1-chris.sommers@icloud.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
The Lenovo ThinkPad T440p (PNP ID LEN0036, board id 2722) has a
Synaptics touchpad whose SMBus companion is not ready at boot and
takes roughly 200 seconds to appear. During this window the touchpad
and TrackPoint are completely unresponsive on approximately 50% of
boots, making the machine unusable until the companion finally
registers.
The device is in the topbuttonpad_pnp_ids[] SMBus allowlist, so the
kernel attempts to use SMBus/RMI4 mode by default. When the companion
is not ready, psmouse_smbus_init() leaves breadcrumbs and returns
-EAGAIN, the PS/2 fallback path is taken, but the device does not
function properly until the companion appears and RMI4 takes over.
Disable SMBus InterTouch for board id 2722 so the touchpad and
TrackPoint work immediately via PS/2 from boot. Users can still force
SMBus with psmouse.synaptics_intertouch=1 if needed.
Tested-by: Raphaël Larocque <rlarocque@disroot.org>
Signed-off-by: Raphaël Larocque <rlarocque@disroot.org>
Link: https://patch.msgid.link/20260910164425.12832-1-rlarocque@disroot.org
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
In two places, current code forces vmbus_connection.conn_state to
DISCONNECTED prior to calling vmbus_disconnect(). But vmbus_disconnect()
calls vmbus_initiate_unload(), which unloads the VMBus connection
only if the conn_state is CONNECTED. Consequently, the connection
remains and the Hyper-V host might continue to send messages or post
VMBus interrupts.
The problem was introduced in commit 74347a99e73ae ("x86/Hyper-V:
Unload vmbus channel in hv panic callback"), in that
vmbus_initiate_unload() started checking the current connection
state before doing the unload. This commit removed some occurrences
where conn_state was forced to DISCONNECTED, but these two remained,
apparently due to an oversight at the time.
Fix this by not forcing conn_state to DISCONNECTED during VMBus exit,
or if a failure occurs when establishing the connection in the first
place. Whatever value conn_state has at the time is then read by
vmbus_initiate_unload() to determine if there is a connection to
be unloaded.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-hyperv/20260805205806.B5AC31F000E9@smtp.kernel.org/
Fixes: 74347a99e73ae ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
|
|
The removal of stimer message mode in commit be0cfab740e5 ("clocksource:
hyper-v: Remove support for stimer interrupts in message mode") left a
few comments out of date. hv_stimer_setup_percpu_clockev() picked up two
typos ("afters", "to allows"), and the hv_synic_suspend() comment still
references the deleted hv_stimer_legacy_cleanup(), the legacy non-Direct
Mode configuration, and clockevents_unbind_device(), which is no longer
on the cleanup path.
Update the typos and rewrite the hv_synic_suspend() comment to describe
the current Direct Mode path: non-boot CPU stimers are cleaned up via
the cpuhp teardown callback hv_stimer_cleanup(), and CPU0's stimer is
left alone because it is harmless (interrupts stay disabled across the
suspend/resume window) and is shut down later by the timekeeping code.
Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
|
|
There is a retry loop in init_vp_index() where the CPUs from a certain
node are stripped out if they have already been in the allocated cpumask
or not in HK_TYPE_MANAGED_IRQ housekeeping cpumask. If there is no
CPU left, the allocated cpumask is ignored and the process is retried
again. However, if the HK_TYPE_MANAGED_IRQ housekeeping cpumask turns
out not to contain any CPU in that particular node, that will become an
infinite retry loop. This particular problem was reported by sashiko
[1]. This should rarely happen, but we still need to guard against this.
Fix this infinite loop problem by also skipping NUMA node that has no
housekeeping CPU in the inner while loop of init_vp_index(). Also update
the early abort check to check for the absence of online housekeeping
CPUs instead of just the emptiness of the cpumask. As the outer for
loop will only be reached if the housekeeping cpumask has at least one
online CPU, a NUMA node with housekeeping CPUs will eventually be found.
Link: https://sashiko.dev/#/message/20260422030903.E1BFCC2BCB0%40smtp.kernel.org [1]
Fixes: 6640b5df1a38 ("Drivers: hv: vmbus: Don't assign VMbus channel interrupts to isolated CPUs")
Signed-off-by: Waiman Long <longman@redhat.com>
Reviewed-by: Michael Kelley <mhkelley@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
|
|
dpu_hw_ctl_clear_pending_flush() resets the cached per-block state after a
flush transaction, but misses pending_periph_flush_mask.
The peripheral flush updater accumulates interface bits in this mask. A
later transaction which sets the top-level peripheral flush bit can write
stale interface bits to CTL_PERIPH_FLUSH together with the current state.
Peripheral flush support was added after the helper started clearing every
individual pending flush mask. Clear the peripheral mask together with the
other cached child masks.
Fixes: 64f7b81f0358 ("drm/msm/dpu: add support of new peripheral flush mechanism")
Cc: stable@vger.kernel.org
Signed-off-by: Saim Shujah <saimzst@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/748968/
Link: https://lore.kernel.org/r/20260828065440.140410-1-saimzst@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
msm_dp_display_mode_valid() halves the pixel clock when either YUV420 or
wide bus is in use, then uses that halved value both for the controller
pixel clock limit and for the DP link bandwidth check.
Only YUV420 halves the data crossing the link. Wide bus widens the
internal DPU to DP interface to two pixels per clock, halving the
controller clock. Every pixel is still transmitted, so the link
bandwidth requirement remains.
As a result, modes needing up to twice the available link bandwidth pass
validation. On the IMDT QCS8550 SBC (rev5 with CYPD6125), where DP runs
over USB-C alt mode where only two lanes are available, 3840x2160@60 was
accepted despite needing 9.6 Gbps against the 8.64 Gbps the link can
carry.
Use a separate link pixel clock that is only halved for YUV420 for the
bandwidth calculation, leaving the wide bus halving to apply solely to
the controller pixel clock limit. With this, 4k@60 is correctly rejected
and 4k@30 selected instead.
Fixes: df9cf852ca30 ("drm/msm/dp: account for widebus and yuv420 during mode validation")
Assisted-by: Claude:claude-opus-5
Signed-off-by: William Bright <william.bright@imd-tec.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/746145/
Link: https://lore.kernel.org/r/20260812-msm-dp-link-bw-v1-1-b0e3ce1190be@imd-tec.com
[DB: dropped useless comment]
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
adreno_gpu_init() calls pm_runtime_use_autosuspend(), but
adreno_gpu_cleanup() does not call the matching
pm_runtime_dont_use_autosuspend() during teardown.
If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during teardown, this reference is not dropped and usage_count remains
unbalanced.
The documentation for pm_runtime_use_autosuspend() also notes that it
is important to undo it with pm_runtime_dont_use_autosuspend() at
driver exit time, unless runtime PM was initially enabled with
devm_pm_runtime_enable().
Add the missing pm_runtime_dont_use_autosuspend() call to
adreno_gpu_cleanup().
This issue was found by manual code inspection.
Fixes: eeb754746b14 ("drm/msm/gpu: use pm-runtime")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/745110/
Link: https://lore.kernel.org/r/20260808131624.2854412-1-lgs201920130244@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
msm_dp_display_atomic_enable() returns early when link training fails,
leaving ->power_on false and the main link down.
msm_dp_display_atomic_disable() nevertheless writes DP_STATE_CTRL_PUSH_IDLE
and waits for an idle-pattern completion that cannot arrive, so every failed
enable is followed by "PUSH_IDLE pattern timedout".
Every other step of the teardown is already gated on that flag:
msm_dp_display_disable(), called from .atomic_post_disable(), returns early
on !power_on. The PUSH_IDLE write is the only one that is not, so the
controller's runtime-PM reference is then dropped without the link having
been taken down.
On glymur (Snapdragon X2 Elite) the consequence is not a warning. The SoC
does not survive it: TrustZone force-stops the SOCCP and ADSP remote
processors and the machine resets silently about 50 ms later, with no oops
and no panic. On an ASUS Zenbook A16 (UX3607OA), whose eDP panel does not
currently train, this reproduces without any compositor or GPU involvement:
# eDP enable has already failed with "Failed link training (rc=-104)"
echo 1 > /sys/class/graphics/fb0/blank
[535.645455] === marker ===
[535.694833] qcom_q6v5_pas d00000.remoteproc: fatal error received: \
sys_m_smsm.c:512:TZ force stop
[535.694875] remoteproc remoteproc0: crash detected in soccp: type fatal error
[535.728857] qcom_q6v5_pas 6800000.remoteproc: fatal error received: \
sys_m_smsm.c:783:err fatal notification received from TZ
<SoC reset>
Gate the PUSH_IDLE write on ->power_on so the disable path is consistent
with the rest of the teardown. With this applied the same sequence is
harmless and the machine stays up; without it, it resets every time.
The unconditional write dates back to the original DP driver
(c943b4948b58 ("drm/msm/dp: add displayPort driver support")), but the
surrounding code has been restructured several times since, so no Fixes:
tag is offered.
Note that the eDP link-training failure that exposes this on the A16 is a
separate problem in the glymur eDP PHY and is reported separately; this
change is about not damaging the machine when training fails, for whatever
reason.
Tested on ASUS Zenbook A16 (UX3607OA), Snapdragon X2 Elite Extreme, on
linux-next next-20260803 and next-20260807. The machine has since been
running next-20260807 with this patch as its daily driver.
Assisted-by: Anthropic:Claude-Opus-5
Signed-off-by: Jesse Casco <jesse.casco@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/745167/
Link: https://lore.kernel.org/r/20260808171325.133041-1-jesse.casco@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
msm_fbdev_driver_fbdev_probe() points screen_buffer at a kernel virtual
mapping of the GEM object and uses the deferred sysmem fb ops, but never
sets FBINFO_VIRTFB. The framebuffer core then assumes the memory is not
in the virtual address space and warns on the first console draw:
fb0: sys_fillrect: framebuffer is not in virtual address space.
The drm_fbdev_dma, drm_fbdev_shmem and drm_fbdev_ttm helpers all set the
flag for system memory. Do the same here.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Assisted-by: Claude:claude-opus-5
Patchwork: https://patchwork.freedesktop.org/patch/743293/
Link: https://lore.kernel.org/r/20260730-drm-msm-fbinfo-virt-v1-1-a27099a6dc58@oss.qualcomm.com
Acked-by: Rob Clark <robin.clark@oss.qualcomm.com> # on IRC
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Since commit c6b1b34b5090 ("media: pci: intel: Add CVS support for IPU
bridge driver") the internal camera no longer works on laptops where the
sensor sits behind an IVSC, for example a Dell XPS 16 9640 (IPU6,
INTC10CF, ov02c10):
intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00
intel-ipu6 0000:00:05.0: Connected 1 cameras
ivsc_csi intel_vsc-92335fcf-3203-4472-af93-7b4453ac29da: mei-csi probed
without device fwnode!
No sensor subdevice is registered, the media graph has no sensor entity
and userspace finds no camera at all.
ipu_bridge_get_ivsc_csi_dev() first looks for the platform device named
"intel_vsc" and returns its mei-csi child. That device is created by
mei_vsc, which on this machine only appears once the LJCA USB bridge and
its SPI controller have probed, about a second after the IPU6 probe that
runs the bridge:
07:59:29.297 platform INTC10CF:00 created (ACPI scan)
07:59:41 intel-ipu6 probe -> ipu_bridge_init()
07:59:42.391 platform intel_vsc created (mei_vsc)
The commit above added two fallbacks for CVS which match on the ACPI
companion alone. They are reached for every entry of ivsc_acpi_ids[],
IVSC IDs included. The IVSC ACPI device has two physical nodes:
INTC10CF:00/physical_node -> platform/INTC10CF:00 (no driver bound)
INTC10CF:00/physical_node1 -> platform/intel_vsc (mei_vsc)
so bus_find_device_by_acpi_dev(&platform_bus_type, adev) returns the bare
platform device. ipu_bridge_instantiate_ivsc() then attaches the IVSC
software node to that device instead of to the mei-csi client, the bridge
reports success, and the probe is never retried. mei_csi later probes
without a fwnode, the CSI-2 link is never described, and the sensor ACPI
device, which has an honoured _DEP on the IVSC device, is never
enumerated.
Before those fallbacks existed the lookup returned NULL here, the bridge
failed with -ENODEV and the probe was retried once the IVSC device had
shown up.
Skip those fallbacks for IVSC devices, keying on the IVSC IDs rather than
the CVS ones: new CVS IDs keep being added, whereas the IVSC list is
complete. CVS binds a driver to the ACPI device itself, so matching on the
companion stays unambiguous there.
Fixes: c6b1b34b5090 ("media: pci: intel: Add CVS support for IPU bridge driver")
Link: https://lore.kernel.org/linux-media/20260901194526.6369-1-gvozdoder@gmail.com/
Cc: stable@vger.kernel.org
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Sergey Zagursky <gvozdoder@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Some laptops carry a MediaTek power table in their firmware, and the
driver reads it to set a transmit limit for each frequency range. It
only fills in the ranges themselves when it registers the device.
The startup step that does this existed already, but it never programmed
anything. Two recent commits made it run a regulatory update instead,
which sets the limits on the way through, long before registration.
As a result, on a machine that has the table the driver reads through an
empty pointer and the interface never appears:
BUG: kernel NULL pointer dereference, address: 0000000000000004
RIP: 0010:mt792x_init_acpi_sar_power
Call Trace:
mt7921_set_tx_sar_pwr
mt7921_mcu_regd_update
mt7921_regd_update
mt7921_run_firmware
mt7921e_mcu_init
mt7921_init_work
Skip it when the ranges are missing. They are applied again once the
device is up, which is where they came from before.
Reported-by: Klara Modin <klarasmodin@gmail.com>
Closes: https://lore.kernel.org/linux-wireless/aoyxqHYvSuaBeubf@soda.int.kasm.eu/
Fixes: 9b80bd9cab40 ("wifi: mt76: mt7921: add regulatory wiphy self manager support")
Fixes: e9f3f1cc133f ("wifi: mt76: mt7925: add regulatory wiphy self manager support")
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Tested-by: David Gow <david@davidgow.net>
Tested-by: Klara Modin <klarasmodin@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Treat an out-of-range CLC index as newer firmware rather than a
malformed image. linux-firmware 20260810 ships MT7922 records with
idx 3, and rejecting them made mt7921e fail to probe.
Keep the record-length checks, and report those as errors so a
truncated table is visible instead of a silent retry loop.
Fixes: 9417c5818a01 ("wifi: mt76: mt7921: validate CLC firmware records")
Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com>
Reviewed-by: Junjie Cao <junjie.cao@intel.com>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Pull Rust fixes from Miguel Ojeda:
"Toolchain and infrastructure:
- Work around a 'bindgen' 0.73.2 bug that emits an 'allow' attribute
for 'unnecessary_transmutes', which is unknown in older compilers
- Clean 'clippy::as_underscore' lints in generated code by the new
'bindgen' 0.73.0+ releases
- Clean new 'clippy::needless_range_loop' lint for the upcoming Rust
1.100.0 (expected 2026-11-12)
'kernel' crate:
- 'num' module: fix soundness issue in 'Bounded' by sealing the
'Integer' trait
'pin-init' crate:
- Fix unreachable warning for the upcoming Rust 1.100.0 (expected
2026-11-12) due to 'Infallible' becoming an alias of '!'
Samples:
- Add missing newlines in 'pr_*!'s macro calls"
* tag 'rust-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
rust: allow `unknown_lints` in generated bindings for Rust < 1.88
rust: allow `clippy::as_underscore` in the generated bindings
rust: num: seal Integer
drm/panic: clean new `clippy::needless_range_loop` lint for Rust 1.100.0
rust: samples: add missing newlines in rust_print_main
rust: pin-init: use irrefutable pattern for `stack_pin_init`
|
|
Pull irq fix from Ingo Molnar:
- Fix ARM gic-v5 irqchip driver regression, where its
enable/disable functions may corrupt unrelated
ICC_CR0_EL1 hardware state (Sascha Bischoff)
* tag 'irq-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/gic-v5: Preserve ICC_CR0_EL1 state
|
|
The comment in the mtk_phy_tmds_clk_ratio() function clearly and
correctly explains that the TMDS ratio has to be 1/10 for data
rates under 3.4Gbps, and 1/40 over that.
Unfortunately though, the TXC_DIV register setting was wrong, as
in value 3 means to divide by 8 and, in order to achieve the in
spec 1/40 (tmds) data rate, this has to divide by 4 instead!
Add definitions for the TXC_DIV register values clearly explaining
the meanings (DIV2, DIV4, DIV8), and program the correct, DIV 4,
value to the register in mtk_phy_tmds_clk_ratio().
This fixes out of spec clocking and, with this change, SoCs using
the MT8195 class HDMI PHYs can now successfully be configured to
output 3840x2160@60Hz over HDMI.
Fixes: 45810d486bb4 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20260911074015.9994-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
When trying to calculate a PLL rate for target display resolutions
above 2560x1440, 24bpp, 30Hz, the pixel clock value will be more
than 32-bits long but the division to finally calculate the digital
clock divider is being done with div_u64(), which expects a 32bit
unsigned divisor.
Fix the overflow by using div64_u64() instead.
Fixes: 9d9ff3d2a4a5 ("phy: mediatek: hdmi: mt8195: fix wrong pll calculus")
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20260911074015.9994-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The OTG PHY initialization sequence needs to wait for 20 ms at a specific
step, as described in commit 72c0339c115b ("phy: renesas:
rcar-gen3-usb2: follow the hardware manual procedure").
Commit 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware
registers and driver data") tried to address various problems in the
rcar-gen3-usb2 driver and converted the mutex protecting HW register
accesses to a spin lock, leaving, however, a long delay in the critical
section protected by the spin lock. This may become a problem,
especially on RT kernels.
To address this, release the spin lock before sleeping for 20 ms as
required by the HW manual and reacquire it afterwards. To avoid other
threads entering the critical section and configuring the HW while the
software is waiting for the OTG initialization to complete, introduce the
otg_initializing variable alongside the otg_init_done wait queue. Any
other thread trying to configure the HW while the OTG PHY initialization
is in progress waits for the wait queue instead of immediately returning
errors to PHY users. The IRQs were also disabled while waiting for the OTG
PHY initialization to complete, as the interrupt handler may also apply HW
settings.
The OTG can only be initialized once. It is initialized by the first PHY
that calls struct phy_ops::rcar_gen3_phy_usb2_init().
To avoid failures when multiple PHYs call struct
phy_ops::rcar_gen3_phy_usb2_init() simultaneously, and the PHY responsible
for initializing the OTG either fails or deinit quiqly and another PHY
takes over the PHY init role), the code waiting for the
channel->otg_init_done wait queue retries up to NUM_OF_PHYS times.
Fixes: 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver data")
Cc: stable@vger.kernel.org
Reported-by: Pavel Machek <pavel@nabladev.com>
Closes: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz
Reported-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Closes: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz
Link: https://patch.msgid.link/20260716183246.3183877-1-claudiu.beznea+renesas@tuxon.dev
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Pull EDAC fix from Borislav Petkov:
- A single fix to altera_edac to use the proper objects when performing
managed device operations instead of using temporary shallow struct
copies which can cause dangling list pointers and havoc eventually
* tag 'edac_urgent_for_v7.3_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
EDAC/altera: Use parent device for devres in altr_portb_setup()
|
|
We were using 10ms, kgsl uses 100ms. In practice it is usually takes
less than 10ms, but very occasionally goes a bit above 10ms, leading to
a "GMU firmware inialization timed out", from which point things go
south.
There are probably some things that could be done to speed up init, like
increasing GMU freq. But to be safe, increase the timeout to match
kgsl.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/753014/
Message-ID: <20260912150915.28700-1-robin.clark@oss.qualcomm.com>
|
|
Pull fbdev fixes from Helge Deller:
"Two patches for VT core code and fbcon prevent potential out-of-bounds
reads on font or screen size changes, one fix limits the Superblitter
in atafb to supported modes only, and some minor fixes for vfb,
ssd1307fb and omapfb"
* tag 'fbdev-for-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev:
fbdev: vfb: defer cleanup until the last reference
fbdev: atafb: Restrict SuperBlitter to supported formats
fbdev: ssd1307fb: fix NULL pointer dereference on missing match data
fbcon: Fix KASAN slab-out-of-bounds Read in fbcon_prepare_logo
fbdev: omapfb: Fix __be32 sparse warning in panel_enabled()
vt: hide cursor prior to font changes to avoid out-of-bound reads
|
|
Pull IOMMU fixes from Joerg Roedel:
"RISC-V:
- Serialize command queue publication to prevent concurrent producers
from exposing incomplete or out-of-order commands to hardware
- Wait for queue space outside the command queue lock
- Avoid waiting for IOFENCE completion when command enqueue failed
AMD:
- Prevent GA log buffers from being reallocated and leaked during
resume, where allocation also occurs in an unsuitable syscore
callback context
- Fix a regression on older systems whose firmware advertises
incorrect IOMMU features
- Preserve allocation errors when assigning host domain IDs to nested
domains
s390:
- Prevent a NULL dereference when translating an unmapped IOVA with
five-level ZPCI translation tables
Misc:
- Remove a stale MAINTAINERS entry and clean up unused or redundant
AMD IOMMU declarations, macros, and checks"
* tag 'iommu-fixes-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux:
iommu/amd: Remove unused macro
iommu/amd: Remove redundant checks from interrupt handler path
iommu/amd: Remove redundant check in irq_remapping_select()
iommu/amd: Make iommu_sva_set_dev_pasid as static
MAINTAINERS: Drop the nonexistent vsi-iommu.h file entry
iommu/amd: Fix ineffective error check in nested domain allocation
iommu/amd: Fix premature break in init_iommu_one() again
iommu/amd: Do not reallocate GA log buffers on resume
iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX
iommu/riscv: Avoid waiting on failed command enqueue
iommu/riscv: Serialize command queue publishing
iommu/riscv: Add command queue lock
|
|
The plane property loop uses req->properties[num_properties + i] as write
index while simultaneously incrementing `num_properties` inside the loop.
At iteration i, num_properties has also incremented by i, so the write
is done at `initial_num_properties + 2*i`, skipping every other index and
advancing by 2 per iteration.
With just 2 connector and 32 plane properties the last write happens at
index 64, one slot past the end of the 64-slot (indices 0–63)
allocation. A USB device can trigger OOB by advertising the maximum
number of properties.
Fix by dropping the redundant `+ i`; num_properties is already the correct
running index, as gud_connector_fill_properties() fills the preceding
slots.
Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260821071812.16500-1-sajal2005gupta%40gmail.com?part=1
Signed-off-by: Sajal Gupta <sajal2005gupta@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: Ruben Wauters <rubenru09@aol.com>
Signed-off-by: Ruben Wauters <rubenru09@aol.com>
Link: https://patch.msgid.link/20260902123254.36987-1-sajal2005gupta@gmail.com
|
|
When running in full update mode, previously small updates (such as
moving the mouse across the screen) would cause many full frames to be
generated. This would bog down the bus and lower the effective framerate
significantly - I was seeing a drop from 60 FPS to 2 FPS.
Set ignore_damage_clips in full update mode so the damage iterator
yields a single full-plane rectangle instead of one per clip.
Fixes: 73cfd166e045 ("drm/gud: Replace simple display pipe with DRM atomic helpers")
Cc: <stable@vger.kernel.org> # 6.18.x
Signed-off-by: Sophie D <patches@scd31.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Ruben Wauters <rubenru09@aol.com>
Signed-off-by: Ruben Wauters <rubenru09@aol.com>
Link: https://patch.msgid.link/20260910014910.8564-1-patches@scd31.com
|
|
Trying to resolve them by DT index causes massive havoc on OMAP3, Clocks
around the timers used as a system clocksource are not properly resolved
causing ealy boot failures. The problem seems to be that parents must be
resolved by looking into the clocks property of the component node marked
with "ti,composite-mux-clock", with the switch to dt index, that node
was not used anymore. It was used by the of_clk_parent_fill() call.
To a lesser extent also OMAP4/5 boards are affected.
Since this patch was introduced just because of a cleanup request
and not to solve the actual problem
(https://lore.kernel.org/linux-omap/alkZmw-XmnCOZfOD@redhat.com/)
just revert it. Cleanup needs really more thought here.
The similar change to the TI mux clock, which solves a problem on the AM3
platform, seems to be harmless.
So just revert
commit fe3dd92ac54a ("clk: ti: composite: resolve parent clocks by DT index, not by name")
for now.
Fixes: fe3dd92ac54a ("clk: ti: composite: resolve parent clocks by DT index, not by name")
Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
Pull regulator fixes from Mark Brown:
"One fix for pf1550 which checked for errors on multiple regulators
but always notified via one of them regardless of which one had the
problem, plus one device ID addition in the fan53555 DT bindings"
* tag 'regulator-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: pf1550: fix which regulator is notified
regulator: dt-bindings: fan53555: add tcs,tcs4526
|
|
Pull drm fixes from Dave Airlie:
"Weekly fixes pull, this seems relatively quiet for the new world,
scattered fixes, mostly amdgpu leading the way, but lots of minor
fixes in other drivers.
drm_exec:
- fix 0 object handling
sched:
- null ptr deref fix in kunit tests
amdgpu:
- Freesync fix
- GPUVM fix
- Debugfs fixes
- HDMI fixes
- IPS fix
- GPU reset fix
- RGB quantization fixes
- SMU 13.0.x fixes
xe:
- runtime PM guard fix
- cache flushing fix
i915:
- Fix a memleak on perf config query error path
- Fix UHBR SST SDP splitting when sink doesn't support it
bridge:
- fix ti-sn65dsi83 error handling
- tc358768: Enforce input bus flags via atomic_check
ast:
- fix blend mode property on cursor plane
qxl:
- fix blend mode property on primary/cursor planes
virtio:
- fix blend mode property on cursor plane
vboxvideo:
- fix blend mode property on planes
rockchip:
- fix endpoint name length
- fix Kconfig issues
ivpu:
- limit firmware log prints to field size
- validate buffer range in ivpu address translation
- validate fw log buffers
ethosu:
- ensure SRAM sizing
- ensure cmd stream formatting
- drop IRQF_SHARED
- fix open return value
adp:
- fix Kconfig
logicvc:
- fix Kconfig"
* tag 'drm-fixes-2026-09-12' of https://gitlab.freedesktop.org/drm/kernel: (38 commits)
drm/amd/pm: report energy accumulator for smu 13.0.0
drm/amd/pm: fix gpu metrics energy accumulator for smu 13.0.0/13.0.7
drm/amd/display: Rebuild InfoFrames on output color space changes
drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output
drm/amd/display: Propagate HDMI RGB quantization selectability
Revert "drm/amdgpu: debugfs: avoid extra EOLs in amdgpu_gem_info"
drm/amdgpu: skip gfx switch_power_profile during GPU reset
drm/amd/display: Fix HF-VSDB DSC bpc detection to be cumulative
drm/amd/display: Exit IPS before connector detection on resume
drm/amd/display: Shorten hdmi_frl_status_polling_workqueue
dm/amdgpu: fix malformed link_settings debugfs output
drm/amdgpu: skip the VMID 0 flush for VRAM
drm/amd/display: Consult MCCS FreeSync cap only if requested & supported
drm/i915: Fix memory leak in query_perf_config_list()
drm/i915/dp: Gate UHBR SST SDP splitting on sink capability
drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches
drm/xe: Guard page-fault worker with runtime PM check
drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()
drm/bridge: tc358768: Enforce input bus flags via atomic_check
drm/drm_exec: fix up contended obj when num_objects is 0
...
|
|
Pull RISC-V fixes from Paul Walmsley:
"From a RISC-V point of view, there's one notable fix here, reverting
an earlier bogus fix to the pointer masking code. Fortunately the
practical impact appears to be small.
- Revert a bad fix, likely LLM-generated, in the pointer masking code
that confused the RISC-V hardware pointer masking implementation
with the Linux kernel tagged address feature
- Fix unexpected faults caused by kprobe instruction slot writes when
!CONFIG_STRICT_MODULE_RWX
- Fix unexpected faults on minimal configurations during runtime code
patching on !CONFIG_STRICT_MODULE_RWX systems
- Fix a misplaced variable clear causing incorrect reuse of previous
values in the RISC-V hardware feature probing code
- Fix two bugs in the PMU SBI perf code on rv32: use BIT_ULL rather
than BIT on 64-bit masks; and use a bitmap rather than an unsigned
long on a quantity that can exceed 32 bits
And a few miscellaneous cleanups:
- Avoid a potential dereference-before-NULL-pointer-check bug in the
PMU SBI perf driver
- Use CONFIG_GENERIC_BUG_RELATIVE_POINTERS to simplify the rv32 bug
table code (like x86 and PPC)
- Report the RISC-V standard ISA extensions Z[v]fhmin when support is
claimed for the superset RISC-V standard ISA extensions Z[v]fh; and
simplify our FPU test code to only check for the presence of the D
extension
- Use an existing kernel string helper in place of some open-coded
code in kernel/usercfi.c
- Fix some yamllint issues in the RISC-V DT bindings for CPUs
- Convert one use of __ASSEMBLY__ to __ASSEMBLER__ that snuck into
the RISC-V CFI selftest code
- Update the translation for the simplified Chinese translation of
the RISC-V kernel patch acceptance policy"
* tag 'riscv-for-linus-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: skip software algning code for HAVE_EFFICIENT_UNALIGNED_ACCESS
kselftest/riscv: Replace __ASSEMBLY__ with __ASSEMBLER__
docs/zh_CN: Update arch/riscv/patch-acceptance.rst translation
dt-bindings: riscv: cpus: Fix yamllint style issues
riscv: hwprobe: simplify has_fpu() to check D extension only
perf: RISC-V: check cpu_hw_evt before dereference in overflow IRQ
riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present
perf: RISC-V: store available counter mask as bitmap
perf: RISC-V: use BIT_ULL for u64 overflow masks
riscv: bug: Make RV32 use GENERIC_BUG_RELATIVE_POINTERS
riscv: hwprobe: initialize pair->value in hwprobe_one_pair()
riscv: use string helper in setup_global_riscv_enable()
Revert "riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set"
riscv: patch: skip fixmap mapping when kernel text is already writable
riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX
|
|
Pull x86 platform driver fixes from Ilpo Järvinen:
- amd/pmf: Fix build on !CONFIG_AMD_PMF_DEBUG
- asus-laptop: Fix ACPI event handling
- hp-wmi: Fix board_params typo for 8DD6 board
- x86-android-tablets: Fix Arizona and Crystal Cove GPIO lookups
* tag 'platform-drivers-x86-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
MAINTAINERS: fix sysfs-platform-ayaneo-ec documentation path
platform/x86: x86-android-tablets: fix gpio_secondary_fwnode_init() not working
platform/x86: x86-android-tablets: use shared battery swnode group on Yoga Tab 2
platform/x86: x86-android-tablets: drop redundant swnode group on YT3
platform/x86: x86-android-tablets: add Crystal Cove GPIO swnode support
platform/x86: x86-android-tablets: pass node group to gpio_secondary_fwnode_init()
platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown
platform/x86: x86-android-tablets: fix Arizona GPIO swnode references
platform/x86/amd/pmf: fix build on !CONFIG_AMD_PMF_DEBUG
platform/x86: asus-laptop: Fix ACPI event handling
platform/x86: hp-wmi: Fix board_params typo for 8DD6 board
|
|
Pull block fixes from Jens Axboe:
- Fix the start and length check added to iov_iter_extract_bvecs(),
which used iter_iov_addr()/iter_iov_len() helpers that aren't safe
for the ITER_BVEC/FOLIOQ/etc iterator types passed
- sunvdc fixes for an -EIO issue from lack of retries, and unmapping
LDC cookies when the descriptor send fails
- Clear force_abort in ublk_queue_reset_io_flags()
- ublk selftest install fix
* tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
selftests: ublk: add batch IO cases to recover_03
ublk: clear force_abort in ublk_queue_reset_io_flags()
sunvdc: fix -EIO issue due to lack of retries
sunvdc: unmap LDC cookies when the descriptor send fails
block: Fix start and length check added to iov_iter_extract_bvecs()
selftests: ublk: install test_common.sh and trace/ scripts
|
|
The a750 uses the GMU CX AO Counters instead of the GMU_ALWAYS_ON_COUNTER
register on A6xx and other A7xx GPUs, use it when running a A750 GPU.
The GMU_ALWAYS_ON_COUNTER at offset 0x1f888 doesn't seem to exist
on the SM8650 A750 GMU and returns 0, but the CX AO counter at offset
0x1f880 returns some proper timestamp data.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/752235/
Message-ID: <20260909-topic-sm8650-gmu-a750-timestamp-reg-v2-2-091d74958951@linaro.org>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
The a750 uses the CX AO Counters instead of the GMU_ALWAYS_ON_COUNTER
register on A6xx and other A7xx GPUs.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/752234/
Message-ID: <20260909-topic-sm8650-gmu-a750-timestamp-reg-v2-1-091d74958951@linaro.org>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
The adreno_perfcntrs macro already takes the XML file stem as its second
argument, allowing each perf counter JSON file to select the appropriate
register XML. The a2xx and a5xx entries already pass their respective
XML file stems.
Remove the stale TODO comment.
Signed-off-by: George Emmanuel Thomas <georgeemmanuelthomas@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/746745/
Message-ID: <20260815164335.158958-1-georgeemmanuelthomas@gmail.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
As it turns out, Turing isn't the only architecture that needs this. On
this Dell Precision 7780 with an AD103 GPU, along with pretty much every
other laptop I tested, runtime PM is still somewhat unreliable. At first
glance it seems as if it's fixed, but lowering the autosuspend delay to
500ms and then doing a stress test of suspend/resume cycles on the GPU ends
up causing everything to start timing out.
After quite a lot of digging, I eventually landed back on this magic
timeout in r535_gsp_fini(). As it turns out, increasing the timeout ends up
fixing the runtime PM issues as far as I can tell, even during intense
stress testing.
Unfortunately after spending quite a bit of time trying to dig through
OpenRM to figure out what this magic sleep is actually doing, I've also
come up short with any reasonable explanation. In lieu of that, I'm going
to include the observations I did make while trying to figure this out in
hopes someone eventually does figure this out:
* The magic sleep has to occur after fbsr is initialized. Performing it at
any time before that doesn't appear to work.
* In situations where runtime PM starts getting flaky, some rather
interesting visual effects end up happening on occasion before the GPU
fully falls over. In particular, squares that look like the result of an
incomplete blitting operation to a tiled buffer end up showing up on
applications like vkcube. Interestingly enough, they remain in precisely
the same place between runtime PM cycles until the GPU falls over - even
when restarting vkcube multiple times, and even when vkcube is actively
updating the screen. Even more interestingly, they're not limited to a
specific framebuffer - you can see the squares changing as the cube
rotates around.
We cannot however, say that this is likely to be a incomplete fbsr
operation. The magic sleep happens before fbsr is actually saved (which
happens on the GSP unload), so it's something else.
* During a short bit of testing with a desktop that I have, the magic sleep
seemed to make no difference to whether or not suspend/resume works. It
seems to generally work almost always. So we can assume this is likely
exclusive to runtime PM, not S3.
As well, here's a list of the things I tried before settling on the magic
sleep:
* Hooking up NV2080_CTRL_CMD_INTERNAL_GCX_ENTRY_PREREQUISITE and then
blocking runtime PM until OpenRM signals that GC6/GCOFF is ready appears
to make no difference.
* Hooking up some (maybe not all, unsure about that part) bits of comptag
saving including:
* Fetching static memsys information from GSP
* Adding the size of the comptag storage to the fbsr data
* Adding a GA103+ workaround for disabling raw compression mode during
fbsr (it doesn't seem like it applies for any systems I tried it on
anyhow)
* Setting bPreserveVideoMemoryAllocations=1 in GspSystemInfo
So, until we can figure this out properly - just sleep for longer.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144")
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-5-lyude@redhat.com
(cherry picked from commit 09b47186a4164f3aaa3591313f80794443117342)
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
There's two flags that we've never been setting when asking GSP to suspend
the GPU, which OpenRM does set:
GPU_STATE_FLAGS_PRESERVING
GPU_STATE_FLAGS_PM_TRANSITION
These flags aren't -supposed- to do much in GSP, they're mostly used by
OpenRM itself for state tracking. The only thing they do from GSP's side is
control whether or not a single display related workaround is applied
during suspend.
But as it turns out, that single workaround is actually quite crucial for
getting runtime PM working with nouveau - and without it set we end up
seeing a lot more failures with runtime PM resume. So, let's start setting
it.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144")
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-4-lyude@redhat.com
(cherry picked from commit ca57629b3eb912c77bc4357178a2130ea6c2d6df)
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
Previously, it looked as if we were able to fix suspend/resume on some
desktops by setting Gcoff based on whether or not we were entering runtime
PM. This was a mistake though - the only time suspend/resume would end up
actually working was if Gcoff = 0.
It seems like it's likely the main reason for this is the FBSR GcOff
argument actually controls GSP's behavior with regards to which buffers it
decides to save across suspend/resume. When GcOff = 1, RM reserved regions
are saved unless they are marked as LOST_ON_SUSPEND, and RM channel-context
and kernel-client buffers are also saved -including- when they are
LOST_ON_SUSPEND. This means with GcOff = 1, we end up having GSP save and
restore buffers that actually need to be reinitialized on resume - causing
the failures we're setting.
Thanks to John Hubbard from Nvidia for providing some background on what
these options do in the GSP firmware do!
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144")
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-3-lyude@redhat.com
(cherry picked from commit c7abe771e013848970421e5ca29c6b2f05c31965)
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
This reverts commit 8302d0afeaec0bc57d951dd085e0cffe997d4d18.
It turns out this looked like the right fix on some systems, but it's not -
as this causes runtime PM to actually fail on many a laptop.
Fixes: 8302d0afeaec ("nouveau/gsp: fix suspend/resume regression on r570 firmware")
Cc: <stable@vger.kernel.org> # v6.19+
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-2-lyude@redhat.com
(cherry picked from commit 94097122bfd701976bc1a62ccd434c13f3f67cde)
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
The M-XGL20DLBK is matched as a USB device by hid-elecom, but
its entry in hid_have_special_driver[] uses HID_BLUETOOTH_DEVICE.
This prevents the special-driver quirk entry from matching the USB
device handled by hid-elecom. Use HID_USB_DEVICE there as well.
Fixes: 55633e681afb ("HID: elecom: add support for EX-G M-XGL20DLBK wireless mouse")
Signed-off-by: Oscar Priego Verdugo <oscar.priegov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Pull media fixes from Mauro Carvalho Chehab:
"Core:
- add bounded tile-count helpers for HEVC stateless decoders
- validate AV1 tile counts fits in array size
- validate HEVC tile counts fits in array size
- fix memcmp() size in B1 reference list comparison
mediatek:
- bound AV1 tile-start copy to fit in array size
rockchip:
- reject AV1 frames exceeding the tile size
- guard VPU981 AV1 divisor and tile buffer
hantro and rkvdec:
- bound G2 HEVC tile loops and PPS id to the buffer size
rppx1:
- read the raw pattern from the PRE2 acquisition module
- describe the MAIN_POST white balance gains block"
* tag 'media/v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
media: mediatek: vcodec: bound AV1 tile-start copy to the array capacity
media: verisilicon: rockchip: reject AV1 frames exceeding the tile capacity
media: verisilicon: rockchip: guard VPU981 AV1 divisor and tile buffer
media: verisilicon: hantro: bound G2 HEVC tile loop to the buffer capacity
media: rkvdec: bound HEVC tile loops and PPS id to the array capacity
media: hevc: add bounded tile-count helpers
media: v4l2-ctrls: validate AV1 tile counts
media: v4l2-ctrls: validate HEVC tile counts
media: v4l2-h264: Fix memcmp() size in B1 reference list comparison
media: rppx1: bls: read the raw pattern from the PRE2 acquisition module
media: rppx1: describe the MAIN_POST white balance gains block
|
|
The 2025 revision of the left-handed EX-G wireless trackball
(M-XT4DRBK-G) reports USB ID 056e:018e instead of 056e:00fd. Its report
descriptor declares an 8-bit button field (Report Count 8) but only five
usages (Usage Maximum 5), so the sixth (Fn) button ends up as a
duplicate of button 5 and is unusable.
The report descriptor has the same layout as the M-XT3DRBK 018C
(button usage maximum at offset 16, button report count at 22, button
report size at 24, padding report size at 30), so reuse that fixup.
Rename the existing M_XT4DRBK define to M_XT4DRBK_00FD to match the
convention used for the other EX-G revisions.
Tested on a Raspberry Pi 5 with the same fixup in an
out-of-tree module on 6.12 (6.12.96+rpt-rpi-2712);
all six buttons are reported after the fix, and they
work (tested with xev as well).
Report descriptor as sent by the device, pre-fix (056e:018e,
215 bytes):
05 01 09 02 A1 01 09 01 A1 00 85 01 05 09 19 01
29 05 15 00 25 01 95 08 75 01 81 02 95 01 75 00
81 01 05 01 09 30 09 31 16 00 80 26 FF 7F 75 10
95 02 81 06 C0 A1 00 05 01 09 38 15 81 25 7F 75
08 95 01 81 06 C0 A1 00 05 0C 0A 38 02 95 01 75
08 15 81 25 7F 81 06 C0 C0 06 01 FF 09 00 A1 01
85 02 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0
05 0C 09 01 A1 01 85 05 15 00 26 3C 02 19 00 2A
3C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85
03 19 81 29 83 15 00 25 01 95 03 75 01 81 02 95
01 75 05 81 01 C0 06 BC FF 09 88 A1 01 85 04 95
01 75 08 15 00 26 FF 00 19 00 2A FF 00 81 00 C0
06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00
75 08 95 07 B1 02 C0
Assisted-by: LLM
Signed-off-by: Berke Durak <berke.durak@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The size was incorrectly stated as 4 bytes since the ID was missed out.
Add the ID in and correct the indices for the firmware versions.
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
I have recently acquired a cheap Apollo Lake-based laptop that uses a
Hynitron CST128-A touchpad controller. While booting from a Debian LiveCD,
the kernel log is flooded with the following error (though the touchpad
works well):
i2c_hid_acpi i2c-ALPS0001:00: i2c_hid_get_input: incomplete report (27/42405)
The CST128-A was identified via ACPI as ALPS0001:00, and the I2C HID
device ID (0911:5288) was shared with the Hantick 5288.
Add the I2C_HID_QUIRK_BAD_INPUT_SIZE quirk option to the existing Hantick
5288 quirk entry to suppress the kernel log flood.
Signed-off-by: Youth Cao <cocoh2os08@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
oxp_hid_remove() uses cancel_delayed_work() for all three delayed work
items. cancel_delayed_work() only dequeues a pending work item without
waiting for a currently executing callback to finish. If any of the
work callbacks (oxp_rgb_queue_fn, oxp_btn_queue_fn, oxp_mcu_init_fn) is
running at the time of removal, the callback continues executing
concurrently with hid_hw_close() and hid_hw_stop(), accessing the HID
device after it has been closed and stopped.
Use cancel_delayed_work_sync() instead to ensure that any in-progress
work callback completes before device teardown proceeds.
Fixes: 84910c459d65 ("HID: hid-oxp: Add OneXPlayer configuration driver")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>
Link: https://lore.kernel.org/r/20260804-oxp-fix-v2-1-b2d56e4c8a2c@cherr.cc
Link: https://lore.kernel.org/r/20260804-oxp-fix-v1-1-51a4fe787167@cherr.cc
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The ITE controller behind the keyboard of the Lenovo Yoga Slim 7x Gen 11
(048d:83db) carries out a reset but never raises the interrupt that
acknowledges it. i2c_hid_finish_hwreset() therefore waits out its full
one second timeout and logs "device did not ack reset within 1000 ms" on
every probe and every resume, before the keyboard comes up regardless.
Set I2C_HID_QUIRK_NO_IRQ_AFTER_RESET for it, as is already done for
several other ITE parts, so the reset is followed by a fixed 100 ms sleep
instead.
Signed-off-by: Oleg Keri <okerixx@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Extend critical section in roccat_connect() to ensure that partially
initialized 'struct roccat_device' is never exposed in 'devices' list,
and do the same in roccat_disconnect() to avoid racy 'devices' access
against roccat_release().
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Remove unsed device range capability related macros.
No functional changes.
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
|
|
PPR and GAlog interrupt is enabled only if buffer is allocated.
(See amd_iommu_enable_ppr_log() and iommu_ga_log_enable()).
The duplicate check in interrupt hanlder path is unnecessary
and can be removed.
No functional changes.
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
|
|
The amd_iommu_irq_remap flag is already validated during irq remapping
domain creation (before calling amd_iommu_create_irq_domain()). The
duplicate check in irq_remapping_select() is unnecessary and can be
removed.
Additionally, mark amd_iommu_irq_remap as static.
No functional changes.
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
|
Hans de Goede
Gabor Juhos
Chris Sommers
Raphaël Larocque
Michael Kelley
Jiangshan Yi
Waiman Long
Saim Shujah
William Bright
Guangshuo Li
Jesse Casco
Dmitry Baryshkov
Sergey Zagursky
Devin Wittmayer
Laxman Acharya Padhya
Linus Torvalds
AngeloGioacchino Del Regno
Claudiu Beznea
Rob Clark
Sajal Gupta
Sophie D
Andreas Kemnade
Neil Armstrong
George Emmanuel Thomas
Lyude Paul
Oscar Priego Verdugo
Berke Durak
Stuart Hayhurst
Youth Cao
Tristan Madani
Oleg Keri
Dmitry Antipov
Vasant Hegde