All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
	Leon Romanovsky <leonro@nvidia.com>,
	Andreas Larsson <andreas@gaisler.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Geoff Levand <geoff@infradead.org>, Helge Deller <deller@gmx.de>,
	Ingo Molnar <mingo@redhat.com>,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Jason Wang <jasowang@redhat.com>, Juergen Gross <jgross@suse.com>,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	Matt Turner <mattst88@gmail.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	sparclinux@vger.kernel.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	virtualization@lists.linux.dev, x86@kernel.org,
	xen-devel@lists.xenproject.org,
	Magnus Lindholm <linmag7@gmail.com>
Subject: Re: [PATCH v1 5/9] sparc64: Use physical address DMA mapping
Date: Fri, 3 Oct 2025 12:16:03 -0300	[thread overview]
Message-ID: <20251003151603.GD3360665@nvidia.com> (raw)
In-Reply-To: <bac909dab3c82fc6a7a4f5a31f22bac9a69f7f07.1759071169.git.leon@kernel.org>

On Sun, Sep 28, 2025 at 06:02:25PM +0300, Leon Romanovsky wrote:
> @@ -273,13 +272,16 @@ static dma_addr_t dma_4u_map_page(struct device *dev, struct page *page,
>  	u32 bus_addr, ret;
>  	unsigned long iopte_protection;
>  
> +	if (attrs & DMA_ATTR_MMIO)
> +		goto bad_no_ctx;
> +
>  	iommu = dev->archdata.iommu;
>  	strbuf = dev->archdata.stc;
>  
>  	if (unlikely(direction == DMA_NONE))
>  		goto bad_no_ctx;
>  
> -	oaddr = (unsigned long)(page_address(page) + offset);
> +	oaddr = (unsigned long)(phys_to_virt(phys));
>  	npages = IO_PAGE_ALIGN(oaddr + sz) - (oaddr & IO_PAGE_MASK);
>  	npages >>= IO_PAGE_SHIFT;

This should be cleaned up some more:

	oaddr = (unsigned long)(page_address(page) + offset);
	ret = bus_addr | (oaddr & ~IO_PAGE_MASK);

	base_paddr = __pa(oaddr & IO_PAGE_MASK);

Makes no sense to phys_to_virt() then __pa() on that result. Drop oaddr.

Then I would copy and paste the comment from mips about DMA_ATTR_MMIO
> @@ -367,13 +366,16 @@ static dma_addr_t dma_4v_map_page(struct device *dev, struct page *page,
>  	dma_addr_t bus_addr, ret;
>  	long entry;
>  
> +	if (attrs & DMA_ATTR_MMIO)
> +		goto bad;
> +
>  	iommu = dev->archdata.iommu;
>  	atu = iommu->atu;
>  
>  	if (unlikely(direction == DMA_NONE))
>  		goto bad;
>  
> -	oaddr = (unsigned long)(page_address(page) + offset);
> +	oaddr = (unsigned long)(phys_to_virt(phys));
>  	npages = IO_PAGE_ALIGN(oaddr + sz) - (oaddr & IO_PAGE_MASK);
>  	npages >>= IO_PAGE_SHIFT;

Same remarks here

> +static dma_addr_t iounit_map_phys(struct device *dev, phys_addr_t phys,
> +		size_t len, enum dma_data_direction dir, unsigned long attrs)
>  {
> -	void *vaddr = page_address(page) + offset;
> +	void *vaddr = phys_to_virt(phys);
>  	struct iounit_struct *iounit = dev->archdata.iommu;
>  	unsigned long ret, flags;

iounit_get_area() does not seem to need vaddr:

        npages = ((vaddr & ~PAGE_MASK) + size + (PAGE_SIZE-1)) >> PAGE_SHIFT;

~PAGE_MASK is page_offset()

	iopte = MKIOPTE(__pa(vaddr & PAGE_MASK));

__pa(phys_to_virt(pa)) again:
  iopte = MKIOPTE(PAGE_ALIGN(pa));

	vaddr = IOUNIT_DMA_BASE + (scan << PAGE_SHIFT) + (vaddr & ~PAGE_MASK);

page_offset, then it replaces vaddr.

So I'd tidy this too.

> @@ -202,10 +204,10 @@ static dma_addr_t __sbus_iommu_map_page(struct device *dev, struct page *page,
>	 * We expect unmapped highmem pages to be not in the cache.
>  	 * XXX Is this a good assumption?
>  	 * XXX What if someone else unmaps it here and races us?
>  	 */

At least ARM32 has code that seems to say these assumptions are not
always true.. Oh well.

Jason

  reply	other threads:[~2025-10-03 15:16 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-28 15:02 [PATCH v1 0/9] Remove DMA .map_page and .unmap_page callbacks Leon Romanovsky
2025-09-28 15:02 ` [PATCH v1 1/9] alpha: Convert mapping routine to rely on physical address Leon Romanovsky
2025-09-28 17:35   ` Magnus Lindholm
2025-10-03 14:47   ` Jason Gunthorpe
2025-09-28 15:02 ` [PATCH v1 2/9] MIPS/jazzdma: Provide physical address directly Leon Romanovsky
2025-10-03 14:48   ` Jason Gunthorpe
2025-09-28 15:02 ` [PATCH v1 3/9] parisc: Convert DMA map_page to map_phys interface Leon Romanovsky
2025-10-03 15:01   ` Jason Gunthorpe
2025-10-03 17:18     ` John David Anglin
2025-10-03 17:26       ` Jason Gunthorpe
2025-10-03 20:28         ` John David Anglin
2025-10-05 14:29       ` James Bottomley
2025-10-05 13:22     ` Leon Romanovsky
2025-10-05 23:31       ` Jason Gunthorpe
2025-10-06  4:03         ` Leon Romanovsky
2025-10-05 14:22     ` James Bottomley
2025-09-28 15:02 ` [PATCH v1 4/9] powerpc: Convert to physical address DMA mapping Leon Romanovsky
2025-10-03 16:35   ` Jason Gunthorpe
2025-10-04  6:19     ` Christophe Leroy
2025-10-04 20:02       ` Jason Gunthorpe
2025-09-28 15:02 ` [PATCH v1 5/9] sparc64: Use " Leon Romanovsky
2025-10-03 15:16   ` Jason Gunthorpe [this message]
2025-09-28 15:02 ` [PATCH v1 6/9] x86: Use physical address for " Leon Romanovsky
2025-10-03 15:16   ` Jason Gunthorpe
2025-09-28 15:02 ` [PATCH v1 7/9] vdpa: Convert to physical address " Leon Romanovsky
2025-10-03 15:58   ` Jason Gunthorpe
2025-09-28 15:02 ` [PATCH v1 8/9] xen: swiotlb: Convert mapping routine to rely on physical address Leon Romanovsky
2025-10-03 16:18   ` Jason Gunthorpe
2025-09-28 15:02 ` [PATCH v1 9/9] dma-mapping: remove unused map_page callback Leon Romanovsky
2025-09-28 15:17   ` Sam Ravnborg
2025-09-28 15:20     ` Sam Ravnborg
2025-09-28 15:31       ` Leon Romanovsky
2025-09-28 15:28     ` Leon Romanovsky
2025-10-03 16:18   ` Jason Gunthorpe

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=20251003151603.GD3360665@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=andreas@gaisler.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=geoff@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=jasowang@redhat.com \
    --cc=jgross@suse.com \
    --cc=leon@kernel.org \
    --cc=leonro@nvidia.com \
    --cc=linmag7@gmail.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maddy@linux.ibm.com \
    --cc=mattst88@gmail.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=mst@redhat.com \
    --cc=richard.henderson@linaro.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=sstabellini@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tsbogend@alpha.franken.de \
    --cc=virtualization@lists.linux.dev \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.