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