Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751824AbdHAKVR (ORCPT <rfc822;w@1wt.eu>);
        Tue, 1 Aug 2017 06:21:17 -0400
Received: from mail-it0-f43.google.com ([209.85.214.43]:37728 "EHLO
        mail-it0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751595AbdHAKVP (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 1 Aug 2017 06:21:15 -0400
Subject: Re: [PATCH v2 5/5] ACPI/IORT: Add IORT named component memory address
 limits
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
        linux-acpi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        Will Deacon <will.deacon@arm.com>, Robin Murphy <robin.murphy@arm.com>,
        Nate Watterson <nwatters@codeaurora.org>,
        Robert Moore <robert.moore@intel.com>, Feng Kan <fkan@apm.com>,
        Jon Masters <jcm@redhat.com>, Zhang Rui <rui.zhang@intel.com>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>
References: <20170731152323.32488-1-lorenzo.pieralisi@arm.com>
 <20170731152323.32488-6-lorenzo.pieralisi@arm.com>
From: Hanjun Guo <hanjun.guo@linaro.org>
Message-ID: <35b7d17a-7ab2-9b36-9482-33a7449691d2@linaro.org>
Date: Tue, 1 Aug 2017 18:20:43 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170731152323.32488-6-lorenzo.pieralisi@arm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1749
Lines: 50

Hi Lorenzo,

On 2017/7/31 23:23, Lorenzo Pieralisi wrote:
> IORT named components provide firmware configuration describing
> how many address bits a given device is capable of generating
> to address memory.
> 
> Add code to the kernel to retrieve memory address limits
> configuration for IORT named components and configure DMA masks
> accordingly.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Nate Watterson <nwatters@codeaurora.org>
> ---
>   drivers/acpi/arm64/iort.c | 40 ++++++++++++++++++++++++++++++----------
>   1 file changed, 30 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 67b85ae..b85d19f 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -680,6 +680,24 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
>   	return ret ? NULL : ops;
>   }
>   
> +static int nc_dma_get_range(struct device *dev, u64 *size)
> +{
> +	struct acpi_iort_node *node;
> +	struct acpi_iort_named_component *ncomp;
> +
> +	node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
> +			      iort_match_node_callback, dev);
> +	if (!node)
> +		return -ENODEV;
> +
> +	ncomp = (struct acpi_iort_named_component *)node->node_data;
> +
> +	*size = ncomp->memory_address_limit >= 64 ? ~0ULL :
> +			1ULL<<ncomp->memory_address_limit;

Just a question here, if the IORT table didn't configure this
value properly, will the device working properly? I'm asking this
because in the table of IORT of D05, this value is set to 0 so far
(SAS and network), but I can boot D05 OK with your patch set, not
sure if any further issues.

Thanks
Hanjun