Message-ID: <CAL_JsqKfQJFrd8MOdjW55cYdEb8yyPyR+P3ran9+X3dCwUgdyA@mail.gmail.com>
Date:   Tue, 12 Sep 2023 14:12:04 -0500
From:   Rob Herring <robh@...nel.org>
To:     Andy Shevchenko <andriy.shevchenko@...el.com>
Cc:     Lizhi Hou <lizhi.hou@....com>, Andrew Lunn <andrew@...n.ch>,
        linux-pci@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, max.zhen@....com,
        sonal.santan@....com, stefano.stabellini@...inx.com
Subject: Re: [PATCH V13 0/5] Generate device tree node for pci devices

On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
<andriy.shevchenko@...el.com> wrote:
>
> On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
> > This patch series introduces OF overlay support for PCI devices which
> > primarily addresses two use cases. First, it provides a data driven method
> > to describe hardware peripherals that are present in a PCI endpoint and
> > hence can be accessed by the PCI host. Second, it allows reuse of a OF
> > compatible driver -- often used in SoC platforms -- in a PCI host based
> > system.
> >
> > There are 2 series devices rely on this patch:
> >
> >   1) Xilinx Alveo Accelerator cards (FPGA based device)
>
> >   2) Microchip LAN9662 Ethernet Controller
>
> I believe you should Cc this to Andrew Lunn for the comments.
> IIRC something similar was tried to being solved for DSA (?)
> devices where SFP hotpluggable hardware can be attached or
> detached at run-time (sorry if I messes / mixing up things,
> I wrote this from my memory, might be completely wrong).

Could be similar in the sense that this problem exists on any
discoverable bus with non-discoverable devices downstream.

The LAN9662 case is that it's an SoC that can run Linux. Standard
stuff there. You have a DT and a bunch of drivers and SoC support in
the kernel. Now take that same SoC with the CPU cores disabled and
expose the whole (or part of) SoC via PCIe to Linux running on another
host. How to reuse all the drivers? Yes, you could define swnode
stuff, but then the PCI driver becomes a board file (or multiple). In
fact that's what they started doing at one point. It doesn't scale.

> >      Please see: https://lore.kernel.org/lkml/20220427094502.456111-1-clement.leger@bootlin.com/
> >
> > Normally, the PCI core discovers PCI devices and their BARs using the
> > PCI enumeration process. However, the process does not provide a way to
> > discover the hardware peripherals that are present in a PCI device, and
> > which can be accessed through the PCI BARs. Also, the enumeration process
> > does not provide a way to associate MSI-X vectors of a PCI device with the
> > hardware peripherals that are present in the device. PCI device drivers
> > often use header files to describe the hardware peripherals and their
> > resources as there is no standard data driven way to do so. This patch
> > series proposes to use flattened device tree blob to describe the
> > peripherals in a data driven way. Based on previous discussion, using
> > device tree overlay is the best way to unflatten the blob and populate
> > platform devices. To use device tree overlay, there are three obvious
> > problems that need to be resolved.
> >
> > First, we need to create a base tree for non-DT system such as x86_64. A
> > patch series has been submitted for this:
> > https://lore.kernel.org/lkml/20220624034327.2542112-1-frowand.list@gmail.com/
> > https://lore.kernel.org/lkml/20220216050056.311496-1-lizhi.hou@xilinx.com/
>
> Can you point out to the ACPI excerpt(s) of the description of anything related
> to the device(s) in question?

I don't understand what you are asking for.

Rob

Powered by blists - more mailing lists