Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp3776137ybv; Tue, 25 Feb 2020 07:07:55 -0800 (PST) X-Google-Smtp-Source: APXvYqylMBSb0fbs2Mg0oe0A5Ip3T4N4L6drlDj0fWWRxHmhJYEXftBBYipdxvg2zMA9PkxiOjWf X-Received: by 2002:a9d:5e8b:: with SMTP id f11mr32121747otl.110.1582643275289; Tue, 25 Feb 2020 07:07:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582643275; cv=none; d=google.com; s=arc-20160816; b=u0PdKHo4x65sB7wou1Uq4QYmcpRhjLm4CF1b9orMK35S7eKYePhqNyBWOZbwQZKKkg +Z6uPxqGcQFoPPBIuVZT8Al9PpAjmcDIYzKYgmNvU+/ueeMjVS0FLB6CCWa9zOQ4pK+e N3skpD80Ix/BB6yHzMdwBfehWS3x90XuPPc/UVdqV8SRqJ6EE3gwoM0NrBD6qTVVpBOW jWg4ZRfeQZNvyhWN1nG0SvXu+R9tBR7ll2xC8r2e0IcfH/vgghCaPmdzc6P8J+DjN6Sb +T2Nhjm8ooZ29FMcR5r8Wsmayd9F/seF3IkoeELzT7eDBOc1cGtoCn1Vi9S4teWtZpKa B5dQ== 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=5uBb6UhXK+099udKIFCWCHG4fb0FzazZS3YxOWhDCEM=; b=kfD8dBsHZgq0hRSBOm9E3lX3tKwEYizc5o8LZpiyvbosqkmzvWRFegRAVOh9b4/DAt 9A38Cc+xtawe54Lx8rs8a7RaMXcBCKEuMHw63z29D3iBfvrUS1QKpZchi/qrnoLrcheM 4L45VOT8OLEboDCq6P6mW4yOh+ExU62g57GvOaq/oMY1PCqmydLNSEmgPDiIRlIwQnRh AP7MdeoiMvNSdCe9OeWQyue90RzWZaC8IdLMgSaQuRqwb2ka+2zn0Rhjy4X52+OZdRsi poRg+PdsjWZKbDjUVZJVkp+j+PJUqt6j47RgGSTmqKgVtgGPBwyRXD6nQ7A9r6YZBC/F KxRQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c196si6946777oib.36.2020.02.25.07.07.32; Tue, 25 Feb 2020 07:07:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730890AbgBYO5G (ORCPT + 99 others); Tue, 25 Feb 2020 09:57:06 -0500 Received: from foss.arm.com ([217.140.110.172]:51830 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729207AbgBYO5G (ORCPT ); Tue, 25 Feb 2020 09:57:06 -0500 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 CA9691FB; Tue, 25 Feb 2020 06:57:05 -0800 (PST) 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 7B1233F703; Tue, 25 Feb 2020 06:57:04 -0800 (PST) Date: Tue, 25 Feb 2020 14:57:02 +0000 From: Lorenzo Pieralisi To: Heyi Guo Cc: devel@edk2.groups.io, wanghaibin.wang@huawei.com, Hanjun Guo , Sudeep Holla , "Rafael J. Wysocki" , Len Brown , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] acpi/iort: check output reference for the real used mapping Message-ID: <20200225145702.GB8970@e121166-lin.cambridge.arm.com> References: <20200225090136.40989-1-guoheyi@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200225090136.40989-1-guoheyi@huawei.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 On Tue, Feb 25, 2020 at 05:01:36PM +0800, Heyi Guo wrote: > The function iort_node_map_id() does the sanity check against the > first mapping in the node, but not the one which we really use. > > Logically we need check the mapping we use, or check every mapping in > the node. Choose the first fix for we are not firmware tester. Yes, I agree with you, I will think about what's best to do, can I pick up this patch and resend it on your behalf please ? Thanks, Lorenzo > Signed-off-by: Heyi Guo > > --- > Cc: Lorenzo Pieralisi > Cc: Hanjun Guo > Cc: Sudeep Holla > Cc: "Rafael J. Wysocki" > Cc: Len Brown > Cc: linux-acpi@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/acpi/arm64/iort.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c > index ed3d2d1a7ae9..d0fe8d673240 100644 > --- a/drivers/acpi/arm64/iort.c > +++ b/drivers/acpi/arm64/iort.c > @@ -470,13 +470,6 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node, > map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node, > node->mapping_offset); > > - /* Firmware bug! */ > - if (!map->output_reference) { > - pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n", > - node, node->type); > - goto fail_map; > - } > - > /* > * Get the special ID mapping index (if any) and skip its > * associated ID map to prevent erroneous multi-stage > @@ -497,6 +490,13 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node, > if (i == node->mapping_count) > goto fail_map; > > + /* Firmware bug! */ > + if (!map->output_reference) { > + pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n", > + node, node->type); > + goto fail_map; > + } > + > node = ACPI_ADD_PTR(struct acpi_iort_node, iort_table, > map->output_reference); > } > -- > 2.19.1 >