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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 472C9C433FF for ; Fri, 2 Aug 2019 09:10:55 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1E9CB21783 for ; Fri, 2 Aug 2019 09:10:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="aGAcjhn4"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="zYvVPi0S" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E9CB21783 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-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=568c+Ejz9/iCIv3cfgKbod8n9zqR0HGIy4ugbVja7So=; b=aGAcjhn4veCocq YL3Y5xwiCknAfFXLE8ih4Ju03kDaQXH5CWwt939r/49ne3i/H0Zq9MlmhIwfX4NtG7rLLoZjNd1xA xAba8Jyd6/pRnxi1aoEB7A3hjMh8634MA8KknF9i0G0aYz2mGt2DhN1xuQ2WYrGdmfnJEudalSTbm g7TH/6J2xc2UBtDH8y5evzlvb6toSlykAxB0cKMMvFauRcIWlarvFc8Dk7t7RHYKNrF9DZQw8kbRC ZBKbwNqVEQTAKIOdFxw4Z6XgaqEgIBzq4N4qbSmhu5wzuji+/5Y2GeJI32lEG29GfaKtt+B47oCWC E2cZGn21H1llBDKAQt2A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1htTaA-00024d-O9; Fri, 02 Aug 2019 09:10:38 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1htTa5-00024J-Cf for linux-arm-kernel@lists.infradead.org; Fri, 02 Aug 2019 09:10:35 +0000 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 AA3E821783; Fri, 2 Aug 2019 09:10:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564737031; bh=en2oSylP6cRO7O7KFL0SwRSisE8H9qAKYUfpBjF1n+4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=zYvVPi0SSIRMPjGVWWPJtxTQnKi4QzmcXKusWrJ7Gl7XZVmmA4KIg92jCVLs8XYPk HUS+OEb0xsJ9OiMDxb581nc30HOP08C9GM9/4b5sAI5Ds3r3KfAwotBsyLRFzLPvS6 VMOpwbUPbGKvQ3EMc5J9UDXawYwN+fvwSvHjpRQs= Date: Fri, 2 Aug 2019 11:10:28 +0200 From: Greg KH To: Mathieu Poirier Subject: Re: [PATCH 0/1] coresight: Fix for v5.3-rc3 Message-ID: <20190802091028.GA14004@kroah.com> References: <20190801172323.18359-1-mathieu.poirier@linaro.org> <20190801181739.GB5048@kroah.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190802_021033_507284_903FCAFC X-CRM114-Status: GOOD ( 21.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-kernel , "Suzuki K. Poulose" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Aug 01, 2019 at 02:16:46PM -0600, Mathieu Poirier wrote: > On Thu, 1 Aug 2019 at 12:17, Greg KH wrote: > > > > On Thu, Aug 01, 2019 at 11:23:22AM -0600, Mathieu Poirier wrote: > > > Good morning Greg, > > > > > > Here is a fix I'd like you to consider for this cycle. Do you think you > > > could apply it to driver-core-next rather than char-misc-next? > > > > All of my -next branches are for 5.4-rc1, not 5.3 (i.e. the "next" > > kernel). > > > > So either one of them isn't going to matter to you for 5.3-final. > > > > > My current > > > coresight branch is based on driver-core-next to pick up Suzuki's > > > generic device lookup helpers patchset [1]. Applying it to char-misc-next > > > will create two different signature for the same patch, something that > > > gives Stephen a hard time when building the linux-next tree. > > > > Why would Suzuki's patch matter for 5.3-final? > > There was a similar situation during the 5.2 cycle [1]. Here too we > can fix a problem that is present in 5.3 rather than wait for 5.4. > > [1]. https://www.spinics.net/lists/arm-kernel/msg736274.html But that has nothing to do with Suzuki's patch that is in my driver core tree. I still fail to see the dependency here. > > > I also think this patch should go in stable but haven't marked it as such since > > > it doesn't apply to any of the stable trees. Once it is part of v5.3 I intend > > > to send a new version of the patch that does apply cleanly to those trees. Let > > > me know if you want me to proceed differently. > > > > > > Thanks, > > > Mathieu > > > > > > [1]. https://www.spinics.net/lists/dri-devel/msg219674.html > > > > > > > > > Suzuki K Poulose (1): > > > coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute > > > > > > drivers/hwtracing/coresight/coresight-etm-perf.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > Why would this patch depend on anything in any of my trees? > > I send you patches for inclusion in the next cycle and as such I > thought it should be the same for fixes in the current cycle. If that > is not the case, should I send them directly to Linus? You can send me fixes to forward on to Linus for this current cycle, if they are not depending on patches that are only for the -next release. I always keep 2 branches in my git trees: -linus : patches for Linus this release cycle -next : patches for Linus the next release cycle If you have bugfixes, make them against my -linus branch and send them on. Odds are they don't have dependancies other than what is in Linus's tree, so that's fine. If you have patches for the next cycle, send them against my -next branch. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel