From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lorenzo Pieralisi Subject: Re: [PATCH -next] ACPI/IORT: Fix the error return code in iort_add_smmu_platform_device() Date: Mon, 6 Feb 2017 12:07:33 +0000 Message-ID: <20170206120733.GA31126@red-moon> References: <20170205154559.31664-1-weiyj.lk@gmail.com> <20170206100411.GA12444@red-moon> <1922286.EyoiMMS0FI@aspire.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from foss.arm.com ([217.140.101.70]:56248 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751456AbdBFMFb (ORCPT ); Mon, 6 Feb 2017 07:05:31 -0500 Content-Disposition: inline In-Reply-To: <1922286.EyoiMMS0FI@aspire.rjw.lan> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: "Rafael J. Wysocki" Cc: Wei Yongjun , Hanjun Guo , Sudeep Holla , Len Brown , Wei Yongjun , linux-acpi@vger.kernel.org, catalin.marinas@arm.com, will.deacon@arm.com [+ Catalin, Will] On Mon, Feb 06, 2017 at 12:41:12PM +0100, Rafael J. Wysocki wrote: > On Monday, February 06, 2017 10:04:11 AM Lorenzo Pieralisi wrote: > > On Sun, Feb 05, 2017 at 03:45:59PM +0000, Wei Yongjun wrote: > > > From: Wei Yongjun > > > > > > The error return code PTR_ERR(pdev) is always 0 since pdev is > > > equal to 0 in this error handling case. > > > > > > Signed-off-by: Wei Yongjun > > > --- > > > drivers/acpi/arm64/iort.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > It has been reported twice already: > > > > https://patchwork.kernel.org/patch/9521003/ > > > > Rafael, do you expect me to send you a pull request with IORT fixes ? > > > > I can't see Dan's patch in linux-acpi patchwork anymore, and there > > is another fix pending: > > > > https://patchwork.kernel.org/patch/9507041/ > > > > Please let me know how you want to handle them. > > I wasn't sure about who was the target maintainer to be honest. > > I'd prefer ARM64-specific material to go in via the ARM64 tree, if > that's possible. I CC'ed Catalin and Will so that we can sort this out, I took for granted that ACPI changes would go via the ACPI tree even if they are ARM64 specific, I am not sure it makes much sense for them to go via the arm64 arch tree, anyway it is something to be decided because the two fixes above have already missed -rc* and I have to know which way patches should go from now onwards. Thanks, Lorenzo