| Age | Commit message (Collapse) | Author |
|---|
|
hp_get_string_from_buffer()
utf16s_to_utf8s() writes into dst, but the loop that follows
overwrites dst from the raw UTF-16 code units with truncating casts,
so any character above U+007F is mangled. For example, U+00E9 is
stored as 0xe9 instead of 0xc3 0xa9.
Convert into a scratch buffer first, then escape '\\', '\r', '\n' and
'\t' into dst with string_escape_mem(). Quotes are not escaped, so the
existing strreplace() still handles them.
Tested on HP EliteBook 840 G2 (Fedora 44, Linux 7.2.7).
Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg")
Cc: stable@vger.kernel.org
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://lore.kernel.org/all/20261007134711.473857-1-meatuni001@gmail.com/
Link: https://patch.msgid.link/20261007134711.473857-3-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The escape prescan loop uses 'size' as both its bound and its
accumulator, so each escape character found extends the loop and
reads past the end of src[].
Use the original u16 count as the loop bound. Also include the 2-byte
length prefix in the bounds check, pass the u16 count instead of the
byte count to utf16s_to_utf8s(), and advance the buffer by the bytes
actually consumed instead of the escape-inflated count.
Tested on HP EliteBook 840 G2 (Fedora 44, Linux 7.2.7).
Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20261007134711.473857-2-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Add a KUnit case verifying that dma_fence_dedup_array() returns 0,
not 1, when called with num_fences == 0. This locks down the
contract documented in the kernel-doc and prevents a regression
of commit 77a9298741f8 ("dma-fence: Make dma_fence_dedup_array()
robust against 0-count input").
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Baineng Shou <shoubaineng@gmail.com>
Link: https://lore.kernel.org/r/20261014024909.1769215-1-shoubaineng@gmail.com
Signed-off-by: Christian König <christian.koenig@amd.com>
|
|
Since the previous change wled_probe() seeds wled->brightness from
MOD_EN, but with default-brightness rather than the level the hardware
is actually driving, so a backlight left lit by the bootloader still
visibly steps on the first update, and actual_brightness reports the
last value written rather than what the panel shows.
Add wled_read_brightness(), which returns 0 when MOD_EN is clear and
otherwise reads the brightness register the matching
wledN_set_brightness() writes: the first enabled string on WLED3 and
WLED4, the selected modulator on WLED5. Use it to seed both
wled->brightness and the initial backlight property, and expose it as
backlight_ops.get_brightness so that actual_brightness reflects the
hardware too.
A module that is enabled with the brightness registers at zero, which
wled4_setup() and wled_auto_string_detection() can leave behind on a
cold boot, now reads back as off. The OVP interrupt is then armed by the
first brightness update rather than from probe, which is what happens
on every other board where the module starts out disabled.
Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Assisted-by: LLM
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-4-bab8c7ef73cb@ixit.cz
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
wled_configure_ovp_irq() derives the initial state of the OVP interrupt
from the hardware:
/* Keep OVP irq disabled until module is enabled */
if (!(val & WLED3_CTRL_REG_MOD_EN_MASK))
disable_irq(wled->ovp_irq);
but wled->brightness, which is what the rest of the driver uses to tell
whether the module is on, is left at zero.
On boards where the bootloader hands the kernel a lit backlight the two
disagree. MOD_EN is already set, so the interrupt is left enabled, while
wled_update_status() still believes the backlight is off and takes
if (!!brightness != !!wled->brightness)
rc = wled_module_enable(wled, !!brightness);
on the first backlight update. wled_module_enable() then schedules
wled_ovp_work(), which calls enable_irq() on the already enabled
interrupt:
Unbalanced enable for IRQ 176
WARNING: CPU: 0 PID: 160 at kernel/irq/manage.c:774 __enable_irq+0x50/0x80
Hardware name: Xiaomi Pocophone F1 (DT)
Workqueue: events wled_ovp_work
Call trace:
__enable_irq+0x50/0x80
enable_irq+0x48/0xa0
wled_ovp_work+0x18/0x24
process_one_work+0x1d0/0x350
worker_thread+0x13c/0x460
kthread+0x110/0x114
ret_from_fork+0x10/0x20
The bootloader is not the only way to get there. The readback runs after
wledN_setup(), and wled4_setup() sets MOD_EN itself on the path where the
sink configuration does not already match, as does the tail of
wled_auto_string_detection(), which all three setup paths can reach
through wled_auto_detection_at_init(). A cold-booted board with a dark
panel can therefore reach the same disagreement.
Move the MOD_EN readback into wled_probe() and use it to seed
wled->brightness, so the driver starts out agreeing with the hardware,
and key the OVP interrupt off wled->brightness instead. The first
backlight update then only reprograms the brightness registers and
leaves both the module and the interrupt alone. The OVP interrupt also
stays armed from probe whenever the module is already enabled, rather
than being disabled at probe and only enabled once something writes
brightness.
Note that a backlight update requesting brightness 0 before any non-zero
one now really does turn the module off wherever MOD_EN was already set,
where before it was silently ignored.
wled->brightness is seeded with default-brightness rather than the level
the bootloader actually programmed, so the first update can still step
the brightness. Reading that level back is version specific and is done
in a follow-up, to keep this fix small enough to backport.
Assisted-by: LLM
Fixes: 8663c188beea ("backlight: qcom-wled: Add auto string detection logic")
Cc: stable@vger.kernel.org
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-3-bab8c7ef73cb@ixit.cz
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
WLED3 has a 16-bit brightness register pair per string, at 0x40 + 2*n,
which is what the pm8941-wled driver wrote to:
rc = regmap_bulk_write(wled->regmap,
wled->addr + WLED3_CTRL_REG_VAL_BASE + 2 * i,
v, 2);
The restructuring for WLED3 turned that into WLED3_SINK_REG_BRIGHT(n),
defined as 0x40 + n, so the two byte writes for consecutive strings
overlap: string 1 overwrites the MSB of string 0 with its own LSB, and
with the default three strings only string 1 ends up with the requested
value.
Use the 2 byte stride.
Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-2-bab8c7ef73cb@ixit.cz
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
wled_probe() doesn't set the driver data for the platform device.
As a result, platform_get_drvdata() in wled_remove() will return NULL,
and the first dereference of it crashes on unbind.
Set the platform device driver data in wled_probe().
Cc: stable@vger.kernel.org
Fixes: feeab87b3072 ("backlight: qcom-wled: Add support for short circuit handling")
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-1-bab8c7ef73cb@ixit.cz
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Remove an incorrect comment about the Microsoft MacroPad reference
implementation allegedly deviating from the spec and add more
information about the module and some other minor improvements.
Reviewed-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Aaron Erhardt <aer@tuxedocomputers.com>
Link: https://patch.msgid.link/20261007080202.81694-6-aer@tuxedocomputers.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The LED mappings in sirius_16_[iso|ansii]_kbl_map did contain a
flipped line that caused LEDs to turn on in the wrong order when
counting up the Lamp ID.
Fixes: cfd84b3f419b ("platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices")
Cc: stable@vger.kernel.org
Reviewed-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Aaron Erhardt <aer@tuxedocomputers.com>
Link: https://patch.msgid.link/20261007080202.81694-5-aer@tuxedocomputers.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
So far, this driver assumed incorrectly that the HID spec requires an
8-bit intensity value to be honored. The spec actually allows multiple
intensities for RGB lamps, but suggest to rather set brightness
through the individual channels, which is also what the Microsoft
MacroPad reference implementation does.
Accordingly, this commit simplifies intensity handling by offering
only two intensity values for turning LEDs on and off. All other color
values are submitted through the color channels individually, thus
avoiding duplicated handling of brightness.
Additionally, the incorrect comments explaining the deviation from the
MacroPad reference implementation were removed.
Reviewed-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Aaron Erhardt <aer@tuxedocomputers.com>
Link: https://patch.msgid.link/20261007080202.81694-4-aer@tuxedocomputers.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
While not strictly necessary due to the synchronous handling of HID
requests, it is better to set the ID of the HID report before
returning the buffer. This also better complies with the HID spec and
avoids problems with userspace tools expecting a report ID.
Reviewed-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Aaron Erhardt <aer@tuxedocomputers.com>
Link: https://patch.msgid.link/20261007080202.81694-3-aer@tuxedocomputers.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The WMI driver for TUXEDO Sirius devices used to rely on the device
driver data through dev_set_drvdata even though it is only a virtual
low level HID driver. For this purpose, it is better to use the
driver_data of the hid_device struct to avoid interfering with high
level device drivers.
Reviewed-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Aaron Erhardt <aer@tuxedocomputers.com>
Link: https://patch.msgid.link/20261007080202.81694-2-aer@tuxedocomputers.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Since the previous change wled_probe() seeds wled->brightness from
MOD_EN, but with default-brightness rather than the level the hardware
is actually driving, so a backlight left lit by the bootloader still
visibly steps on the first update, and actual_brightness reports the
last value written rather than what the panel shows.
Add wled_read_brightness(), which returns 0 when MOD_EN is clear and
otherwise reads the brightness register the matching
wledN_set_brightness() writes: the first enabled string on WLED3 and
WLED4, the selected modulator on WLED5. Use it to seed both
wled->brightness and the initial backlight property, and expose it as
backlight_ops.get_brightness so that actual_brightness reflects the
hardware too.
A module that is enabled with the brightness registers at zero, which
wled4_setup() and wled_auto_string_detection() can leave behind on a
cold boot, now reads back as off. The OVP interrupt is then armed by the
first brightness update rather than from probe, which is what happens
on every other board where the module starts out disabled.
Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Assisted-by: LLM
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-4-bab8c7ef73cb@ixit.cz
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
wled_configure_ovp_irq() derives the initial state of the OVP interrupt
from the hardware:
/* Keep OVP irq disabled until module is enabled */
if (!(val & WLED3_CTRL_REG_MOD_EN_MASK))
disable_irq(wled->ovp_irq);
but wled->brightness, which is what the rest of the driver uses to tell
whether the module is on, is left at zero.
On boards where the bootloader hands the kernel a lit backlight the two
disagree. MOD_EN is already set, so the interrupt is left enabled, while
wled_update_status() still believes the backlight is off and takes
if (!!brightness != !!wled->brightness)
rc = wled_module_enable(wled, !!brightness);
on the first backlight update. wled_module_enable() then schedules
wled_ovp_work(), which calls enable_irq() on the already enabled
interrupt:
Unbalanced enable for IRQ 176
WARNING: CPU: 0 PID: 160 at kernel/irq/manage.c:774 __enable_irq+0x50/0x80
Hardware name: Xiaomi Pocophone F1 (DT)
Workqueue: events wled_ovp_work
Call trace:
__enable_irq+0x50/0x80
enable_irq+0x48/0xa0
wled_ovp_work+0x18/0x24
process_one_work+0x1d0/0x350
worker_thread+0x13c/0x460
kthread+0x110/0x114
ret_from_fork+0x10/0x20
The bootloader is not the only way to get there. The readback runs after
wledN_setup(), and wled4_setup() sets MOD_EN itself on the path where the
sink configuration does not already match, as does the tail of
wled_auto_string_detection(), which all three setup paths can reach
through wled_auto_detection_at_init(). A cold-booted board with a dark
panel can therefore reach the same disagreement.
Move the MOD_EN readback into wled_probe() and use it to seed
wled->brightness, so the driver starts out agreeing with the hardware,
and key the OVP interrupt off wled->brightness instead. The first
backlight update then only reprograms the brightness registers and
leaves both the module and the interrupt alone. The OVP interrupt also
stays armed from probe whenever the module is already enabled, rather
than being disabled at probe and only enabled once something writes
brightness.
Note that a backlight update requesting brightness 0 before any non-zero
one now really does turn the module off wherever MOD_EN was already set,
where before it was silently ignored.
wled->brightness is seeded with default-brightness rather than the level
the bootloader actually programmed, so the first update can still step
the brightness. Reading that level back is version specific and is done
in a follow-up, to keep this fix small enough to backport.
Assisted-by: LLM
Fixes: 8663c188beea ("backlight: qcom-wled: Add auto string detection logic")
Cc: stable@vger.kernel.org
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-3-bab8c7ef73cb@ixit.cz
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
WLED3 has a 16-bit brightness register pair per string, at 0x40 + 2*n,
which is what the pm8941-wled driver wrote to:
rc = regmap_bulk_write(wled->regmap,
wled->addr + WLED3_CTRL_REG_VAL_BASE + 2 * i,
v, 2);
The restructuring for WLED3 turned that into WLED3_SINK_REG_BRIGHT(n),
defined as 0x40 + n, so the two byte writes for consecutive strings
overlap: string 1 overwrites the MSB of string 0 with its own LSB, and
with the default three strings only string 1 ends up with the requested
value.
Use the 2 byte stride.
Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-2-bab8c7ef73cb@ixit.cz
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
wled_probe() doesn't set the driver data for the platform device.
As a result, platform_get_drvdata() in wled_remove() will return NULL,
and the first dereference of it crashes on unbind.
Set the platform device driver data in wled_probe().
Cc: stable@vger.kernel.org
Fixes: feeab87b3072 ("backlight: qcom-wled: Add support for short circuit handling")
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-1-bab8c7ef73cb@ixit.cz
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The interrupt handler queues delayed work to read the interrupt status.
After free_irq() stops the producer, this work can still be waiting on its
timer. destroy_workqueue() cannot drain delayed work that has not yet been
queued by its timer, so the timer can outlive both the workqueue and the
devm-allocated chip containing the work.
Cancel the delayed work synchronously after freeing the IRQ and before
destroying the workqueue. This also waits for any running status read to
finish before the chip's resources are released.
This issue was identified during our ongoing static-analysis research
while reviewing kernel code.
Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Link: https://patch.msgid.link/20261003030439.599330-1-mhun512@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The HP HyperX OMEN 16-am2xxx (DMI board 8F1C, 26C1 platform cycle, Arrow
Lake-HXR) is listed in the OMEN Command Center device capability table
with DisplayName "HyperX OMEN 16" and the "PerformanceControl" feature,
but is missing from the kernel's hp_wmi_feature_boards[] list.
Add 8F1C to the hp_wmi_feature_boards[] list, using
omen_v1_legacy_board_params as driver_data.
Tested on a HyperX OMEN 16-am2xxx (kernel 7.3.0-rc6): after loading the
patched hp-wmi module, the platform_profile interface is exposed, and
switching to the performance profile raises the CPU from a ~2.9 GHz
(P-core) / 2.6 GHz (E-core) cap to ~5 GHz / ~3.5 GHz under a
multi-thread load (stress-ng). The GPU cap is raised to ~114W, tested
with gpu_burn.
Suggested-by: Krishna Chomal <krishna.chomal108@gmail.com>
Signed-off-by: Shuwen Bao <baoshuwen2013@outlook.com>
Link: https://patch.msgid.link/SI2PR04MB589508E55CCCD8E26E53E4DBA2942@SI2PR04MB5895.apcprd04.prod.outlook.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The Mahua-based Surface Laptop 13.8" 8th Edition exposes the same SAM
client devices as the Surface Laptop 7: keyboard, fan and platform
profile. Battery and AC status come from pmic-glink here as well, so
the Surface Laptop 7 node group can be reused as is.
Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20261006-mahua-surface-laptop-v1-3-406fc042162a@oss.qualcomm.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
of_clk_bulk_get() leaves 'clk_bulk_data->id' as NULL for every clock that
has no matching entry in "clock-names", which is legal: a node may list
more "clocks" phandles than it names. Both scans of the bulk array
dereference that id unconditionally, so such a node oopses during probe.
The loop in imx_pcie_probe() has been wrong since it was written. The
loop in imx_setup_phy_mpll() was not: it read a fixed clks[] whose ids
came from the driver's own clk_names[] and were never NULL, and only
became wrong when the driver moved to the bulk array.
Check 'clk_bulk_data->id' before dereferencing it in both.
Fixes: f6a1fdfc78e2 ("PCI: imx6: Use devm_clk_bulk_get_all() to fetch clocks")
Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode support")
Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Acked-by: Richard Zhu <hongxing.zhu@nxp.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/am8iBwJSEhYhWTqk@6cfee64030a6/
Link: https://patch.msgid.link/aqfqE4OLhnN4a1lW@b65e9c1eb12f
|
|
In apci3xxx_auto_attach(), the number of subdevices is computed with
n_subdevices = (board->ai_n_chan ? 0 : 1) + board->has_ao + ...
The ternary is inverted: when the board has analog input channels
(ai_n_chan != 0), it counts 0 instead of 1, so the AI subdevice that is
actually created is not accounted for. As a result
comedi_alloc_subdevices() allocates one entry too few, and the later
subdevice initialization (notably the TTL Digital I/O subdevice, which
is populated last) writes past the end of the allocated array, causing a
slab out-of-bounds write.
Flip the ternary to count 1 when ai_n_chan is non-zero and 0 otherwise,
matching the subdevice creation order in the function.
Signed-off-by: Yang Zi <2959243019@qq.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20261014101803.11036-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
All of the variables using this particular structure are declared as const.
There is no reason to declare its individual fields as being const.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260911233541.1650895-2-james.quinlan@broadcom.com
|
|
When a contention is detected the drm_exec object grabs a reference to
the contended object, unlocks all other objects and pre-locks the
contended one before anything else.
The problem is that it is possible that this pre-locked object was about
to be destroyed and drm_exec is now holding the last reference to it.
So we never actually see this pre-locked object again to be explicitly
locked and so also never reserve a slot for a dma_fence object on it.
Should the driver now use drm_exec_for_each_locked_object() to add a new
fence to all locked objects we eventually see a warning or even a
BUG_ON() to prevent random memory corruption.
Fix this by keeping the prelocked object out of the array of locked objs
until it was explicitly mentioned by the driver again.
If the prelocked object is never mentioned again by the driver
just unlock and drop the reference at the end of the locking loop.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reported-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7")
CC: stable@vger.kernel.org # v6.6+
Link: https://lore.kernel.org/r/20261007124657.9664-1-christian.koenig@amd.com
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
Miri Korenblit says:
====================
wifi: iwlwifi: updates - 2026-10-14
This contains our usual development commits, notably:
- UHR sniffer support
- Transport refactor: avoid indirection, bring virtualization back
- A UEFI lock for UEFI tables security
- New BIOS tables support
====================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
HP Spectre x360 16-aa0xxx (board 8C17) exposes battery charge mode control
through WMI command 0x2b (GBCO/SBCO). Inhibit charge, force discharge, and
restoring automatic charging all work through that command. The
Spectre x360 14-eu0xxx (board 8C15) shares the same platform and the same
GBCO/SBCO implementation.
Unlike some other HP designs that restore automatic charging through WMI
command 0x1f (SBCC), that path fails on this BIOS. Keep the quirk limited
to boards 8C15 and 8C17 and drive all three behaviours through 0x2b only.
Expose auto / inhibit-charge / force-discharge through the standard
power_supply charge_behaviour property. Seed the reported policy from
GBCO at setup because firmware retains inhibit across reboot. Cache that
policy afterwards: GBCO also encodes live status, so 0x01 means actively
charging and 0x02 is ambiguous between force-discharge and running on
battery alone.
Observed firmware mapping on this board:
- write 0x00 -> auto; write 0x02 -> force-discharge; write 0x05 -> inhibit
- read 0x00/0x01 -> auto (0x01 = actively charging)
- read 0x02 -> force-discharge (also seen on battery alone)
- read 0x04/0x05/0x06 -> inhibit
Tested on HP Spectre x360 16-aa0xxx (board 8C17, BIOS F.16):
- inhibit stops charging on AC; GBCO reads 0x04
- force-discharge discharges on AC; GBCO reads 0x02
- restore-auto via 0x2b mode 0 resumes charging; GBCO reads 0x01
- inhibit persists across reboot (status Not charging, GBCO 0x04)
Board 8C15 was reported working by Alain Cousinie.
Suggested-by: Alain Cousinie <alain.cousinie@laposte.net>
Signed-off-by: Shang En Sim <sim@shangen.org>
Link: https://patch.msgid.link/20261001031012.48473-3-sim@shangen.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
hp_wmi_hwmon_init() initialises keep_alive_dwork with INIT_DELAYED_WORK()
and relies on hp_wmi_bios_remove() to cancel it. Nothing cancels the work
if probe fails after hp_wmi_hwmon_init() has run, so the devm-managed
priv can be freed while the work is still pending.
The ordering is also wrong on both ends. The work is initialised only
after the hwmon device is registered, so a sysfs write to pwm1_enable
can schedule an uninitialised work item. On removal, the work is
cancelled in .remove(), before devres unregisters the hwmon device, so a
sysfs write can requeue it after the cancel.
Use devm_delayed_work_autocancel() and set it up before registering the
hwmon device. devres then cancels the work on every teardown path, after
the hwmon sysfs interface has been removed and before priv and its mutex
are released. Drop the now-unneeded cancel in hp_wmi_bios_remove() and
the platform drvdata that was only used for it.
Fixes: c203c59fb5de ("platform/x86: hp-wmi: implement fan keep-alive")
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Shang En Sim <sim@shangen.org>
Link: https://patch.msgid.link/20261001031012.48473-2-sim@shangen.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
iwl_mld_is_vo_vi_pkt() checks whether the mapped access category
is less than IEEE80211_AC_VI.
Since mac80211 defines IEEE80211_AC_VO as 0 and IEEE80211_AC_VI as 1,
this only matches voice traffic and excludes video traffic.
Synthetic video-priority UDP traffic does not automatically
activate low-latency mode, whereas voice-priority traffic does
Include IEEE80211_AC_VI as intended.
Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver")
Signed-off-by: Endrik Einberg <git@endrik.dev>
Link: https://patch.msgid.link/20261005144225.170280-1-git@endrik.dev
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Unlike the other bus operations, write8 has no generic wrapper and is
never dispatched through trans->ops: all the callers are in the pcie
code and call iwl_trans_pcie_write8() directly. Remove it.
Assisted-by: LLM
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.fecac6ba37d1.Icf8e741c8ccc6eff1abd046223b575c07f69aff5@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
This version has a new flags field that must be set to
indicate which other fields are valid, in preparation
for moving queue pointers during SMD transition.
Only set the IWL_SCD_QUEUE_MODIFY_FLAG_STA_MSK flag on
the existing users of the command for now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.534cc32f2ac6.I394c38c58ad6619e3e52b52c3bc686acbbd2e4f1@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
This is not a performance-critical path, and with clang
and KASAN it can use a lot of stack space. Uninline the
various versions to avoid that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.97f5c8503204.Ib88f908b0638889e84753ae334525c4c52064838@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
With clang we can hit warnings here due to different enum types
on the different sides of the ternary, but we don't really need
to care because they're plain integer variables. Cast them to
avoid the warnings.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.6ea24eaa784d.I91bab31db441f9e230228c3893ff13fd7fc3e7bf@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
ieee80211_update_mu_groups() takes const u8 * pointers, and we
have const values, but remove the const which can lead to some
warnings with clang. Leave it const throughout.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.6acceb79b0ef.Ia22765206364220b115dd84eb1a16b5a979d9340@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
The phy pointer here isn't really const, and if it were we'd
need container_of_const() (which can do both), but as it's
just non-const anyway drop the const.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.ccd4dbfffb5f.Id15631e4372d9495282634f89bd73e7f526ce2ce@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
We shouldn't read this without having NIC access, which I
had broken in the past. Enabling clang's context analysis
now surfaced this bug. Luckily, it only applies to blank
OTP devices, which aren't really common/shipping at all.
Keep the value from earlier, and use zero (as in the past
before I broke it) if it can't be read at all.
Fixes: 0b205d0f0f50 ("wifi: iwlwifi: trans: remove hw_wfpm_id")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.74912aba718d.I9568d08c280c0ca148c3918439c6beb8c4647a40@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
sta is never assigned in iwl_mvm_rx_monitor_no_data(), so the
sta ? &sta->deflink : NULL expression is dead code. Drop the variable
and pass NULL directly. Drop the unneeded RCU read lock,
ieee80211_rx_napi() takes the RCU read lock on its own.
Spotted by Coverity.
Assisted-by: LLM
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.2d0a56daefed.I2bd50c74f1f50e0fd87996333b804d2731dbd0fa@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
There is no point in RSS when we have only one rxq.
Don't send the command in this case - RSS will be disabled by default.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.dbeea799293f.I1c37945a248f101e0bca2cd723ce6551871926ab@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Context info structures and enums are APIs. While they have only been used
in pcie bus until now, part of those will be used for future bus types as
well.
Extract the APIs from pcie/iwl-context-info*.h to
fw/api/context-info*.h.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.87b73a7de1e5.I5e526d01b560a277bc363b3f1b42dcb63d51c574@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Most sequence counters in WoWLAN are documented as "to use next",
but in reality firmware treats them as "last used". Fix the docs
accordingly, while at it noting that for newer versions it only
applies to the offload TID.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.5d17b80be44c.Ia3ec5e1f714029561b08ab659b116bc20a60beb3@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
When converting a v3 rate to the v1 format, the MCS index was read
from the mask of the NSS field and written into the mask of the MCS
field. This is obviously wrong, we must not mix the NSS and the MCS.
Fixes: 3592c0083fb2 ("wifi: iwlwifi: mvm: fix beacon template/fixed rate")
Assisted-by: LLM
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.dfca0c8b560a.I7a3e1f0e91f0d0c6f4c5f1e6a33dc7c0c5e9ad11@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Start supporting Core 109 FW on these devices.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261011140453.603d3010fb29.I53bc9bf1f5931e573fd55b62eef8be16270e6a92@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
If the worker index is bad, then the pointer to the containing
array cannot be determined. Avoid it, and just make it a WARN_ONCE()
since it should never happen.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20261001161715.dd857cfe0d6b.I8162af7b34d03b1b30be5914cde6248ad84b6a9f@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
All the firmwares used by iwlmvm and iwlmld set
IWL_UCODE_TLV_API_NEW_VERSION. Since iwl_sar_geo_support is not called
by iwldvm, simplify the ucode_ver check.
No functional change intended.
Assisted-by: LLM
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20261001161715.5e290d456f51.Ic33c983411e93201e5e05a9d3df5af524de09b9a@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
The firmware added CIGTK rekey support for D3:
- KEK_KCK_MATERIAL_CMD version 5 has a new cigtk_cipher field.
- WOWLAN_INFO_NOTIFICATION version 7 reports the CIGTK material of
the active link, and MLO keys can now be of type CIGTK.
The CIGTK material itself is not used yet, this is done in a
separate patch.
Assisted-by: LLM
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20261001161715.45aa7d3f2421.I1c53d0b8f1a1f1b3a4e35a86b5a6a5c04ff5f1a2@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
This is supported by hardware, advertise it. We'll
have to separately work on enabling it in firmware
if the AP supports it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20261001161715.6c5fc579f2d8.I0cdf7516e95181e31c33fde374216fb6bc8f4aa1@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
There are a number of places checking for the U-SIG CRC and
then reporting if it failed, but we should set the failed
PLCP CRC top-level radiotap flag for easier discarding of
such packets in users such as wireshark. Do that with a new
helper function, to avoid doing it in so many places.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20261001161715.cda01742eff8.I824c410fefd4022973403c1cf18f47459e34c4b2@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
We didn't report the guard interval for UHR to mac80211,
fix that by refactoring the EHT function and using it.
The LTF is reported only in radiotap (differently), so
the code for UHR doesn't need it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20261001161715.9f728be36075.Ic46d2234d03fdf3b098a8b25f607bd3559e6a2db@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Detect UHR sounding packets by checking their data length just like
for EHT and reporting them to the sniffer immediately.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20261001161715.1c6817d2205b.Icc0cb8f2ef738bba6105f7b909c47d6d0cf12491@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Clearly the existing code is wrong. Since it's not clear that
the value is reported by hardware, and we probably won't need
it, remove it for now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20261001161715.56c9dd83eb39.I4482c69e48aa4661d11aecc23aab03fb9fef5ead@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Sounding PPDUs are currently reported as "not for us" in the
sniffer, since PHY reports that aren't detected as sounding
immediately by a zero-length indication (which doesn't exist
for trigger-based) are released only on the next PHY sniffer
notification, when no MPDU was received.
The "not for us" indication is, however, wrong in both cases:
for TB sounding PPDUs it should be sounding, for others it
should be some unspecified (DSP?) error. Fix both cases.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20261001161715.f8f6a08851a8.I8689a2a1599578aea53dda62cffc7f012d1d10f7@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
In per-user information for UHR sniffer, report whether or
not beamforming was used, according to rate_n_flags.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20261001161715.3f8de2b3592b.Ie21d26e1a25a117515907e9577a51de3bc29692b@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
