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

"Ionut Nechita (Wind River)" <[email protected]> Mon, 3 Aug 2026 16:22:09 +0300
Newsgroups dev.linux.lists.mfd,org.kernel.vger.linux-fpga,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Mon, 3 Aug 2026 10:41:18 +0800, Xu Yilun wrote:
> 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.

Thanks, that is exactly what I want to align with rather than duplicate.
Could you point me at those discussions and any WIP branch/series? I have
searched lore but I am not sure I have found the thread you mean - a
Message-ID, a lore link, or the name of the series/tree would be enough for
me to catch up before I propose anything.

I agree the two hard parts are the same whether the image comes from a user
blob or from nvram: gracefully quiescing the affected devices before the
reload, and re-enumerating whatever comes back. On N3000 the affected set
reaches past the FPGA to the other functions of the card (the i40e VFs
behind it), so it clearly cannot live in this driver.

Two things I would like your read on, once I have seen the prior work:

 - whether a per-slot "disruption" hint (none / device_reset / bus_reprobe)
   fits the direction you already have, or cuts across it;
 - where the quiesce/re-enumerate step is expected to sit - the bus/portdrv
   layer, or something the region core drives.

I am happy to do the generic work and to be the first user of whatever we
agree on, since the N3000 is the only such card I can actually test on. If
you would rather I hold this driver patch until that lands, tell me and I
will drop this upstream submission and carry it only in our tree until the
generic interface is in place.

Thanks,
Ionut