Date: Sat, 06 Nov 2004 14:03:09 +0000 From: Ian Dowse <iedowse@maths.tcd.ie> To: Julian Elischer <julian@elischer.org> Cc: usb@freebsd.org Subject: Re: roll call and USB "plan" Message-ID: <200411061403.aa18842@salmon.maths.tcd.ie> In-Reply-To: Your message of "Fri, 05 Nov 2004 13:15:03 PST." <418BED57.6090203@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <418BED57.6090203@elischer.org>, Julian Elischer writes: >ok, so, who's subscribed? (who considers themselves able to work on USB) > >1/ where are we? > I've seen USB commits recently from several people.. > anyone have any plans and uncommitted work? >2/ what do we need? > I know we need to look at multifunction devices, and USB2 hub support >for USB1 devices. > EHCI command completion interrupts probably also need work.. >3/ scottl has said that he wants to work on CAM/SIM and that may impact >umass. >4/ I think we need to do more work on umass devices in general. I have some uncommitted changes that improve the use of bus_dma to avoid the need for big physically contiguous data buffers and memory copying, but that's about it. I've also started looking through some of the old PRs. Things I can think of that need work include: o Error handling - many communication errors cause panics. e.g try plugging in and out a umass device 10 times in quick succession. o Missing EHCI features (Lennart Augustsson in NetBSD might be working on some split transaction support) o Exploring uhci/ohci devices should be deferred until ehci has initialised (David Gwynne in OpenBSD mentioned trying to do this) o Memory allocation (lots of memory is leaked on detach) There also seem to be many cases where a particular device works for some people and not for others - it's hard to tell if the USB code is doing something bad and we are just getting away with it on some hardware (this has been the case a few times), or if there are particular host controller hardware bugs that we need to work around. Regarding the compat stuff, I guess it makes sense to remove the bits that get in the way, but it can be helpful when comparing our code with other BSDs. It would certainly cause less confusion if we removed all the non-FreeBSD bits from usb_port.h. Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411061403.aa18842>