M. Warner Losh wrote: > : I'd like to hear comments on the proper way of handling non-standard > behaviour > : of a host controller when a workaround needs to be aplied at the shared code > : level. In the following I followed an example of existing VIA/ATI chip > workaround: > : > : http://people.freebsd.org/~raj/patches/misc/usb-workarounds.diff > : > : The respective flags are potentially set in platform-specific attachment > : driver code, which knows if they apply etc. > : > : Does anybody see a better way to handle such cases? > > This seems fine, but... > > +#define EHCI_SCFLG_USBMODEBUG 0x0003 /* workaround for Marvell > 88F5281 chipsets */ > +#define EHCI_SCFLG_FORCESPEED 0x0004 /* workaround for Marvell > chipsets */ > +#define EHCI_SCFLG_NORESTERM 0x0005 /* don't terminate reset sequence on > Marvell chipsets */ > > Two comments. '3' isn't a bit, so those values need to change.
Ah, sure, thanks. > Second, I'd make the descriptions a little better. The first two > aren't very helpful... > I have more detailed descriptions in the platform code that sets this, e.g. /* * Workaround for Marvell 88F5281 integrated EHCI controller: reset of * the EHCI core clears the USBMODE register, which sets the core in * an undefined state (neither host nor agent), so it needs to be set * again for proper operation. * * Refer to errata document (p. 5.24 GL USB-2) for details. */ But maybe it really better fits in the ehic.c/ehcivar.h.. I'll try to improve this. Rafal _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
