linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Petr Tesarik <ptesarik@suse.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin@web.codeaurora.org, Bagas Sanjaya <bagasdotme@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Leon Romanovsky <leon@kernel.org>,
	Keith Busch <kbusch@kernel.org>,
	Caleb Sander Mateos <csander@purestorage.com>,
	Sagi Grimberg <sagi@grimberg.me>, Jens Axboe <axboe@kernel.dk>,
	John Garry <john.g.garry@oracle.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
	iommu@lists.linux.dev
Subject: Re: [PATCH 7/8] docs: dma-api: update streaming DMA API physical address constraints
Date: Fri, 27 Jun 2025 05:52:07 -0700	[thread overview]
Message-ID: <aF6T9-iUWMVx4DyK@infradead.org> (raw)
In-Reply-To: <20250626070602.3d42b607@mordecai.tesarici.cz>

On Thu, Jun 26, 2025 at 07:06:02AM +0200, Petr Tesarik wrote:
> @Marek, @Robin Do you agree that device drivers should not be concerned
> about the physical address of a buffer passed to the streaming DMA API?
> 
> I mean, are there any real-world systems with:
>   * some RAM that is not DMA-addressable,
>   * no IOMMU,
>   * CONFIG_SWIOTLB is not set?
> 
> FWIW if _I_ received a bug report that a device driver fails to submit
> I/O on such a system, I would politely explain the reporter that their
> kernel is misconfigured, and they should enable CONFIG_SWIOTLB.

Modulo the case of < 32-bit (or 31-bit for some systems) case the
general idea was that the iommu API always works except for temporary
resource shortages.  Now if you configure without SWIOTLB on system
that would otherwise need it you gotta keep the pieces.  That's why
I've always argued against making that (and ZONE_DMA) user selectable,
but some arch maintainers insisted that they want that, breaking the
original guarantee.  Which is annoying as dma_map_* can't tell you
if the failure is permanent or transient.


  parent reply	other threads:[~2025-06-27 12:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-24 13:39 [PATCH 0/8] update DMA API documentation Petr Tesarik
2025-06-24 13:39 ` [PATCH 1/8] docs: dma-api: use "DMA API" consistently throughout the document Petr Tesarik
2025-06-25  2:41   ` Randy Dunlap
2025-06-24 13:39 ` [PATCH 2/8] docs: dma-api: replace consistent with coherent Petr Tesarik
2025-06-26  4:51   ` Petr Tesarik
2025-06-26  7:21     ` Marek Szyprowski
2025-06-24 13:39 ` [PATCH 3/8] docs: dma-api: remove remnants of PCI DMA API Petr Tesarik
2025-06-26  1:46   ` Bagas Sanjaya
2025-06-24 13:39 ` [PATCH 4/8] docs: dma-api: add a kernel-doc comment for dma_pool_zalloc() Petr Tesarik
2025-06-24 13:39 ` [PATCH 5/8] docs: dma-api: remove duplicate description of the DMA pool API Petr Tesarik
2025-06-25  2:40   ` Randy Dunlap
2025-06-25  6:41     ` Petr Tesarik
2025-06-24 13:39 ` [PATCH 6/8] docs: dma-api: clarify DMA addressing limitations Petr Tesarik
2025-06-26  1:47   ` Bagas Sanjaya
2025-06-24 13:39 ` [PATCH 7/8] docs: dma-api: update streaming DMA API physical address constraints Petr Tesarik
2025-06-26  1:49   ` Bagas Sanjaya
2025-06-26  5:06     ` Petr Tesarik
2025-06-26  7:09       ` Marek Szyprowski
2025-06-26  8:25         ` Petr Tesarik
2025-06-26  9:58       ` Robin Murphy
2025-06-26 13:48         ` Petr Tesarik
2025-06-26 16:45           ` Robin Murphy
2025-06-26 19:40             ` Petr Tesarik
2025-06-27 11:07               ` Robin Murphy
2025-06-27 11:32                 ` Petr Tesarik
2025-06-27 12:55             ` Christoph Hellwig
2025-06-27 13:02               ` Petr Tesarik
2025-06-27 12:52       ` Christoph Hellwig [this message]
2025-06-24 13:39 ` [PATCH 8/8] docs: dma-api: clean up documentation of dma_map_sg() Petr Tesarik
2025-06-26  1:50   ` Bagas Sanjaya

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=aF6T9-iUWMVx4DyK@infradead.org \
    --to=hch@infradead.org \
    --cc=Robin@web.codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=bagasdotme@gmail.com \
    --cc=corbet@lwn.net \
    --cc=csander@purestorage.com \
    --cc=iommu@lists.linux.dev \
    --cc=john.g.garry@oracle.com \
    --cc=kbusch@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=ptesarik@suse.com \
    --cc=sagi@grimberg.me \
    /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