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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
