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: <8b18433a-5836-4a65-b790-9f51112d1f5c@linaro.org>
Date: Tue, 10 Feb 2026 10:01:00 +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/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.

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
>