Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1182287ybk; Thu, 14 May 2020 02:32:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyrn6kDdcHoN46Kh0Au76NjTDhh8Hdaf31zm7QSosbiCCRbxXy4hMUzgLmJtPYk1jItKiN3 X-Received: by 2002:a05:6402:1bd9:: with SMTP id ch25mr2926634edb.15.1589448727526; Thu, 14 May 2020 02:32:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589448727; cv=none; d=google.com; s=arc-20160816; b=H6oybAwqDISoVVBayNDfX0wNHQLd9UsXhfwEA/x72RpDMdzhydbaNcFxdErUBdPiDo /SRESQLTOVWkzpokiGK2tnKJwOMB7jyMxRungsoV2mFh/AguWieAMgQXnO4Gr8mQPVqM hmIv72KYXGOowHxUpD1tAxKh4WAIes5+w6cpT3iyX39eSKa6jThsGdAvIzZM09ihZUcm VfhSwmxBTQFX80K4RJ+S3SMiDLDVQUf5VCLdwS2HNUTAubw3JZna3qSkURDjn2Vbo93z pkaq3biNfqPyT2CFgprDJ1ideG0d9wgjxynTwm2biTIz3U9qaKmGHrjFbVANe7NCTUaX 3ZPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=tj+wdX8cprna7Y7iyWi/bIkKTa/GVN3GPUlLdIUylFc=; b=h+v3Fx2VtClljxH2ZvRHGf4/Mw+vF3iU494gMzpgfglTI3/wNhPNDgOrWiDUKjUI0l l8ENi8yyQf6OF4vadhP1a5mK6pyfLyHlQBsPpy5YYXaRaRhs2Yq5hQ7Ka06Hoa/Wjg/k UvbHjluoJg0mwhy3Zbezcw8I3rdmQ59YnF+RjzxpISEFjhDTSJ6xxlwZC90Ae3PKgZc2 q5fkS83p7eQdK7M+OzFwpXldt01BHrFZTKQHHfAb6q2VP5GJtdRFXnAcu36uLTPsTwiS aHhMQ8C3jg8T4AMPoM5pHQO7KC2qZhjY6zkxJ1DtuYb16YRglnrv2Pj85kHKOmNOqgg0 X4yQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j4si1544348ejn.341.2020.05.14.02.31.44; Thu, 14 May 2020 02:32:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726050AbgENJ3x (ORCPT + 99 others); Thu, 14 May 2020 05:29:53 -0400 Received: from foss.arm.com ([217.140.110.172]:33072 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725878AbgENJ3x (ORCPT ); Thu, 14 May 2020 05:29:53 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7F26531B; Thu, 14 May 2020 02:29:52 -0700 (PDT) Received: from e121166-lin.cambridge.arm.com (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D47A93F71E; Thu, 14 May 2020 02:29:50 -0700 (PDT) Date: Thu, 14 May 2020 10:29:44 +0100 From: Lorenzo Pieralisi To: Tuan Phan Cc: patches@amperecomputing.com, Hanjun Guo , Sudeep Holla , "Rafael J. Wysocki" , Len Brown , Will Deacon , Robin Murphy , Neil Leeder , Shameer Kolothum , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] ACPI/IORT: Fix PMCG node always look for a single ID mapping. Message-ID: <20200514092944.GA18032@e121166-lin.cambridge.arm.com> References: <1589415122-5899-1-git-send-email-tuanphan@os.amperecomputing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1589415122-5899-1-git-send-email-tuanphan@os.amperecomputing.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Please update the subject: Subject: "ACPI/IORT: Fix PMCG node single ID mapping handling" On Wed, May 13, 2020 at 05:12:02PM -0700, Tuan Phan wrote: > PMCG node can have zero ID mapping if its overflow interrupt > is wire based. The code to parse PMCG node can not assume it will > have a single ID mapping. "An IORT PMCG node can have no ID mapping if its overflow interrupt is wire based therefore the code that parses the PMCG node can not assume the node will always have a single mapping present at index 0. Fix iort_get_id_mapping_index() by checking for an overflow interrupt and mapping count." > Fixes: 24e516049360 ("ACPI/IORT: Add support for PMCG") > Reviewed-by: Hanjun Guo > Signed-off-by: Tuan Phan > --- > v1 -> v2: > - Use pmcg node to detect wired base overflow interrupt. > > v2 -> v3: > - Address Hanjun and Robin's comments. > > drivers/acpi/arm64/iort.c | 5 +++++ > 1 file changed, 5 insertions(+) Acked-by: Lorenzo Pieralisi > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c > index ed3d2d1..12bb70e 100644 > --- a/drivers/acpi/arm64/iort.c > +++ b/drivers/acpi/arm64/iort.c > @@ -414,6 +414,7 @@ static struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node, > static int iort_get_id_mapping_index(struct acpi_iort_node *node) > { > struct acpi_iort_smmu_v3 *smmu; > + struct acpi_iort_pmcg *pmcg; > > switch (node->type) { > case ACPI_IORT_NODE_SMMU_V3: > @@ -441,6 +442,10 @@ static int iort_get_id_mapping_index(struct acpi_iort_node *node) > > return smmu->id_mapping_index; > case ACPI_IORT_NODE_PMCG: > + pmcg = (struct acpi_iort_pmcg *)node->node_data; > + if (pmcg->overflow_gsiv || node->mapping_count == 0) > + return -EINVAL; > + > return 0; > default: > return -EINVAL; > -- > 2.7.4 >