linux-kernel - Re: pci: acpi: Query on ACPI Device Tree Representation and Enumeration for Xilinx FPGA PCIe Endpoint functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250227160448.GA597390@bhelgaas>
Date: Thu, 27 Feb 2025 10:04:48 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Muni Sekhar <munisekharrms@...il.com>
Cc: linux-pci@...r.kernel.org, linux-acpi@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	kernelnewbies <kernelnewbies@...nelnewbies.org>
Subject: Re: pci: acpi: Query on ACPI Device Tree Representation and
 Enumeration for Xilinx FPGA PCIe Endpoint functions

On Thu, Feb 27, 2025 at 07:25:32PM +0530, Muni Sekhar wrote:
> Hi all,
> 
> I am currently working on a project involving a Xilinx FPGA connected
> to an x86 CPU via a PCIe root port. The Xilinx FPGA functions as a
> PCIe endpoint with single function capability and is programmed to
> emulate the Soundwire Master controller. It can be dynamically
> reprogrammed to emulate other interfaces as needed. Essentially, the
> FPGA emulates an interface and connects to the CPU via the PCIe bus.
> 
> Given this setup, the BIOS does not have prior knowledge of the
> function implemented in the Xilinx FPGA PCIe endpoint. I have a couple
> of questions regarding this configuration:
> 
> Is it possible to define an ACPI Device Tree representation for this
> type of hardware setup?
> Can we achieve ACPI-based device enumeration with this configuration?

If the FPGA is programmed before BIOS enumerates PCI devices, the FPGA
would look just like any other PCI device, and BIOS would be able to
read the Vendor ID and Device ID and would be able to size and program
the BARs.

So I assume the FPGA is not programmed before BIOS enumeration, the
FPGA doesn't respond at all when BIOS or Linux reads the Vendor ID,
and you want to program the FPGA later and make Linux enumerate to
find it.

>From Linux's point of view, this is basically a hot-add of a PCI
device.  If the Root Port supports hotplug and you have pciehp enabled
(CONFIG_HOTPLUG_PCI_PCIE=y) and if the FPGA comes out of reset and
brings up the PCIe link after being programmed, it all might "just
work."  You can also force a complete re-enumeration by writing a
non-zero value to /sys/bus/pci/rescan.

I'm not sure why you would need ACPI or a device tree to be involved.
ACPI and device tree are ways to tell the OS about devices that do not
have a native enumeration protocol.  PCI devices (like the programmed
FPGA) do support native enumeration, so generally we don't need ACPI
or device tree descriptions of them.  PCI host bridges have a
CPU-specific bus on the upstream side and a PCI bus on the downstream
side, so they are not themselves PCI devices, and we do need ACPI or
device tree descriptions for them.

If you have something that doesn't work like you expect, can you post
a complete dmesg log and any user commands you're using to program the
FPGA?

Bjorn