[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aA9jjyBR5DZcSbyQ@hovoldconsulting.com>
Date: Mon, 28 Apr 2025 13:16:31 +0200
From: Johan Hovold <johan@...nel.org>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Wenbin Yao <quic_wenbyao@...cinc.com>, catalin.marinas@....com,
will@...nel.org, linux-arm-kernel@...ts.infradead.org,
andersson@...nel.org, konradybcio@...nel.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, krishna.chundru@....qualcomm.com,
quic_vbadigan@...cinc.com, quic_mrana@...cinc.com,
quic_cang@...cinc.com, quic_qianyu@...cinc.com
Subject: Re: [PATCH v2 2/4] arm64: dts: qcom: x1e80100: add bus topology for
PCIe domain 3
On Sat, Apr 26, 2025 at 12:44:57PM +0200, Konrad Dybcio wrote:
> On 4/25/25 1:55 PM, Johan Hovold wrote:
> > On Fri, Apr 25, 2025 at 12:22:56PM +0200, Konrad Dybcio wrote:
> >> On 4/25/25 11:29 AM, Wenbin Yao wrote:
> >>> From: Qiang Yu <quic_qianyu@...cinc.com>
> >>>
> >>> Add pcie3port node to represent the PCIe bridge of PCIe3 so that PCI slot
> >>> voltage rails can be described under this node in the board's dts.
> >>>
> >>> Signed-off-by: Qiang Yu <quic_qianyu@...cinc.com>
> >>> Signed-off-by: Wenbin Yao <quic_wenbyao@...cinc.com>
> >>> ---
> >>> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 11 +++++++++++
> >>> 1 file changed, 11 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> >>> index 46b79fce9..430f9d567 100644
> >>> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> >>> @@ -3287,6 +3287,17 @@ opp-128000000 {
> >>> opp-peak-kBps = <15753000 1>;
> >>> };
> >>> };
> >>> +
> >>> + pcie3port: pcie@0 {
> >>
> >> @0,0 for PCIe adressing (bus,device)
> >
> > No, the bus number is not included in the unit address, so just the
> > device number (0) is correct here (when the function is 0) IIUC.
>
> Some DTs definitely have that, but I couldn't find any documentation to
> back the syntax up or explain it properly
It's part of the spec:
http://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf
The first number is the device number and the second is the function
which can be left out if zero.
Johan
Powered by blists - more mailing lists