Runtime ownership and driver binding for SPI-NOR shared with FPGA

[Patryk]

Hi
I've been working on a baseboard where I have an SoC running Linux and
FPGA that uses external flash as a bitstream storage.
This flash is in fact shared between Linux and FPGA but not
simultaneously. It is "muxed" so that it can only be accessible either
by Linux or FPGA at once. This is designed so that the flash can be
updated from Linux.
When the platform is booting, the mux is always switched so that the
FPGA can access the flash and load its bitstream.  Whenever I want to
update the flash I need to make it accessible physically (need to
change the mux config) for Linux as well as "logically" -  meaning
that the appropriate driver has to be loaded. Once the update is done,
Linux should release the flash and no longer use it unless the update
has to be repeated so the update sequence is roughly like this:
- change mux config
- bind driver
- write flash
- unbind driver
- change mux config again

I am trying to determine the correct way to model and implement this.
I could implement most of the sequence in userspace, but the SPI
device still needs platform-specific information such as the SPI
controller, chip select, maximum clock frequency, and possibly a
GPIO-based chip select provided by a GPIO expander.

One possible approach would be to describe the flash normally in the
Device Tree with  "okay" status. The initial spi-nor probe would fail
because the flash is connected to the FPGA during boot. Later, when an
update is required, userspace could switch the mux and retry probing
the existing SPI device:
- change mux
- echo spi0.2 > /sys/bus/spi/drivers_probe or echo spi0.2 >
/sys/bus/spi/drivers/spi-nor/bind
- update flash
- echo spi0.2 > /sys/bus/spi/drivers/spi-nor/unbind
- change mux again

but is this really a good option? I feel that I'm leaking hardware
specific information to userspace, I'll have to hardcode some paths,
driver names in flashing script / prepare separate script for each
device (if there are differences between platforms) or carry platform
hardware description config file so that the flashing tool could stay
generic and read necessary info from config.

Is there any better way? Would be grateful for any suggestion
Best regards

Patryk