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: <b46da4da-93aa-4213-ad75-ec7709008b95@linaro.org>
Date: Mon, 9 Feb 2026 15:59:20 +0100
From: Neil Armstrong <neil.armstrong@...aro.org>
To: Manivannan Sadhasivam <mani@...nel.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 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.

Neil

> 
> - Mani
>