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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
