[PATCH v3] drm: Use USB controller's DMA mask when importing dmabufs

Greg KH gregkh at linuxfoundation.org
Tue Feb 23 17:30:05 UTC 2021


On Tue, Feb 23, 2021 at 11:00:54AM -0500, 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.

Yes, sorry for not being clear, that is what I think would make the most
sense, then all USB drivers could use it easily and it can be changed in
one location if the DMA logic ever changes.

thanks,

greg k-h


More information about the dri-devel mailing list