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 | org.kernel.vger.linux-fpga,dev.linux.lists.mfd,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