[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180610065706.GA17389@kroah.com>
Date: Sun, 10 Jun 2018 08:57:06 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Joel Stanley <joel@....id.au>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jeremy Kerr <jk@...abs.org>,
Christopher Bostic <cbostic@...ux.vnet.ibm.com>
Subject: Re: [PATCH 00/15] fsi: Overall improvements and new SBE fifo driver
On Sun, Jun 10, 2018 at 04:46:53PM +1000, Benjamin Herrenschmidt wrote:
> (Greg, see below)
>
> On Tue, 2018-05-29 at 22:00 +0930, Joel Stanley wrote:
> > On 29 May 2018 at 11:00, Benjamin Herrenschmidt
> > <benh@...nel.crashing.org> wrote:
> > > This series brings in a number of improvements to our FSI stack
> > > (one of the service interfaces for communicating between a BMC chip and
> > > our POWER processors).
> > >
> > > The GPIO based "Soft FSI" performance is significantly improved, and
> > > it's reliability as well.
> > >
> > > The SBE fifo driver provides the interface to the processor "Self Boot
> > > Engine"
> > >
> > > Some of these patches have been simmering for a while in the OpenBMC
> > > tree.
> >
> > I run this series atop of 4.17-rc7 today, and they look solid.
> >
> > Tested-by: Joel Stanley <joel@....id.au>
>
> So how do we proceed ? I have more coming on top of this, but we should
> start with getting this series merged.
>
> Greg, should we create a FSI git repo with a 3-member maintainer team
> (Jeremy, Chris and myself) and send you pull requests ? Or are you
> happy to continue picking up patches ?
Which ever is best/easiest for you is fine with me, I can work either
way just fine.
> We have more stuff to come in there, including support for a HW master
> contoller in a future BMC chip, some more slave drivers, etc..
>
> It also looks like the s390 guys might start using some of that as well
> (their chips use FSI as well, so far they used our old service
> processor which uses an ancient non-uptream set of drivers & stack, but
> that's likely to change).
Then maybe a git tree is easiest for all of you to work against?
thanks,
greg k-h
Powered by blists - more mailing lists