| d51fc9d4 | 31-Jul-2026 |
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> |
power: sequencing: rename pwrseq_power_on/off() to pwrseq_enable/disable()
The way power sequencing works means that a call to pwrseq_power_on() does not necessarily result in the pwrseq target bein
power: sequencing: rename pwrseq_power_on/off() to pwrseq_enable/disable()
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 <jeff.johnson@oss.qualcomm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Acked-by: Alessio Belle <alessio.belle@imgtec.com> # imagination Link: https://patch.msgid.link/20260731-pwrseq-vote-rename-v3-1-44e60b8be053@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| a39ac465 | 24-Jul-2026 |
Wei Deng <wei.deng@oss.qualcomm.com> |
power: sequencing: pcie-m2: Match WCN6855 and WCN7851 UART BT variants by subdevice ID
The WCN6855 and WCN7851 combo chips are available in M.2 card variants that differ by their BT interface: some
power: sequencing: pcie-m2: Match WCN6855 and WCN7851 UART BT variants by subdevice ID
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 <mani@kernel.org> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com> Link: https://patch.msgid.link/20260724-hamoa-m2-sub-id-v2-v3-1-af97de70bbbe@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| 2d5a7d40 | 18-Jun-2026 |
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> |
power: sequencing: fix ABBA deadlock in pwrseq_device_unregister()
The pwrseq core takes three locks in consistent order everywhere:
pwrseq_sem -> pwrseq->rw_lock -> pwrseq->state_lock
pwrseq_ge
power: sequencing: fix ABBA deadlock in pwrseq_device_unregister()
The pwrseq core takes three locks in consistent order everywhere:
pwrseq_sem -> pwrseq->rw_lock -> pwrseq->state_lock
pwrseq_get() -> pwrseq_match_device() takes pwrseq_sem for reading, then rw_lock for reading. pwrseq_power_on()/pwrseq_power_off() take rw_lock for reading and then state_lock.
pwrseq_device_unregister() is the only exception, it takes: state_lock, then rw_lock for writing and finally pwrseq_sem for writing. This created two potential ABBA deadlock situations that sashiko pointed out.
- pwrseq_power_on/off() take rw_lock for reading then state_lock, while pwrseq_unregister() takes state_lock then rw_lock for writing - pwrseq_get() takes pwrseq_sem for reading then rw_lock for reading, while pwrseq_unregister() takes rw_lock for writing then pwrseq_sem for writing
Reorder the unregister path to taking pwrseq_sem for writing -> rw_lock for writing and drop the state_lock entirely. This is safe as enable_count is only ever written under rw_lock held for read (via pwrseq_unit_enable()/disable(), reached only from pwrseq_power_on/off()), so holding rw_lock for writing already excludes every other writer and reader and the active-users WARN() stays race-free without state_lock.
Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Closes: https://sashiko.dev/#/patchset/20260616151049.1705503-1-vulab%40iscas.ac.cn Link: https://patch.msgid.link/20260618-pwrseq-abba-deadlock-v1-1-943a3fd81c06@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| 251c8e86 | 17-Jun-2026 |
Wei Deng <wei.deng@oss.qualcomm.com> |
power: sequencing: pcie-m2: Sort PCI device IDs in ascending order
Sort the entries in pwrseq_m2_pci_ids[] by device ID in ascending order: 0x1103 (WCN6855) before 0x1107 (WCN7850).
Fixes: 2abcfdd9
power: sequencing: pcie-m2: Sort PCI device IDs in ascending order
Sort the entries in pwrseq_m2_pci_ids[] by device ID in ascending order: 0x1103 (WCN6855) before 0x1107 (WCN7850).
Fixes: 2abcfdd91e6a ("power: sequencing: pcie-m2: Add PCI ID 0x1103 for WCN6855 Bluetooth") Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com> Link: https://patch.msgid.link/20260617143055.820096-1-wei.deng@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| 2abcfdd9 | 08-Jun-2026 |
Wei Deng <wei.deng@oss.qualcomm.com> |
power: sequencing: pcie-m2: Add PCI ID 0x1103 for WCN6855 Bluetooth
WCN6855 is a Qualcomm Wi-Fi/BT combo chip that uses PCI device ID 0x1103. Add it to pwrseq_m2_pci_ids[] alongside the existing 0x1
power: sequencing: pcie-m2: Add PCI ID 0x1103 for WCN6855 Bluetooth
WCN6855 is a Qualcomm Wi-Fi/BT combo chip that uses PCI device ID 0x1103. Add it to pwrseq_m2_pci_ids[] alongside the existing 0x1107 (WCN7850) entry, so that the pwrseq-pcie-m2 driver creates a Bluetooth serdev device for WCN6855 cards inserted into PCIe M.2 Key E connectors.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com> Link: https://patch.msgid.link/20260608091702.3797437-2-wei.deng@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| 9085f712 | 19-May-2026 |
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> |
power: sequencing: Add an API to return the pwrseq device's 'dev' pointer
The consumer drivers can make use of the pwrseq device's 'dev' pointer to query the pwrseq provider's DT node to check for e
power: sequencing: Add an API to return the pwrseq device's 'dev' pointer
The consumer drivers can make use of the pwrseq device's 'dev' pointer to query the pwrseq provider's DT node to check for existence of specific properties.
Hence, add an API to return the pwrseq device's 'dev' pointer to consumers.
Note that since pwrseq_get() would've increased the pwrseq refcount, there is no need to increase the refcount in this API again.
Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-6-b39dc2ae3966@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| f2aeaa6d | 19-May-2026 |
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> |
power: sequencing: pcie-m2: Create BT node based on the pci_device_id[] table
Currently, pwrseq_pcie_m2_create_bt_node() hardcodes the BT compatible for creating the devicetree node. But to allow ad
power: sequencing: pcie-m2: Create BT node based on the pci_device_id[] table
Currently, pwrseq_pcie_m2_create_bt_node() hardcodes the BT compatible for creating the devicetree node. But to allow adding support for more devices in the future, create the BT node based on the pci_device_id[] table. The BT compatible is passed using 'driver_data'.
Co-developed-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com> Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-5-b39dc2ae3966@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| c4be5209 | 19-May-2026 |
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> |
power: sequencing: pcie-m2: Create serdev for PCI devices present before probe
So far, the driver is registering a notifier to create serdev for the PCI devices that are going to be attached after p
power: sequencing: pcie-m2: Create serdev for PCI devices present before probe
So far, the driver is registering a notifier to create serdev for the PCI devices that are going to be attached after probe. But it doesn't handle the devices present before probe. Due to this, serdev is not getting created for those existing devices.
Hence, create serdev for PCI devices available before probe as well.
Note that the serdev for available devices are created before registering the notifier. There is a small window where a device could appear after pwrseq_pcie_m2_create_serdev(), before notifier registration. But since M.2 cards are fixed to a slot, they are mostly added either before booting the host or after using hotplug. So this window is mostly theoretical.
Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-4-b39dc2ae3966@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| 8ababf88 | 19-May-2026 |
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> |
power: sequencing: pcie-m2: Improve PCI device ID check
Instead of hardcoding the PCI device check, use pci_match_id() to check for the known IDs using the pwrseq_m2_pci_ids[] array.
This makes add
power: sequencing: pcie-m2: Improve PCI device ID check
Instead of hardcoding the PCI device check, use pci_match_id() to check for the known IDs using the pwrseq_m2_pci_ids[] array.
This makes adding support for new devices easier.
Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-3-b39dc2ae3966@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| 08224255 | 19-May-2026 |
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> |
power: sequencing: pcie-m2: Allow creating serdev for multiple PCI devices
Current code makes it possible to create serdev for only one PCI device. But for scaling this driver, it is necessary to al
power: sequencing: pcie-m2: Allow creating serdev for multiple PCI devices
Current code makes it possible to create serdev for only one PCI device. But for scaling this driver, it is necessary to allow creating serdev for multiple PCI devices.
Hence, add provision for it by creating 'struct pwrseq_pci_dev' for each PCI device that requires serdev and add them to 'pwrseq_pcie_m2_ctx::pci_devices' list.
Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-2-b39dc2ae3966@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| da35b212 | 19-May-2026 |
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> |
power: sequencing: pcie-m2: Fix inconsistent function prefixes
All functions in this driver follow 'pwrseq_pcie_m2' prefix except a few. Fix them to avoid inconsistency.
Tested-by: Wei Deng <wei.de
power: sequencing: pcie-m2: Fix inconsistent function prefixes
All functions in this driver follow 'pwrseq_pcie_m2' prefix except a few. Fix them to avoid inconsistency.
Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-1-b39dc2ae3966@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| b4464d8f | 01-Apr-2026 |
Arnd Bergmann <arnd@arndb.de> |
power: sequencing: pcie-m2: add SERIAL_DEV_BUS dependency
The newly added serdev code fails to link when serdev is turned off:
arm-linux-gnueabi-ld: drivers/power/sequencing/pwrseq-pcie-m2.o: in fu
power: sequencing: pcie-m2: add SERIAL_DEV_BUS dependency
The newly added serdev code fails to link when serdev is turned off:
arm-linux-gnueabi-ld: drivers/power/sequencing/pwrseq-pcie-m2.o: in function `pwrseq_pcie_m2_remove_serdev': pwrseq-pcie-m2.c:(.text+0xc8): undefined reference to `serdev_device_remove' arm-linux-gnueabi-ld: drivers/power/sequencing/pwrseq-pcie-m2.o: in function `pwrseq_m2_pcie_notify': pwrseq-pcie-m2.c:(.text+0x69c): undefined reference to `of_find_serdev_controller_by_node' arm-linux-gnueabi-ld: pwrseq-pcie-m2.c:(.text+0x6f8): undefined reference to `serdev_device_alloc' arm-linux-gnueabi-ld: pwrseq-pcie-m2.c:(.text+0x724): undefined reference to `serdev_device_add'
Add another Kconfig dependency for this
Fixes: 3f736aecbdc8 ("power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260401191030.948046-1-arnd@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| 19b8c8fc | 01-Apr-2026 |
Arnd Bergmann <arnd@arndb.de> |
power: sequencing: pcie-m2: enforce PCI and OF dependencies
The driver fails to build when PCI is disabled:
drivers/power/sequencing/pwrseq-pcie-m2.c: In function 'pwrseq_pcie_m2_register_notifier'
power: sequencing: pcie-m2: enforce PCI and OF dependencies
The driver fails to build when PCI is disabled:
drivers/power/sequencing/pwrseq-pcie-m2.c: In function 'pwrseq_pcie_m2_register_notifier': drivers/power/sequencing/pwrseq-pcie-m2.c:368:54: error: 'pci_bus_type' undeclared (first use in this function); did you mean 'pci_pcie_type'? 368 | ret = bus_register_notifier(&pci_bus_type, &ctx->nb); | ^~~~~~~~~~~~ | pci_pcie_type
Similarly, when CONFIG_OF is disabled:
drivers/power/sequencing/pwrseq-pcie-m2.c: In function 'pwrseq_m2_pcie_create_bt_node': drivers/power/sequencing/pwrseq-pcie-m2.c:191:9: error: implicit declaration of function 'of_changeset_init' [-Wimplicit-function-declaration] 191 | of_changeset_init(ctx->ocs); | ^~~~~~~~~~~~~~~~~
Make both dependencies unconditional to prevent compile-testing in either configuration.
Fixes: 3f736aecbdc8 ("power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://patch.msgid.link/20260401091847.305294-1-arnd@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|
| 3f736aec | 26-Mar-2026 |
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> |
power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth
For supporting bluetooth over the non-discoverable UART interface of WCN7850, create the serdev device after enumerating the PC
power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth
For supporting bluetooth over the non-discoverable UART interface of WCN7850, create the serdev device after enumerating the PCIe interface. This is mandatory since the device ID is only known after the PCIe enumeration and the ID is used for creating the serdev device.
Since by default there is no OF or ACPI node for the created serdev, create a dynamic OF 'bluetooth' node with the 'compatible' property and attach it to the serdev device. This will allow the serdev device to bind to the existing bluetooth driver.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64) Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260326-pci-m2-e-v7-8-43324a7866e6@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
show more ...
|