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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <o6e5qygss55p6npjgaicxffsqdpv7kojgidr46zinsvfpxfxug@vn67nq4k6jzk>
Date: Mon, 9 Feb 2026 20:19:57 +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 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.

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

- Mani

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