Merge tag 'pwrseq-updates-for-v6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel...
authorLinus Torvalds <torvalds@linux-foundation.org>
Tue, 16 Jul 2024 00:34:31 +0000 (17:34 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Tue, 16 Jul 2024 00:34:31 +0000 (17:34 -0700)
commite763c9ec71dd462337d0b671ec5014b737c5342e
treecb077cc4599fb10db856d74ff7ac8a7508c1ca8d
parentcdf471c348c1200ca243775b4b8d6eaa6d7f3979
parent50b040ef373293b4ae2ecdc5873daa4656724868
Merge tag 'pwrseq-updates-for-v6.11-rc1' of git://git./linux/kernel/git/brgl/linux

Pull power sequencing updates from Bartosz Golaszewski:
 "This has been in development since last year's Linux Plumbers
  Conference and was inspired by the need to enable support upstream for
  Bluetooth/WLAN chips on Qualcomm platforms.

  The main problem we're fixing is powering up devices which are
  represented as separate objects in the kernel (binding to different
  drivers) but which share parts of the power-up sequence and thus need
  some kind of a mediator who knows the possible interactions and can
  assure they don't interfere with neither device's bring up. An example
  of such an inter-driver interaction is the WCN family of BT/WLAN chips
  from Qualcomm of which some models require the user to observe a
  certain delay between driving the bt-enable and wlan-enable GPIOs.

  This is not a new problem but up to this point all attempts at
  addressing it ended up hitting one wall or another and being dropped.
  The main obstacle was the fact that most these attempts tried to
  introduce the concept of a "power sequence" into the device-tree
  bindings which breaks the main DT rule: describe the hardware, not its
  behavior. The solution I proposed focuses on making the power
  sequencer drivers interpret the actual HW description flexibly. More
  details on that are in the linked cover letter.

  The second problem fixed here is powering up PCI devices before they
  are detected on the bus. This is achieved by creating special platform
  devices for device-tree nodes describing hard-wired PCI devices which
  bind to the so-called PCI power control drivers which enable required
  resources and trigger a bus rescan once the controlled device is up
  then setup the correct devlink hierarchy for power-management.

  By combining the two new frameworks we implemented the power
  sequencing PCI power control driver which is capable of powering up
  the WLAN modules of the QCom WCN family of chipsets.

  All this has spent a significant amount of time in linux-next and
  enabled WLAN/BT support on several Qualcomm platforms. To further
  prove that this is useful and needed: right after this was picked up
  into next, I was sent a series using the subsystem for a similar
  use-case on Amlogic platforms.

  This contains the core power sequencing framework, the first driver,
  PCI changes using the pwrseq library (blessed by Bjorn Helgaas) and
  some fixes that came later"

* tag 'pwrseq-updates-for-v6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  PCI/pwrctl: only call of_platform_populate() if CONFIG_OF is enabled
  power: sequencing: simplify returning pointer without cleanup
  PCI/pwrctl: Add a PCI power control driver for power sequenced devices
  PCI/pwrctl: Add PCI power control core code
  PCI/pwrctl: Create platform devices for child OF nodes of the port node
  PCI/pwrctl: Reuse the OF node for power controlled devices
  PCI: Hold the rescan mutex when scanning for the first time
  power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets
  power: sequencing: implement the pwrseq core
MAINTAINERS