From: Luca Ceresoli <luca@lucaceresoli.net>
To: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
Cc: Greg KH <greg@kroah.com>, kernelnewbies@kernelnewbies.org
Subject: Re: Remote I/O bus
Date: Sun, 6 Oct 2019 00:29:18 +0200 [thread overview]
Message-ID: <26e4a95a-8c1f-1fc3-47d3-d951e9fe503a@lucaceresoli.net> (raw)
In-Reply-To: <154634.1570225877@turing-police>
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@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2019-10-05 22:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 11:04 Remote I/O bus Luca Ceresoli
2019-10-04 13:22 ` Greg KH
2019-10-04 14:08 ` Luca Ceresoli
2019-10-04 14:54 ` Greg KH
2019-10-04 15:08 ` Luca Ceresoli
2019-10-04 21:51 ` Valdis Klētnieks
2019-10-05 22:29 ` Luca Ceresoli [this message]
2019-10-06 0:19 ` Valdis Klētnieks
2019-10-06 9:18 ` Greg KH
2019-10-07 7:48 ` Luca Ceresoli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26e4a95a-8c1f-1fc3-47d3-d951e9fe503a@lucaceresoli.net \
--to=luca@lucaceresoli.net \
--cc=greg@kroah.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=valdis.kletnieks@vt.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).