On Wed, 2 Feb 2005, David Brownell wrote: > > 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).
The appropriate changes will no doubt be obvious when I go over the existing code. > > 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... But it does matter when you are restarting from a system suspend. Depending on what kind of reset is performed, resetting the controller will also reset the port state-machines, thereby breaking all existing connections. When the power management API is sophisticated enough to tell us at boot time whether this is a resume or a fresh boot, we'll be able to decide properly whether to reset. > 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. I'll look into it. > 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. I'm not that ambitious. :-) And not having an ARM-based system, I wouldn't even cross-compile the entire kernel. Just the updated HCD modules. Alan Stern ------------------------------------------------------- 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
