Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220305052304.726050-1-lizhi.hou@xilinx.com> <20220305052304.726050-3-lizhi.hou@xilinx.com>
 <e4c058e9-6549-4ce2-be05-d09d5b1a9fc9@redhat.com>
In-Reply-To: <e4c058e9-6549-4ce2-be05-d09d5b1a9fc9@redhat.com>
From:   Rob Herring <robh@kernel.org>
Date:   Mon, 7 Mar 2022 08:07:55 -0600
Message-ID: <CAL_JsqKzxq8T=obPQwXeNyqedQOKkmm8hwHdfVgKr15EyAgBnQ@mail.gmail.com>
Subject: Re: [PATCH V1 RESEND 2/4] Documentation: devicetree: bindings: add
 binding for PCIe endpoint bus
To:     Tom Rix <trix@redhat.com>, Lizhi Hou <lizhi.hou@xilinx.com>
Cc:     PCI <linux-pci@vger.kernel.org>, devicetree@vger.kernel.org,
        Xu Yilun <yilun.xu@intel.com>, Max Zhen <maxz@xilinx.com>,
        Sonal Santan <sonal.santan@xilinx.com>,
        Yu Liu <yliu@xilinx.com>,
        Michal Simek <michal.simek@xilinx.com>,
        Stefano Stabellini <stefanos@xilinx.com>,
        Moritz Fischer <mdf@kernel.org>,
        David Woodhouse <dwmw2@infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Max Zhen <max.zhen@xilinx.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Mar 6, 2022 at 9:37 AM Tom Rix <trix@redhat.com> wrote:
>
> Lizhi,
>
> Sorry for the delay, I am fighting with checking this with 'make
> dt_binding_check'
>
> There is a recent failure in linux-next around display/mediatek,*
> between next-20220301 and next-20220302 that I am bisecting.

There's already patches for that posted.

Just use 'make -k'.

>
> There are a couple of checkpatch --strict warnings for this set, the
> obvious one is adding to the MAINTAINERS for new files.
>
> Tom
>
> On 3/4/22 9:23 PM, Lizhi Hou wrote:
> > Create device tree binding document for PCIe endpoint bus.
> >
> > Signed-off-by: Sonal Santan <sonal.santan@xilinx.com>
> > Signed-off-by: Max Zhen <max.zhen@xilinx.com>
> > Signed-off-by: Lizhi Hou <lizhi.hou@xilinx.com>
> > ---
> >   .../devicetree/bindings/bus/pci-ep-bus.yaml   | 72 +++++++++++++++++++
> >   1 file changed, 72 insertions(+)
> >   create mode 100644 Documentation/devicetree/bindings/bus/pci-ep-bus.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/bus/pci-ep-bus.yaml b/Documentation/devicetree/bindings/bus/pci-ep-bus.yaml
> > new file mode 100644
> > index 000000000000..0ca96298db6f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/bus/pci-ep-bus.yaml
> > @@ -0,0 +1,72 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/bus/pci-ep-bus.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: PCIe Endpoint Bus binding
> > +
> > +description: |
> > +  PCIe device may use flattened device tree to describe apertures in its
> > +  PCIe BARs. The Bus PCIe endpoint node is created and attached under the
> > +  device tree root node for this kind of device. Then the flatten device
> > +  tree overlay for this device is attached under the endpoint node.
> > +
> > +  The aperture address which is under the endpoint node consists of BAR
> > +  index and offset. It uses the following encoding:
> > +
> > +    0xIooooooo 0xoooooooo
> > +
> > +  Where:
> > +
> > +    I = BAR index
> > +    oooooo oooooooo = BAR offset
> > +
> > +  The endpoint is compatible with 'simple-bus' and contains 'ranges'
> > +  property for translating aperture address to CPU address.


This binding is completely confusing because 'PCIe endpoint' is
generally used (in context of bindings and Linux) for describing the
endpoint's system (i.e. the internal structure of a PCIe device (e.g.
add-in card) from the view of its own processor (not the host
system)). This binding seems to be describing the host system's view
of a PCIe device. We already have that! That's just the PCI bus
binding[1] which has existed for ~25 years.

For a non-DT system, what you are going to need here is some way to
create DT nodes of the PCI bus hierarchy or at least from your device
back up to the host bridge. I would suggest you solve that problem
separately from implementing the FPGA driver by making it work first
on a DT based system.

Rob

[1] https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf