summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-07dt-bindings: fix typos and bracketsManuel Ebner
Add missing '(', ')', '}' Remove needless '(', ')', '{', '}' 'lover voltage' -> 'lower voltage' Signed-off-by: Manuel Ebner <manuelebnerli@mailbox.org> Link: https://patch.msgid.link/20260722101246.3113818-2-manuelebnerli@mailbox.org [robh: drop .txt binding changes] Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-08-07docs: dt: submitting-patches: Mention expectation about dt-check-styleKrzysztof Kozlowski
Any new DTS example in the binding should pass dt-check-style 'strict' mode without warnings, although scripts does report some false positives. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260803091758.232633-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-08-07docs: dt: maintainer: Add Devicetree and OF maintainer profile documentKrzysztof Kozlowski
Document how Devicetree and Open Firmware maintainers handle their subsystem, especially focusing on two caveats: Devicetree subsystem handles patches with a minor difference comparing to other subsystems: while DT maintainers pick up OF code, they only provide review of DT bindings without applying these. All three DT bindings maintainers rely currently on Patchwork and due to enormous amount of emails per day, regardless how much DT maintainers try, they cannot read all the emails. Cc: Rob Herring <robh@kernel.org> Cc: Conor Dooley <conor+dt@kernel.org> Cc: Saravana Kannan <saravanak@kernel.org> Cc: devicetree@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260721060916.12465-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-08-07docs: dt: writing-schema: Extend expectations about example part of bindingKrzysztof Kozlowski
Document already used rules about example DTS in the binding: - All final device bindings (except sub-block of more complex devices) should have an example. - Phandles do not need to be resolvable - Sashiko already provided incorrect review, so this might help it to understand the concept. - Example should be complete, readable (use known defines), without 'status' property. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260722062240.19382-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-08-07dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPUChen-Yu Tsai
The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is one of the Series6XT GPUs, another sub-family of the Rogue family. This was part of the very first few versions of the PowerVR submission, but was later dropped. [1] https://lore.kernel.org/dri-devel/6eeccb26e09aad67fb30ffcd523c793a43c79c2a.camel@imgtec.com/ Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://patch.msgid.link/20260728091804.382753-4-wenst@chromium.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-08-07Merge patch series "scsi: qla2xxx: Bug fixes and hardening"Martin K. Petersen (Oracle)
Nilesh Javali <njavali@marvell.com> says: This series collects bug fixes, hardening, and small cleanups for the qla2xxx driver that are independent of the QLA29xx adapter enablement. Most were uncovered by static analysis and fuzzing of the driver's interrupt, mailbox, NVMe, and BSG paths; 30 of the 33 patches carry a Fixes: tag and are marked for stable. The series is organised as follows: Queue pairs, MSI-X, and interrupt setup/teardown Clamp MSI-X derived queue counts to avoid truncation, fix a use-after-free of qpair work on queue teardown, and quiesce the response IRQ before freeing the request queue. Firmware dump, FCE trace, and flash/version paths Improve firmware dump data capture, serialize the flash version read in the reset handler, clarify the MPI optrom address/length units, fix FCE trace enable parsing in debugfs, and fix a use-after-free of the FCE trace during a firmware dump. Probe and mailbox paths Fix the cs84xx use-after-free on host teardown, don't query firmware state while the chip is down, zero the mailbox struct in qla2x00_get_firmware_state(), and null out freed pointers in the qla2x00_mem_alloc() error path. Response/status IOCB path Use memset_io() to clear the QLAFX00 request ring slot, fix response queue over-consumption in __qla_consume_iocb(), fix a soft lockup in the polling continuation IOCB signature, bound rsp_info_len to avoid an out-of-bounds sense-data read, avoid a req_q_map double-read in qla2x00_error_entry(), and reject non-SCSI SRBs on the status IOCB fast path. NPIV and report-ID acquisition Clamp max_npiv_vports to the VP_CTRL bitmap capacity, avoid a double completion on async IOCB timeout, and correct vport handling in report ID acquisition (skip a vport under deletion, drop the vport reference under lock, and hold vport_slock for the host map update). NVMe LS and abort handling Fix an abort reference leak on repeated abort, skip the NVMe LS reject IOCB when firmware is not started, unlink the unsolicited context before freeing on the LS reject error path, and serialize the unsolicited context list with a per-fcport lock. BSG passthrough hardening Use a coherent DMA buffer for D_Port diagnostics, zero-init bsg stack buffers and the SFP DMA buffer to avoid information leaks, validate the BSG request_len before reading vendor_cmd[], and bound i2c->length in the I2C bsg handlers. The final patch bumps the driver version to 12.00.00.2607b2. The series applies on top of the qla2xxx QLA29xx series (v6, 56 patches) on Linux 7.2-rc1. Link: https://patch.msgid.link/20260730155838.2119230-1-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
2026-08-07Merge patch series "scsi: qla2xxx: Add QLA29xx series adapter support"Martin K. Petersen (Oracle)
Nilesh Javali <njavali@marvell.com> says: Add support for the QLA29xx generation of Marvell QLogic Fibre Channel HBAs (ISP2091/ISP2291/ISP2099/ISP2299). The 29xx family shares much of its architecture with the existing 27xx/28xx adapters but introduces 128-byte request and response ring entries (up from 64 bytes), requiring extended IOCB definitions and updated ring management throughout the driver. The key hardware change is the wider IOCB format: every request and response queue entry is now 128 bytes. This propagates into every code path that builds, submits, or processes IOCBs -- command submission, status completion, marker, CT pass-through, ELS, logio, task management, abort, ABTS, VP control, and NVMe. The series is organised as follows: Patches 01-08: Foundation and flash/firmware infrastructure PCI device ID registration, ISP-flags wiring, flash read/write interface, NVRAM configuration, queue initialisation, FC operational firmware load, removal of a redundant VPD flash read in the sysfs read path, and BSG passthrough (flash block I/O, MPI firmware load/dump). Patches 09-11: 128-byte IOCB infrastructure New qla_fw29.h header with extended structure definitions, status continuation and marker IOCBs, and IO-path updates that select the correct IOCB size via the entry-size helpers. Patches 12-24: Sysfs, mailbox commands, and core enablement Sysfs attribute gating for unsupported 29xx features, mailbox command enablement (get_fw_version, execute_fw, get_adapter_id, init_firmware, get_firmware_state, serdes, ELS, echo_test, data rate), shutdown path, ring-slot helpers, and memory allocation updates. Patches 25-39: Response-path IOCB handling and final wiring Status continuation, status entry, CT pass-through, PUREX, ELS, logio, task management, abort, ABTS, VP control/config/report-ID, LS4 pass-through, and BSG feature gating adjustments. Patches 40-55: bug fixes uncovered during review of the earlier postings -- queue teardown NULL dma_free and bitmap locking, endianness/bitfield cleanups, 64-bit FPM word counters, 64G/128G port speed setting and reporting, an edif NULL deref, Name Server logout detection on FWI2 adapters, VP index bounds, NVMe abort and LS-reject locking, a dport diagnostics info leak, a BSG job leak, and an unbounded FRU image count. Patch 56: bump the driver version to 12.00.00.2607b1. The series applies on top of Linux 7.2-rc1. Thanks, Nilesh [mkp: Resolve merge conflict] Link: https://patch.msgid.link/20260723050413.3897522-1-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
2026-08-07regulator: qcom-rpmh: Support RPMH address reads and use it for rpmh-regulatorsMark Brown
Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> says: This patch series adds a new `rpmh_read()` API to allow reading RPMH addresses. Using this API enhances the RPMH regulator driver by adding readback of the voltage/bypass/mode settings as they have been applied by APPS during the bootloader stage, so regulator framework can get them via `get_mode`, `get_bypass` & `get_voltage_selector` callbacks during regulator registration. This is needed because currently regulator framework does a unnecessary write with `min-microvolt` DT setting for all the RPMH regulators during regulator registration, because the first time after boot the value is seen as -ENOTRECOVERABLE, as there is no option to read these regulator settings. With this change this unnecessary write can be avoided and regulator framework gets a sense of the initial state set during the bootloader stage for all regulator settings. NOTE - During discussion on the v2 series - PATCH 3/4, reviewer had inquired about possible need for the use of the sync_state() to handle the "multiple" client case - for maintaining the regulator settings till all the clients are probed. This case was not covered in my previous series and had originally planned to do that series separately. But after the discussion decided to merge the 2 series as it seemed this would be a better approach. But after working on sync_state change. I realized a basic issue with using sync_state() for regulators - that its per-driver and not per-regulator resource. But we needed a sync_state callback for each regulator separately. I had been experimenting with few ideas but seems its going to need more time for me to close on the equivalent solution that has per-regulator sync_state or something to that effect. So I thought to close on this series and attend to that separately. Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-0-9fcb54928523@oss.qualcomm.com
2026-08-07regulator: qcom-rpmh: Fix coding style issuesKamal Wadhwa
Fix the code style/format issues reported by checkpatch.pl script. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-4-9fcb54928523@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-07regulator: qcom-rpmh: readback voltage/bypass/mode set during bootupKamal Wadhwa
Currently, during regulator registration, regulator framework sends an unnecessary `min-microvolts` request for the rpmh-regulator device. This happens because in current design, we do not have a way to readback the voltage settings that was set during the bootloader stage. Fix this by using the rpmh_read() API to read the regulator voltage settings done during boot and make it available to regulator framework from the very first read after the bootup. Also use this API to read the mode/bypass settings as well. This will provide the regulator framework a sense of the initial settings done by bootloader and thus preventing any redundant writes for any setting post bootup incase the same setting was already applied during bootup. Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-3-9fcb54928523@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-07regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handlingKamal Wadhwa
Currently, when `rpmh_regulator_set_mode_bypass()` helper function is called to set bypass mode, it sends PMIC4's BOB bypass mode value for even if its a PMIC5 BOB. To fix this, introduce new hw_data parameter`pmic_bypass_mode` to store bypass mode value. Use it to send correct PMIC bypass mode value that corresponds to PMIC4/5 BOB regulators from the helper function. Fixes: 610f29e5cc0e8d58 ("regulator: qcom-rpmh: Update PMIC modes for PMIC5") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-2-9fcb54928523@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-07soc: qcom: rpmh: Add support to read back resource settingsMaulik Shah
All rpmh_*() APIs so far have supported placing votes for various resource settings but the H/W also have option to read resource settings. Add new rpmh_read() API to allow clients to read back resource setting from H/W. This will be useful for clients like regulators, which currently don't have a way to know the settings applied during bootloader stage. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-1-9fcb54928523@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-07Merge tag 'mhi-for-v7.3' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mani/mhi into char-misc-next Manivannan writes: MHI Host -------- - Add SAHARA channel support in the pci_generic driver for Foxconn products. This allows capturing crashdump (ramdump) using the in-kernel sahara client driver. - Add support for devices with no M3 state. Some devices do not support the M3 power state due to hardware issues. For those devices, MHI bus will now run the full host-side suspend/resume sequence but skip the device-side M3/M0 handshake, so any transfer queued by clients during suspend is deferred until resume. - Set 'mhi_cntrl->no_m3' flag in the pci_generic driver for the QDU100 device so that the MHI bus also skips the M3 transition during system suspend. Earlier, the flag was only used to disable runtime PM, but the system suspend path was still transitioning the device to M3. - Fix sys error transition latency by polling for the state transition in mhi_pm_sys_error_transition() instead of waiting up to 24 seconds for an interrupt from the device. Since a device that has been reset (e.g., via AT!RESET) is not guaranteed to raise one. - Flush the posted write after writing to MHI_SOC_RESET_REQ_OFFSET in mhi_soc_reset() so that the reset actually reaches the device before the caller's post-reset delay begins. - Fix controller cleanup on EDL sysfs failure in mhi_register_controller(). The error path was leaving the device registered when sysfs_create_file() failed. MHI Endpoint ------------ - Add mhi_cntrl->flush_async() callback to drain the in-flight async DMA read/write operations issued through the MHI controller driver. This is used by the MHI EP stack before disconnect to avoid UAF where a late DMA completion could invoke a now-invalid xfer_cb(). - Implement the flush_async() callback in the PCI EPF MHI controller driver by waiting for the in-flight DMA operations to complete and then flushing the DMA workqueue. Since I'm the maintainer for this PCI EPF driver, I'm taking this patch through MHI tree due to dependency. - Flush the in-flight async transfers before notifying disconnect in mhi_ep_abort_transfer() to fix a UAF, where a success callback delivered after the -ENOTCONN notification could reference resources already freed by the client. - Fix device refcount leak in the error path of mhi_ep_create_device() when dev_set_name() or device_add() fails. Common ------ - Clean up kernel-doc warnings in include/linux/mhi.h. - Add Jeff Hugo as the Reviewer of MHI bus. * tag 'mhi-for-v7.3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mani/mhi: PCI: epf-mhi: Implement mhi_cntrl->flush_async() to flush DMA read/write bus: mhi: ep: Flush async transfers before notifying disconnect in mhi_ep_abort_transfer() bus: mhi: ep: Add mhi_cntrl->flush_async() callback to flush the async read/write bus: mhi: Clean up some kernel-doc warnings bus: mhi: host: Fix controller cleanup on EDL sysfs failure bus: mhi: pci_generic: Add SAHARA channel support for Foxconn products bus: mhi: host: pci_generic: Set 'mhi_cntrl->no_m3' flag bus: mhi: host: Add support for devices with no M3 state bus: mhi: host: Flush the posted write after writing to MHI_SOC_RESET_REQ_OFFSET MAINTAINERS: Add Jeff Hugo as the Reviewer of MHI bus bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation bus: mhi: core: Fix sys error transition latency
2026-08-07mtd: maps: remove dead select of MTD_CFI_BE_BYTE_SWAPJulian Braha
'select' does not work on config options in a 'choice', so currently it is possible to enable MTD_PHYSMAP_IXP4XX without MTD_CFI_BE_BYTE_SWAP. From a previous conversation, it was decided to remove the select entirely: https://lore.kernel.org/all/c6268184-4904-49d9-b14f-0e11dce8bdad@app.fastmail.com/ This dead select was found by kconfirm, a static analysis tool for Kconfig. Signed-off-by: Julian Braha <julianbraha@gmail.com> Link: $URL [1]" Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-08-07ACPI: TAD: Add locking around AML evaluationsRafael J. Wysocki
In the ACPI TAD driver, there are hidden assumptions that the ACPI control methods used by it will not be evaluated concurrently due to ACPICA namespace and interpreter locking. However, that may not be the case since ACPICA may drop and re-acquire the namespace and interpreter locks during the evaluation of a given object in a few cases, including the one in which the AML in question sleeps causing acpi_ex_system_do_sleep() to be called. In that case, the evaluation of one control method may be started while the evaluation of another one is still in progress. For this reason, add a global lock to the ACPI TAD driver and acquire it every time before evaluating an ACPI control method, except for the initial evaluation of _GCP in acpi_tad_probe(). Fixes: 95c513ec84f7 ("ACPI: Add Time and Alarm Device (TAD) driver") Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/12951141.O9o76ZdvQC@rafael.j.wysocki
2026-08-07mtd: rawnand: gpmi: add debugfs entry for BCH geometryHan Xu
Export the BCH geometry parameters via debugfs to aid debugging and provide the necessary information for legacy kobs-ng tool. The debugfs directory "gpmi-nand" is created under the root debugfs tree, exposing: bch_geometry - blob containing the struct bch_geometry fields raw_mode - flag indicating raw mode status The implementation is guarded with #ifdef CONFIG_DEBUG_FS to avoid build failures when debugfs is disabled. Signed-off-by: Han Xu <han.xu@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-08-07mtd: rawnand: validate ONFI extended parameter page sectionsPengpeng Hou
nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section. Fixes: 6dcbe0cdd83f ("mtd: get the ECC info from the Extended Parameter Page") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-08-07mtd: rawnand: sunxi: add H616 MBUS DMA supportJames Hilliard
The H616 NAND controller uses a descriptor-based internal MBUS DMA engine instead of the direct address and count registers used by the A23/A33 controller. Since the driver does not support these descriptors, it currently attempts to request an external rxtx DMA channel and falls back to PIO when none is provided. Add a single-descriptor backend to the existing ECC page DMA paths. Allocate the descriptor coherently, constrain data mappings to the controller's 32-bit address range, program the H6-style data block mask, and request an interrupt for both command and DMA completion. Keep the existing external DMA and legacy MBUS DMA paths unchanged, and fall back to PIO if the descriptor cannot be allocated. With identical kernels except for this patch, running flash_speed -d -b 1906 -c 100 /dev/mtd6 on an H616 board with 2 KiB-page SLC NAND reported: PIO descriptor DMA eraseblock write 3365 KiB/s 4192 KiB/s eraseblock read 6454 KiB/s 16040 KiB/s page write 3254 KiB/s 4021 KiB/s page read 6419 KiB/s 15686 KiB/s Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-08-07mtd: spinand: fmsh: fix FM25G01B/FM25G02B Quad I/O read dummy cyclesAleksandr Mineev
The FM25G01B/FM25G02B datasheets specify a single dummy byte for the 0xEB Quad I/O read-from-cache operation, but the generic read_cache_variants set uses two dummy bytes for the 1S-4S-4S variant. The extra dummy byte shifts the data phase and returns corrupted data with no ECC error, breaking boot on boards using these chips. Use a dedicated read-from-cache variant set with ndummy=1 for the 1S-4S-4S (0xEB) operation. FM25G01B datasheet: https://www.fmsh.com/nvm/FM25G01B_ds_eng.pdf FM25G02B datasheet: https://www.fmsh.com/nvm/FM25G02B_ds_eng.pdf Fixes: d5a5c9eb2ee9 ("mtd: spinand: fmsh: add support for FM25G{01,02}B") Cc: stable@vger.kernel.org Signed-off-by: Aleksandr Mineev <sanderrrs@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-08-07Merge tag 'thermal-7.2-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fixes from Rafael Wysocki: "Revert three thermal core updates, two recent ones and one older. The recent ones attempted to fix a design issue in the thermal core and simplify code on top of that, but they made changes visible to user space and made it unhappy. The older one is a misguided code cleanup that introduced a (potentially nasty) bug" * tag 'thermal-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "thermal/drivers/hwmon: Cleanup coding style a bit" Revert "thermal: hwmon: Register a hwmon device for each thermal zone" Revert "thermal: hwmon: Use extra_groups for adding temperature attributes"
2026-08-07Merge tag 'sound-7.2-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of small fixes since the last pull request. More than few, but an enough-manageable amount at this time. USB-audio: - UAF, OOB and such hardening fixes for USB-audio, usx2y and us144mkii - Mixer regression fixes for Logitech PRO X 2 LIGHTSPEED headset and M-Audio Fast Track Ultra HD-audio: - Fix for an ACPI reference leak in TAS2781 HDA side-codec ASoC: - Fixes the default tables for Cirrus Logic codecs - Fixes for invalid enum accesses for Qualcomm LPASS - Error handling and robustness fixes for Intel SOF & Soundwire - DMI quirks for a few AMD devices" * tag 'sound-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (22 commits) ALSA: usb-audio: Fix sticky mixer regressions on M-Audio Fast Track Ultra ASoC: cs4265: sort the register default table ASoC: cs35l45: sort the register default table ASoC: cs35l41: sort the register default table ASoC: amd: yc: Add DMI quirk for MSI Raider A18 HX A7VHG ASoC: amd: yc: Add DMI quirk for Xiaomi RedmiBook 16 2025 ALSA: usx2y: bound the hwdep mmap fault offset ALSA: usb-audio: fix OOB write on Type II inbound URBs ALSA: us144mkii: re-anchor capture URBs on resubmission ALSA: FCP: fix OOB write in fcp_meter_ctl_get() MAINTAINERS: add SpacemiT K1/K3 I2S entry ASoC: rt5645: Make the Kconfig symbol user selectable ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN for Logitech PRO X 2 LIGHTSPEED ALSA: hda/tas2781: fix ACPI reference handling ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout ASoC: amd: yc: Add DMI quirk for HP Victus Laptop 16-e1xxx ASoC/soundwire: Intel: reset the PCMSyCM registers in hda_sdw_bpt_close ASoC: SOF: sof-audio: Fix error path in sof_widget_setup_unlocked() ...
2026-08-07RISC-V: KVM: Improve dirty log clearing by skipping zero bits in maskWang Yechao
The existing kvm_riscv_gstage_wp_range() walks the entire [start, end) range to apply write protection for dirty log clearing, even when the provided mask has zero bits (i.e., many GFNs do not need protection). This leads to unnecessary page table walks when the mask is sparse. Replace the range-based approach with a new function kvm_riscv_gstage_wp_pt_masked() that iterates only over the set bits in the mask. For each set bit, it looks up the leaf PTE and applies write protection. Once a huge page is encountered, the entire huge-page range is processed in one go, and the corresponding bits in the mask are cleared using bitmap_clear(). Performance was measured with KVM selftests dirty_log_perf_test on a Spacemit k3 host with the following configuration: - vCPUs: 2 (-v 2) - Memory: 1GB (-b 1G) - Iterations: 3 (-i 3) - Write percentage varied via -w parameter to simulate different dirty mask densities. The following data shows the time spent in the clear-dirty-log phase (i.e., the KVM_CLEAR_DIRTY_LOG ioctl) under each configuration. +------------------+------------------+------------------+-------------+ | Write Percentage | Original (s) | Patched (s) | Improvement | +------------------+------------------+------------------+-------------+ | 10% | 0.012905 | 0.009213 | +28.6% | | 30% | 0.014217 | 0.010287 | +27.6% | | 50% | 0.014606 | 0.011772 | +19.4% | | 70% | 0.014735 | 0.013199 | +10.4% | | 100% | 0.014759 | 0.015294 | -3.6% | +------------------+------------------+------------------+-------------+ The performance improvement is most significant when the dirty mask is sparse (low write percentage), which is common in real-world scenarios with low to moderate memory write intensity. In the worst-case scenario where the mask is fully set (100% write), the optimization introduces a slight 3.6% overhead due to the additional bit operations, which is acceptable given the substantial gains in common cases. This change significantly reduces the number of page-table walks when the dirty mask has many zero bits, improving the efficiency of KVM_CLEAR_DIRTY_LOG and related ioctls. Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260717080654.877151-1-wang.yechao255@zte.com.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-07selftests/bpf: Add load-acquire test for probe-memory pointer typesDaniel Borkmann
Add a verifier test that a BPF_LOAD_ACQ from a rdonly_untrusted_mem pointer (PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED, obtained via bpf_rdonly_cast()) is rejected. Such a source requires BPF_PROBE_MEM fault protection which is not applied to atomic loads; without the verifier fix the load is accepted and would crash the kernel on a fault. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_load_acquire [...] #621/1 verifier_load_acquire/load-acquire, 8-bit:OK #621/2 verifier_load_acquire/load-acquire, 8-bit @unpriv:OK #621/3 verifier_load_acquire/load-acquire, 16-bit:OK #621/4 verifier_load_acquire/load-acquire, 16-bit @unpriv:OK #621/5 verifier_load_acquire/load-acquire, 32-bit:OK #621/6 verifier_load_acquire/load-acquire, 32-bit @unpriv:OK #621/7 verifier_load_acquire/load-acquire, 64-bit:OK #621/8 verifier_load_acquire/load-acquire, 64-bit @unpriv:OK [...] #621/19 verifier_load_acquire/load-acquire from rdonly_untrusted_mem pointer:OK #621/20 verifier_load_acquire/load-acquire with invalid register R15:OK #621/21 verifier_load_acquire/load-acquire with invalid register R15 @unpriv:OK #621/22 verifier_load_acquire/load-acquire from pkt pointer:OK #621/23 verifier_load_acquire/load-acquire from flow_keys pointer:OK #621/24 verifier_load_acquire/load-acquire from sock pointer:OK #621 verifier_load_acquire:OK Summary: 1/24 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20260806201047.333389-6-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-08-07selftests/bpf: Add arena fault test for load-acquireDaniel Borkmann
Add stream_arena_load_acquire_fault, which performs a load-acquire from an unmapped arena address, next to the existing read and write fault tests. The test covers both halves of the JIT bug that treated a load-acquire as a store when populating its exception table entry: - the fault has to be reported as a READ, and at the address held by the source register, which __stderr() and test_address() check, and - the destination register has to be cleared by the fault handler, which the program checks by poisoning it before the load-acquire and returning it, so __retval(0) fails if it is left untouched Note, load-acquire is open coded since linux/filter.h cannot be included alongside vmlinux.h. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t stream_arena_fault_address [...] #462/1 stream_arena_fault_address/read_fault:OK #462/2 stream_arena_fault_address/write_fault:OK #462/3 stream_arena_fault_address/load_acquire_fault:OK #462 stream_arena_fault_address:OK Summary: 1/3 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20260806201047.333389-5-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-08-07bpf, arm64: Fix exception table metadata for arena load-acquireDaniel Borkmann
Same problem as on x86-64: add_exception_handler() decides whether an instruction is a load by its class, and a load-acquire is of BPF_STX class even though it reads from src_reg into dst_reg. As a result ... if (BPF_CLASS(insn->code) != BPF_LDX) dst_reg = DONT_CLEAR; ... drops the register to clear, and ... if (BPF_CLASS(insn->code) == BPF_LDX) arena_reg = bpf2a64[insn->src_reg]; else arena_reg = bpf2a64[insn->dst_reg]; ... hands ex_handler_bpf() the value register instead of the address register. A load-acquire from an arena pointer that faults on an unmapped page is therefore reported as a WRITE at a bogus address, and dst_reg keeps its previous value instead of being cleared to 0. Note that emit_atomic_ld_st() already picks src_reg as the address for BPF_LOAD_ACQ, so only the exception table metadata was out of sync with the emitted access. Same as on x86-64, use bpf_atomic_is_load_acq() so a load-acquire takes the load path. Fixes: 9bb12368d539 ("bpf, arm64: Support load-acquire and store-release instructions") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/bpf/20260806201047.333389-4-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-08-07bpf, x86: Fix exception table metadata for arena load-acquireDaniel Borkmann
A load-acquire from an arena pointer is converted to BPF_PROBE_ATOMIC and gets an exception table entry, but the entry is filled in as if it were a store, since populate_extable() decides based on instruction class alone and a load-acquire is of BPF_STX class: if (BPF_CLASS(insn->code) == BPF_LDX) { arena_reg = reg2pt_regs[src_reg]; fixup_reg = reg2pt_regs[dst_reg]; } else { arena_reg = reg2pt_regs[dst_reg]; fixup_reg = DONT_CLEAR; } For a load-acquire dst_reg holds the loaded value and src_reg holds the address, so both assignments in the else branch are wrong. On a fault over an unmapped arena page ex_handler_bpf() then: - computes the reported address from the value register instead of the address register - reports the access as a WRITE, since it derives the direction from fixup_reg == DONT_CLEAR - leaves dst_reg untouched, so the program continues with a stale value instead of the 0 that BPF_PROBE_* loads deliver The access itself is emitted correctly, emit_atomic_ld_st_index() uses src_reg as the address, so this is a broken probe contract and a wrong diagnostic rather than a memory safety issue. Use bpf_atomic_is_load_acq() helper so a load-acquire takes the load path. Fixes: 5341c9a4d833 ("bpf, x86: Support load-acquire and store-release instructions") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20260806201047.333389-3-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-08-07bpf, riscv: Add and use bpf_atomic_is_load_acq() helperDaniel Borkmann
A load-acquire is the only BPF_STX class instruction that reads from src_reg into dst_reg, that is, it has the operand roles of a BPF_LDX. JIT code which tells loads from stores apart by instruction class alone has to special case it, for example when deciding which register holds the faulting address and which one to clear from an exception handler. riscv64 already does so, open coded as a bare insn->imm test. Add a bpf_atomic_is_load_acq() helper and convert riscv64 over to it, so that the x86-64 and arm64 JITs can use the same helper in subsequent patches. Unlike bpf_atomic_is_load_store(), which presumes that its argument is already known to be a BPF_ATOMIC instruction, the new helper is called from code which still sees all instruction classes, so it checks class and mode itself. Also, move bpf_atomic_is_load_store() to filter.h next to BPF_ATOMIC_OP, so that both helpers stay together. No functional change intended. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20260806201047.333389-2-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-08-07bpf: Reject load-acquire from pointers requiring fault protectionDaniel Borkmann
A BPF_LOAD_ACQ is not rewritten to a BPF_PROBE_MEM load by the verifier, unlike a regular BPF_LDX, so the JIT emits a plain load with no exception table entry and a fault panics the kernel instead of being handled. Reject the source pointer types that a BPF_LDX would have had that fault protection applied to, i.e. the ones bpf_convert_ctx_accesses() turns into BPF_PROBE_MEM: a bare PTR_TO_BTF_ID, PTR_TO_BTF_ID | PTR_UNTRUSTED, PTR_TO_BTF_ID | MEM_ALLOC | PTR_UNTRUSTED and PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED. This is reachable e.g. by loading ->mm out of a trusted task_struct yields an untrusted pointer to mm_struct, and it is NULL for a kernel thread: [...] SEC("tp_btf/sched_switch") int BPF_PROG(demo, bool preempt, struct task_struct *prev, struct task_struct *next) { struct mm_struct *mm = next->mm; /* untrusted */ out_ldx = (__u64)mm->pgd; /* BPF_LDX */ out_acq = load_acquire(&mm->pgd); /* BPF_LOAD_ACQ */ return 0; } [...] Both dereference the same pointer, but only the BPF_LDX is protected (x86-64 JIT, jump targets shown prog-relative): [...] ; out_ldx = (__u64)mm->pgd; 17: movq $-10485760, %r10 1e: movq %rsi, %r11 21: addq $184, %r11 28: subq %r10, %r11 2b: movabsq $140737498841088, %r10 35: cmpq %r10, %r11 38: ja 0x3e <-- kernel addr? 3a: xorl %edi, %edi <-- no: dst = 0, skip the load 3c: jmp 0x45 3e: movq 184(%rsi), %rdi <-- yes: load + extable entry [...] ; load_acquire(&mm->pgd) 53: movq %rsi, %rdi 56: movq 184(%rdi), %rax <-- no check, no extable entry [...] Note that BPF_PROBE_MEM is not visible in a bpftool xlated dump, as bpf_insn_prepare_dump() rewrites it back to BPF_MEM. A PTR_TRUSTED pointer is deliberately not on the list. Such a load is not converted either, but it does not need to be, since the pointer is guaranteed live, so load-acquire from it stays allowed. The check is gated on BPF_LOAD_ACQ so that atomic RMW and store-release error messages are unchanged; writes (RMW / store-release) to such pointers are already rejected elsewhere, so only load-acquire needs this. Fixes: 880442305a39 ("bpf: Introduce load-acquire and store-release instructions") Reported-by: STAR Labs SG <info@starlabs.sg> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20260806201047.333389-1-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-08-07s390/virtio: Enable CONTEXT_ANALYSISHeiko Carstens
All virtio code passes clang's compile time context analysis. Therefore enable CONTEXT_ANALYSIS. Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-08-07s390/cio: Enable CONTEXT_ANALYSISHeiko Carstens
All cio code passes clang's compile time context analysis. Therefore enable CONTEXT_ANALYSIS. Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-08-07s390/vfio_ccw: Add __must_hold() attribute to vfio_ccw_sch_quiesce()Heiko Carstens
Add __must_hold() attribute to vfio_ccw_sch_quiesce() in order to let clang's context analysis know that sch->lock must be held on function entry. This can also be easily verified when inspecting the function. Without this annotation this leads to a valid warning when context analysis is enabled: drivers/s390/cio/vfio_ccw_drv.c:55:9: warning: expecting spinlock 'sch->lock' to be held at start of each loop [-Wthread-safety-analysis] 55 | ret = cio_cancel_halt_clear(sch, &iretry); | ^ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> [borntraeger@linux.ibm.com: fix spurious ;] Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-08-07arm_mpam: Disable driver unbind to avoid UAFBen Horgan
When a user unbinds an MSC and that MSC is the only MSC left for a component then the corresponding mpam_component will be freed. If the user then goes on to read the schemata file in the resctrl filesystem then the mpam_component will be accessed from resctrl_arch_get_config() leading to a use after free. As the MPAM driver is not a module the unbind sysfs interface is the only way to trigger the remove. Instead of dealing with the complexity of allowing some unused MSC to unbind just remove the unbind sysfs interface. Fixes: f04046f2577a ("arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate") Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-07arm_mpam: Fix a NULL pointer dereference on unbinding after an error interruptBen Horgan
If a user unbinds an MSC after mpam_disable() has been run in response to an error interrupt then a dereference of a NULL pointer occurs as mpam_disable() sets the drvdata to NULL. Add an early return to the driver remove callback to avoid this. Fixes: f04046f2577a ("arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate") Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-07perf: arm_pmuv3: Zero initialize hw_id branch stack fieldJames Clark
PERF_SAMPLE_BRANCH_HW_INDEX is supported by BRBE so hw_id is passed to userspace, but it's never set by the BRBE driver. Zero initialize it as it should be according to the docs: * For the architectures whose raw branch records are * already stored in age order, the hw_idx should be 0. It's probably too risky to remove PERF_SAMPLE_BRANCH_HW_INDEX from BRBE now in case anyone is setting it and reading the value, but zero initializing the whole struct also protects against the same issue with new fields that are added in the future. Fixes: 58074a0fce66 ("perf: arm_pmuv3: Add support for the Branch Record Buffer Extension (BRBE)") Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-07arm64: mm: Unmap kernel data/bss entirely from the linear mapArd Biesheuvel
The linear aliases of the kernel text and rodata are also mapped read-only in the linear map. Given that the contents of these regions are mostly identical to the version in the loadable image, mapping them read-only and leaving their contents visible is a reasonable hardening measure. Data and bss, however, are now also mapped read-only but the contents of these regions are more likely to contain data that we'd rather not leak. So let's unmap these entirely in the linear map when the kernel is running normally. When going into hibernation or waking up from it, these regions need to be mapped, so map the region initially, and toggle the valid bit so map/unmap the region as needed. Doing so is required because pages covering the kernel image are marked as PageReserved, and therefore disregarded for snapshotting by the hibernate logic unless they are mapped. Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Kevin Brodsky <kevin.brodsky@arm.com> Cc: Liz Prucka <lizprucka@google.com> Cc: Seth Jenkins <sethjenkins@google.com> Cc: Kees Cook <kees@kernel.org> Cc: David Hildenbrand <david@kernel.org> Cc: Jann Horn <jannh@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-07Merge tag 'amd-drm-fixes-7.2-2026-08-06' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.2-2026-08-06: amdgpu: - JPEG queue reset fixes - GC 12 fix - GMC 12.1 fixes - Lockdep false positive fix - Userq fix - Bounds checking fixes - Devcoredump fixes - DCN 2.0.1 fix - Aperture mapping fix - DC avmute fix - DC self refresh fix radeon: - Performance regression fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260806211538.994087-1-alexander.deucher@amd.com
2026-08-07Merge tag 'drm-misc-fixes-2026-08-06' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v7.2-rc6: - panthor & shmem helpers: Check vma range inside pmd fault handler. - panthor: handle empty firmware sections correctly. - bridge/ps8640: Forward aux transfer errors. - amdxdna: Improve error handling in amdxdna_insert_pages. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/415659f6-5199-4078-8319-22d7529e777d@linux.intel.com
2026-08-07coresight: etm4x: remove redundant fields in etmv4_save_stateYeoreum Yun
Some of fields are redundant in etmv4_save_state and never used: ss_status => trcsscsr seq_state => trcseqstr cntr_val => trccntvr vinst_ctrl => trcvictlr Reviewed-by: Leo Yan <leo.yan@arm.com> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20260725113645.57519-13-yeoreum.yun@arm.com
2026-08-07coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enableYeoreum Yun
In the perf enable path, there are missing cases where cscfg_csdev_disable_active_config() is not called: - Branch broadcast is selected but not supported by the hardware - etm4_enable_hw() fails This can lead to a leak of config_desc->active_cnt. Fix this by properly calling cscfg_csdev_disable_active_config() in these error paths. Fixes: 810ac401db1f ("coresight: etm4x: Add complex configuration handlers to etmv4") Suggested-by: Leo Yan <leo.yan@arm.com> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20260725113645.57519-6-yeoreum.yun@arm.com
2026-08-07coresight: etm4x: fix leaked trace idYeoreum Yun
If etm4_enable_sysfs() fails in cscfg_csdev_enable_active_config(), the trace ID may be leaked because it is not released. To address this, call etm4_release_trace_id() when etm4_enable_sysfs() fails in cscfg_csdev_enable_active_config(). Fixes: 7ebd0ec6cf94 ("coresight: configfs: Allow configfs to activate configuration") Reviewed-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: Leo Yan <leo.yan@arm.com> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20260725113645.57519-4-yeoreum.yun@arm.com
2026-08-07coresight: etm4x: fix underflow for usage of (nrseqstate - 1)Yeoreum Yun
According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR<n> is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR<n> with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR<n> relevant fields setup. Link: https://developer.arm.com/documentation/ihi0064/latest/ [0] Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver") Suggested-by: Leo Yan <leo.yan@arm.com> Suggested-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20260725113645.57519-3-yeoreum.yun@arm.com
2026-08-07coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()Yeoreum Yun
According to Embedded Trace Macrocell Architecture Specification ETMv4.0 to ETM4.6 [0], TRCSSPCICR<n> is present only if all of the following are true: - TRCIDR4.NUMSSCC > n. - TRCIDR4.NUMPC > 0b0000. - TRCSSCSR<n>.PC == 0b1. Comment for etm4x_sspcicrn_present() is align with the specification. However, the check should use drvdata->nr_pe_cmp to check TRCIDR4.NUMPC not nr_pe. Link: https://developer.arm.com/documentation/ihi0064/latest/ [0] Fixes: f6a18f354c58 ("coresight: etm4x: Handle access to TRCSSPCICRn") Reviewed-by: Leo Yan <leo.yan@arm.com> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20260725113645.57519-2-yeoreum.yun@arm.com
2026-08-07hwtracing: hisi_ptt: Remove unnecessary trace buffer zeroing in trace_start()Sanman Pradhan
hisi_ptt_trace_start() clears all four trace buffers before enabling tracing. This is unnecessary. On trace stop, hisi_ptt_update_aux() copies only the number of bytes reported in HISI_PTT_TRACE_WR_STS. On buffer-full interrupts, it copies a full completed buffer. In both cases the driver only consumes data written by hardware. Remove the buffer clearing from the trace start path. Signed-off-by: Sanman Pradhan <psanman@juniper.net> Reviewed-by: Yicong Yang <yangyccccc@gmail.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20260414172451.14331-3-sanman.pradhan@hpe.com
2026-08-07hwtracing: hisi_ptt: Propagate DMA reset timeout in trace_start()Sanman Pradhan
hisi_ptt_wait_dma_reset_done() discards the return value of readl_poll_timeout_atomic(). If the DMA engine does not complete its reset within the timeout, hisi_ptt_trace_start() proceeds to start tracing regardless. Return a bool from hisi_ptt_wait_dma_reset_done(), consistent with the other wait helpers in this driver. On timeout, log an error, de-assert the reset bit, and return -ETIMEDOUT. Move ctrl->started to the successful path so a failed start does not leave the trace marked as active. Fixes: ff0de066b463 ("hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan <psanman@juniper.net> Reviewed-by: Sizhe Liu <liusizhe5@huawei.com> Reviewed-by: Yicong Yang <yangyccccc@gmail.com> Tested-by: Sizhe Liu <liusizhe5@huawei.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20260414172451.14331-2-sanman.pradhan@hpe.com
2026-08-07MAINTAINERS: Update HiSilicon PCI Trace and Tune maintainerJonathan Cameron
Yicong left Huawei a while back so drop both of our entries and add one for Sizhe Liu who will be looking after this code going forwards. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Sizhe Liu <liusizhe5@huawei.com> Acked-by: Jie Zhan <zhanjie9@hisilicon.com> Acked-by: Yicong Yang <yangyccccc@gmail.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20260416094219.25258-1-Jonathan.Cameron@huawei.com
2026-08-07coresight: etm3x: Fix cntr_val_show() to match cntr_val_store() behaviorKuan-Wei Chiu
The cntr_val_show() function was intended to print the values of all counters using a loop. However, due to a buffer overwrite issue with sprintf(), it effectively only displayed the value of the last counter. The companion function, cntr_val_store(), allows users to modify a specific counter selected by 'cntr_idx'. To maintain consistency between read and write operations and to align with the ETM4x driver behavior, modify cntr_val_show() to report only the value of the currently selected counter. This change removes the loop and the "counter %d:" prefix, printing only the hexadecimal value. It also adopts sysfs_emit() for standard sysfs output formatting. Fixes: a939fc5a71ad ("coresight-etm: add CoreSight ETM/PTM driver") Cc: stable@vger.kernel.org Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Reviewed-by: James Clark <james.clark@linaro.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20251202082613.3265761-1-visitorckw@gmail.com
2026-08-07md/raid1: don't set array_frozen in raid1_takeover()Bruce Johnston
raid1_takeover() sets conf->array_frozen = 1 on the newly-allocated r1conf and nothing ever clears it, so every I/O to the array stalls permanently once _wait_barrier() sees it stuck at 1. This used to be harmless: level_store() called mddev_resume() right after pers->run(), which called raid1_quiesce(mddev, 0) and cleared array_frozen back to 0 regardless of what raid1_takeover() set. Commit b39f35ebe86d ("md: don't quiesce in mddev_suspend()") removed that quiesce(mddev, 0) call, so the pre-set now sticks. setup_conf() already zero-initializes the new r1conf via kzalloc, so just don't set array_frozen here. Same class of bug as commit 892da88d1cd9 ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()"), also triggered by b39f35ebe86d. Fixes: b39f35ebe86d ("md: don't quiesce in mddev_suspend()") Link: https://issues.redhat.com/browse/RHEL-191802 Signed-off-by: Bruce Johnston <bjohnsto@redhat.com> Link: https://patch.msgid.link/20260803180240.1177104-1-bjohnsto@redhat.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-08-07Merge branch 'misc' into for-nextMike Rapoport (Microsoft)
2026-08-07Merge branch 'range-checks' into for-nextMike Rapoport (Microsoft)
2026-08-07Merge branch 'numa_memblks-redundant-work' into for-nextMike Rapoport (Microsoft)