Remote I/O bus

[Luca Ceresoli]

Hi Valdis,

On 04/10/19 23:51, Valdis Klētnieks wrote:
> On Fri, 04 Oct 2019 17:08:30 +0200, Luca Ceresoli said:
>> Yes, the read/write helpers are nicely isolated. However this sits in a
>> vendor kernel that tends to change a lot from one release to another, so
> 
> I admit having a hard time wrapping my head around "vendor kernel that
> changes a lot from one release to another", unless you mean something like
> the RedHat Enterprise releases that updates every 2 years, and at that point you get hit
> with a jump of 8 or 10 kernel releases.
> 
> And of course, the right answer is to fix up the driver and upstream it, so that
> in 2022 when your vendor does a new release, the updated driver will already be
> there waiting for you.
> 
> And don't worry about having to do patches to update the driver to a new kernel
> release because APIs change - that's only a problem for out-of-tree drivers.  If it's
> in-tree, the person making the API change is supposed to fix your driver for you.

Thanks for your words! I totally agree, and I do upstream my work
whenever I can. I also use the same arguments you used to convince other
people to do so.

Weird enough, the whole idea of an io-over-spi bridge came exactly
because I want my work to be as close to upstream as possible -- even
the non-upstreamable hacks I need in embedded products. All the drivers
I'm going to use in the FPGA are platform drivers, and there is no way
my-own-io-over-spi bus support in those drivers will ever be mainlined.

That's why I came up with the idea of keeping those drivers as platform
drivers (the devices after all expose a real I/O bus, not SPI) and have
the io-over-spi logic in a "bridge" driver (which is what the
microprocessor in the FPGA does). This would allow to use *exactly* the
mainlined driver when one is in mainline, without any change.

But it looks like mine was not the right idea.

BTW I guess having an FPGA external to the SoC connected via SPI or I2C
is not uncommon. Am I wrong?

-- 
Luca