From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,T_DKIMWL_WL_HIGH autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by aws-us-west-2-korg-lkml-1.web.codeaurora.org (Postfix) with ESMTP id 8F6D8C5CFF1 for ; Tue, 12 Jun 2018 11:45:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 44A63208B2 for ; Tue, 12 Jun 2018 11:45:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Km68lXO/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 44A63208B2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933308AbeFLLpF (ORCPT ); Tue, 12 Jun 2018 07:45:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:37538 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932313AbeFLLpE (ORCPT ); Tue, 12 Jun 2018 07:45:04 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 26419208B0; Tue, 12 Jun 2018 11:45:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1528803903; bh=feLEjvg+sQs44YKG51Q6CRV2Vm7tYiW4mSsnqZjHg1k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Km68lXO/BRSHrPDI/cQ8Rmw3DI/u13+HpASP3Gui7Se7QBiU+NVY5K0LHwBNaDS0w e8Jm2z4xBKXX2zqiTH4JGUlS+qJBWbpaeckKKBTe4WzVHRxZYNHpUKCosEP2IBp7Dh dTUCjcU7/c09v24pNMuGLzd7jmxTFI5fx+GqliGc= Date: Tue, 12 Jun 2018 13:44:42 +0200 From: Greg Kroah-Hartman To: Benjamin Herrenschmidt Cc: "linux-kernel@vger.kernel.org" , openbmc@lists.ozlabs.org Subject: Re: [GIT PULL v2] FSI updates for 4.17 Message-ID: <20180612114442.GB5777@kroah.com> References: <7c268f5bb58cb45a2868020b3c5b8f48ac6844ea.camel@kernel.crashing.org> <5c7f9044fefed8bc0e4ca5688801ffa379f38f62.camel@kernel.crashing.org> <20180612111839.GA3536@kroah.com> <01ffcf6a777323eb3bde1bbb5cb72dc849f404e3.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ffcf6a777323eb3bde1bbb5cb72dc849f404e3.camel@kernel.crashing.org> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 12, 2018 at 09:25:11PM +1000, Benjamin Herrenschmidt wrote: > 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 ... For code that goes into -rc1, it has to be in linux-next _BEFORE_ -final comes out. That's been the rule for years, you should know that... > 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. There should not be a rush here, remember, kernel development does not have deadlines :) greg k-h