Hi, on an embedded system I currently have a standard platform device: .-----. data .--------. | CPU |--------| DEVICE | '-----' bus '--------' The driver is a standard platform driver that uses ioread32() and iowrite32() to access registers. So far, so good. Now in a new design I have the same device in an FPGA, external to the SoC. The external FPGA is not reachable via an I/O bus, but via SPI (or I2C). A microprocessor in the FPGA acts as a bridge: as an SPI client it receives register read/write requests from the CPU, forwards them to the devices on the in-FPGA data bus as a master, then sends back the replies over SPI. SoC <- | -> FPGA .-----. data .---------. .--------. data .--------. | CPU |---------| SPI CTL |-------| BRIDGE |---------| DEVICE | '-----' bus A '---------' SPI '--------' bus B '--------' What would be a proper way to model this in the Linux kernel? Of course I can hack the drivers to hijack them on SPI, but I'm trying to solve the problem in a better way. IMO "a proper way" implies that the platform driver does not need to be aware of the existence of the bridge. Note: in the real case there is more than one device to handle. At first sight I think this should be modeled with a "bridge" device that: * is a SPI device * implements a "platform bus" where regular platform devices can be instantiated, similar to a "simple-bus" In device tree terms: &amba { /* data bus A in picture */ spi0: spi@42000000 { reg = <0x42000000 0x1000>; #address-cells = <1>; io-over-spi-bridge@1 { /* data bus B */ reg = <1>; /* slave select pin 1 */ compatible = "linux,io-over-spi-bridge"; #address-cells = <1>; #size-cells = <1>; mydevice@4000 { /* 1 kB I/O space at 0x4000 on bus B */ reg = <0x4000 0x1000>; }; }; }; }; The io-over-spi driver is supposed to request allocation of a virtual memory area that: 1. is as large as the address space on bus B 2. is __iomem (non cached, etc) 3. is not mapped on the physical CPU address space (bus A) 4. page faults at every read/write access, triggering a callback that starts an SPI transaction, waits for the result and returns After some research I haven't found how this could be implemented, mostly due to my newbieness about kernel memory management. Also, as drivers might access the bus in IRQ handlers, I suspect there is no way to do an SPI transaction in IRQ context, but this could be handled differently (threaded IRQ...). Does this look like a good approach to handle the problem? If it does, how would you implement the iomem access and handle IRQ context? Otherwise, which way would you suggest? Many thanks in advance, -- Luca