[PATCH RFC] dwc2: Don't assume URB transfer_buffer are dword-aligned

Greg Kroah-Hartman gregkh at linuxfoundation.org
Fri Mar 17 23:25:56 PDT 2017


On Fri, Mar 17, 2017 at 04:25:21PM -0700, Michael Zoran wrote:
> On Fri, 2017-03-17 at 10:24 +0900, Greg Kroah-Hartman wrote:
> > On Thu, Mar 16, 2017 at 09:08:40PM -0300, Mauro Carvalho Chehab
> > wrote:
> > > The dwc2 hardware doesn't like to do DMA transfers without
> > > aligning data in DWORD. The driver also assumes that, even
> > > when there's no DMA, at dwc2_read_packet().
> > > 
> > > That cause buffer overflows, preventing some drivers to work.
> > 
> > Why aren't the drivers being fixed?  This is a well-known (hopefully)
> > restriction on USB data buffers, can't the uvc_driver be fixed?
> > 
> > > In the specific case of uvc_driver, it uses an array where
> > > it caches the content of video controls, passing it to the
> > > USB stack via usb_control_msg(). Typical controls use 1 or 2
> > > bytes. The net result is that other values of the buffer
> > > gets overriden when this function is called.
> > 
> > Not good, it should be fixed, otherwise you are going to have to try
> > to
> 
> Silly question this being an RFC an all. 
> 
> But I wonder if this would be best to fix in the core usb subsystem
> rather then making an attempt to fix each and every driver and host
> controller.
> 
> Since usb_control_msg is a wrapper that can sleep, it's safe to
> allocate some memory in the case the destinate buffer isn't aligned.
> Essentially have the usb core handle the copy to a temp buffer and copy
> it back after the transaction is over.

It's come up every-so-often to do this, an additional memory
allocation/copy/free isn't that big of a deal for a normal control
message, but I think what prevents this from actually being changed is
that there might be devices that this would affect throughput.

No one has really tried, and I don't think I've ever seen a patch to
make this change.  That combined with the fact that all other USB
transfers have this requirement, would make this one type of transfer an
oddity.

thanks,

greg k-h



More information about the linux-rpi-kernel mailing list