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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cish7iljd23mon4onzbonpuvii7mccwygllr3bcqcpo7zbp2o2@lbzokxr6dod3>
Date: Tue, 10 Feb 2026 16:33:08 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Neil Armstrong <neil.armstrong@...aro.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Geert Uytterhoeven <geert+renesas@...der.be>, 
	Magnus Damm <magnus.damm@...il.com>, Bartosz Golaszewski <brgl@...nel.org>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Bjorn Andersson <andersson@...nel.org>, 
	Konrad Dybcio <konradybcio@...nel.org>, linux-usb@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org, linux-pci@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v3 4/9] pci: pwrctrl: generic: support for the
 UPD720201/UPD720202 USB 3.0 xHCI Host Controller

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@...aro.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.
> > > 
> > > > 
> > > > > 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.

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

-- 
மணிவண்ணன் சதாசிவம்