Thread (29 messages) 29 messages, 9 authors, 2023-01-21

Re: [PATCH v1 00/12] add FPGA hotplug manager driver

From: Greg KH <gregkh@linuxfoundation.org>
Date: 2023-01-21 07:34:39
Also in: linux-fpga, linux-pci

On Fri, Jan 20, 2023 at 07:42:53PM +0100, Lukas Wunner wrote:
On Fri, Jan 20, 2023 at 08:28:51AM -0800, Russ Weight wrote:
quoted
On 1/19/23 05:33, Greg KH wrote:
quoted
On Wed, Jan 18, 2023 at 08:35:50PM -0500, Tianfei Zhang wrote:
quoted
This patchset introduces the FPGA hotplug manager (fpgahp) driver which
has been verified on the Intel N3000 card.

When a PCIe-based FPGA card is reprogrammed, it temporarily disappears
from the PCIe bus. This needs to be managed to avoid PCIe errors and to
reprobe the device after reprogramming.

To change the FPGA image, the kernel burns a new image into the flash on
the card, and then triggers the card BMC to load the new image into FPGA.
A new FPGA hotplug manager driver is introduced that leverages the PCIe
hotplug framework to trigger and manage the update of the FPGA image,
including the disappearance and reappearance of the card on the PCIe bus.
The fpgahp driver uses APIs from the pciehp driver. Two new operation
callbacks are defined in hotplug_slot_ops:

  - available_images: Optional: available FPGA images
  - image_load: Optional: trigger the FPGA to load a new image
Why is all of this tied into the pci hotplug code? Shouldn't it be
specific to this one driver instead?  pci hotplug is for removing/adding
PCI devices to the system, not messing with FPGA images.

This feels like an abuse of the pci hotplug bus to me as this is NOT
really a PCI hotplug bus at all, right?
While it is true that triggering an FPGA image-load does not involve
hotplug specific registers to be managed, the RTL that comprises
the PCIe interface will disappear and then reappear after the FPGA
is reprogrammed. When it reappears, it_could/_/have a different PCI
ID. The process of managing this event has a lot of similarity to a
PCIe hotplug event; there is a lot of existing PCIe hotplug related
code that could be leveraged.
It sounds like the N3000 is a PCI endpoint device which, when reprogrammed,
briefly disappears from the bus and then may reappear under a different
device ID.

What you want to do then is make sure that the slot into which the N3000
is plugged is hotplug-capable.  In that case, pciehp will handle
disappearance and reappearance of the card just fine.  Once the N3000
disables the link, pciehp will bring down the slot.  Once it re-enables
the link, it will bring the slot up again.  It's as if the card was
removed and replaced with a different one.  pciehp will bind to the
Root Port or Downstream Port associated with the hotplug slot.

The pci_hotplug_port infrastructure is for hotplug controllers which
handle devices disappearing and reappearing *below* them.  It is not
for endpoint devices.
Yes, thank you for expressing my concerns about this design much better
than I originally did.  I totally agree.

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help