Re: [PATCH v2] fpga: m10bmc-sec: add image_load sysfs for N3000 and D5005

Xu Yilun <[email protected]> Mon, 3 Aug 2026 10:41:18 +0800
Newsgroups org.kernel.vger.linux-fpga,dev.linux.lists.mfd,org.kernel.vger.linux-kernel
Message-ID <am//znBXTh9eV5CC@yilunxu-OptiPlex-7050>
> on N3000 that reboot also resets the FPGA and drops the PCIe link, so the card
> leaves the bus and re-enumeration is left to userspace. Nothing is quiesced on
> the kernel side first. That is documented in the ABI file rather than handled,
> because I do not think it can be handled meaningfully inside a single driver:
> the blast radius reaches the other functions of the card, and where it has to
> be dealt with is the bus layer, not here.

Yeah, so what I've got from your description is that the user API is located at
the wrong place. It should be located in a place that can properly
quiesce and unregister all affected devices before the reload.

[...]

> For the generic side I would propose, and can post as an RFC if you agree with
> the direction, an fpga_image_slot class: one device per reloadable slot, with

We had quite a lot of discussions about the uAPI for fpga region
reprogramming before and WIP. Although the reprograming from nvram doesn't
require a user input binary blob, the main concern is the same - how to
gracefully quiesce the affected devices, and how to re-enumerate the new
programmed devices.

> the slot name and a "disruption" attribute reading none, device_reset or
> bus_reprobe, so that userspace knows what it is about to trigger before it
> triggers it, while drivers keep only their load callback. One detail worth
> flagging early: a reload triggered from a sysfs store handler runs with the
> kernfs active reference held, so any slot whose reset removes the device needs
> sysfs_break_active_protection() or device_remove_file_self(), or the store
> deadlocks against its own removal.