linux-kernel - Re: [PATCH v2 5/5] ACPI/IORT: Add IORT named component memory address limits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170801112111.GA23348@red-moon>
Date:   Tue, 1 Aug 2017 12:21:11 +0100
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Hanjun Guo <hanjun.guo@...aro.org>
Cc:     linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Will Deacon <will.deacon@....com>,
        Robin Murphy <robin.murphy@....com>,
        Nate Watterson <nwatters@...eaurora.org>,
        Robert Moore <robert.moore@...el.com>, Feng Kan <fkan@....com>,
        Jon Masters <jcm@...hat.com>, Zhang Rui <rui.zhang@...el.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH v2 5/5] ACPI/IORT: Add IORT named component memory
 address limits

On Tue, Aug 01, 2017 at 06:20:43PM +0800, Hanjun Guo wrote:
> 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@....com>
> >Cc: Will Deacon <will.deacon@....com>
> >Cc: Robin Murphy <robin.murphy@....com>
> >Cc: Nate Watterson <nwatters@...eaurora.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.

Then you wonder why I wrote it as a separate patch. Why is that
value set to 0 (is that because that's the insane default ?) ?
It is a firmware bug and if things work ok with this patch applied
either this patch contains a bug or drivers override the DMA masks
to cancel out this patch effects.

Please fix the firmware.

Thanks,
Lorenzo