All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Julien Grall <julien.grall.oss@gmail.com>,
	Elliott Mitchell <ehem+xen@m5p.com>,
	 xen-devel <xen-devel@lists.xenproject.org>,
	 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	julien@xen.org
Subject: Re: Question on PCIe Device Tree bindings, Was: [PATCH] xen/arm: domain_build: Ignore device nodes with invalid addresses
Date: Thu, 4 Feb 2021 15:08:21 -0600	[thread overview]
Message-ID: <CAL_JsqKTz8J3txk9W5ekqmfON_g_TdLYsLi0YXYU3rmiyubL2A@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2102041228560.29047@sstabellini-ThinkPad-T480s>

On Thu, Feb 4, 2021 at 2:36 PM Stefano Stabellini
<sstabellini@kernel.org> wrote:
>
> On Thu, 4 Feb 2021, Rob Herring wrote:
> > On Thu, Feb 4, 2021 at 11:56 AM Stefano Stabellini
> > <sstabellini@kernel.org> wrote:
> > >
> > > Hi Rob,
> > >
> > > We have a question on the PCIe device tree bindings. In summary, we have
> > > come across the Raspberry Pi 4 PCIe description below:
> > >
> > >
> > > pcie0: pcie@7d500000 {
> > >    compatible = "brcm,bcm2711-pcie";
> > >    reg = <0x0 0x7d500000  0x0 0x9310>;
> > >    device_type = "pci";
> > >    #address-cells = <3>;
> > >    #interrupt-cells = <1>;
> > >    #size-cells = <2>;
> > >    interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> > >                 <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
> > >    interrupt-names = "pcie", "msi";
> > >    interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> > >    interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143
> > >                                                      IRQ_TYPE_LEVEL_HIGH>;
> > >    msi-controller;
> > >    msi-parent = <&pcie0>;
> > >
> > >    ranges = <0x02000000 0x0 0xc0000000 0x6 0x00000000
> > >              0x0 0x40000000>;
> > >    /*
> > >     * The wrapper around the PCIe block has a bug
> > >     * preventing it from accessing beyond the first 3GB of
> > >     * memory.
> > >     */
> > >    dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000
> > >                  0x0 0xc0000000>;
> > >    brcm,enable-ssc;
> > >
> > >    pci@1,0 {
> > >            #address-cells = <3>;
> > >            #size-cells = <2>;
> > >            ranges;
> > >
> > >            reg = <0 0 0 0 0>;
> > >
> > >            usb@1,0 {
> > >                    reg = <0x10000 0 0 0 0>;
> > >                    resets = <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
> > >            };
> > >    };
> > > };
> > >
> > >
> > > Xen fails to parse it with an error because it tries to remap reg =
> > > <0x10000 0 0 0 0> as if it was a CPU address and of course it fails.
> > >
> > > Reading the device tree description in details, I cannot tell if Xen has
> > > a bug: the ranges property under pci@1,0 means that pci@1,0 is treated
> > > like a default bus (not a PCI bus), hence, the children regs are
> > > translated using the ranges property of the parent (pcie@7d500000).
> > >
> > > Is it possible that the device tree is missing device_type =
> > > "pci" under pci@1,0? Or is it just implied because pci@1,0 is a child of
> > > pcie@7d500000?
> >
> > Indeed, it should have device_type. Linux (only recently due to
> > another missing device_type case) will also look at node name, but
> > only 'pcie'.
> >
> > We should be able to create (or extend pci-bus.yaml) a schema to catch
> > this case.
>
> Ah, that is what I needed to know, thank you!  Is Linux considering a
> node named "pcie" as if it has device_type = "pci"?

Yes, it was added for Rockchip RK3399 to avoid a DT update and regression.

> In Xen, also to cover the RPi4 case, maybe I could add a check for the
> node name to be "pci" or "pcie" and if so Xen could assume device_type =
> "pci".

I assume this never worked for RPi4 (and Linux will have the same
issue), so can't we just update the DT in this case?

Rob


  reply	other threads:[~2021-02-04 21:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02 17:47 [PATCH] xen/arm: domain_build: Ignore device nodes with invalid addresses Elliott Mitchell
2021-02-02 18:12 ` Julien Grall
2021-02-02 19:21   ` Julien Grall
2021-02-03  0:18     ` Stefano Stabellini
2021-02-03 17:44       ` Julien Grall
2021-02-03 22:18         ` Stefano Stabellini
2021-02-03 22:52           ` Julien Grall
2021-02-04  0:13             ` Stefano Stabellini
2021-02-04 16:29               ` Julien Grall
2021-02-04 17:56                 ` Question on PCIe Device Tree bindings, Was: " Stefano Stabellini
2021-02-04 18:31                   ` Rob Herring
2021-02-04 20:36                     ` Stefano Stabellini
2021-02-04 21:08                       ` Rob Herring [this message]
2021-02-04 21:33                         ` Stefano Stabellini
2021-02-04 21:52                           ` Rob Herring
2021-02-04 22:02                             ` Stefano Stabellini
2021-02-05  3:32                             ` Elliott Mitchell
2021-02-05 13:56                               ` Rob Herring
2021-02-04 22:39                 ` Stefano Stabellini
2021-02-06  8:47                   ` Julien Grall

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_JsqKTz8J3txk9W5ekqmfON_g_TdLYsLi0YXYU3rmiyubL2A@mail.gmail.com \
    --to=robh@kernel.org \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=ehem+xen@m5p.com \
    --cc=julien.grall.oss@gmail.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.