kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
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

  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).