On 2/10/26 09:00, Manivannan Sadhasivam wrote:

On Mon, Feb 09, 2026 at 03:59:20PM +0100, Neil Armstrong wrote:

quoted

On 2/9/26 15:49, Manivannan Sadhasivam wrote:

quoted

On Mon, Feb 09, 2026 at 03:00:02PM +0100, Neil Armstrong wrote:

quoted

On 2/9/26 12:30, Manivannan Sadhasivam wrote:

quoted

On Fri, Feb 06, 2026 at 03:50:32PM +0100, Neil Armstrong wrote:

quoted

Enable the generic pwrctrl driver to control the power of the
PCIe UPD720201/UPD720202 USB 3.0 xHCI Host Controller.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
    drivers/pci/pwrctrl/generic.c | 4 ++++
    1 file changed, 4 insertions(+)

diff --git a/drivers/pci/pwrctrl/generic.c b/drivers/pci/pwrctrl/generic.c
index 08e53243cdbd..4a57a631362f 100644
--- a/drivers/pci/pwrctrl/generic.c
+++ b/drivers/pci/pwrctrl/generic.c

@@ -73,6 +73,10 @@ static const struct of_device_id pci_pwrctrl_slot_of_match[] = {
    	{
    		.compatible = "pciclass,0604",
    	},
+	/* Renesas UPD720201/UPD720202 USB 3.0 xHCI Host Controller */
+	{
+		.compatible = "pci1912,0014",

No need to add the compatible to the driver. Just use the existing compatible as
fallback in the binding/dts.

???

Sorry but this is insane, in no world a standalone PCIe USB controller could be qualified as
compatible as a pciclass,0604 slot.

AFAIU, 'compatibility' implies that the driver can safely fallback and would
still work. If we add dedicated compatibles for each endpoint devices, then we
will just keep adding forever. Powering up a PCIe slot and an endpoint device
are conceptually same.

We're not speaking about driver here, but about compatible string which describes
a device, a PCI endpoint and a PCIe slot are 2 very different devices that are
nowhere compatible.

quoted

quoted

Technically it would work just fine, but "compatibility" has a meaning....

I view compatibility interms of device operation, not device as a whole. But
sure, I could be wrong. If the DT maintainers say so, I won't insist.

In the actual way it's defined _today_, the "slot" and "endpoint" power up schemes are
compatible, but I hope the slot bindings will get much more features to describe the
real world slots power properties. And no, endpoints will definitely not have the same
features as slots, using it as a fallback today is an error.

On the other side, adding a "simple-pci-endpoint" compatible that enables any supply
and clock would be a good solution, if the DT maintainers agrees of course.

We do have a 'pci-host-cam-generic' compatible. So we can also have something
like 'pci-pwrctrl-generic' IMO.

I don't want to into this route, I just want to powerup the USB3 controller on
the Pocket S2 gaming device, not spend 6 months into _not_ modifying a driver compatible
list.

All this feels bulky, who a pci device would be compatible with something like
'pci-pwrctrl-generic' we're speaking about a pci device, not a power control device.

It's nowhere similar to the 'pci-host-cam-generic' situation, this describes well defined
host controller interface.

Neil

- Mani