| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Signed-off-by: Helge Deller <deller@gmx.de>
Noticed-by: Breno Rodrigues Alves <breno3011alves@gmail.com>
|
|
sstfb_probe() enables the PCI device with pci_enable_device(), but
failure paths after that point return without disabling it. The successful
probe path has the same imbalance because sstfb_remove() releases the
framebuffer, mappings and memory regions, but never calls
pci_disable_device().
Use pcim_enable_device() so the PCI core disables the device automatically
after probe failure or driver removal. The driver still releases its
framebuffer, mappings and memory regions explicitly.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The acornfb driver contains code to support machines with a MEMC chip
and without IOMD and VIDC20 chips. All 32-bit Acorn hardware has IOMD
and VIDC20 chips and does not have a MEMC chip.
Linux formerly supported 26-bit Acorn computers, but that support was
removed in commit 99eb8a550dbc ("Remove the arm26 port") because it had
bitrotted to the extent that it did not even compile.
Remove this unused code. Also take the opportunity to remove incorrect
file paths in the file headers, which are bad style regardless.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Failures in nvidia_set_fbinfo() or register_framebuffer() leave the handle
from arch_phys_wc_add() allocated. Release it in the shared error path,
as nvidiafb_remove() already does on normal removal.
The missing cleanup was already present in the initial Git import,
when the driver used mtrr_add() directly.
This issue was identified during our ongoing static-analysis research
while reviewing kernel code.
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>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
If register_framebuffer() fails, kyrofb_probe() frees the framebuffer
without releasing its write-combining range. Release the range before
freeing the framebuffer. Earlier failures still skip this cleanup.
The missing cleanup already exists in the initial Git import, before
the conversion from mtrr_add() to arch_phys_wc_add().
This issue was identified during our ongoing static-analysis research
while reviewing kernel code.
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>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
gxt4500_probe() adds a write-combining range before allocating the cmap
and registering the framebuffer. If a later step fails, the range is
not released. Add the missing cleanup before unmapping the framebuffer,
matching the successful remove path.
This issue was identified during our ongoing static-analysis research
while reviewing kernel code.
Fixes: 38fc4d45fae5 ("gxt4500: Use arch_phys_wc_* for framebuffer")
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>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The LCD controller IRQ schedules sinfo->task to recover from a FIFO
underflow. Probe currently requests the IRQ before initializing the
work, so an early interrupt can schedule an uninitialized work item.
The probe error path and remove path cancel the work before freeing the
IRQ. A FIFO-underflow interrupt can schedule the work again after that
cancellation. framebuffer_release() may then free sinfo while the work
is still pending.
KASAN reported a use-after-free in atmel_lcdfb_task() when an underflow
interrupt occurred during removal. With the IRQ freed before the work
was cancelled, the same test completed without a kernel diagnostic.
Initialize the work before requesting the IRQ. In both cleanup paths,
free the IRQ before cancelling the work so that it cannot be scheduled
again after cancellation.
Fixes: d22579b83735 ("atmel_lcdfb: FIFO underflow management")
Cc: stable@vger.kernel.org
Assisted-by: Codex:GPT-5
Signed-off-by: Yibo Tan <lhfff@tju.edu.cn>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently sh_mobile_lcdc_start() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due
to an allocation failure) info->fbdefio_state is left NULL.
When the file is subsequently opened, fb_open() will dereference a NULL
pointer (calling fb_deferred_io_open()).
Fix this by checking for the error.
Also clear info->fbdefio in that case, so that sh_mobile_lcdc_stop() does
not attempt to clean up deferred I/O state that was never initialised.
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently ufx_ops_open() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due to
an allocation failure) info->fbdefio_state is left NULL.
fb_open() will then dereference a NULL pointer (calling
fb_deferred_io_open()) as soon as ufx_ops_open() returns.
Additionally, if the allocation of info->fbdefio itself fails,
ufx_ops_open() sets info->fbdefio to NULL and invokes
fb_deferred_io_init() regardless, hitting BUG_ON(!fbdefio).
Fix this by only invoking fb_deferred_io_init() if the allocation
succeeded, and checking for the error.
The driver already supports operating without deferred I/O, so in either
case fall back to that by setting info->fbdefio to NULL.
The ignored return value was introduced in commit 56c134f7f1b5 ("fbdev:
Track deferred-I/O pages in pageref struct").
However, the BUG_ON() issue originates from the earlier
commit 3c8a63e22a08 ("Add support for SMSC UFX6000/7000 USB display
adapters"), so target that for the fix.
Fixes: 3c8a63e22a08 ("Add support for SMSC UFX6000/7000 USB display adapters")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently dlfb_ops_open() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due to
an allocation failure) info->fbdefio_state is left NULL.
fb_open() will then dereference a NULL pointer (calling
fb_deferred_io_open()) as soon as dlfb_ops_open() returns.
Additionally, if the allocation of info->fbdefio itself fails,
dlfb_ops_open() sets info->fbdefio to NULL and invokes
fb_deferred_io_init() regardless, hitting BUG_ON(!fbdefio).
Fix this by only invoking fb_deferred_io_init() if the allocation
succeeded, and checking for the error.
The driver already supports operating without deferred I/O, so in either
case fall back to that by setting info->fbdefio to NULL.
The ignored return value was introduced in commit 56c134f7f1b5 ("fbdev:
Track deferred-I/O pages in pageref struct").
However, the BUG_ON() issue originates from the earlier
commit 5bea1fbf9423 ("staging: udlfb: fix incorrect fb_defio
implementation for multiple framebuffers"), so target that for the fix.
Fixes: 5bea1fbf9423 ("staging: udlfb: fix incorrect fb_defio implementation for multiple framebuffers")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently picolcd_init_framebuffer() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due
to an allocation failure) info->fbdefio_state is left NULL.
When the file is subsequently opened, fb_open() will dereference a NULL
pointer (calling fb_deferred_io_open()).
Fix this by checking for the error.
Also correct cleanup ordering - defio is initialised after the sysfs file,
so cleanup defio first.
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently xenfb_probe() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due
to an allocation failure) info->fbdefio_state is left NULL.
When the file is subsequently opened, fb_open() will dereference a NULL
pointer (calling fb_deferred_io_open()).
Fix this by checking for the error.
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently ssd1307fb_probe() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due
to an allocation failure) info->fbdefio_state is left NULL.
When the file is subsequently opened, fb_open() will dereference a NULL
pointer (calling fb_deferred_io_open()).
Fix this by checking for the error.
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
framebuffer_alloc() returns zeroed memory, so info->modelist starts out
with NULL next and prev pointers. The list head is initialized only
later, by fb_videomode_to_modelist() or by do_register_framebuffer().
The "fix potential memory leak" commits listed below added
fb_destroy_modelist(&info->modelist) to the probe error paths of s3fb,
tdfxfb, tridentfb, i740fb and carminefb. These paths can run before
the list head is initialized:
- s3fb, tdfxfb, tridentfb and i740fb call fb_videomode_to_modelist()
only after a successful EDID read, and tridentfb can also hit the
error path on an ioremap() or kmalloc() failure before that;
- carminefb jumps to the error path when fb_find_mode() fails, before
its fb_videomode_to_modelist() call.
fb_destroy_modelist() then dereferences the NULL head. Reproduced on
Debian 12 (6.1.180) by binding s3fb to a VGA device without EDID and
forcing fb_alloc_cmap() to fail:
s3fb 0000:00:03.0: cannot allocate colormap
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:fb_destroy_modelist+0x10/0x80
Call Trace:
s3_pci_probe.cold+0x12b/0x2bf [s3fb]
local_pci_probe+0x41/0x80
pci_device_probe+0xc3/0x240
really_probe+0xde/0x380
__driver_probe_device+0x84/0x150
driver_probe_device+0x1f/0x90
__driver_attach+0xce/0x1c0
bus_for_each_dev+0x87/0xd0
bus_add_driver+0x1ae/0x200
driver_register+0x89/0xe0
do_one_initcall+0x59/0x220
do_init_module+0x4a/0x1f0
Initialize the list head in framebuffer_alloc(), so info->modelist is
always a valid, possibly empty, list and fb_destroy_modelist() is safe
on every error path. Keep the lazy initialization in
do_register_framebuffer(), as drivers that embed struct fb_info rather
than calling framebuffer_alloc() still depend on it.
Fixes: 3b0ed04bc852 ("fbdev: s3fb: fix potential memory leak in s3_pci_probe()")
Fixes: bb019d755366 ("fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()")
Fixes: 7a35ec619d9a ("fbdev: tridentfb: fix potential memory leak in trident_pci_probe()")
Fixes: 5936063409af ("fbdev: i740fb: fix potential memory leak in i740fb_probe()")
Fixes: 6fcca16a2b19 ("fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()")
Cc: stable@vger.kernel.org
Signed-off-by: Andrey Misiurov <andrey.misyrov@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
dlfb_setup_modes() frees info->modelist with fb_destroy_modelist() and
rebuilds it, but fbcon holds raw pointers into that list in
fb_display[i].mode and nothing un-publishes them the way
do_unregister_framebuffer() and store_modes() do with
fbcon_delete_modelist(). The function does refuse to install a new mode
while the framebuffer has users (dlfb->fb_count != 0), but only after the
list is already destroyed. Reached from the 0666 "edid" sysfs attribute,
an unprivileged write to /sys/class/graphics/fb0/edid therefore fails with
-EINVAL and still leaves every fb_display[i].mode dangling; the next
console switch reads the freed fb_videomode in fb_videomode_to_var().
Test fb_count before touching the list. fbcon takes a reference through
fbcon_open(), so that condition covers exactly the states in which
fb_display[] points into the list, and the errno returned to userspace is
unchanged.
BUG: KASAN: slab-use-after-free in fb_videomode_to_var (drivers/video/fbdev/core/modedb.c:905)
Read of size 4 at addr ffff8880107b449c by task kworker/1:1/47
Workqueue: events console_callback
Call Trace:
fb_videomode_to_var (drivers/video/fbdev/core/modedb.c:905)
display_to_var (drivers/video/fbdev/core/fbcon.c:998)
fbcon_switch (drivers/video/fbdev/core/fbcon.c:2182)
redraw_screen (drivers/tty/vt/vt.c:994)
complete_change_console (drivers/tty/vt/vt_ioctl.c:1141)
console_callback (drivers/tty/vt/vt.c:3358)
process_one_work (kernel/workqueue.c:3396)
worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
...
The buggy address is located 28 bytes inside of
freed 96-byte region [ffff8880107b4480, ffff8880107b44e0)
Cc: stable@vger.kernel.org
Fixes: 7d9485e2c53c ("Staging: udlfb: Add functions to expose sysfs metrics and controls")
Reported-by: co+ed9902f2e44184d9@bugs.sh
Closes: https://lore.kernel.org/all/1jSCSNaDKmuUG7h40rTsSl1rMaSwdlJef4rp%40bugs.sh/
Assisted-by: Claude:claude-opus-5
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://lore.kernel.org/all/1jSCSNaDKmuUG7h40rTsSl1rMaSwdlJef4rp%40bugs.sh/
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The ovl_* files documented in
Documentation/ABI/testing/sysfs-devices-platform-sh_mobile_lcdc_fb no
longer exist.
Commit a979182a2453 ("fbdev: lcdcfb: Register sysfs groups through driver
core") moved the attributes from each overlay's framebuffer device to
the platform driver's dev_groups and renamed them overlay_*. There is
now only one set of attributes for the whole LCDC. The callbacks still
expect dev_get_drvdata() to return a struct fb_info, but the platform
device holds struct sh_mobile_lcdc_priv, so they access the wrong
structure.
Restore the documented names and register the group on each overlay's
framebuffer device with device_add_groups(). Remove it with
device_remove_groups() before unregistering the framebuffer. Skip
creation when dev_of_fbinfo(info) is NULL, as the old device_create_file()
calls did.
Drop the CONFIG_FB_DEVICE guard, since the driver already depends on it.
Fixes: a979182a2453 ("fbdev: lcdcfb: Register sysfs groups through driver core")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The HP EliteBook x360 1030 G2 is a 2-in-1 convertible with volume up and
volume down buttons on the side of the chassis. These buttons are reported
through the intel-hid 5 button array, but the array is not enabled by
default on this model, so pressing them produces no input events at all.
Loading the driver with enable_5_button_array=1 makes both buttons work as
KEY_VOLUMEUP and KEY_VOLUMEDOWN. Add the model to button_array_table so the
array is enabled automatically.
Signed-off-by: Mattias Andersson <86.mattias@gmail.com>
Link: https://patch.msgid.link/20261005192915.25392-1-86.mattias@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Use bool for the local is_thinkpad variable because it only stores a
boolean value.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/20261005163130.20375-2-blum@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Commit d6479c25ecef ("platform/x86: thinkpad_acpi: Use
input_device_enabled()") changed hotkey_poll_setup() to acquire
tpacpi_inputdev->mutex and call input_device_enabled(tpacpi_inputdev).
However, the input core already holds dev->mutex when invoking a
device's open() and close() callbacks. Because hotkey_inputdev_open()
and hotkey_inputdev_close() call into hotkey_poll_setup(), attempting to
acquire tpacpi_inputdev->mutex again results in an immediate
self-deadlock.
Additionally, locking tpacpi_inputdev->mutex inside hotkey_poll_setup()
while holding hotkey_mutex introduces an ABBA lock ordering inversion
with hotkey_inputdev_open() and hotkey_inputdev_close(), which acquire
hotkey_mutex while holding tpacpi_inputdev->mutex. Finally,
input_inhibit_device() calls dev->close() before setting dev->inhibited,
so input_device_enabled() still returns true inside
hotkey_inputdev_close().
Track whether the input device is active in a driver-local boolean
protected by hotkey_mutex instead of locking tpacpi_inputdev->mutex and
querying input_device_enabled().
Fixes: d6479c25ecef ("platform/x86: thinkpad_acpi: Use input_device_enabled()")
Reported-by: Ali Ahmet Memiş <aliamemis@disroot.org>
Closes: https://lore.kernel.org/all/20260930075829.53484-1-aliamemis@disroot.org/
Reported-by: Qiling Zhu <kmatzkaczor244@gmail.com>
Closes: https://lore.kernel.org/all/asDVVtAXt8YVbZ3C@ThinkPad/
Reported-by: Oleksii Kryvenko <diver.ua@gmail.com>
Closes: https://lore.kernel.org/all/20261010002413.30007-1-krivenko@itstep.org/
Tested-by: Ali Ahmet Memiş <aliamemis@disroot.org>
Assisted-by: LLM
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20261010031827.3306077-1-dmitry.torokhov@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
intel_vsec_walk_header() used to return a bool that was true when devices
were found. It was converted to return 0 on success and a negative errno
on failure, but the boolean test in intel_vsec_get_features() was left
unchanged, so its meaning is now inverted.
A successful walk returns 0 and leaves found set to false, while a failed
walk returns an error that evaluates to true. When no other capabilities
are present, intel_vsec_pci_init() then returns -ENODEV even though the
auxiliary devices were created, and the driver core tears them back down.
This affects platforms that have no DVSEC or VSEC capabilities and
describe their features through device_data instead, which today means
DG1. Test the return value for success explicitly.
Fixes: a6ce8bf3c993 ("platform/x86/intel/vsec: Return real error codes from registration path")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://patch.msgid.link/20261001220351.1592138-3-david.e.box@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
EC SCI events require I2C transfers to retrieve the event information.
During system resume, an SCI interrupt can be delivered before the I2C
controller is ready to handle transfers, resulting in failed event reads:
geni_i2c a84000.i2c: error turning SE resources:-13
qcom-hamoa-ec 3-0076: Failed to read EC SCI Event: -13
Keep SCI interrupt handling disabled across system sleep so that EC
events are processed only while the I2C controller is available. This
prevents event reads from racing with the controller's suspend and
resume transitions.
Fixes: 5c44f48e91de ("platform: arm64: Add driver for EC found on Qualcomm reference devices")
Reviewed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20261001-qcom-hamoa-ec-suspend-irq-v2-1-ec71a7cdec79@oss.qualcomm.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The ASUS ROG Flow Z13 (GZ302EA/GZ302EAC) wakes up from suspend-to-idle
without any user input. With PM debug messages enabled, each unexpected
wakeup shows the EC raising IRQ1 at the same time as the ACPI SCI:
PM: Triggering wakeup from IRQ 9
PM: Triggering wakeup from IRQ 1
ACPI: EC: Query(0xa3) started
ACPI: PM: Wakeup after ACPI Notify sync
EC query 0xa3 only notifies the battery of a status change, which
happens when it transitions between Charging and Full while on AC.
The ACPI core correctly treats that as a non-wakeup event and cancels
the SCI wakeup, but the IRQ1 wakeup remains pending and resumes the
system. i8042 debugging confirms that the keyboard controller has no
data at that point ("Interrupt 1, without any data").
The detachable keyboard on this device is a USB device, so disabling
the i8042 wakeup source does not result in any functional loss. With
serio0 wakeup disabled, the same battery event is processed during
suspend-to-idle and the system stays asleep.
Add the spurious_8042 quirk for it. The GZ302EAC reports sys_vendor
"ASUS" while the GZ302EA reports "ASUSTeK COMPUTER INC.", so match on
"ASUS" and on the "GZ302EA" board name to cover both models.
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260929181655.26105-1-matthew.schwartz@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The PM notifier iterates over every uncore frequency instance to restore
user-configured MSR_UNCORE_RATIO_LIMIT values after resume. Entries that
have never been configured legitimately have stored_uncore_data set to
zero.
The refactoring that split common and enumeration code changed the
iteration from active control CPUs to all allocated instances. It also
changed the skip for an invalid or unconfigured entry from continue to
return, causing that entry to terminate the entire restore operation.
On a multi-package or multi-die system, configuring only a later instance
therefore leaves its limit unrestored after suspend, hibernation, or
restore if an earlier entry is invalid or unconfigured.
Use continue to skip only the current entry and restore all remaining
configured instances.
Fixes: dbce412a7733 ("platform/x86/intel-uncore-freq: Split common and enumeration part")
Cc: stable@vger.kernel.org
Tested-by: Yijia Wang <wangyijia.yeah@bytedance.com>
Signed-off-by: Guixiong Wei <weiguixiong@bytedance.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20260929163133.14326-2-weiguixiong@bytedance.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Add the PCI root complex device ID (0x1b20) for AMD Family 1Ah model DCh
to the PMC driver. This new model shares the same PMC configuration as
the existing Family 1Ah model 80h, so reuse amd_1ah_m80_cpu_info for the
device data.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260929155317.1710272-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
reuse
The driver stores its state in a single file-scope static struct
amd_pmc_dev, which is reused on every bind. Its regbase, smu_virt_addr,
stb_virt_addr and fch_virt_addr members are MMIO mappings created with
devm_ioremap().
On unbind the driver core unmaps these mappings, but it does not clear
the pointers in the static struct. Since the struct is not freed, the
members keep pointing at the now-unmapped addresses.
On the next bind, the probe path re-maps a region only when its pointer
is still NULL, so the stale pointer is reused and the following
memcpy_fromio()/ioread32() touches freed MMIO, causing use-after-unmap
crash. Clear these pointers in amd_pmc_remove() so the next probe re-maps
them instead of reusing stale ones.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Fixes: 156ec4731cb22b ("platform/x86: amd-pmc: Add AMD platform support for S2Idle")
Link: https://patch.msgid.link/20260929155609.1712638-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The Thinkpad L14 Gen3 with DMI product name 21C5 is affected by the same
s2idle resume stall as the already listed 21C6 variant: resuming from
s2idle blocks for several seconds before the kernel resumes.
DMI_MATCH() performs substring matching, so a "21C5" entry also covers
SKUs such as 21C5S05800. Add the 21C5 model to the existing
quirk_s2idle_bug table.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222070
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221273
Signed-off-by: Bruno BOI <bruno.boi@bobtopus.eu>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/20260928160607.679319-1-bruno.boi@bobtopus.eu
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Commit dee82409a883 ("platform/x86: msi-wmi: Reformat
msi_wmi_notify()") turned the condition for reporting a hotkey into
an early return, but only negated the brightness key comparisons,
not the backlight check. As a result, when the driver registers its
own backlight device, all WMI hotkeys are now dropped, instead of all
of them being reported as before.
Restore the original behavior: only drop the brightness keys, and
only when brightness is handled by the ACPI video driver.
This was found by code inspection. It is not tested on hardware that
uses the vendor backlight; on an MSI Katana 15 B13VFK (no vendor
backlight) hotkey handling is unchanged.
Fixes: dee82409a883 ("platform/x86: msi-wmi: Reformat msi_wmi_notify()")
Signed-off-by: Patryk Pilichowski <pat.pilichowski@gmail.com>
Link: https://patch.msgid.link/20260925213333.198058-1-pat.pilichowski@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
amd_hfi_init() manually registers a platform device with
platform_device_register_simple() before registering the driver. This
device has no ACPI companion, so when amd_hfi_probe() runs for it the
acpi_match_device() check fails and probe returns -ENODEV.
The driver already advertises an ACPI match table, so the ACPI subsystem
enumerates the real AMDI0104 device and binds it to the driver. The
manually created device therefore serves no purpose: it never binds and
lingers as an unbound platform device, wasting memory and cluttering the
device tree.
Drop the manual platform_device_register_simple() and the device that
tracked it, and rely solely on ACPI enumeration. The CPU feature gating
in amd_hfi_init() is retained so the driver is only registered on
supported hardware.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://patch.msgid.link/20260921170411.1149960-4-mario.limonciello@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
amd_hfi_fill_metadata() parses CPU core ranking data out of the
firmware-provided PCC shared memory but trusts two values it should not:
- n_bitmaps is used to bound the outer loop that reads the APIC ID
bitmaps from table_data[], but it is never validated against the size
of the shared memory region (pcct_ext->length). A firmware-supplied
count larger than the region reads past the end of table_data.
- When resolving the base of the ranking data for a processor, the
pointer is shifted by an extra "i * nr_class" term, where i is the
current bitmap index. The per-processor offset is already applied
through apic_index, which uses the running count of active processors
(apic_start). The extra shift compounds for every logical processor
beyond the first bitmap (APIC ID >= 32), reading out of bounds.
Both result in out-of-bounds reads that can corrupt the ranking metrics,
oops, or otherwise destabilise the system.
Reject an n_bitmaps value that would not fit within the shared memory
region, and drop the bogus "i * nr_class" term so the ranking data is
addressed only through its correct per-processor offset.
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: d4e95ea7a78e ("platform/x86: hfi: Parse CPU core ranking data from shared memory")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260921170411.1149960-3-mario.limonciello@amd.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
amd_hfi_probe() registers CPU hotplug callbacks with
cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, ...) and schedules the static
sched_amd_hfi_itmt_work work item, but amd_hfi_remove() tears down
neither. The dynamically assigned hotplug state returned by
cpuhp_setup_state() is discarded, so cpuhp_remove_state() can never be
called, and the pending work is never cancelled.
After the module is unloaded and its memory is freed, any subsequent CPU
hotplug event or execution of the scheduled work dereferences the stale
callback and work function pointers, resulting in a use-after-free and
kernel panic.
Store the hotplug state returned by cpuhp_setup_state() and, on removal,
call cpuhp_remove_state() to unregister the callbacks and
cancel_work_sync() to flush the scheduled work before the module memory
goes away.
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: bb20421c05fc ("platform/x86: hfi: Add online and offline callback support")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260921170411.1149960-2-mario.limonciello@amd.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
A user has reported that the LAPKC71E variant of the Intel NUC x15
also works with the uniwill-laptop driver. The difference between the
LAPKC71E and the LAPKC71F seems to be the dedicated NVidia GPU module.
Add support for this device as well. It is suspected that the LAPKC71F
also supports the new UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL feature, but
this would need to be verified on real hardware.
Link: https://github.com/Wer-Wolf/uniwill-laptop/issues/17
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261007144101.323289-6-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The LED subsystem specifies that LEDs capable of producing arbitrary
colors (like RGB) should label themselfs as "rgb" instead of
"multicolor".
Use the "rgb" label instead of the "multicolor" label to fix
detection by userspace applications.
Reported-by: Werner Sembach <wse@tuxedocomputers.com>
Closes: https://github.com/Wer-Wolf/uniwill-laptop/issues/18
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261007144101.323289-5-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Intel NUC 9 Extreme (Queens County) devices have a separate bit
inside the EC_ADDR_LIGHTBAR_AC_CTRL register for enabling the
breathing animation in s2idle mode.
Add support for this additional setting.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261007144101.323289-4-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
It turns out that some models require the lightbar to be activated
in order to display the rainbow animation, so users have to access
both the "rainbow_animation" sysfs attribute and the LED sysfs
interface when enabling the rainbow animation. This can cause short
glitches when the lightbar was previously disabled.
Fix this by replacing the sysfs attribute with a custom LED trigger
called "uniwill-rainbow". Selecting this trigger will atomically
activate the lightbar and enable the rainbow animation mode. This
can potentially break userspace applications using the old sysfs
attribute, but so far no such application is known to exist (yet).
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261007144101.323289-3-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The LED sysfs ABI now allows us to specify the maximum values for the
global brightness and the color intensity values independently. At the
same time the maximum brightness value reported for the lightbar (like
200) does not match the real value supported by the hardware (1),
potentially confusing users.
Report the correct maximum brightness value and only use the intensity
values for controlling the lightbar color.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261007144101.323289-2-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The PCSpecialist Recoil 16 AMD / TUXEDO Stellaris 16 Gen7 chassis has an
"Sc" key next to F12, meant to rotate the lay-flat screen by 180 degrees.
It reports WMI event 0xD0, which is currently reported as KEY_UNKNOWN.
Map it to KEY_ROTATE_DISPLAY.
Signed-off-by: Mohamed Jouini <amad3v@gmail.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261008135624.3520849-3-amad3v@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The PCSpecialist Recoil 16 AMD is a rebadged TUXEDO Stellaris 16 Gen7 AMD
but reports sys_vendor "PCSpecialist" and board name "X6FR57TY", so the
existing entry does not match it. Use the Stellaris 16 Gen7 AMD feature
set.
Signed-off-by: Mohamed Jouini <amad3v@gmail.com>
Link: https://patch.msgid.link/20261008135624.3520849-2-amad3v@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
ec_dbgfs_cmd_write() copies user input into a zero-initialized stack
buffer and passes it to sscanf(). A write that overwrites the entire
buffer leaves no terminator, so the subsequent parsing can read beyond
the buffer.
Limit the copy to leave room for the trailing NUL.
Fixes: 6cca83d498bd ("Platform: OLPC: move debugfs support from x86 EC driver")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Link: https://patch.msgid.link/20260926121250.3258285-2-yaojiale02@163.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
On HP systems with a large number of BIOS attribute instances, the
kzalloc_objs() allocation in hp_alloc_ordered_list_data() and
hp_alloc_string_data() can fail when physical memory is fragmented,
leaving the driver unable to register those attributes.
The same failure mode was already fixed for enumeration_data in
hp_alloc_enumeration_data() by commit 916727cfdb72 ("platform/x86:
hp-bioscfg: Support allocations of larger data"), reported on HP
Z2 Tower G9 and Z4 G5 Workstation systems:
https://bugs.debian.org/1127612
order-list-attributes.c and string-attributes.c use the identical
allocation pattern and are still affected. Apply the same fix: fall back
to kvzalloc_objs()/kvfree() instead of kzalloc_objs()/kfree(), and
return -EINVAL early when the instance count is zero.
Link: https://bugs.debian.org/1127612
Signed-off-by: Artem Maksimov <okuroshioffc@gmail.com>
Link: https://patch.msgid.link/20260925194454.6850-1-okuroshioffc@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
register_platform_devices() registers the battery, LED, and watchdog
platform devices in sequence. If LED registration fails, the battery
device remains registered. If watchdog registration fails, the LED and
battery devices remain registered.
These failure paths leave successful platform_device_register_data()
calls without the matching platform_device_unregister() calls.
Add an unwind ladder to unregister previously registered platform
devices in reverse order before returning the registration error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: dd123e62bded ("platform/x86: simatic-ipc: add main driver for Siemens devices")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://patch.msgid.link/20260924115617.1578309-1-lgs201920130244@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
On certain 2025 Lenovo laptops, such as the Yoga Pro 7 14ASP10 and Legion
Pro 7 16AFR10H, a switch on the side disables the camera. This is handled
by the firmware, which also sends event 0x0d (camera disabled) or 0x0c
(camera enabled) through the WMI event GUID handled with
ideapad_wmi_context_fn_keys. These events are currently reported as
KEY_UNKNOWN.
Other Lenovo laptops expose a similar camera switch through a separate WMI
GUID, which lenovo-wmi-camera reports as SW_CAMERA_LENS_COVER since
commit d98bf6a6ed61 ("platform/x86: lenovo-wmi-camera: Use
SW_CAMERA_LENS_COVER instead of KEY_CAMERA_ACESS"). That driver does not
bind on these laptops, so map the WMI events to SW_CAMERA_LENS_COVER as
well via sparse keymap KE_SW.
Unfortunately, there is no programmatic way to determine the current
state on the mentioned devices until the next relevant WMI key event.
Therefore, no switch event is emitted on probe or resume, intentionally
leaving the default (0, i.e., no covered) or the last state unchanged,
and let the first relevant WMI key event to correct it. This should
fulfill the requirement of using the switch events to show an OSD.
AFAIK, no userspace software queries its state via EVIOCGBIT(EV_SW).
The above behavior is basically the same as lenovo-wmi-camera, except
that SW_CAMERA_LENS_COVER is always exposed even on devices with no
camera switch. It's because, again, there is no programmatic way to
determine the switch's existence on the mentioned devices. Doing so
should be harmless as long as no switch event is emitted and eliminates
the need to dynamically register an additional input device at run time
like lenovo-wmi-camera does. Even if a userspace program does query the
switch's state via EVIOCGBIT(EV_SW), the returned state will always be 0
(not covered), which is the correct state on unsupported devices.
Co-developed-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Tested-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Huang Wei <huangwei@kylinos.cn>
Link: https://patch.msgid.link/20260924-ideapad-laptop-camera-sw-v3-1-922ea6a9fff4@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
telemetry_def_get_trace_verbosity() returns success without initializing
the output verbosity value.
The default telemetry operations are installed when the core driver is
initialized and again by telemetry_clear_pltdata() when the platform
driver is removed. The telemetry debugfs files can remain available after
the platform driver removal.
A subsequent read of pss_trace_verbosity or ioss_trace_verbosity calls
telemetry_get_trace_verbosity(), which may use the default callback and
return success without setting verbosity. The uninitialized value is then
passed to seq_printf().
Validate the output pointer and initialize the default verbosity to zero
so callers never use an uninitialized value after a successful call.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 378f956e3f93 ("platform/x86: Add Intel Telemetry Core Driver")
Signed-off-by: Aleksandrova Alyona <aga@itb.spb.ru>
Link: https://patch.msgid.link/20260917110812.2831-1-aga@itb.spb.ru
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
There are several simple and dumb wrappers of
ap{mf,ts}_if_call_store_buffer() defined as global symbols, which are
heavily used by multiple layers and become symbols against linkage. This
bloats the size of the module.
Since is_apmf_func_supported() has been converted, convert the mentioned
wrappers into static inline functions to get rid of the overhead of
function outlining and linkage, and shrink the module
(!CONFIG_AMD_PMF_DEBUG && CONFIG_AMD_PMF_UTIL_SUPPORT) size by 515 Bytes
(GCC 16 -O2):
text data bss total filename (before)
26261 31264 2768 60293 amd-pmf.ko
text data bss total filename (after)
26046 30964 2768 59778 amd-pmf.ko
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260901-amd-pmf-fix-outlining-v1-5-b54ff94d3d45@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The Smart PC TA interfaces have a simple and dumb helper function
defined as a global symbol, which is used by other layers and becomes a
symbol against linkage. This bloats the size of the module.
Convert it into a static inline function to get rid of the overhead of
function outlining and linkage, and shrink the module
(!CONFIG_AMD_PMF_DEBUG && CONFIG_AMD_PMF_UTIL_SUPPORT) size by 208 Bytes
(GCC 16 -O2):
text data bss total filename (before)
26341 31392 2768 60501 amd-pmf.ko
text data bss total filename (after)
26261 31264 2768 60293 amd-pmf.ko
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260901-amd-pmf-fix-outlining-v1-4-b54ff94d3d45@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The SPS Layer has a simple and dumb helper function defined as a global
symbol, which is heavily used by other layers and becomes a symbol
against linkage. This bloats the size of the module.
Convert it into a static inline function to get rid of the overhead of
function outlining and linkage, and shrink the module
(!CONFIG_AMD_PMF_DEBUG && CONFIG_AMD_PMF_UTIL_SUPPORT) size by 252 Bytes
(GCC 16 -O2):
text data bss total filename (before)
26533 31452 2768 60753 amd-pmf.ko
text data bss total filename (after)
26341 31392 2768 60501 amd-pmf.ko
There are also two duplicated prototypes, so remove one of them as well.
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260901-amd-pmf-fix-outlining-v1-3-b54ff94d3d45@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
