linux-kernel - Re: [GIT PULL v2] FSI updates for 4.17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <01ffcf6a777323eb3bde1bbb5cb72dc849f404e3.camel@kernel.crashing.org>
Date:   Tue, 12 Jun 2018 21:25:11 +1000
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        openbmc@...ts.ozlabs.org
Subject: Re: [GIT PULL v2]  FSI updates for 4.17

On Tue, 2018-06-12 at 13:18 +0200, Greg Kroah-Hartman wrote:
> On Tue, Jun 12, 2018 at 08:54:39PM +1000, Benjamin Herrenschmidt wrote:
> > Hi Greg !
> > 
> > There are a first round of updates of the FSI stack, aiming at reducing/removing
> > he gap with the OpenBMC tree and a first step in getting dependent drivers
> > upstream.
> > 
> > These changes significantly improve the FSI bitbanging driver performance
> > and reliability, and add the new "sbefifo" driver for communicating with
> > the POWER9 Self Boot Engine (which will be needed for some upcoming
> > additional drivers).
> > 
> > These were posted to the list as patches a couple of weeks ago and were
> > prior to that tested in the OpenBMC tree and CI. Some subsequent driver
> > work depends on some of these, so merging early is probably the best.
> 
> Yeah, but as they are not "regression fixes", I'll put them into my
> -next branch for merging with 4.19-rc1.  I'll do that once 4.18-rc1 is
> released, can't touch my trees until that happens.

We are in regression only mode even before -rc1 these days ? including
for code that is basically completely unused upstream (which is what
this is trying to fix) ? :-) That's rather full-on ...

Anyway no biggie, it will just slow down some getting some of the other
drivers I suppose, though we can always explicitly list the dependency
on this tag to work around it.

Cheers,
Ben.