linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Laura Abbott <labbott@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Liam Mark <lmark@codeaurora.org>,
	sumit.semwal@linaro.org, arve@android.com, tkjos@android.com,
	maco@android.com, joel@joelfernandes.org, christian@brauner.io,
	devel@driverdev.osuosl.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org,
	afd@ti.com, john.stultz@linaro.org
Subject: Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes
Date: Mon, 21 Jan 2019 00:30:46 -0800	[thread overview]
Message-ID: <20190121083046.GD12420@infradead.org> (raw)
In-Reply-To: <7ae73c39-9049-bcf6-775f-b0817ba0ec5f@redhat.com>

On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
> > And who is going to decide which ones to pass?  And who documents
> > which ones are safe?
> > 
> > I'd much rather have explicit, well documented dma-buf flags that
> > might get translated to the DMA API flags, which are not error checked,
> > not very well documented and way to easy to get wrong.
> > 
> 
> I'm not sure having flags in dma-buf really solves anything
> given drivers can use the attributes directly with dma_map
> anyway, which is what we're looking to do. The intention
> is for the driver creating the dma_buf attachment to have
> the knowledge of which flags to use.

Well, there are very few flags that you can simply use for all calls of
dma_map*.  And given how badly these flags are defined I just don't want
people to add more places where they indirectly use these flags, as
it will be more than enough work to clean up the current mess.

What flag(s) do you want to pass this way, btw?  Maybe that is where
the problem is.

  reply	other threads:[~2019-01-21  8:30 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 18:37 [PATCH 0/4] ION stability and perf changes Liam Mark
2019-01-18 18:37 ` [PATCH 1/4] staging: android: ion: Support cpu access during dma_buf_detach Liam Mark
2019-01-18 19:34   ` Andrew F. Davis
2019-01-18 20:40   ` Laura Abbott
2019-01-18 18:37 ` [PATCH 2/4] staging: android: ion: Restrict cache maintenance to dma mapped memory Liam Mark
2019-01-18 20:20   ` Andrew F. Davis
2019-01-18 21:18     ` Liam Mark
2019-01-29 23:44       ` Liam Mark
2019-01-30 11:31         ` Brian Starkey
2019-02-06 15:40           ` [Linaro-mm-sig] " Ørjan Eide
2019-02-07  7:31             ` Christoph Hellwig
2019-02-07 15:45               ` Ørjan Eide
2019-02-28 23:49             ` Liam Mark
2019-01-30 14:31         ` Andrew F. Davis
2019-01-18 18:37 ` [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes Liam Mark
2019-01-18 20:48   ` Laura Abbott
2019-01-18 21:32     ` Liam Mark
2019-01-18 22:45       ` Laura Abbott
2019-01-19 10:25   ` Christoph Hellwig
2019-01-19 16:50     ` Laura Abbott
2019-01-21  8:30       ` Christoph Hellwig [this message]
2019-01-21 19:44         ` Liam Mark
2019-01-21 19:49           ` Andrew F. Davis
2019-01-21 20:20             ` Liam Mark
2019-01-21 20:24               ` Andrew F. Davis
2019-01-21 22:18                 ` Liam Mark
2019-01-22 15:42                   ` Andrew F. Davis
2019-01-22 22:47                     ` Liam Mark
2019-01-21 21:30               ` Christoph Hellwig
2019-01-21 22:14                 ` Liam Mark
2019-01-21 21:29           ` Christoph Hellwig
2019-01-21 22:12             ` Liam Mark
2019-01-22 16:06               ` Andrew F. Davis
2019-01-22 22:50                 ` Liam Mark
2019-01-18 18:37 ` [PATCH 4/4] staging: android: ion: Support " Liam Mark
2019-01-21 12:19   ` Brian Starkey
2019-01-22 22:37     ` Liam Mark

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=20190121083046.GD12420@infradead.org \
    --to=hch@infradead.org \
    --cc=afd@ti.com \
    --cc=arve@android.com \
    --cc=christian@brauner.io \
    --cc=devel@driverdev.osuosl.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=joel@joelfernandes.org \
    --cc=john.stultz@linaro.org \
    --cc=labbott@redhat.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lmark@codeaurora.org \
    --cc=maco@android.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tkjos@android.com \
    /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).