From: Yann Sionneau <ysionneau@kalrayinc.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, "Will Deacon" <will@kernel.org>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Nick Piggin" <npiggin@gmail.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Jonathan Borne" <jborne@kalrayinc.com>,
"Julian Vetter" <jvetter@kalrayinc.com>,
"Clement Leger" <clement@clement-leger.fr>,
"Guillaume Thouvenin" <thouveng@gmail.com>,
"Jean-Christophe Pince" <jcpince@gmail.com>,
"Jules Maselbas" <jmaselbas@zdiv.net>,
"Julien Hascoet" <jhascoet@kalrayinc.com>,
"Louis Morhet" <lmorhet@kalrayinc.com>,
"Marc Poulhiès" <dkm@kataplop.net>,
"Marius Gligor" <mgligor@kalrayinc.com>,
"Vincent Chardon" <vincent.chardon@elsys-design.com>,
linux-arch@vger.kernel.org, linux-mm@kvack.org,
linux-riscv@lists.infradead.org,
"Robin Murphy" <robin.murphy@arm.com>
Subject: Re: [RFC PATCH v3 24/37] kvx: Add memory management
Date: Fri, 23 Aug 2024 18:02:15 +0200 [thread overview]
Message-ID: <be04b692-d4ef-4e59-896c-085d92e3d193@kalrayinc.com> (raw)
In-Reply-To: <Zp5zrkwyagnkoY7F@infradead.org>
Hello Christoph,
On 22/07/2024 16:58, Christoph Hellwig wrote:
>> +#include "../../../drivers/iommu/dma-iommu.h"
> This is not a public header as you can guess from the file path.
Yes indeed this is not "correct" however I didn't know how to do it properly so I am sending this as "RFC" to get some help to clean this up properly :)
If I understood correctly the remaining part of your review: including this header is not needed anymore since we don't need to call `iommu_setup_dma_ops()` anymore.
So let's remove both the incorrect non-public header include and the call to iommu_setup_dma_ops().
>
>> + switch (dir) {
>> + case DMA_TO_DEVICE:
>> + break;
>> + case DMA_FROM_DEVICE:
>> + break;
>> +
>> + case DMA_BIDIRECTIONAL:
>> + inval_dcache_range(paddr, size);
> Doing this just for bidirectional is weird unless your architecture
> never does any speculative prefetching. Other architectures
> include DMA_FROM_DEVICE here.
Indeed our arch never does any speculative prefetching on data.
>
>> +#ifdef CONFIG_IOMMU_DMA
>> +void arch_teardown_dma_ops(struct device *dev)
>> +{
>> + dev->dma_ops = NULL;
>> +}
>> +#endif /* CONFIG_IOMMU_DMA*/
> This should not be needed right now. And will be completley
> useless once we do the direct calls to dma-iommu which we plan
> to do for Linux 6.12.
Alright, let's remove this.
>
>> +void arch_setup_dma_ops(struct device *dev, bool coherent)
>> +{
>> + dev->dma_coherent = coherent;
>> + if (device_iommu_mapped(dev))
>> + iommu_setup_dma_ops(dev);
>> +}
> And this seems odd, as iommu_setup_dma_ops is called from the iommu
> code and you shouldn't need it here.
Let's remove the `if device_iommu_mapped(dev)) iommu_setup_dma_ops(dev);` then.
>
> I also wonder if we can come up with a way to do the ->dma_coherent
> setup in common code and remove a few of these arch hooks entirely.
Thanks!
Regards,
--
Yann
next prev parent reply other threads:[~2024-08-23 16:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240722094226.21602-1-ysionneau@kalrayinc.com>
2024-07-22 9:41 ` [RFC PATCH v3 12/37] kvx: Add ELF-related definitions ysionneau
2024-07-22 9:41 ` [RFC PATCH v3 24/37] kvx: Add memory management ysionneau
2024-07-22 14:58 ` Christoph Hellwig
2024-07-30 13:48 ` Robin Murphy
2024-08-23 16:02 ` Yann Sionneau [this message]
2024-07-22 9:41 ` [RFC PATCH v3 27/37] kvx: Add ELF relocations and module support ysionneau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=be04b692-d4ef-4e59-896c-085d92e3d193@kalrayinc.com \
--to=ysionneau@kalrayinc.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@kernel.org \
--cc=aou@eecs.berkeley.edu \
--cc=clement@clement-leger.fr \
--cc=dkm@kataplop.net \
--cc=hch@infradead.org \
--cc=jborne@kalrayinc.com \
--cc=jcpince@gmail.com \
--cc=jhascoet@kalrayinc.com \
--cc=jmaselbas@zdiv.net \
--cc=jvetter@kalrayinc.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lmorhet@kalrayinc.com \
--cc=mgligor@kalrayinc.com \
--cc=npiggin@gmail.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=robin.murphy@arm.com \
--cc=thouveng@gmail.com \
--cc=vincent.chardon@elsys-design.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox