linux-toradex.git/drivers/pci/pwrctrl, branch master

PCI/pwrctrl: Power off child devices on power-on failure

2026-10-21T18:15:28+00:00

pci_pwrctrl_power_on_device() recursively powers on the child nodes of a
device before powering on the device itself. If powering on a child fails
(e.g. returning -EPROBE_DEFER), the function returned immediately, leaving
the sibling children that were already powered on in the same loop
iteration enabled.

Since probe deferral is a standard boot path, this leads to unbounded
regulator and clock enable increments across retries. The error path in
pci_pwrctrl_power_on_devices() only powers off the top-level children
processed before the failing one and explicitly stops at it, so it can
never clean up the siblings leaked deeper in the failed subtree.

Power off the sibling children that were successfully powered on before a
child fails, and power off all children if the device's own power_on()
fails after its children were already enabled. Switch to a manual child
iterator so the failing node can be tracked and its reference released in
the error path.

Fixes: b35cf3b6aa1e ("PCI/pwrctrl: Add APIs to power on/off pwrctrl devices")
Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Bartosz Golaszewski 
Reviewed-by: Manivannan Sadhasivam 
Link: https://patch.msgid.link/20260909-pwrtctl-power-on-rallback-v1-1-412ef996ba27@oss.qualcomm.com

PCI/pwrctrl: Only destroy devices created by pwrctrl core

2026-10-21T18:15:28+00:00

pci_pwrctrl_create_device() only creates platform devices for OF nodes
that pci_pwrctrl_is_required() accepts, but pci_pwrctrl_destroy_device()
unregisters the platform device of every available child node without
that check.

Nodes under a PCI host controller that are not pwrctrl devices may have
been populated by another mechanism.  Destroying them here would tear down
devices owned by other code.

Mirror the check done at creation time so that only devices created by the
pwrctrl core are removed.

Fixes: 4c4132489201 ("PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices")
Signed-off-by: Shawn Lin 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Bartosz Golaszewski 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/1791446700-100166-1-git-send-email-shawn.lin@rock-chips.com

PCI/pwrctrl: generic: Fix leaking array from of_regulator_bulk_get_all()

2026-10-21T18:15:28+00:00

of_regulator_bulk_get_all() allocates the consumers array and returns it to
the caller, who is expected to free it at an appropriate time.  PCI pwrctrl
never did, leading to a memory leak.

Add an explicit kfree() for the consumers array.

Fixes: 75996c92f4de ("PCI/pwrctrl: Add pwrctrl driver for PCI slots")
Signed-off-by: Alexey Charkov 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Bartosz Golaszewski 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260930-pci-pwrctrl-kfree-v1-1-f09bbffd8da3@flipper.net

PCI/pwrctrl: tc9563: Switch per-port reset to GPIO descriptor API

2026-10-21T18:15:28+00:00

Remove the local TC9563_GPIO_MASK and TC9563_GPIO_DEASSERT_BITS
definitions, which are no longer used after switching to the GPIO
descriptor API. Move TC9563_GPIO_CONFIG and TC9563_RESET_GPIO
definitions in tc9563.h header file.

Replace the direct regmap-based per-port reset logic in
assert_deassert_reset() with gpiod_direction_output() calls, falling
back to the legacy regmap approach only when no reset-gpios DT
property is present for a given port.

Add the reset GPIO pointer to struct tc9563_pwrctrl_cfg and introduce
tc9563_pwrctrl_parse_reset_line() to look up reset-gpios from each PCI
downstream port child node. The lookup is done lazily at the beginning of
power_on(), returning -EPROBE_DEFER until the GPIO chip is registered.

Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Bartosz Golaszewski 
Reviewed-by: Manivannan Sadhasivam 
Reviewed-by: Alex Elder 
Link: https://patch.msgid.link/20260909-pci-tc9563-aux-v5-4-c9b33f56c8d3@oss.qualcomm.com

PCI/pwrctrl: tc9563: Add GPIO auxiliary device support

2026-10-21T18:15:17+00:00

The TC9563 embeds a GPIO controller used for per-port reset signals.
Create an auxiliary device for it so the gpio-tc9563 driver can register
the GPIO chip and enable DT-based GPIO lookups. Pass the tc9563 regmap to
the auxiliary device as its platform data.

The pwrctrl driver does not wait for the GPIO chip to be probed. The
per-port reset GPIO lookup, returning -EPROBE_DEFER until the chip is
registered, is added in the next patch.

Signed-off-by: Lorenzo Bianconi 
[bhelgaas: squash Geert Uytterhoeven  Kconfig fix:
  https://lore.kernel.org/all/45484c37512a3102495d8b75b6e9f72a141ba42e.1792574560.git.geert+renesas@glider.be,
  Reviewed-by: Bartosz Golaszewski 
  Acked-by: Lorenzo Bianconi ]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Bartosz Golaszewski 
Reviewed-by: Manivannan Sadhasivam 
Reviewed-by: Alex Elder 
Link: https://patch.msgid.link/20260909-pci-tc9563-aux-v5-3-c9b33f56c8d3@oss.qualcomm.com

PCI/pwrctrl: tc9563: Allow RESX reset assertion to sleep

2026-09-03T20:46:56+00:00

The RESX GPIO may be provided by a sleeping GPIO controller, such as an I2C
or SPI I/O expander. Calling gpiod_set_value() for such a GPIO triggers the
following warning:

  WARNING: ... drivers/gpio/gpiolib.c:4030 at gpiod_set_value()

The TC9563 power-on and power-off callbacks already sleep while enabling or
disabling regulators and while waiting for oscillator stabilization.  Use
gpiod_set_value_cansleep() for RESX so it can be driven without triggering
the warning.

Fixes: 4c9c7be47310 ("PCI: pwrctrl: Add power control driver for TC9563")
Signed-off-by: Abel Vesa 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam 
Reviewed-by: Bartosz Golaszewski 
Link: https://patch.msgid.link/20260825-pci-pwrctl-tc9563-use-cansleep-for-resx-v1-1-0dbe7cfd8200@oss.qualcomm.com

PCI/pwrctrl: tc9563: Use devm-managed I2C dummy device allocation

2026-08-31T17:29:20+00:00

Switch from i2c_new_dummy_device() to its devm variant
devm_i2c_new_dummy_device() so the I2C client is automatically
unregistered when the driver is removed or on probe failure.

This allows removing the manual i2c_unregister_device() calls from both the
probe error path and the remove function, and lets the i2c_client pointer
be a local variable in probe instead of storing it in the driver data
structure.

Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam 
Reviewed-by: Bartosz Golaszewski 
Link: https://patch.msgid.link/20260729-pci-pwrctrl-tc956x-regmap-v1-2-20ce61a3ce12@oss.qualcomm.com

PCI/pwrctrl: tc9563: Rely on regmap APIs

2026-08-31T17:29:20+00:00

Replace the custom tc9563_pwrctrl_i2c_{read,write,bulk_write} functions
with standard regmap APIs. The device uses 24-bit big-endian register
addresses and 32-bit little-endian register values over I2C, which is
directly supported by regmap.

This removes the open-coded I2C transfer handling and lets the regmap
core handle formatting, locking, and multi-register coalescing.

Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam 
Reviewed-by: Bartosz Golaszewski 
Link: https://patch.msgid.link/20260729-pci-pwrctrl-tc956x-regmap-v1-1-20ce61a3ce12@oss.qualcomm.com

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