Date: Fri, 07 Mar 2008 08:15:02 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: raj@semihalf.com Cc: usb@freebsd.org Subject: Re: Workarounds in generic EHCI code Message-ID: <20080307.081502.-116098145.imp@bsdimp.com> In-Reply-To: <47D15050.3010809@semihalf.com> References: <47D15050.3010809@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <47D15050.3010809@semihalf.com> Rafal Jaworowski <raj@semihalf.com> writes: : Greetings, : : 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. Second, I'd make the descriptions a little better. The first two aren't very helpful... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080307.081502.-116098145.imp>