fpga: m10bmc-sec: upstreaming image_load sysfs for N3000/D5005 (and 6.18-stable)?

[Ionut Nechita]

Hi Matthew, Yilun,

I'm moving Intel PAC N3000 (and D5005) support off the out-of-tree OPAE
driver and onto the in-tree DFL stack on a 6.18-based product. The goal
is simply to have the N3000 FPGA fully functional with the current
opae-sdk (2.14.x) userspace on top of the mainline drivers, so we can
drop the OOT driver entirely. Before sending any patch I'd like your
guidance on one functional gap.

The mainline MAX10 BMC secure-update driver
(drivers/fpga/intel-m10-bmc-sec-update.c) exposes only the
firmware-upload ABI (/sys/class/firmware/secure-updateN) for flashing
images. It does not provide the control/available_images and
control/image_load sysfs attributes that opae-sdk uses to *trigger* a
reload rather than a flash:

  - bmc_user / bmc_factory: reload the BMC user/factory image via the
    doorbell (DRBL_CONFIG_SEL | DRBL_REBOOT_REQ)
  - retimer_fw (N3000 only): trigger a PKVL retimer EEPROM reload and
    poll for completion

These attributes existed in linux-dfl (commits e1b885714f68 and
604ad4f48cee) but were never upstreamed. As far as I can tell there is
no equivalent mechanism in mainline to trigger a bank reload or a
retimer EEPROM reload from userspace. In practice this means the
migration off the OOT OPAE driver is blocked for these field-update
use cases: opae-sdk expects control/image_load, and without it the
in-tree driver cannot fully replace the OOT one on N3000/D5005.

My questions:

1. Would you be open to upstreaming the N3000/D5005 subset of this
   interface to mainline? I have a patch that adds a small image_load
   handler table gated per-device (N6000 keeps .image_load = NULL, so
   the control/ group stays hidden for it), plus the M10BMC_PKVL_*
   register definitions needed by the retimer path. I intentionally
   left out the N6000/PMCI/SDM handlers.

   Or was this interface deliberately dropped during upstreaming in
   favour of another mechanism I've missed? If so, I'd rather adopt the
   preferred approach so opae-sdk keeps working on the in-tree driver.

2. Assuming it's acceptable and lands in mainline, would a subsequent
   backport to 6.18.y stable be reasonable via the normal
   (mainline-first) stable process?

If the direction sounds right, I'll send it as a proper RFC/PATCH with
the ABI documentation update. Tested on Intel PAC N3000 (0x8086:0x0b30)
with 6.18.15 and opae-sdk 2.14.x: control/available_images reports
"bmc_factory bmc_user retimer_fw" and control/image_load accepts a
valid name.

Thanks,
Ionut