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=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 39AE1C33CB1 for ; Fri, 17 Jan 2020 12:44:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0E8582082F for ; Fri, 17 Jan 2020 12:44:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579265092; bh=zPwtUVW8q+p3YGHy4YZsdaGNdFuKXjOFb6ZDNggBGM4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=wR4KGprOpcu9FPfN/lOVE0vgWjeZJW5dbbh5fgpBcJhrkkvl1+1sU6mI/26otozn9 T9/HOHvBQhs7NBor9N5d2rGnR/aJ05ah25hUS/VuSs51KQZ/w52G4IsplZMqUUI6p9 SBur7VlicAoC1RcYFOa3KpS10cjBVVHPx6JXllkQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726559AbgAQMov (ORCPT ); Fri, 17 Jan 2020 07:44:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:54770 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726554AbgAQMov (ORCPT ); Fri, 17 Jan 2020 07:44:51 -0500 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (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 5503120730; Fri, 17 Jan 2020 12:44:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579265090; bh=zPwtUVW8q+p3YGHy4YZsdaGNdFuKXjOFb6ZDNggBGM4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dkfq2y9na1BRPh97ABqmiHjVIOABPVUMPl12zX8yYbN/6KPKN1dbvK/W3HV5VRfnQ UxaiXtYNrJv7axoB1b77/YJ/Jvr4M1DJxpw/ye3umkf9deT6kPdh0ThpoZMPAi8QAv nibITdBqQU1f7UUnt/wp+eOE4prYJrXkvU3IF7ME= Date: Fri, 17 Jan 2020 12:44:45 +0000 From: Will Deacon To: Lorenzo Pieralisi Cc: Hanjun Guo , Sudeep Holla , "Rafael J. Wysocki" , Pankaj Bansal , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxarm@huawei.com, John Garry , Shameerali Kolothum Thodi , Ganapatrao Kulkarni , Ard Biesheuvel , Tyler Baicar , Catalin Marinas , Robin Murphy Subject: Re: [PATCH v2] ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map() Message-ID: <20200117124444.GC8199@willie-the-truck> References: <1579004051-48797-1-git-send-email-guohanjun@huawei.com> <20200117121448.GA8199@willie-the-truck> <20200117123226.GA9918@e121166-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200117123226.GA9918@e121166-lin.cambridge.arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Fri, Jan 17, 2020 at 12:32:26PM +0000, Lorenzo Pieralisi wrote: > On Fri, Jan 17, 2020 at 12:14:49PM +0000, Will Deacon wrote: > > On Tue, Jan 14, 2020 at 08:14:11PM +0800, Hanjun Guo wrote: > > > Reported-by: Pankaj Bansal > > > Link: https://lore.kernel.org/linux-acpi/20191215203303.29811-1-pankaj.bansal@nxp.com/ > > > Signed-off-by: Hanjun Guo > > > Signed-off-by: Lorenzo Pieralisi > > > Cc: Pankaj Bansal > > > Cc: Will Deacon > > > Cc: Sudeep Holla > > > Cc: Catalin Marinas > > > Cc: Robin Murphy > > > --- > > > > I'm a bit confused about the SoB chain here and which tree this is > > targetting. > > > > Lorenzo? > > sorry about that. It targets arm64 - previously wasn't addressed > to you and Catalin: > > https://lore.kernel.org/linux-arm-kernel/1577708824-4873-1-git-send-email-guohanjun@huawei.com/ > > I rewrote the commit log and asked Hanjun to repost it to target an arm64 > merge. No need to apologise, just trying to figure out what's going on. Thanks for the explanation. > Having said that, this patch makes me nervous, it can break on platforms > that have non-compliant firmware, I wonder whether it is best to leave > it in -next for a whole cycle (I can send it to -next) to catch any > fall-out rather than targeting v5.6 given that technically is _not_ a > fix (we may even have to revert it - it requires coverage on all ARM64 > ACPI systems). > > What do you think ? My experience with linux-next is that it doesn't get tonnes of runtime testing but rather lots of build testing, so I'd be inclined to queue this for 5.6 (i.e. for the upcoming merge window) and revert it the moment it causes a problem. I'll stick it on its own branch so we can also drop it if something comes up before then. Will