Hi, On Wed, Feb 26, 2020 at 1:04 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > > In some situations, the following error messages are reported. > > dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown > dwc2 ff540000.usb: hcint 0x00000002, intsts 0x04000021 > > This is sometimes followed by: > > dwc2 ff540000.usb: dwc2_update_urb_state_abn(): trimming xfer length > > and then: > > WARNING: CPU: 0 PID: 0 at kernel/v4.19/drivers/usb/dwc2/hcd.c:2913 > dwc2_assign_and_init_hc+0x98c/0x990 > > The warning suggests that an odd buffer address is to be used for DMA. > > After an error is observed, the receive buffer may be full > (urb->actual_length >= urb->length). However, the urb is still left in > the queue unless three errors were observed in a row. When it is queued > again, the dwc2 hcd code translates this into a 1-block transfer. > If urb->actual_length (ie the total expected receive length) is not > DMA-aligned, the buffer pointer programmed into the chip will be > unaligned. This results in the observed warning. > > To solve the problem, abort input transactions after an error with > unknown cause if the entire packet was already received. This may be > a bit drastic, but we don't really know why the transfer was aborted > even though the entire packet was received. Aborting the transfer in > this situation is less risky than accepting a potentially corrupted > packet. > > With this patch in place, the 'ChHltd set' and 'trimming xfer length' > messages are still observed, but there are no more transfer attempts > with odd buffer addresses. > > Cc: Boris ARZUR <boris@xxxxxxxxx> > Cc: Douglas Anderson <dianders@xxxxxxxxxxxx> > Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx> > --- > drivers/usb/dwc2/hcd_intr.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) Seems sane to me. Also suggest a "Fixes" or "Cc: stable" tag. Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
