linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Alistair Popple" <apopple@nvidia.com>
Cc: rust-for-linux@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] rust: Add dma_set_mask() and dma_set_coherent_mask() bindings
Date: Tue, 08 Jul 2025 11:48:36 +0200	[thread overview]
Message-ID: <DB6KV5SVWIYG.2FAIFGZ90ZR2I@kernel.org> (raw)
In-Reply-To: <DB6JF2JLZEO8.4HZPDC26F3G8@kernel.org>

On Tue Jul 8, 2025 at 10:40 AM CEST, Danilo Krummrich wrote:
> On Tue Jul 8, 2025 at 8:04 AM CEST, Alistair Popple wrote:
>> Add bindings to allow setting the DMA masks for both a generic device
>> and a PCI device.
>
> Nice coincidence, I was about to get back to this. I already implemented this in
> a previous patch [1], but didn't apply it yet.
>
> I think the approach below is thought a bit too simple:
>
>   (1) We want the DMA mask methods to be implemented by a trait in dma.rs.
>       Subsequently, the trait should only be implemented by bus devices where
>       the bus actually supports DMA. Allowing to set the DMA mask on any device
>       doesn't make sense.

Forgot to mention, another reason for a trait is that we can also use it as a
trait bound on dma::CoherentAllocation::new(), such that people can't pass
arbitrary devices to dma::CoherentAllocation::new(), but only those that
actually sit on a DMA capable bus.

>
>   (2) We need to consider that with this we do no prevent
>       dma_set_coherent_mask() to concurrently with dma_alloc_coherent() (not
>       even if we'd add a new `Probe` device context).
>
> (2) is the main reason why I didn't follow up yet. So far I haven't found a nice
>     solution for a sound API that doesn't need unsafe.
>
> One thing I did consider was to have some kind of per device table (similar to
> the device ID table) for drivers to specify the DMA mask already at compile
> time. However, I'm pretty sure there are cases where the DMA mask has to derived
> dynamically from probe().
>
> I think I have to think a bit more about it.
>
> [1] https://lore.kernel.org/all/20250317185345.2608976-7-abdiel.janulgue@gmail.com/


  reply	other threads:[~2025-07-08  9:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-08  6:04 [PATCH 1/2] rust: Add dma_set_mask() and dma_set_coherent_mask() bindings Alistair Popple
2025-07-08  6:04 ` [PATCH 2/2] rust: Add several miscellaneous PCI helpers Alistair Popple
2025-07-08  7:05   ` Alexandre Courbot
2025-07-08  8:07   ` Greg Kroah-Hartman
2025-07-09  1:50     ` Alistair Popple
2025-07-08  9:32   ` Danilo Krummrich
2025-07-09  1:43     ` Alistair Popple
2025-07-08  7:01 ` [PATCH 1/2] rust: Add dma_set_mask() and dma_set_coherent_mask() bindings Alexandre Courbot
2025-07-08  8:07   ` Alistair Popple
2025-07-08  8:40 ` Danilo Krummrich
2025-07-08  9:48   ` Danilo Krummrich [this message]
2025-07-08 20:44     ` Danilo Krummrich
2025-07-09  1:41       ` Alistair Popple
2025-07-10 19:39       ` Danilo Krummrich

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=DB6KV5SVWIYG.2FAIFGZ90ZR2I@kernel.org \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jhubbard@nvidia.com \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /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;
as well as URLs for NNTP newsgroup(s).