[PATCH RFC] dwc2: Don't assume URB transfer_buffer are dword-aligned
stern at rowland.harvard.edu
Sat Mar 18 07:33:41 PDT 2017
On Fri, 17 Mar 2017, 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
> 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.
There are two reasons not to do this. First, not all host controllers
require buffers to be aligned, and doing these copies for them would be
a waste of time.
Second, not all USB transfers use usb_control_msg(). How would you go
about changing the rest of them? Especially the ones that can't sleep?
More information about the linux-rpi-kernel