> > OK, as promised: here's an updated version, split into two patches, > > which I'd like you to test. > > I tested the patch and there are some issues.
Testing will find those sometimes ... :) > From a quick glance it seems that the data/addr resources are requested > twice, both in sl811_cs via platform_device_register() and then in the > probe function of the hcd driver but the release order is different, The release order of those resources doesn't matter; they're independent of each other. And don't confuse "request" with "register" ... if you look at /proc/iomem on a PC you'll see the same sort of effect, where the BAR allocated to a PCI device is registered (often as a child of the relevant bus) and then a driver requests it. If two drivers request the same resource, that'd be a bug, detectable by the second one not succeeding. Resources are branches in a tree. > sl811h_remove is called after cs_release and this causes some trouble: > > kernel: sl811_cs: sl811_cs_release(0xc3c30160) > kernel: Badness in __release_resource at kernel/resource.c:184 > kernel: [<c003dbf4>] (release_resource+0x0/0xd8) from [<c012e8f8>] > (platform_device_unregister+0x60/0x6c) ... > kernel: Trying to free nonexistent resource <c4860001-c4860001> > kernel: Trying to free nonexistent resource <c4860000-c4860000> Well, that does look bad. I suspect the problem is really just that platform_device_unregister() should be called before the pcmcia_release_configuration() call ... That wasn't something I could test, I keep ending up with busybox versions that refuse to support the 2.6 style modutils. (Probably related to the way it hasn't finished removing kernel dependencies, as with "bridge" and "pcmcia" components; and the way the various 2.6-ish vs 2.4-ish things aren't all coupled to that global "which kernel headers" switch. Or uClibc bugs.) > Is the resource requisition necessary in both modules? If it isn't, using > device_register() instead of platform_device register() might eliminate > the problem. Best not to play that particular game IMO; but in this case there really _is_ only one place the resource is allocated. And I think the issue there is that the platform device isn't getting unregistered at the right spot. > The second issue is some irq problem that the new changes in sl811-hcd.c > introduced. > When plugging in a usb device, it is recognized only after a few seconds > of delay and unplugging goes unnoticed frequently, resulting in various > errors. See the attached log snippet. That's pretty wierd. Maybe one of the relevant boards is wiring the IRQ line up through an inverter or FPGA or something, and others aren't. (I saw that recently with smc91x ...) How does IRQT_FALLING act? > I'll investigate these issues a bit further. Thanks. These "doesn't work on _my_ hardware" issues always work a lot better when the person with the hardware has skills to debug them directly ... :) - Dave ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
