Re: [PATCH v3 4/9] pci: pwrctrl: generic: support for the UPD720201/UPD720202 USB 3.0 xHCI Host Controller

[Dmitry Baryshkov]

On Tue, Feb 10, 2026 at 04:33:08PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Feb 10, 2026 at 10:01:00AM +0100, Neil Armstrong wrote:
> > On 2/10/26 09:00, Manivannan Sadhasivam wrote:
> > > On Mon, Feb 09, 2026 at 03:59:20PM +0100, Neil Armstrong wrote:
> > > > On 2/9/26 15:49, Manivannan Sadhasivam wrote:
> > > > > On Mon, Feb 09, 2026 at 03:00:02PM +0100, Neil Armstrong wrote:
> > > > > > On 2/9/26 12:30, Manivannan Sadhasivam wrote:
> > > > > > > On Fri, Feb 06, 2026 at 03:50:32PM +0100, Neil Armstrong wrote:
> > > > > > > > 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@xxxxxxxxxx>
> > > > > > > > ---
> > > > > > > >     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.
> > > > 
> > > > > 
> > > > > > 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.
> > 
> 
> Sure, I don't want you to spend that much time either. But I was trying to avoid
> having a solution that just works only for your platform.
> 
> > 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.
> > 
> 
> I honestly don't see much difference. ECAM is just *a way* of accessing the
> config space of the PCIe devices. If we can have a compatible based on that,
> then I don't see why can't we have one for pwrctrl. Only difference is that
> "pwrctrl" terminology is not part of any spec, but for sure every device would
> have some kind of power control implementation.

ECAM is a way of accessing config space. But there is nothing like that
for "pwrctrl-generic". It's just a Linux-internal view on powering on
these devices. Other OS would support ECAM, but would have no idea, what
pwrctrl-generic means.

> 
> Anyhow, I don't have other solutions on top of my head now. Let's go with
> per-device compatible for now. I'll deal with a generic solution later.
> 
> - Mani
> 
> -- 
> மணிவண்ணன் சதாசிவம்

-- 
With best wishes
Dmitry