On Wednesday 02 February 2005 2:17 pm, Alan Stern wrote: > > Glad to have your approval!
Sorry it took so long to get it ... :( > > - Probably usb_add_hcd() should drop the IRQ handler parameter; > > everything should use the standard filter. (All existing cases > > where something else is used are wrong.) > > Okay. This means removing the other handlers too, right? There should be handlers in the hc_driver struct; delete the layer that just calls the standard filter, it's pointless! I had one in sl811 as an oversight (didn't notice till Olav cloned it in his isp116x-hcd and had a problem!), the lh7a404 should have been removed before merging, and the issue being addressed in sa1111 should be addressed elsewhere (always return IRQ_HANDLED). > > - In usb_add_hcd(), that call to the driver reset() will eventually > > need reworking. I think the "usb-handoff" stuff is probably a > > better approach for the PC BIOS initialization problems, although > > should live in the USB subtree (not the PCI quirks.c file) and > > not have a different copy of that logic. > > I agree about reset(); it doesn't really do the right thing for the way > it's used. The current implementation of the usb-handoff stuff isn't > exactly what we want either. Yeah, we didn't exactly understand what was needed until relatively recently, if then. BIOS ~== mysterious dark hole. > It should be less anxious to do a full > reset; that's needed only when we can prove that the BIOS has interfered > with the settings. Otherwise it's necessary only to prevent the device > from interrupting or doing DMA. Actually I have no problem with a full reset at that point; nobody else is supposed to be using the chip, and it's _good_ to formally stick the chip into a known state. Nothing it's doing at that point is allowed to matter, anyway... > > - I noticed that the ohci-lh7a404.c built with a warning. Probably > > worth asking Marc Singer to test-drive your patch and resolve that. > > (It's not initializing quite right ...) > > All right. This is the Marc Singer who contributes to the linux-arm list? He's the person who contributed that ohci code, and I think he also maintains the main kernel-supported boards with those chips; yes. > > - Huh, I noticed that most of the non-PCI OHCI chips claim to be > > using IO space accessors, not memory accessors. That's untrue; > > but it works because ARM doesn't have IO space. (This bug seems > > to have been cloned from the original ohci-sa1111 support.) > > I'm not sure what you mean. Their probe() functions call > request_mem_region(). See the flag I changed in that OMAP patch. It only affacts that diagnostic ... given your patch, I expected to see it tell me (wrongly) about PCI memory, and it told me about IO space! > > - The OHCI PPC bus glue will need to be updated for this. > > Development doesn't stand still! Whenever a patch takes a while to be > approved, more than likely new code will be added in the meantime that the > patch also needs to address... Yeah, and in this case the PPC glue took a long time to merge too; most of that got merged a while back, but not those last bits. > > Unfortunately we can't realistically expect all the non-PCI bus glue > > to be re-tested with 2.6.11, except for cases where the relevant board > > handles an almost-stock kernel ... which isn't as routine with embedded > > hardware as we might like, it takes time to merge enough drivers to > > the mainline kernel. So I think there may be a few issues lurking > > with some of this stuff, especially for older hardware like sa1111, > > for a while yet. But it looks basically OK. > > It wouldn't be at all surprising. I can't even test-compile those > drivers! It's easy enough to test compile them given an ARM cross-compile toolchain. I did that for the lh7a404, omap, and pxa27x support, then got tired. :) One thing you could do is grab one of the pre-built ARM toolchains, and install it in the place it expects to be installed: http://linux.omap.com/pub/toolchain/ I use the 3.4.0 one, it behaves; newer is OK too. You'll have to make two changes in your top level kernel Makefile: (a) ARCH=arm, rather than guessing it as the native one; and (b) CROSS_COMPILE = arm-linux- so that all the kernel components get built with arm-linux-gcc and the native helpers (kconfig etc) get built with normal gcc. Or if you're ambitious and patient, you could use OpenEmbedded or any of several other cross-compilation environments like buildroot or ptxdist. Probably not worth your time until you need to boot the kernel you've built, at which point having viable userspace is important. Busybox alone suffices, but most folk want a few more goodies than that. - Dave ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
