From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CE565C5472D for ; Wed, 28 Aug 2024 04:16:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=94WRxCLOfpj09LmMM2vaQuNwRCG0n7bk5YDtD5HamXk=; b=jZTYmJUiEzz6cw9gvh1x/HXfd0 Zt0oMS5oLWjsf6CKlra85Dp21TNecbcL/RcPE3bQEL2Pz2981MumTPqNgA/inMbzCA2mqqs6Z4Qjo bQlcsC1SVlo/pjO3WOQw65+8R2XXHTNLuKGLUi+t63yptlhj226C1REqfgUjgxzglW4vNmuMm+0cH 4mlo5PaLPF+fBuVJqC1G95wWLBqHpTkYqSedjX37THFOKwU14IdA2FDl22vRM1Lvfe1bzQ+r18SXW CSh9aFeDRVlOYCrQDz2GVL3KzlYcJ3FF1DtYpVlpimxVj/QiSdeSDN/rc9oRhFlB8FzPbmF0oMUj2 3tugS0vg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjA67-0000000DlX4-0Bjk; Wed, 28 Aug 2024 04:15:55 +0000 Received: from mail.tkos.co.il ([84.110.109.230]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjA5G-0000000DlPk-2Oge for linux-arm-kernel@lists.infradead.org; Wed, 28 Aug 2024 04:15:05 +0000 Received: from localhost (unknown [10.0.8.3]) by mail.tkos.co.il (Postfix) with ESMTP id A7195440F90; Wed, 28 Aug 2024 07:13:03 +0300 (IDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tkos.co.il; s=default; t=1724818383; bh=HDk7c503UbfGOlzje5ZzCxaJMFZSS4/0pwfqqArE/9I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ArST6NtbDOFjm4LykbnIQT39RmzOiJmByFAQjNooW5e+R//nJd6BzdQgdTZWq2Gz7 MUsAsGpoMBzc0KIqopaPcWmY8Et5CKqgrnnaFAisIlIUT/ZvcnILJnW3Z/StqiM3OY aJdLs4YAjKFqEhTWE50sgdx7VlM8kB5nv+uzUya2/hkHqi7I0LDA2V3ZnChm4cKZj3 1lHFIb3w4h8s8ppaOgAk2EELgFqxXeASYYfwLk5atekiLdI0FvvAzz7gscLWjbyQ2j mn4DMWKbqGGlFLR09qM/9XFu5try/KEdpwDVmX4TYD4aHYscXZl1yIiLduezho7Mol ZQyuikyzxV30g== From: Baruch Siach To: Robin Murphy Cc: Christoph Hellwig , Marek Szyprowski , Catalin Marinas , Will Deacon , iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Petr =?utf-8?B?VGVzYcWZw61r?= , Ramon Fried , Elad Nachman Subject: Re: [PATCH] arm64: mm: fix DMA zone when dma-ranges is missing In-Reply-To: <53679dda-178c-435b-81c5-42d139911cef@arm.com> (Robin Murphy's message of "Tue, 27 Aug 2024 11:22:28 +0100") References: <731d204f5f556ad61bbaf004b1d984f83c90b4f5.1724748249.git.baruch@tkos.co.il> <53679dda-178c-435b-81c5-42d139911cef@arm.com> Date: Wed, 28 Aug 2024 07:14:56 +0300 Message-ID: <87ed69uvun.fsf@tarshish> MIME-Version: 1.0 Content-Type: text/plain X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240827_211503_347421_CB00E4CC X-CRM114-Status: GOOD ( 21.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Robin, On Tue, Aug 27 2024, Robin Murphy wrote: > On 2024-08-27 9:44 am, Baruch Siach wrote: >> Some platforms, like Rockchip RK3568 based Odroid M1, do not provide DMA >> limits information in device-tree dma-ranges property. Still some device >> drivers set DMA limit that relies on DMA zone at low 4GB memory area. >> Until commit ba0fb44aed47 ("dma-mapping: replace zone_dma_bits by >> zone_dma_limit"), zone_sizes_init() restricted DMA zone to low 32-bit >> when there is RAM there. >> Restore DMA zone 32-bit limit for platforms that have RAM in this area. >> Fixes: ba0fb44aed47 ("dma-mapping: replace zone_dma_bits by zone_dma_limit") >> Reported-by: Marek Szyprowski >> Tested-by: Marek Szyprowski >> Signed-off-by: Baruch Siach >> --- >> This should go via the dma-mapping tree that contains the fixed commit. >> --- >> arch/arm64/mm/init.c | 3 +++ >> 1 file changed, 3 insertions(+) >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c >> index bfb10969cbf0..7fcd0aaa9bb6 100644 >> --- a/arch/arm64/mm/init.c >> +++ b/arch/arm64/mm/init.c >> @@ -116,6 +116,9 @@ static void __init arch_reserve_crashkernel(void) >> static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit) >> { >> + if (memblock_start_of_DRAM() < U32_MAX) >> + zone_limit = min(zone_limit, U32_MAX); > > This seems like a bit of a bodge, since it now means we either get the old or > the new behaviour depending on where DRAM is, so if, say, RAM starts at 3GB > but all devices have a 3GB DMA offset, we still can't have a properly-sized > DMA zone. I'm not following your example here. What is "3GB DMA offset"? Is it relative to 0? Relative to start of RAM? > Really it comes down to this change: > > - zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits); > + zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit); > > where although the "32" represented the assumption of RAM starting at 0, it > also implicitly removed the handling of the case where no DMA ranges are > specified. Per the commit message, it's that which we want to account for, not > the placement of RAM. > > I think the more correct version should be: > > if (zone_limit == PHYS_ADDR_MAX) > zone_limit = U32_MAX; I like your proposal. The condition of no dma-ranges data is explicit. I'll post v2 later today. Thanks, baruch -- ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -