From: Rob Herring <robh@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Sergio Paracuellos" <sergio.paracuellos@gmail.com>,
"Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Hector Martin" <marcan@marcan.st>,
"Sven Peter" <sven@svenpeter.dev>,
"Alyssa Rosenzweig" <alyssa@rosenzweig.io>,
"Ray Jui" <rjui@broadcom.com>,
"Scott Branden" <sbranden@broadcom.com>,
"Broadcom internal kernel review list"
<bcm-kernel-feedback-list@broadcom.com>,
"Florian Fainelli" <florian.fainelli@broadcom.com>,
"Jim Quinlan" <jim2101024@gmail.com>,
"Nicolas Saenz Julienne" <nsaenz@kernel.org>,
"Will Deacon" <will@kernel.org>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Srikanth Thokala" <srikanth.thokala@intel.com>,
"Ryder Lee" <ryder.lee@mediatek.com>,
"Jianjun Wang" <jianjun.wang@mediatek.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Daire McNamara" <daire.mcnamara@microchip.com>,
"Bjorn Andersson" <andersson@kernel.org>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
"Marek Vasut" <marek.vasut+renesas@gmail.com>,
"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
"Shawn Lin" <shawn.lin@rock-chips.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Jingoo Han" <jingoohan1@gmail.com>,
"Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
"Bharat Kumar Gogada" <bharat.kumar.gogada@amd.com>,
"Michal Simek" <michal.simek@amd.com>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Mark Kettenis" <kettenis@openbsd.org>,
"Tom Joseph" <tjoseph@cadence.com>,
"Ahmad Zainie" <wan.ahmad.zainie.wan.mohamad@intel.com>,
"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Thippeswamy Havalige" <thippeswamy.havalige@amd.com>,
linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, asahi@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-rpi-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v2 2/4] dt-bindings: PCI: mediatek,mt7621: add missing child node reg
Date: Thu, 11 Apr 2024 12:41:07 -0500 [thread overview]
Message-ID: <CAL_JsqKaJR9v=EEwm=rGf-XtXhhSd4_U2FUJoCoN_mcvPBtPBA@mail.gmail.com> (raw)
In-Reply-To: <20240411161108.GA2184354@bhelgaas>
On Thu, Apr 11, 2024 at 11:11 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Thu, Apr 11, 2024 at 09:21:07AM -0500, Rob Herring wrote:
> > On Thu, Apr 11, 2024 at 07:39:17AM -0500, Bjorn Helgaas wrote:
> > > On Thu, Apr 11, 2024 at 08:13:18AM +0200, Sergio Paracuellos wrote:
> > > > On Thu, Apr 11, 2024 at 8:01 AM Krzysztof Kozlowski
> > > > <krzysztof.kozlowski@linaro.org> wrote:
> > > > > On 10/04/2024 23:26, Bjorn Helgaas wrote:
> > > > > > On Wed, Apr 10, 2024 at 08:15:19PM +0200, Krzysztof Kozlowski wrote:
> > > > > >> MT7621 PCI host bridge has children which apparently are also PCI host
> > > > > >> bridges, at least that's what the binding suggest.
> > > > > >
> > > > > > What does it even mean for a PCI host bridge to have a child that is
> > > > > > also a PCI host bridge?
> >
> > It should say 'root port' instead as the binding description correctly
> > says.
>
> OK, that makes a lot more sense, and we should fix the commit log.
>
> > > > > I think the question should be towards Mediatek folks. I don't know what
> > > > > this hardware is exactly, just looks like pci-pci-bridge. The driver
> > > > > calls the children host bridges as "ports".
> > > >
> > > > You can see the topology here in my first driver submit cover letter
> > > > message [0].
> > > >
> > > > [0]: https://lore.kernel.org/all/CAMhs-H-BA+KzEwuDPzcmrDPdgJBFA2XdYTBvT4R4MEOUB=WQ1g@mail.gmail.com/t/
> > >
> > > Nothing unusual here, this looks like the standard PCIe topology.
> > >
> > > What *might* be unusual is describing the Root Ports in DT. Since
> > > they are standard PCI devices, they shouldn't need DT description
> > > unless there's some unusual power/clock/reset control or something
> > > that is not discoverable via PCI enumeration.
> >
> > It's only unusual because typically there's only 1 RP per host bridge
> > and properties which really apply to the RP get stuck in the host bridge
> > node because we don't have a RP node. An example is perst-gpios. That's
> > not a property of the RP either, but the RP is the upstream side of a
> > slot and we often don't have a node for the device either.
>
> Makes sense.
>
> I'm still confused about one thing, maybe just because I don't really
> know how to read these bindings. The binding now looks like this:
>
> properties:
> compatible:
> const: mediatek,mt7621-pci
>
> reg:
> items:
> - description: host-pci bridge registers
> - description: pcie port 0 RC control registers # A
> - description: pcie port 1 RC control registers # A
> - description: pcie port 2 RC control registers # A
>
> patternProperties:
> '^pcie@[0-2],0$':
> type: object
> $ref: /schemas/pci/pci-pci-bridge.yaml#
>
> properties:
> reg: # B
> maxItems: 1
>
> It looks like the "A" items are separate things from the "B" items?
>
> But I think the relevant code is here:
>
> mt7621_pcie_probe
> mt7621_pcie_parse_dt
> pcie->base = devm_platform_ioremap_resource(pdev, 0) # 1
> for_each_available_child_of_node(node, child)
> mt7621_pcie_parse_port
> port->base = devm_platform_ioremap_resource(pdev, slot + 1) # 2
>
> where it looks like both "1" and "2" use the items in the "A" list,
> i.e., resources 0, 1, 2, 3, all from the same platform device. Is
> there code that uses the "B" item that this patch adds?
The A items are in the host address space. The B item is a PCI
address. Specifically, for PCI devices, the first entry is config
space with just the device and function (devfn). The format is defined
in the OpenFirmware PCI bus supplement.
Rob
next prev parent reply other threads:[~2024-04-11 17:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-10 18:15 [PATCH v2 1/4] dt-bindings: PCI: cdns,cdns-pcie-host: drop redundant msi-parent and pci-bus.yaml Krzysztof Kozlowski
2024-04-10 18:15 ` [PATCH v2 2/4] dt-bindings: PCI: mediatek,mt7621: add missing child node reg Krzysztof Kozlowski
2024-04-10 21:26 ` Bjorn Helgaas
2024-04-11 6:01 ` Krzysztof Kozlowski
2024-04-11 6:13 ` Sergio Paracuellos
2024-04-11 6:20 ` Krzysztof Kozlowski
2024-04-11 6:37 ` Sergio Paracuellos
2024-04-11 12:39 ` Bjorn Helgaas
2024-04-11 13:33 ` Sergio Paracuellos
2024-04-11 14:21 ` Rob Herring
2024-04-11 16:11 ` Bjorn Helgaas
2024-04-11 17:41 ` Rob Herring [this message]
2024-04-10 18:15 ` [PATCH v2 3/4] dt-bindings: PCI: host-bridges: switch from deprecated pci-bus.yaml Krzysztof Kozlowski
2024-04-10 18:15 ` [PATCH v2 4/4] dt-bindings: PCI: mediatek,mt7621-pcie: " Krzysztof Kozlowski
2024-04-10 19:32 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAL_JsqKaJR9v=EEwm=rGf-XtXhhSd4_U2FUJoCoN_mcvPBtPBA@mail.gmail.com' \
--to=robh@kernel.org \
--cc=alyssa@rosenzweig.io \
--cc=andersson@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=asahi@lists.linux.dev \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bharat.kumar.gogada@amd.com \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=daire.mcnamara@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=florian.fainelli@broadcom.com \
--cc=geert+renesas@glider.be \
--cc=gustavo.pimentel@synopsys.com \
--cc=heiko@sntech.de \
--cc=helgaas@kernel.org \
--cc=jianjun.wang@mediatek.com \
--cc=jiaxun.yang@flygoat.com \
--cc=jim2101024@gmail.com \
--cc=jingoohan1@gmail.com \
--cc=kettenis@openbsd.org \
--cc=kishon@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzk+dt@kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=kw@linux.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=magnus.damm@gmail.com \
--cc=manivannan.sadhasivam@linaro.org \
--cc=marcan@marcan.st \
--cc=marek.vasut+renesas@gmail.com \
--cc=matthias.bgg@gmail.com \
--cc=michal.simek@amd.com \
--cc=neil.armstrong@linaro.org \
--cc=nsaenz@kernel.org \
--cc=rjui@broadcom.com \
--cc=ryder.lee@mediatek.com \
--cc=sbranden@broadcom.com \
--cc=sergio.paracuellos@gmail.com \
--cc=shawn.lin@rock-chips.com \
--cc=srikanth.thokala@intel.com \
--cc=sven@svenpeter.dev \
--cc=thippeswamy.havalige@amd.com \
--cc=tjoseph@cadence.com \
--cc=wan.ahmad.zainie.wan.mohamad@intel.com \
--cc=will@kernel.org \
--cc=yoshihiro.shimoda.uh@renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).