linux-kernel - Re: [PATCH v2 1/8] dt-bindings: PCI: Add binding for qps615

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: <ececab1a-b4c7-49ac-8a76-038d672a0dd4@kernel.org>
Date: Fri, 23 Aug 2024 15:51:25 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Krishna Chaitanya Chundru <quic_krichai@...cinc.com>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>,
 Krzysztof Wilczyński <kw@...ux.com>,
 Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Konrad Dybcio <konrad.dybcio@...aro.org>,
 cros-qcom-dts-watchers@...omium.org, Bartosz Golaszewski <brgl@...ev.pl>,
 Jingoo Han <jingoohan1@...il.com>, andersson@...nel.org,
 quic_vbadigan@...cinc.com, linux-arm-msm@...r.kernel.org,
 linux-pci@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v2 1/8] dt-bindings: PCI: Add binding for qps615

On 23/08/2024 11:44, Manivannan Sadhasivam wrote:
> On Fri, Aug 23, 2024 at 11:01:37AM +0200, Krzysztof Kozlowski wrote:
>> On 22/08/2024 16:16, Manivannan Sadhasivam wrote:
>>> On Mon, Aug 05, 2024 at 04:43:47PM +0200, Krzysztof Kozlowski wrote:
>>>> On 05/08/2024 07:57, Krishna Chaitanya Chundru wrote:
>>>>>>
>>>>> Hi Krzysztof,
>>>>>
>>>>> QPS615 has a 3 downstream ports and 1 upstream port as described below
>>>>> diagram.
>>>>> For this entire switch there are some supplies which we described in the
>>>>> dt-binding (vdd18-supply, vdd09-supply etc) and one GPIO which controls
>>>>> reset of the switch (reset-gpio). The switch hardware can configure the
>>>>> individual ports DSP0, DSP1, DSP2, upstream port and also one integrated
>>>>> ethernet endpoint which is connected to DSP2(I didn't mentioned in the
>>>>> diagram) through I2C.
>>>>>
>>>>> The properties other than supplies,i2c client, reset gpio which
>>>>> are added will be applicable for all the ports.
>>>>> _______________________________________________________________
>>>>> |   |i2c|                   QPS615       |Supplies||Resx gpio |
>>>>> |   |___|              _________________ |________||__________|
>>>>> |      ________________| Upstream port |_____________         |
>>>>> |      |               |_______________|            |         |
>>>>> |      |                       |                    |         |
>>>>> |      |                       |                    |         |
>>>>> |  ____|_____              ____|_____            ___|____     |
>>>>> |  |DSP 0   |              | DSP 1  |            | DSP 2|     |
>>>>> |  |________|              |________|            |______|     |
>>>>> |_____________________________________________________________|
>>>>>
>>>>
>>>> I don't get why then properties should apply to main device node.
>>>>
>>>
>>> The problem here is, we cannot differentiate between main device node and the
>>> upstream node. Typically the differentiation is not needed because no one cared
>>> about configuring the upstream port. But this PCIe switch is special (as like
>>> most of the Qcom peripherals).
>>>
>>> I agree that if we don't differentiate then it also implies that all main node
>>> properties are applicable to upstream port and vice versa. But AFAIK, upstream
>>> port is often considered as the _device_ itself as it shares the same bus
>>> number.
>>
>> Well, above diagram shows supplies being part of the entire device, not
>> each port. That's confusing. Based on diagram, downstream ports do not
>> have any supplies... and what exactly do they supply? Let's look at
>> vdd18 and vdd09 which sound main supplies of the entire device. In
>> context of port: what exactly do they power? Which part of the port?
>>
> 
> The supplies for the downstream ports are derived from the switch power supply
> only. There is no way we can describe them as the port suppliers are internal to
> the device.

IIUC, this means supplies are not valid for downstream ports, so it is a
proof that binding is not correct. I don't get why we keep poking this
and get to the same conclusions I had 3 weeks ago.

Basically the binding is saying that downstream ports are identical to
the device. Including the aspect of having more downstream ports (so
device -> downstream ports -> downstream ports -> downstream ports ...
infinite). To remind that was my conclusion:

"Downstream port is not the same as device. Why downstream port has the
same supplies? To which pins are they connected?"

Best regards,
Krzysztof