| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
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`
|
|
The R timer clocks only have a P divider, but are currently modeled as
MP clocks with a zero-width M divider.
ccu_mp_set_rate() generates an invalid mask for the zero-width M
divider, clearing unrelated register fields. Model these clocks as
P-only clocks to avoid accessing a nonexistent M divider.
Fixes: 8cea339cfb81 ("clk: sunxi-ng: add support for the A523/T527 PRCM CCU")
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
Link: https://patch.msgid.link/20260906-sunxi-clk-no-p-v1-4-cbde21c9fe69@pigmoral.tech
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
|
|
The high-speed timer clocks only have a P divider, but are currently
modeled as MP clocks with a zero-width M divider.
ccu_mp_set_rate() generates an invalid mask for the zero-width M
divider, clearing unrelated register fields. Model these clocks as
P-only clocks to avoid accessing a nonexistent M divider.
Fixes: 74b0443a0d0a ("clk: sunxi-ng: a523: add system mod clocks")
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
Link: https://patch.msgid.link/20260906-sunxi-clk-no-p-v1-3-cbde21c9fe69@pigmoral.tech
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
|
|
The MBUS, IOMMU, and DRAM clocks only have an M divider, but are
currently modeled as MP clocks with a zero-width P divider.
ccu_mp_set_rate() generates an invalid mask for the zero-width P
divider, clearing unrelated register fields. It also ignores
CCU_FEATURE_UPDATE_BIT, so the new divider value does not take effect.
Model these clocks as M-only clocks instead. This avoids accessing a
nonexistent P divider and uses ccu_div_set_rate(), which handles the
update bit.
Fixes: 74b0443a0d0a ("clk: sunxi-ng: a523: add system mod clocks")
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
Link: https://patch.msgid.link/20260906-sunxi-clk-no-p-v1-2-cbde21c9fe69@pigmoral.tech
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
|
|
Add a variant of SUNXI_CCU_M_DATA_WITH_MUX_GATE() that accepts CCU
feature flags, such as CCU_FEATURE_UPDATE_BIT.
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
Link: https://patch.msgid.link/20260906-sunxi-clk-no-p-v1-1-cbde21c9fe69@pigmoral.tech
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
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>
|
|
The flushing field in the at_context structure is used for the internal
branches in handle_at_packet(). This field is enabled in
at_context_flush() when either handling the selfIDComplete event in
the threadedIRQ handler or calling the .remove callback of the PCI
device.
In these two flushing cases, the pointer to the work structure retrieved
by current_work() should be different from the one in the at_context
structure. Replacing the flushing field with a work structure check is
preferable since the branching can be self-contained without relying on an
external flag.
Link: https://lore.kernel.org/r/20260912032219.3379821-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras
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()
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Instead of passing an ACPI device object pointer as devdata to
thermal_cooling_device_create(), make acpi_fan_probe() pass a pointer
to struct acpi_fan to it, which allows the callback functions in
fan_cooling_ops to be simplified.
Also avoid using acpi_driver_data() in two functions invoked by the
cooling device callbacks by passing struct acpi_fan pointers instead
of struct acpi_device pointers to them.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/3631084.QJadu78ljV@rafael.j.wysocki
|
|
In preparation for subsequent changes, instead of storing a fan ACPI
handle in struct acpi_fan, store a pointer to the corresponding struct
acpi_device in it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/8772267.NyiUUSuA9g@rafael.j.wysocki
|
|
Instead of passing an ACPI device object pointer as devdata to
thermal_cooling_device_create(), make acpi_processor_thermal_init()
pass a pointer to the struct acpi_processor representing the given CPU
to it, which allows the callback functions in processor_cooling_ops to
be simplified and the second argument of acpi_processor_thermal_init()
and acpi_processor_thermal_exit() to be dropped.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/6192780.MhkbZ0Pkbq@rafael.j.wysocki
|
|
The ACPI thermal zone .should_bind() callback function,
acpi_thermal_should_bind_cdev(), expects the given cooling device's
devdata to point to an ACPI device object whose ACPI handle should be
compared with ACPI handles in a list associated with the given trip
point. That is not particularly straightforward and it effectively
requires the drivers of ACPI cooling devices to populate the devdata
with addresses of the ACPI companions of the devices they bind to.
Consequently, the devdata cannot be used by the driver for its own
needs which is its intended purpose.
That can be overcome with the help of the observation that the
ACPI device objects to be matched against the lists of ACPI handles
associated with trip points are in fact the ACPI companions of the
parents of cooling devices. Thus instead of using the given cooling
device's devdata, it is sufficient to obtain the ACPI handle of its
parent and compare that ACPI handle with the ones in the list
associated with the given trip point.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
[ rjw: Added parent_handle check against NULL ]
Link: https://patch.msgid.link/9672996.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Instead of using thermal_cooling_device_register() for
registering a cooling device in the ACPI fan driver, make it use
thermal_cooling_device_create() and pass a pointer to the platform
device representing the given fan to that function as the cooling
device's parent. That will cause the cooling device's sysfs directory
to be created under the parent's sysfs directory (among other things).
Since creating a class device under a parent causes a "device" symbolic
link from the sysfs directory of the class device to the sysfs directory
of the parent to appear automatically, remove the code creating that
symbolic link manually.
Moreover, since the cooling device is now located in sysfs under its
parent and it can be easily identified as a cooling device, there is
no need to create a "thermal_cooling" symbolic link from its parent
to it. Accordingly, also remove the code creating that symbolic link.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/3969045.kQq0lBPeGt@rafael.j.wysocki
|
|
Instead of using thermal_cooling_device_register() for registering a
backlight cooling device in the ACPI video bus driver, make it use
thermal_cooling_device_create() and pass a pointer to the LCD device
to that function as the cooling class device's parent. That will
cause the cooling device's sysfs directory to be created under
the parent's sysfs directory (among other things).
Since creating a class device under a parent causes a "device" symbolic
link from the sysfs directory of the class device to the sysfs directory
of the parent to appear automatically, remove the code creating the
"device" symbolic link from the sysfs directory of the cooling device
in question to the sysfs directory of the parent's ACPI companion
device. That companion device is reachable through the "firmware_node"
symbolic link in the parent's sysfs directory regardless.
Moreover, since the cooling class device is now located in sysfs under
its parent and it can be easily identified as a cooling device, there is
no need to create a "thermal_cooling" symbolic link from its parent's
ACPI companion to it. Accordingly, also remove the code creating that
symbolic link.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/23237491.EfDdHjke4D@rafael.j.wysocki
|
|
Instead of using thermal_cooling_device_register() for registering
a cooling device in the ACPI processor driver, make it use
thermal_cooling_device_create() and pass a pointer to the processor
device representing the given CPU to that function as the cooling
device's parent. That will cause the cooling device's sysfs directory
to be created under the parent's sysfs directory (among other things).
Since creating a class device under a parent causes a "device" symbolic
link from the sysfs directory of the class device to the sysfs directory
of the parent to appear automatically, remove the code creating the
"device" symbolic link from the sysfs directory of the cooling device
in question to the sysfs directory of the parent's companion ACPI
device. That ACPI device is reachable through the "firmware_node"
symbolic link in the parent's sysfs directory regardless.
Moreover, since the cooling device is now located in sysfs under its
parent and it can be easily identified as a cooling device, there is
no need to create a "thermal_cooling" symbolic link from its parent's
ACPI companion to it. Accordingly, also remove the code creating that
symbolic link.
While at it, check for error pointer values in addition to checking
for NULL in acpi_processor_thermal_exit() to avoid dereferencing them
mistakenly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
[ rjw: Corrected typo in the changelog ]
Link: https://patch.msgid.link/2362345.iZASKD2KPV@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Currently, thermal cooling devices have no parents, but it would be
generally useful to be able to create them under specific parents in
the device hierarchy (for instance, it may help to identify the device
representing the actual cooling hardware).
To make that possible, add thermal_cooling_device_create() that will
work like thermal_cooling_device_register() except that it will take
an additional parent argument (which may be NULL).
Redefine thermal_cooling_device_register() as a static inline wrapper
around thermal_cooling_device_create().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/8729484.T7Z3S40VBb@rafael.j.wysocki
|
|
In acpi_video_dev_unregister_backlight(), the sysfs interface of the
cooling class device may access the brightness object under the
backlight device's ACPI companion, so that object cannot be freed
before unregistering the cooling class device.
Adjust the code to take that into account.
Fixes: 67b662e189f4 ("ACPI / video: seperate backlight control and event interface")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
[ rjw: Fixed the Fixes: tag ]
Link: https://patch.msgid.link/3429468.aeNJFYEL58@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
An ACPI device object's dev field in passed as the first argument to
devm_kcalloc() in acpi_fan_get_fps() which is incorrect and leads to
a memory leak on driver probe errors and removal because the driver
is not bound to that ACPI device.
Address this by replacing that pointer with a pointer to the device the
driver is actually bound to.
While at it, drop a redundant error message after a memory allocation
failure (that also gets printed relative to the ACPI device).
Fixes: d91a1d129b63 ("ACPI: fan: Use platform device for devres-related actions")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/14089663.uLZWGnKmhe@rafael.j.wysocki
|
|
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev
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
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux
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
|
|
The ata_scsi_remove_dev() comment misspells its caller as
ata_eh_scsi_hotplug(). The caller is ata_scsi_hotplug(). Correct the
reference, which predates libata's move from drivers/scsi to
drivers/ata.
Fixes: 580b2102327a ("[PATCH] libata-hp: implement SCSI part of hotplug")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://lore.kernel.org/r/20260912101215.86413-1-kmehltretter@gmail.com
Signed-off-by: Niklas Cassel <cassel@kernel.org>
|
|
spi_new_ancillary_device() returns the new struct spi_device, or an
ERR_PTR() on failure, but its kernel-doc says "0 on success; negative
errno on failure", which was never true. Describe the pointer.
Fixes: 0c79378c0199 ("spi: add ancillary device support")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260911230211.11755-1-kmehltretter@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
* ras/edac-misc:
EDAC/{bluefield,loongson}: Use named initializers for acpi_device_id
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
|
|
Use a named initializer for the acpi_device_id fields which makes the code
more readable and consistent with how lists are initialized in the rest of the
kernel code base. Also drop explicitly setting fields to 0 where it is
redundant.
While at it - unify the list terminator to have a single space between
the brackets and no trailing comma.
Signed-off-by: Pawel Zalewski <pzalewski@thegoodpenguin.co.uk>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: David Thompson <davthompson@nvidia.com>
Acked-by: Qunqin Zhao <zhaoqunqin@loongson.cn>
Link: https://patch.msgid.link/20260904-acpi-edac-v1-1-ef93d60bbda4@thegoodpenguin.co.uk
|
|
s2mps11_clk_probe() ignores of_clk_add_hw_provider() failures, stores
driver data and returns success even though DT consumers cannot acquire the
registered clocks.
Return the provider error through the existing lookup cleanup path. Skip
empty lookup slots while unwinding because S2MPS14 omits its CP clock.
The issue was found by our static-analysis tool and manually reviewed.
Fixes: b228fad50c00 ("clk: s2mps11: Migrate to clk_hw based OF and registration APIs")
Assisted-by: LLM
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
The Rx completion queue writeback coalescing window controls how long
the queue manager may defer writing completions to host memory.
Expose this window through the standard rx-cqe-nsecs ethtool
parameter. Preserve the existing 2000 ns default and accept values
from 1000 ns through the device maximum (~109 us).
Hardware expresses COAL_WAIT in 600 MHz core clock cycles, or 1.667 ns
per cycle. Programming rounds the configured value to the nearest clock
cycle, resulting in an error of less than 1 ns. Retain the requested
value for get_coalesce() because this error is below the one-nanosecond
resolution of the ethtool interface.
Signed-off-by: Mohsin Bashir <hmohsin@meta.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260909211111.1795726-1-mohsin.bashr@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The directory's Kconfig already has COMPILE_TEST. This allows it to
work.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
The smc9194 driver was removed in commit 9fdf9f61fa6d ("drivers: net:
smsc: smc9194: Remove this driver"), but smc9194.h was left behind.
Remove it.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260910143516.87304-1-enelsonmoore@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Convert the rs9 clock driver to use the of_clk_hw_onecell_get() helper,
which requires using the clk_hw_onecell_data structure. Embedding that
structure in the rs9_driver_data structure has the benefit that the
clock array always has the correct size, and thus can no longer become
out of sync when adding support for new rs9 variants.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
rs9_of_clk_get() does not validate the clock index in the passed
DT clock specifier. If DT specifies an incorrect and out-of-range
index, this will access memory beyond the end of the clk_dif[] array.
Fix by this adding a range check to rs9_of_clk_get().
Fixes: 892e0ddea1aa6f70 ("clk: rs9: Add Renesas 9-series PCIe clock generator driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
irq_of_parse_and_map() returns 0 when parsing or mapping an IRQ fails,
while platform_get_irq() returns a negative error code on failure.
Handle both failure cases appropriately: return -EINVAL when
irq_of_parse_and_map() fails, and propagate the original error code
returned by platform_get_irq() instead of returning -ENOMEM.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>
Link: https://patch.msgid.link/20260909045450.16176-4-phucduc.bui@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
lp->eth_irq is assigned from platform_get_irq_optional(), which returns
a non-zero interrupt number on success or a negative error number on
failure. Errors other than -ENXIO are handled before this check,
so -ENXIO is the only error value that can reach this point.
Check for a negative value instead of treating 0 as an undefined IRQ.
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260909045450.16176-3-phucduc.bui@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no optional IRQ is available, while other errors should be propagated.
Propagate all error codes returned by platform_get_irq_optional() other
than -ENXIO.
Another call to platform_get_irq_optional() in the same function already
handles the return value this way. Apply the same error handling to this
call site for consistency.
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260909045450.16176-2-phucduc.bui@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
devm_cxl_add_region() returns the new struct cxl_region, or an ERR_PTR()
on failure, but its kernel-doc says "0 if the region was added to the
@cxlrd, else returns negative error code", which was never true.
Describe the pointer.
[ dj: Dropped Fixes tag as it's a comment fix and not code fix. ]
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Link: https://patch.msgid.link/20260911221748.7212-1-kmehltretter@gmail.com
Signed-off-by: Dave Jiang <dave.jiang@intel.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>
|
