Hi, > -----Original Message----- > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb- > owner@xxxxxxxxxxxxxxx] On Behalf Of Mike Frysinger > Sent: Sunday, May 09, 2010 4:30 PM > To: linux-usb@xxxxxxxxxxxxxxx; Felipe Balbi > Cc: uclinux-dist-devel@xxxxxxxxxxxxxxxxxxxx; Cliff Cai > Subject: [PATCH] USB: musb: set NAK limitation for control transfers > > From: Cliff Cai <cliff.cai@xxxxxxxxxx> > > Some bad-behaved peripherals (like cheap USB storage devices) need this in > order to recover during configuration time. > > Signed-off-by: Cliff Cai <cliff.cai@xxxxxxxxxx> > Signed-off-by: Mike Frysinger <vapier@xxxxxxxxxx> > --- > drivers/usb/musb/musb_host.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > index 877d20b..e2667dc 100644 > --- a/drivers/usb/musb/musb_host.c > +++ b/drivers/usb/musb/musb_host.c > @@ -1994,6 +1994,9 @@ static int musb_urb_enqueue( > /* ISO always uses logarithmic encoding */ > interval = min_t(u8, epd->bInterval, 16); > break; > + case USB_ENDPOINT_XFER_CONTROL: > + interval = 8; Why '8'? Device could be high speed or FS/LS so it comes out to, HS device: 2^7 uf = 128uf = 16 msec FS/LS device: 2^7 f = 128msec Also, I have seen high speed bad behaved devices not responding to PING tokens in status phase of control transfers. Are you also getting this issue ? -Ajay > + break; > default: > /* REVISIT we actually want to use NAK limits, hinting to the > * transfer scheduling logic to try some other qh, e.g. try > -- > 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
