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