public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	Mathias Nyman <mathias.nyman@linux.intel.com>,
	airlied@linux.ie, gregkh@linuxfoundation.org,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Oliver Neukum <oneukum@suse.com>, Johan Hovold <johan@kernel.org>,
	hdegoede@redhat.com, Christoph Hellwig <hch@lst.de>,
	dri-devel@lists.freedesktop.org, stable@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	sean@poorly.run, christian.koenig@amd.com
Subject: Re: [PATCH v3] drm: Use USB controller's DMA mask when importing dmabufs
Date: Tue, 23 Feb 2021 17:12:23 +0100	[thread overview]
Message-ID: <s5hy2feu5js.wl-tiwai@suse.de> (raw)
In-Reply-To: <20210223160054.GC1261797@rowland.harvard.edu>

On Tue, 23 Feb 2021 17:00:54 +0100,
Alan Stern wrote:
> 
> On Tue, Feb 23, 2021 at 03:06:07PM +0100, Thomas Zimmermann wrote:
> > Hi
> > 
> > Am 23.02.21 um 14:44 schrieb Takashi Iwai:
> 
> > > Aside from the discussion whether this "workaround" is needed, the use
> > > of udev->bus->controller here looks a bit suspicious.  As the old USB
> > > code (before the commit 6eb0233ec2d0) indicated, it was rather
> > > usb->bus->sysdev that was used for the DMA mask, and it's also the one
> > > most of USB core code refers to.  A similar question came up while
> > > fixing the same kind of bug in the media subsystem, and we concluded
> > > that bus->sysdev is a better choice.
> > 
> > Good to hear that we're not the only ones affected by this. Wrt the original
> > code, using sysdev makes even more sense.
> 
> Hmmm, I had forgotten about this.  So DMA masks aren't inherited after 
> all, thanks to commit 6eb0233ec2d0.  That leas me to wonder how well 
> usb-storage is really working these days...
> 
> The impression I get is that Greg would like the USB core to export a 
> function which takes struct usb_interface * as argument and returns the 
> appropriate DMA mask value.  Then instead of messing around with USB 
> internals, drm_gem_prime_import_usb could just call this new function.
> 
> Adding such a utility function would be a sufficiently small change that 
> it could go into the -stable kernels with no trouble.

Note that drm isn't the only subsystem that needs the proper DMA
mask.  The media and sound subsystems require it, at least.
Those had already used sysdev for the DMA mask and the actual memory
allocation.


Takashi

  reply	other threads:[~2021-02-23 16:13 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23 10:58 [PATCH v3] drm: Use USB controller's DMA mask when importing dmabufs Thomas Zimmermann
2021-02-23 11:19 ` Greg KH
2021-02-23 11:27   ` Greg KH
2021-02-23 11:46   ` Daniel Vetter
2021-02-23 12:02     ` Greg KH
2021-02-23 12:14       ` Daniel Vetter
2021-02-23 12:24         ` Greg KH
2021-02-23 12:40           ` Daniel Vetter
2021-02-23 12:50             ` Greg KH
2021-02-23 12:59               ` Daniel Vetter
2021-02-23 12:51           ` Thomas Zimmermann
2021-02-23 13:09             ` Greg KH
2021-02-25 19:01               ` Sudip Mukherjee
2021-02-25 21:39                 ` Salvatore Bonaccorso
2021-02-23 12:37   ` Thomas Zimmermann
2021-02-23 12:44     ` Greg KH
2021-02-23 12:49       ` Daniel Vetter
2021-02-23 12:52         ` Greg KH
2021-02-23 13:43           ` Thomas Zimmermann
2021-02-23 12:47     ` Daniel Vetter
2021-02-23 15:45   ` Alan Stern
2021-02-24  6:02     ` Thomas Zimmermann
2021-02-23 13:44 ` Takashi Iwai
2021-02-23 14:06   ` Thomas Zimmermann
2021-02-23 16:00     ` Alan Stern
2021-02-23 16:12       ` Takashi Iwai [this message]
2021-02-23 17:30       ` Greg KH
2021-02-24  5:59         ` Thomas Zimmermann
2021-02-24  7:27       ` Christoph Hellwig

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=s5hy2feu5js.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=airlied@linux.ie \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bigeasy@linutronix.de \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=hdegoede@redhat.com \
    --cc=johan@kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=oneukum@suse.com \
    --cc=sean@poorly.run \
    --cc=stable@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    --cc=tzimmermann@suse.de \
    /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