[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<VI1PR09MB2333E5C93A7925E4518959B0947D2@VI1PR09MB2333.eurprd09.prod.outlook.com>
Date: Mon, 7 Oct 2024 13:03:17 +0000
From: Vladimir Kondratiev <Vladimir.Kondratiev@...ileye.com>
To: Christoph Hellwig <hch@...radead.org>
CC: Alexandre Ghiti <alex@...ti.fr>, Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
Andrew Morton <akpm@...ux-foundation.org>, "linux-riscv@...ts.infradead.org"
<linux-riscv@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH v1] riscv: make ZONE_DMA32 optional
>And if there really is not way to provide this, the right way is just
>to stop the runtime allocation that triggered you to do this if
>ZONE_DMA32 is empty, not to add a non-portable option.
I think there's 2 different arrangements:
1) CONFIG_ZONE_DMA32=Y means ZONE_DMA32 exists but empty.
Currently this is a bug. dma_atomic_pool_init() will fail.
2) CONFIG_ZONE_DMA32=N means ZONE_DMA32 does not exists
In this case any code that rely on DMA32 should fail to compile, and this is an intention.
Such system can't have drivers that can't work without DMA32 memory
I understand your suggestion is to go for the option 1, not allocate atomic_pool_dma32 and later
fail all allocations with GFP_DMA32 if requested by the code. This may be valid option but I don't have a vision how to do it properly.
Instead I want realize option 2.
SOC I am working on is not a general purpose system, it is an automotive
SOC that will run very restricted software. It is designed for purpose without support for the 32-bit
devices. I want to avoid any code that assumes DMA32 as this is just not valid on my SOC so I deliberately need to break all such code.
Powered by blists - more mailing lists