kernel/git/next/linux-next.git/drivers/power/sequencing, branch master

Merge branch 'pwrseq/for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git

2026-09-07T13:48:41+00:00

Merge branch 'pwrseq/for-current' of https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git

2026-09-07T11:56:50+00:00

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

power: sequencing: Add Renesas RZ/G3L Power Ready driver

2026-09-02T10:46:21+00:00

Add a power sequencing driver for the Renesas RZ/G3L PWRRDY module, which signals power readiness for various IPs (USB, DSI, CSI etc.) on the SoC. The driver binds as an auxiliary device to the parent SYSC driver, using its regmap to toggle the SYS_PWRRDY_N register bits, and exposes {usb,dsi,csi}-pwrrdy pwrseq targets. Signed-off-by: Biju Das Link: https://patch.msgid.link/20260826122742.153643-4-biju.das.jz@bp.renesas.com Signed-off-by: Bartosz Golaszewski

power: sequencing: Fix build issue with COMPILE_TEST

2026-09-02T10:44:07+00:00

The POWER_SEQUENCING_TH1520_GPU driver depends on (ARCH_THEAD && AUXILIARY_BUS) || COMPILE_TEST. This means when COMPILE_TEST=y and ARCH_THEAD is not set, the driver can still be built even though it requires AUXILIARY_BUS, which may not be selected in that configuration, leading to a build failure. Fix this by dropping AUXILIARY_BUS from the dependency and instead selecting it directly, so the dependency is satisfied regardless of whether COMPILE_TEST or ARCH_THEAD is enabled. Fixes: 1a7312b93ab0 ("power: sequencing: extend build coverage with COMPILE_TEST=y") Signed-off-by: Biju Das Link: https://patch.msgid.link/20260826122742.153643-3-biju.das.jz@bp.renesas.com Signed-off-by: Bartosz Golaszewski

Merge tag 'pwrseq-updates-for-v7.3-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux

2026-08-26T15:45:09+00:00

Pull another power sequencing update from Bartosz Golaszewski: "A single tree-wide rename of two of the public functions to better reflect their actual semantics: - rename pwrseq_power_on/off() to pwrseq_enable/disable() tree-wide" * tag 'pwrseq-updates-for-v7.3-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: rename pwrseq_power_on/off() to pwrseq_enable/disable()

power: sequencing: rename pwrseq_power_on/off() to pwrseq_enable/disable()

2026-08-26T08:05:45+00:00

The way power sequencing works means that a call to pwrseq_power_on() does not necessarily result in the pwrseq target being powered-on at that time: it may have already been powered on before. Similarly: a call to pwrseq_power_off() does not have to result in an actual powering off of resources: there may still be other users that requested a power-on before. We will also introduce the concept of "non-controllable" pwrseq targets soon which further increases the disconnect between the naming convention and the actual semantics. What consumers of pwrseq descriptors actually do is: they *vote* for a powering on of a given target or retract that vote. These operations could be called get/put in line with runtime PM but this could become confusing since we already provide pwrseq_get/put() for a different purpose. pwrseq_vote_on/off() also have been rejected as unusual in the tree. Change the name of the two functions to pwrseq_enable/disable() which better reflects their purpose and semantics and also mirrors other enable-counted resources like regulators and clocks. No functional change intended. If at any point users need to know *when* the exact power event happens, we can provide that information in the form of a notifier. Acked-by: Jeff Johnson Acked-by: Bjorn Helgaas Acked-by: Manivannan Sadhasivam Acked-by: Alessio Belle # imagination Link: https://patch.msgid.link/20260731-pwrseq-vote-rename-v3-1-44e60b8be053@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski

Merge tag 'pwrseq-updates-for-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux

2026-08-19T16:08:06+00:00

Pull power sequencing updates from Bartosz Golaszewski: "This a very tiny pull for v7.3 from the power sequencing tree. It only contains a handful of updates to the pwrseq-pcie-m2 driver: - add support for new devices to pwrseq-pcie-m2 - make device matching more fine-grained for cases where the same combo chips are wired differently on the M.2 card (and - for instance - don't require serial device creation because they expose BT over USB) in pwrseq-pcie-m2" * tag 'pwrseq-updates-for-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: pcie-m2: Match WCN6855 and WCN7851 UART BT variants by subdevice ID power: sequencing: pcie-m2: Add QCA2066 (QCNFA765) BT serdev ID power: sequencing: pcie-m2: Add PCI ID for NXP 88W9098 and AW693 Bluetooth

power: sequencing: pcie-m2: Match WCN6855 and WCN7851 UART BT variants by subdevice ID

2026-07-24T12:36:39+00:00

The WCN6855 and WCN7851 combo chips are available in M.2 card variants that differ by their BT interface: some expose BT over UART while others expose BT over USB. Both variants use the same PCIe device ID for the WiFi interface, distinguished only by their sub-system device ID. The bare PCI_DEVICE() entries match all sub-system IDs, so both UART and USB variants hit the same table entry and trigger UART serdev creation. For USB variants this is wrong — there is no UART BT interface on such a card, and the serdev probe will fail. Narrow the matches to UART variants only by using PCI_DEVICE_SUB with their respective sub-system IDs, so USB variants no longer trigger UART serdev creation. Reviewed-by: Manivannan Sadhasivam Signed-off-by: Wei Deng Link: https://patch.msgid.link/20260724-hamoa-m2-sub-id-v2-v3-1-af97de70bbbe@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski

power: sequencing: pcie-m2: Add QCA2066 (QCNFA765) BT serdev ID

2026-07-03T08:30:08+00:00

Add PCI IDs for Qualcomm QCA2066/QCNFA765 to the M.2 serdev ID table, mapping it to the qcom,qca2066-bt compatible string. The Subsystem Vendor ID (SVID) 0x0108 distinguishes the QCA2066 from the WCN6855. This allows the pwrseq-pcie-m2 driver to automatically create the Bluetooth serdev device when a QCA2066-based M.2 card is enumerated. Reviewed-by: Manivannan Sadhasivam Reviewed-by: Dmitry Baryshkov Signed-off-by: Loic Poulain Link: https://patch.msgid.link/20260702-monza-wireless-v2-2-7b56e2a6a6d4@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski