summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-05-12HID: hid-oxp: Add Second Generation RGB ControlDerek J. Clark
Adds support for the second generation of RGB Control for OneXPlayer devices. The interface mirrors the first generation, with some differences to how messages are formatted. Some devices have both a GEN1 MCU for RGB control and a GEN2 MCU for button mapping. To avoid conflicts, quirk these devices to skip RGB setup for the GEN2_USAGE_PAGE. Reviewed-by: Zhouwang Huang <honjow311@gmail.com> Tested-by: Zhouwang Huang <honjow311@gmail.com> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12HID: hid-oxp: Add OneXPlayer configuration driverDerek J. Clark
Adds OneXPlayer HID configuration driver. In this initial driver patch, add the RGB interface for the first generation of HID based RGB control. This interface provides the following attributes: - brightness: provided by the LED core, this works in a fairly unique way on this device. The hardware accepts 5 brightness values (0-4), which affects the brightness of the multicolor and animated effects built into the MCU firmware. For monocolor settings, the device expects the hardware brightness value to be pushed to maximum, then we apply brightness adjustments mathematically based on % (0-100). This leads to some odd conversion as we need the brightness slider to reach the full range, but it has no affect when incrementing between the division points for other effects. - multi-intensity: provided by the LED core for red, green, and blue. - effect: Allows the MCU to set 19 individual effects. - effect_index: Lists the 19 valid effect names for the interface. - enabled: Allows the MCU to toggle the RGB interface on/off. - enabled_index: Lists the valid states for enabled. - speed: Allows the MCU to set the animation rate for the various effects. - speed_range: Lists the valid range of speed (0-9). The MCU also has a few odd quirks that make sending multiple synchronous events challenging. It will essentially freeze if it receives another message before it has finished processing the last command. It also will not reply if you wait on it using a completion. To get around this, we do a 200ms sleep inside a work queue thread and debounce all but the most recent message using a 50ms mod_delayed_work. This will cache the last write, queue the work, then return so userspace can release its write thread. The work queue is only used for brightness/multi-intensity as that is the path likely to receive rapid successive writes. Reviewed-by: Zhouwang Huang <honjow311@gmail.com> Tested-by: Zhouwang Huang <honjow311@gmail.com> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12HID: playstation: Clamp num_touch_reportsT.J. Mercier
A device would never lie about the number of touch reports would it? If it does the loop in dualshock4_parse_report will read off the end of the touch_reports array, up to about 2 KiB for the maximum number of 256 loop iteraions. The data that is read is emitted via evdev if the DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by clamping the num_touch_reports value provided by the device to the maximum size of the touch_reports array. Fixes: 752038248808 ("HID: playstation: add DualShock4 touchpad support.") Cc: stable@vger.kernel.org Reported-by: Xingyu Jin <xingyuj@google.com> Signed-off-by: T.J. Mercier <tjmercier@google.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12HID: magicmouse: Prevent out-of-bounds (OOB) read during DOUBLE_REPORT_IDLee Jones
It is currently possible for a malicious or misconfigured USB device to cause an out-of-bounds (OOB) read when submitting reports using DOUBLE_REPORT_ID by specifying a large report length and providing a smaller one. Let's prevent that by comparing the specified report length with the actual size of the data read in from userspace. If the actual data length ends up being smaller than specified, we'll politely warn the user and prevent any further processing. Signed-off-by: Lee Jones <lee@kernel.org> Reviewed-by: Günther Noack <gnoack@google.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12HID: mcp2221: fix OOB write in mcp2221_raw_event()Florian Pradines
mcp2221_raw_event() copies device-supplied data into mcp->rxbuf at offset rxbuf_idx without checking that the copy fits within the destination buffer. A device responding with up to 60 bytes to a small I2C/SMBus read can overflow the buffer. Add a rxbuf_size field to struct mcp2221, set it alongside rxbuf in mcp_i2c_smbus_read(), and check rxbuf_idx + data[3] <= rxbuf_size before the memcpy. Reported-by: Benoît Sevens <bsevens@google.com> Signed-off-by: Florian Pradines <florian.pradines@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12HID: multitouch: Fix Yoga Book 9 14IAH10 touchscreen misclassificationDave Carey
The Lenovo Yoga Book 9 14IAH10 (83KJ) (17EF:6161) firmware includes a HID_DG_TOUCHPAD application collection designed for the Windows inbox HID driver's Win8 PTP touchpad mode. On Linux the HID_DG_TOUCHSCREEN collections provide the correct direct-touch interface. The presence of the touchpad collection causes hid-multitouch to misclassify the touchscreen nodes as indirect buttonpads, leaving them non-functional. Within the touchpad collection: - HID_UP_BUTTON usages trigger the touchscreen-with-buttons heuristic that sets INPUT_MT_POINTER on the touchscreen applications. - The HID_DG_TOUCHPAD application itself sets INPUT_MT_POINTER via mt_allocate_application(), propagating to all touchscreen nodes. - A HID_DG_BUTTONTYPE feature (report 0x51) returns MT_BUTTONTYPE_CLICKPAD, setting td->is_buttonpad = true for the entire device. Additionally, the firmware resets if any USB control request arrives while the CDC-ACM interface is initialising (~1.18 s after enumeration). The Win8 compliance blob (0xff00:0xc5) and Contact Count Max feature reports in the touchscreen collections trigger GET_REPORT calls at probe that hit this window. Surface Switch (0x57) and Button Switch (0x58) feature reports are sent by mt_set_modes() on every input-device open and close, repeatedly hitting this window throughout device lifetime. The firmware also leaves a persistent ghost contact in its contact buffer (contact ID 2, fixed coordinates, tip always asserted) on every enumeration. This ghost occupies a multitouch slot and prevents KWin from seeing a clean finger-lift, causing stuck touch state. The ghost is cleared when Input Mode is set via HID_REQ_SET_REPORT at probe. Fix using a report descriptor fixup in mt_report_fixup() and a class definition update: 1. Remove the entire HID_DG_TOUCHPAD application collection. Parsing HID short items from its header to the matching End Collection and closing the gap with memmove eliminates all three BUTTONPAD heuristics and the feature reports within the collection. 2. Neutralize the Win8 compliance blob feature reports remaining in the touchscreen collections by changing Usage Page 0xff00 to 0x0f00, preventing the case 0xff0000c5 branch in mt_feature_mapping() from issuing GET_REPORT. 3. Neutralize the Contact Count Max feature reports by changing usage 0x55 to 0x00; set maxcontacts = 10 in the class definition so the driver uses the correct contact limit without querying the device. 4. Neutralize Surface Switch (0x57) and Button Switch (0x58) feature report usages in the Device Configuration collection so mt_set_modes() does not issue HID_REQ_SET_REPORT for these on every input-device open/close. Input Mode (0x52) is intentionally left intact: the single HID_REQ_SET_REPORT at probe flushes the firmware's contact buffer and clears the persistent ghost contact. By probe time the cdc-acm driver has already satisfied the CDC-ACM init watchdog (~130 ms), so this request arrives safely after the reset window has closed. 5. Add MT_QUIRK_NOT_SEEN_MEANS_UP to the MT_CLS_YOGABOOK9I class so that contacts not present in a frame are released via INPUT_MT_DROP_UNUSED, preventing stale multitouch slots from lingering if the firmware omits a contact from a report. Signed-off-by: Dave Carey <carvsdriver@gmail.com> Tested-by: Dave Carey <carvsdriver@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12HID: sony: use input_dev from sc struct in sony_init_ff()Rosalie Wanders
This commit makes sony_init_ff() use the input_dev from the sc struct, this simplifies the sony_init_ff() function. Signed-off-by: Rosalie Wanders <rosalie@mailbox.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12coresight: fix missing error code when trace ID is invalidJie Gan
When coresight_path_assign_trace_id() cannot assign a valid trace ID, coresight_enable_sysfs() takes the err_path goto with ret still 0, returning success to the caller despite no trace session being started. Change coresight_path_assign_trace_id() to return int, moving the IS_VALID_CS_TRACE_ID() check inside it so it returns -EINVAL on failure and 0 on success. Update both callers to propagate this return value directly instead of inspecting path->trace_id after the call. Fixes: d87d76d823d1 ("Coresight: Allocate trace ID after building the path") Reviewed-by: James Clark <james.clark@linaro.org> Reviewed-by: Richard Cheng <icheng@nvidia.com> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: Leo Yan <leo.yan@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20260512-fix-trace-id-error-v4-1-eb3de789767a@oss.qualcomm.com
2026-05-12HID: usbhid: replace strlcat with better alternativesMahad Ibrahim
In preparation for the removal of the strlcat() API as per the KSPP, replace the string concatenation logic in hid-core, usbkbd, and usbmouse with struct seq_buf, which tracks the current write position and remaining space internally. The changes implemented include: - Replace device name and phys concatenation with seq_buf_puts(). - Include Struct seq_buf and its initialization. - Include header file of seq_buf. - Replace strlen() with seq_buf_used() on the string buffer which was tracked by seq_buf to increase speed. - Add size_t len in files which did not have it. - Use of strscpy with length in place of strlcat. Testing: This driver was compiled as a module as well as in-built in QEMU with the QEMU basic mouse, and QEMU basic keyboard. The testing was done in the following steps. - Add Hardware Mouse in QEMU checking the usbhid module. - Verify dmesg string name of mouse. - Blacklist hidusb module from auto-loading, and removing the module via rmmod. - Load usbmouse module, and reattach QEMU mouse. - Verify dmesg string name of mouse. - Repeat same procedure on usbkbd module. This aligns the driver with KSPP security guidelines. Link: https://github.com/KSPP/linux/issues/370 Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12HID: playstation: Add DualSense Edge extra button supportAaron Webster
The DualSense Edge controller (product ID 0x0df2) has four additional buttons compared to the standard DualSense: two front function buttons (Fn1 and Fn2) and two rear paddles (left and right). These are reported in bits 4-7 of buttons[2] in the input report. Map them to BTN_TRIGGER_HAPPY1 through BTN_TRIGGER_HAPPY4 so that userspace applications can use these extra inputs. An is_edge flag gates the extra button handling based on the product ID. Signed-off-by: Aaron Webster <awebster@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12HID: rakk: add support for Rakk Dasig X side buttonsKarl Cayme
The Rakk Dasig X gaming mouse has a faulty HID report descriptor that declares USAGE_MAXIMUM=3 (buttons 1-3) while actually sending 5 button bits (REPORT_COUNT=5). This causes the kernel to ignore side buttons (buttons 4 and 5). Fix by patching the descriptor to set USAGE_MAXIMUM=5 in the report_fixup callback. The mouse uses Telink vendor ID 0x248a with three product IDs for USB direct (0xfb01), wireless dongle (0xfa02), and Bluetooth (0x8266) connection modes. All three variants have the same bug at byte offset 17. Suggested-by: Terry Junge <linuxhid@cosmicgizmosystems.com> Signed-off-by: Karl Cayme <kcayme@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12HID: quirks: really enable the intended work around for appledisplayLukas Bulwahn
Commit c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for appledisplay") intends to add a quirk for kernels built with Apple Cinema Display support, but it refers to the non-existing config option CONFIG_APPLEDISPLAY, whereas the config option for Apple Cinema Display support is named CONFIG_USB_APPLEDISPLAY. Refer to the intended config option CONFIG_USB_APPLEDISPLAY in the ifdef directive. Fixes: c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for appledisplay") Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12HID: hid-sjoy: race between init and usageOliver Neukum
The driver uses an initial IO to set the device to a default state. That initialization is currently being done after the device node has been created. That means that the single buffer used for output can be altered while IO is in progress. Move the intialization before announcement to user space. Fixes: fac733f029251 ("HID: force feedback support for SmartJoy PLUS PS2/USB adapter") Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-05-12drm/i915/display: Copy color pipeline from plane in the primary joiner pipeChaitanya Kumar Borah
When copying plane color state in a joiner configuration, use the plane in the primary joiner pipe since it carries the pipeline number selected by the user-space. This assumes that all pipes in the joiner are symmetric in their plane color capabilities. Cc: stable@vger.kernel.org # v6.19+ Fixes: a78f1b6baf4d ("drm/i915/color: Add framework to program CSC") Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260511053213.3122314-2-chaitanya.kumar.borah@intel.com
2026-05-12bus: mhi: ep: Protect mhi_ep_handle_syserr() in the error pathManivannan Sadhasivam
All the callers of mhi_ep_handle_syserr() except mhi_ep_process_cmd_ring() are holding the 'state_lock' to avoid the race in setting the MHI state. So do the same in mhi_ep_process_cmd_ring() for sanity. Fixes: e827569062a8 ("bus: mhi: ep: Add support for processing command rings") Cc: stable@vger.kernel.org # 5.18 Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260302085612.18725-1-manivannan.sadhasivam@oss.qualcomm.com
2026-05-12bus: mhi: host: pci_generic: Add Telit FE910C04 modem supportDaniele Palmas
Add SDX35 based modem Telit FE910C04, reusing FN920C04 configuration. 01:00.0 Unassigned class [ff00]: Qualcomm Device 011a Subsystem: Device 1c5d:202a Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260512112458.1048999-1-dnlplm@gmail.com
2026-05-12bus: mhi: ep: Add missing state_lock protection for mhi_state accessSumit Kumar
The mhi_cntrl->mhi_state field should be protected by state_lock to ensure atomic state transitions. However, mhi_ep_power_up() access mhi_state without holding this lock, which can race with concurrent state transitions and lead to state corruption. Add proper state_lock protection around mhi_state access. Fixes: fb3a26b7e8af ("bus: mhi: ep: Add support for powering up the MHI endpoint stack") Fixes: f7d0806bdb1b3 ("bus: mhi: ep: Add support for handling SYS_ERR condition") Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260414-reset_worker_deadlock-v2-2-42fd682b45db@oss.qualcomm.com
2026-05-12bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()Sumit Kumar
There is a potential deadlock scenario in mhi_ep_reset_worker() where the state_lock mutex is acquired twice in the same call chain: mhi_ep_reset_worker() mutex_lock(&mhi_cntrl->state_lock) mhi_ep_power_up() mhi_ep_set_ready_state() mutex_lock(&mhi_cntrl->state_lock) <- Deadlock Fix this by releasing the state_lock before calling mhi_ep_power_up(). The lock is only needed to protect current MHI state read operation. The lock can be safely released before proceeding with the power up sequence. Fixes: 7a97b6b47353 ("bus: mhi: ep: Add support for handling MHI_RESET") Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260414-reset_worker_deadlock-v2-1-42fd682b45db@oss.qualcomm.com
2026-05-12firmware: arm_scmi: Introduce all_rates_get clock operationCristian Marussi
Add a clock operation to get the whole set of rates available to a specific clock: when needed this request could transparently trigger a full rate discovery enumeration if this specific clock-rates were previously only lazily enumerated. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://patch.msgid.link/20260508153300.2224715-16-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12firmware: arm_scmi: Fix OOB in scmi_clock_describe_rates_get_lazy()Geert Uytterhoeven
Lazy discovery of discrete rates works as follows: A. Grab the first three rates, B. Grab the last rate, if there are more than three rates. It is up to the SCMI provider implementation to decide how many rates are returned in response to a single CLOCK_DESCRIBE_RATES command. Each rate received is stored in the scmi_clock_rates.rates[] array, and .num_rates is updated accordingly. When more than 3 rates have been received after step A, the last rate may have been received already, and stored in scmi_clock_rates.rates[] (which has space for scmi_clock_desc.tot_rates entries). Hence grabbing the last rate again will store it a second time, beyond the end of the array. Fix this by only grabbing the last rate when we don't already have it. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://patch.msgid.link/20260508153300.2224715-15-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12firmware: arm_scmi: Use bound iterators to minimize discovered ratesCristian Marussi
Clock rates are guaranteed to be returned in ascending order for SCMI clock protocol versions greater than 1.0: in such a case, use bounded iterators to minimize the number of message exchanges needed to discover min and max rate. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://patch.msgid.link/20260508153300.2224715-14-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12firmware: arm_scmi: Use proper iter_response_bound_cleanup() nameGeert Uytterhoeven
The documentation speaks of the "iter_response_bound_cleanup()" protocol helper, while the actual helper is called "iter_response_cleanup()". Settle on the former name, because the helper is only needed when using bound-iterators. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20260508153300.2224715-13-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12firmware: arm_scmi: Fix bound iterators returning too many itemsGeert Uytterhoeven
When using a bound-iterator with an upper bound, commands are sent, and responses are received, until the upper bound is reached. However, it is up to the SCMI provider implementation to decide how many rates are returned in response to a single CLOCK_DESCRIBE_RATES command. If the last response contains rates beyond the specified upper bound, they are still passed up for further processing. This may lead to buffer overflows in unprepared callsites. While the imprecise bound handling may have been intentional (it was mentioned in the commit message introducing the code), it is still confusing for users, and may cause hard to debug crashes. Fix this by strictly enforcing the upper bound. Note that this may cause an increase in the number of CLOCK_DESCRIBE_RATES commands issued, as retrieving the last rate may no longer be done inadvertentently, but require its own command. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20260508153300.2224715-12-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12firmware: arm_scmi: Add bound iterators supportCristian Marussi
SCMI core stack provides some common helpers to handle in a unified way multipart message replies: such iterator-helpers, when run, currently process by default the whole set of discovered resources. Introduce an alternative way to run the initialized iterator on a limited range of resources. Note that the subset of resources that can be chosen is anyway limited by the SCMI protocol specification, since you are only allowed to choose the start-index on a multi-part enumeration NOT the end-index, so that the effective number of returned items by a bound iterators depends really on platform side decisions. Suggested-by: Etienne Carriere <etienne.carriere@foss.st.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260508153300.2224715-11-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12firmware: arm_scmi: Refactor iterators internal allocationCristian Marussi
Use cleanup handlers to manage iterator data structures. No functional change. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260508153300.2224715-10-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12firmware: arm_scmi: Harden clock parents discoveryCristian Marussi
Fix clock parents enumeration to account only for effectively discovered parents during enumeration, avoiding to trust the total number of parents declared upfront by the platform. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260508153300.2224715-9-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12firmware: arm_scmi: Make clock rates allocation dynamicCristian Marussi
Leveraging SCMI Clock protocol dynamic discovery capabilities, move away from the static per-clock rates allocation model in favour of a dynamic runtime allocation based on effectively discovered resources. No functional change. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260508153300.2224715-8-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12firmware: arm_scmi: Drop unused clock rate interfacesCristian Marussi
Only the unified interface exposing min_rate/max_rate is now used. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://patch.msgid.link/20260508153300.2224715-7-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12clk: scmi: Use new simplified per-clock rate propertiesCristian Marussi
Use the new min_rate and max_rate unified properties that provide the proper values without having to consider the clock type. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260508153300.2224715-6-cristian.marussi@arm.com Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12firmware: arm_scmi: Simplify clock rates exposed interfaceCristian Marussi
Introduce a new internal struct scmi_clock_desc so as to be able to hide, in the future, some of the needlessly public fields currently kept inside scmi_clock_info, while keeping exposed only the two new min_rate and max_rate fields for each clock. No functional change. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260508153300.2224715-5-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12clk: scmi: Use new determine_rate clock operationCristian Marussi
Use the Clock protocol layer determine_rate logic to calculate the closest rate that can be supported by a specific clock. No functional change. Cc: Brian Masney <bmasney@redhat.com> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260508153300.2224715-4-cristian.marussi@arm.com Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12firmware: arm_scmi: Add clock determine_rate operationCristian Marussi
Add a clock operation to help determining the effective rate, closest to the required one, that a specific clock can support. Calculation is currently performed kernel side and the logic is taken directly from the SCMI Clock driver: embedding the determinate rate logic in the protocol layer enables simplifications in the SCMI Clock protocol interface and will more easily accommodate further evolutions where such determine_rate logic into is optionally delegated to the platform SCMI server. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260508153300.2224715-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12clk: scmi: Fix clock rate roundingCristian Marussi
While the do_div() helper used for rounding expects its divisor argument to be a 32bits quantity, the currently provided divisor parameter is a 64bit value that, as a consequence, is silently truncated and a possible source of bugs. Fix by using the proper div64_ul helper. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Fixes: 7a8655e19bdb ("clk: scmi: Fix the rounding of clock rate") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260508153300.2224715-2-cristian.marussi@arm.com Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-12bus: mhi: host: pci_generic: Round up nr_irqs to power of twoJavier Achirica
When an MHI device uses standard MSI, the PCI core requires the allocated number of vectors to be a strict power of two. But devices will only ask for the irqs they need, so they might not be properly aligned. Make sure a power-of-2 number of vectors is requested. Signed-off-by: Javier Achirica <jachirica@gmail.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/CACixm21q7b_diEx5COZxVZm9EhZ0hnakM_WBjEWcCsznfWeniw@mail.gmail.com
2026-05-12wifi: ath10k: skip WMI and beacon transmission when device is wedgedKang Yang
In ath10k_wmi_cmd_send(), the current code detects ATH10K_STATE_WEDGED and sets ret to -ESHUTDOWN, but still proceeds to transmit pending beacons and calls ath10k_wmi_cmd_send_nowait(). This can lead to incorrect behavior, as WMI commands and beacons are still sent after the device has been marked as wedged, and the original -ESHUTDOWN return value may be overwritten by the result of the send path. The wedged state indicates the hardware is already unreliable, and no further interaction with firmware is expected or meaningful in this state. Fix this by skipping beacon transmission and the WMI send path entirely once ATH10K_STATE_WEDGED is detected, ensuring consistent return values and avoiding unnecessary firmware interaction. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189 Fixes: c256a94d1b1b ("wifi: ath10k: shutdown driver when hardware is unreliable") Signed-off-by: Kang Yang <kang.yang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260428061737.37-1-kang.yang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-05-12wifi: ath11k: fix error path leak in ath11k_tm_cmd_wmi_ftm()Nicolas Escande
This is similar to what was fixed by previous patches. We have a call to ath11k_wmi_cmd_send() which does check the return value, but forgot to free the related skb on error. Fixes: b43310e44edc ("wifi: ath11k: factory test mode support") Signed-off-by: Nicolas Escande <nico.escande@gmail.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260506134240.2284016-4-nico.escande@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-05-12wifi: ath11k: fix error path leaks in some WMI callsNicolas Escande
This is the same pattern that was previously identified as problematic: direct 'return ath11k_wmi_cmd_send(...)' will leak the skb in the error path if it is not explicitly handled. Fixes: c417b247ba04 ("ath11k: implement hardware data filter") Fixes: 9cbd7fc9be82 ("ath11k: support MAC address randomization in scan") Fixes: ba9177fcef21 ("ath11k: Add basic WoW functionalities") Fixes: fec4b898f369 ("ath11k: Add WoW net-detect functionality") Fixes: c3c36bfe998b ("ath11k: support ARP and NS offload") Fixes: a16d9b50cfba ("ath11k: support GTK rekey offload") Fixes: 652f69ed9c1b ("ath11k: Add support for SAR") Fixes: 0f84a156aa3b ("ath11k: Handle keepalive during WoWLAN suspend and resume") Signed-off-by: Nicolas Escande <nico.escande@gmail.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260506134240.2284016-3-nico.escande@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-05-12wifi: ath11k: fix error path leaks in some WMI WOW callsNicolas Escande
Fix two instances where we used to directly return the result of ath11k_wmi_cmd_send(...). Because we did not check the return value, we also did not free the skb in the error path. Fixes: 79802b13a492 ("ath11k: implement WoW enable and wakeup commands") Signed-off-by: Nicolas Escande <nico.escande@gmail.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260506134240.2284016-2-nico.escande@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-05-12net: ethernet: cs89x0: remove stale CONFIG_MACH_MX31ADS referenceEthan Nelson-Moore
The legacy ARM board file for MACH_MX31ADS was removed in commit c93197b0041d ("ARM: imx: Remove i.MX31 board files"), but a reference to it remained in the cs89x0 driver. Drop this unused code. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Fixes: c93197b0041d ("ARM: imx: Remove i.MX31 board files") Link: https://patch.msgid.link/20260509023732.42256-1-enelsonmoore@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-12net: ethernet: cortina: Carry over frag counterLinus Walleij
The gmac_rx() NAPI poll function assembles packets in an SKB from a ring buffer. If the ring buffer gets completely emptied during a poll cycle, we exit gmac_rx(), but the packet is not yet completely assembled in the SKB, yet the fragment counter frag_nr is reset to zero on the next invocation. Solve this by making the RX fragment counter a part of the port struct, and carry it over between invocations. Reset the fragment counter only right after calling napi_gro_frags(), on error (after calling napi_free_frags()) or if stopping the port. Reset it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Link: https://sashiko.dev/#/patchset/20260505-gemini-ethernet-fix-v2-1-997c31d06079%40kernel.org Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260509-gemini-ethernet-fixes-v1-3-6c5d20ddc35b@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-12net: ethernet: cortina: Make RX SKB per-portLinus Walleij
The SKB used to assemble packets from fragments in gmac_rx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both. Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead. Zero the pointer once we call napi_gro_frags(), on error (after calling napi_free_frags()) or if the port is stopped. Zero it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Link: https://sashiko.dev/#/patchset/20260505-gemini-ethernet-fix-v2-1-997c31d06079%40kernel.org Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260509-gemini-ethernet-fixes-v1-2-6c5d20ddc35b@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-12net: ethernet: cortina: No mapping is a dropped rxLinus Walleij
Increase stats.rx_dropped++ even if this is the first fragment (skb == NULL) so we are doing proper accounting. Fixes: b266bacba796 ("net: ethernet: cortina: Drop half-assembled SKB") Link: https://sashiko.dev/#/patchset/20260505-gemini-ethernet-fix-v2-1-997c31d06079%40kernel.org Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260509-gemini-ethernet-fixes-v1-1-6c5d20ddc35b@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-12PCI: amd-mdb: Assert PERST# on shutdownSai Krishna Musham
Add a shutdown handler for the AMD MDB PCIe host controller that asserts the PERST# signal via GPIO before the system powers off or reboots. This ensures the connected PCIe endpoint is held in reset during shutdown. Signed-off-by: Sai Krishna Musham <sai.krishna.musham@amd.com> [mani: removed conditional check since GPIO APIs return safely if desc is NULL] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260427121227.290604-1-sai.krishna.musham@amd.com
2026-05-12spi: ep93xx: fix error pointer deref after DMA setup failureJohan Hovold
The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. Fixes: e79e7c2df627 ("spi: ep93xx: add DT support for Cirrus EP93xx") Link: https://sashiko.dev/#/patchset/20260429091333.165363-1-johan%40kernel.org?part=10 Cc: stable@vger.kernel.org # 6.12 Cc: Nikita Shubin <nikita.shubin@maquefel.me> Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Nikita Shubin <nikita.shubin@maquefel.me> Link: https://patch.msgid.link/20260512074849.915143-1-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-12dm-inlinecrypt: add target for inline block device encryptionEric Biggers
Add a new device-mapper target "dm-inlinecrypt" that is similar to dm-crypt but uses the blk-crypto API instead of the regular crypto API. This allows it to take advantage of inline encryption hardware such as that commonly built into UFS host controllers. The table syntax matches dm-crypt's, but for now only a stripped-down set of parameters is supported. For example, for now AES-256-XTS is the only supported cipher. dm-inlinecrypt is based on Android's dm-default-key with the controversial passthrough support removed. Note that due to the removal of passthrough support, use of dm-inlinecrypt in combination with fscrypt causes double encryption of file contents (similar to dm-crypt + fscrypt), with the fscrypt layer not being able to use the inline encryption hardware. This makes dm-inlinecrypt unusable on systems such as Android that use fscrypt and where a more optimized approach is needed. It is however suitable as a replacement for dm-crypt. dm-inlinecrypt supports both keyring key and hex key, the former avoids the key to be exposed in dm-table message. Similar to dm-default-key in Android, it will fallabck to the software block crypto once the inline crypto hardware cannot support the expected cipher. Test: dmsetup create inlinecrypt_logon --table "0 `blockdev --getsz $1` \ inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-05-12ASoC: Add a new SoundWire enumeration helperMark Brown
Charles Keepax <ckeepax@opensource.cirrus.com> says: Add a new SoundWire enumeration helper function, many drivers have almost identical code in runtime resume so it makes sense to move this to the core. It is worth noting this is really step one of a larger process, there are a few drivers that do more custom things and are not covered by this series. But this series picks up the low hanging fruit and moves things in a good direction. The next step is to look at drivers that also wait at probe time, where the unattached_request flag is not going to be valid. Link: https://patch.msgid.link/20260512103022.1154645-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-12soundwire: Add a helper function to wait for device initialisationCharles Keepax
Add a new helper function to wait for the device to enumerate and be initialised by the SoundWire core. Most of the SoundWire drivers have very similar boiler plate code in their runtime resume, and that boiler plate tends to access various internals of the SoundWire structs which is a mild layering violation. Adding a new core helper function greatly eases both of these issues. Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260512103022.1154645-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-12gpio: regmap: Don't set a fixed direction lineLinus Walleij
If a GPIO line has a fixed direction, report an error if a consumer anyway tries to set the direction to something other than what it is hardcoded to. This didn't happen much before because what we supported was all lines input or output and then the implementer would probably not specify the direction registers, but with sparse fixed direction we can have a mixture so let's take this into account. As a consequence, since gpio_regmap_set_direction() can now fail, alter the semantics in gpio_regmap_direction_output() such that we first check if we can set the direction to output before we set the value and the direction. Suggested-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260507-regmap-gpio-sparse-fixed-dir-v1-1-a2e5855e2701%40kernel.org Signed-off-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Alex Elder <elder@riscstar.com> Tested-by: Alex Elder <elder@riscstar.com> Link: https://patch.msgid.link/20260511-regmap-gpio-sparse-fixed-dir-v3-2-1429ec453be7@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-12gpio: regmap: Support sparsed fixed directionLinus Walleij
On some regmapped GPIOs apparently only a sparser selection of the lines (not all) are actually fixed direction. Support this situation by adding an optional bitmap indicating which GPIOs are actually fixed direction and which are not. Link: https://lore.kernel.org/linux-gpio/20260501155421.3329862-10-elder@riscstar.com/ Tested-by: Alex Elder <elder@riscstar.com> Signed-off-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Alex Elder <elder@riscstar.com> Link: https://patch.msgid.link/20260511-regmap-gpio-sparse-fixed-dir-v3-1-1429ec453be7@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-12PCI: loongson: Do not ignore downstream devices on external bridgesRong Zhang
Loongson PCI host controllers have a hardware quirk that requires software to ignore downstream devices with device number > 0 on the internal bridges. The current implementation applies the workaround to all non-root buses, which breaks external bridges (e.g., PCIe switches) with multiple downstream devices. Fix it by only applying the workaround to internal bridges. Tested on Loongson-LS3A4000-7A1000-NUC-SE, using AMD Promontory 21 chipset add-in card [1]. $ lspci -tnnnvvv -[0000:00]-+-00.0 Loongson Technology LLC 7A1000 Chipset Hyper Transport Bridge Controller [0014:7a00] +-00.1 Loongson Technology LLC 7A2000 Chipset Hyper Transport Bridge Controller [0014:7a10] +-03.0 Loongson Technology LLC 2K1000/2000 / 7A1000 Chipset Gigabit Ethernet Controller [0014:7a03] +-04.0 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB OHCI Controller [0014:7a24] +-04.1 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB EHCI Controller [0014:7a14] +-05.0 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB OHCI Controller [0014:7a24] +-05.1 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB EHCI Controller [0014:7a14] +-06.0 Loongson Technology LLC 7A1000 Chipset Vivante GC1000 GPU [0014:7a15] +-06.1 Loongson Technology LLC 2K1000 / 7A1000 Chipset Display Controller [0014:7a06] +-07.0 Loongson Technology LLC 2K1000/2000/3000 / 3B6000M / 7A1000/2000 Chipset HD Audio Controller [0014:7a07] +-08.0 Loongson Technology LLC 2K1000 / 7A1000 Chipset 3Gb/s SATA AHCI Controller [0014:7a08] +-08.1 Loongson Technology LLC 2K1000 / 7A1000 Chipset 3Gb/s SATA AHCI Controller [0014:7a08] +-08.2 Loongson Technology LLC 2K1000 / 7A1000 Chipset 3Gb/s SATA AHCI Controller [0014:7a08] +-09.0-[01]----00.0 Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter [17cb:1103] +-0a.0-[02]----00.0 Etron Technology, Inc. EJ188/EJ198 USB 3.0 Host Controller [1b6f:7052] +-0f.0-[03-08]----00.0-[04-08]--+-00.0-[05]----00.0 Shenzhen Longsys Electronics Co., Ltd. FORESEE XP1000 / Lexar Professional CFexpress Type B Gold series, NM620 PCIe NVME SSD (DRAM-less) [1d97:5216] | +-08.0-[06]----00.0 MAXIO Technology (Hangzhou) Ltd. NVMe SSD Controller MAP1202 (DRAM-less) [1e4b:1202] | +-0c.0-[07]----00.0 Advanced Micro Devices, Inc. [AMD] 600 Series Chipset USB 3.2 Controller [1022:43f7] | \-0d.0-[08]----00.0 Advanced Micro Devices, Inc. [AMD] 600 Series Chipset SATA Controller [1022:43f6] \-16.0 Loongson Technology LLC 7A1000 Chipset SPI Controller [0014:7a0b] Fixes: 2410e3301fcc ("PCI: loongson: Don't access non-existent devices") Co-developed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Co-developed-by: Lain "Fearyncess" Yang <i@lain.vg> Signed-off-by: Lain "Fearyncess" Yang <i@lain.vg> Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://oshwhub.com/wesd/b650 [1] Link: https://patch.msgid.link/20260501-ls7a-bridge-fixes-v2-1-69fa93683805@rong.moe
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-05 19:35:49 +0000