Re: [PATCH v3 0/2] staging: dwc2: add microframe scheduler
On Tue, 22 Jul 2014 18:46:27 +0100, Paul Zimmerman wrote: From: Nick Hudson [mailto:sk...@netbsd.org] Sent: Tuesday, July 22, 2014 12:19 AM On 09/23/13 22:23, Paul Zimmerman wrote: > Here is the third version of the microframe scheduler patch. This > version removes the NAK holdoff patch from the series, since it > was effectively a no-op as pointed out by Matthijs. I think there was a misunderstanding here - Matthijs was pointing out that the next_sched_frame variable was unused. That particular variable is part of the downstream Pi driver's FIQ code. Right, but without that, the patch didn't actually do anything as far as I could see. The nak_frame handling would have added some benefit, but wouldn't handle all cases. I'm seeing problems with devices NAKing to the point of confusing dwc2 completely, so I'd like to investigate a NAK holdoff scheme that's acceptable for dwc2. I suspect the best thing to do here is to add a nak_count field to dwc2_qh (or maybe dwc2_qtd) and increment in dwc2_hc_nak_intr. If the count exceeds a threshold then it would call dwc2_halt_channel(hsotg, chan, qtd, DWC2_HC_XFER_NAK); and go around again. I assume the NAK count would need resetting everywhere qtd->error_count is reset. How does this sound? Sounds good to me. BTW, can you give me a pointer to one of the devices that gives excessive NAKs? I would like to buy one for the lab here to test with. All USB-serial dongles that use a simple bulk in/out FIFO endpoint structure exhibit this behaviour. A URB is submitted to the IN endpoint and it's effectively used to "poll" the endpoint for data. Typically the very large mismatch between the configured baud rate and the full-speed bus transfer rate results in a lengthy sequence of NAKs followed by the next byte received by the UART. USB-serial devices manufactured by FTDI almost exclusively use this method of transport. FTDI ship several variants that package their FT232R USB-serial adapter: bare board or with pigtail attached. Note that the NAK holdoff is capable of being implemented without the FIQ - in our implementation we add a parameter to the QH for the endpoint (nak_frame) that records the last time this endpoint was polled for data. An adjustable parameter changes the interval for considering QTDs in this QH for execution (i.e. submission to the otg core) based on the microframe number of the last nak_frame received. In the case where FIQ support is not provided, then the SOF interrupt will have to be unmasked as long as there are QHs with nak_frame set. Regards Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dwc2 / Raspberry Pi - hardware bug for small transfers results in memory corruption
As reported by one of our users here: https://github.com/raspberrypi/linux/issues/3148 There is a bug when the dwc2 core receives USB data packets that are between 1 and 4 bytes in length - 4 bytes are always written to memory where the non-packet bytes are garbage. This is easily reproducible by - Plugging a UVC-compliant webcam into a Raspberry Pi gen 1, 2 or 3 product - Running "v4l2-ctl -d 0 --all" The camera's control ranges (brightness/contrast etc) are all queried by 1- or 2-byte control IN transfers. As 4 bytes get written to the URB's buffer, this results in the uvcvideo data struct containing the control information getting corrupted like so: contrast 0x00980901 (int): min=0 max=64 step=1 default=57343 value=32 saturation 0x00980902 (int): min=0 max=128 step=1 default=57343 value=105 hue 0x00980903 (int): min=-40 max=40 step=1 default=-8193 value=0 white_balance_temperature_auto 0x0098090c (bool) : default=1 value=1 gamma 0x00980910 (int): min=72 max=500 step=1 default=57343 value=100 [etc] We've implemented a downstream fix for dwc_otg[1] that just forces use of the dword alignment buffer mechanism (aka DMA bounce buffer), but dwc2 only uses a bounce buffer for split-IN transfers. I have two questions: 1) Does this bug occur on non-Pi hardware? 2) What's the easiest way to patch this for dwc2? [1] https://github.com/raspberrypi/linux/commit/c0e4ca17457d6669a263e86a88f0036875fc019e
Re: dwc2 / Raspberry Pi - hardware bug for small transfers results in memory corruption
On Thu, Aug 15, 2019 at 11:55 AM Oliver Neukum wrote: > > Am Mittwoch, den 14.08.2019, 16:59 +0100 schrieb Jonathan Bell: > > As reported by one of our users here: > > https://github.com/raspberrypi/linux/issues/3148 > > > > There is a bug when the dwc2 core receives USB data packets that are > > between 1 and 4 bytes in length - 4 bytes are always written to memory > > where the non-packet bytes are garbage. > > Hi, > > in which function does that happen? If your buffer cannot handle 4 > bytes I cannot see how it copes with teh DMA rules. > In drivers/media/usb/uvc/uvc_ctrl.c:uvc_ctrl_populate_cache() and friends. The UVC driver passes in offsets into a struct uvc_control as the "buffer" that usb_control_msg() fills.
Re: dwc2 / Raspberry Pi - hardware bug for small transfers results in memory corruption
On Thu, Aug 15, 2019 at 1:51 PM Lars Melin wrote: > > On 8/14/2019 22:59, Jonathan Bell wrote: > > There is a bug when the dwc2 core receives USB data packets that are > > between 1 and 4 bytes in length - 4 bytes are always written to memory > > where the non-packet bytes are garbage. > > Which host controller driver, dwc2 or the out-of-tree dwc_otg driver? > > Thanks > Lars The bug was present when using either the out-of-tree dwc_otg or upstream dwc2 driver on Raspberry Pi.
Re: dwc2 / Raspberry Pi - hardware bug for small transfers results in memory corruption
On Thu, Aug 15, 2019 at 3:52 PM Oliver Neukum wrote: > > The UVC driver passes in offsets into a struct uvc_control as the > > "buffer" that usb_control_msg() fills. > > Not quite that bad. It passes a pointer into the middle of a buffer > used at different offsets for the transfer. This is technically allowed > as long as you never touch the buffer while a transfer is ongoing. > > That is an accident waiting to happen. Please make a patch using > a bounce buffer allocated with knalloc() in > drivers/media/usb/uvc/uvc_ctrl.c:uvc_ctrl_populate_cache() and friends. A patch to uvcvideo will not fix the underlying bug with the host controller hardware. There are hundreds of device drivers of varying vintages that potentially react badly to having a rogue host controller DMA engine writing more bytes than were reported by the controller's interrupt status register. So my original two questions still need answering: 1) Does the symptom seen with v4l2-ctl exist on other platforms using dwc2 (which implies that this is not a bug specific to Raspberry Pi) 2) How do we harden upstream dwc2 against a broken controller DMA?
