[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