I've been trying to get musb drivers for Davinci DM365 working as modules. I can get them loading and working (on 3.0-rc7) but they don't unload properly. It seems to be some problem with the way the platform resources are claimed and released, particularly the way the same resources are used for two platform devices; the iomem resource tree gets screwed up. The resource handling seems the same for the different musb glue layers, so I don't think this is a davinci-specific problem. I have tried to test on 3.4 but that dies a horrible OOPS death the moment the modules are loaded, which I haven't looked into further. Can provide details if interested, but patches are needed to get musb loading on DM365 at all. I cherry-picked e9e8c85 "usb: musb: make modules behave better" and as far as I can see the platform resource handling is the same as in 3.4. Here's information about what I see under 3.0-rc7. I'm hoping someone (Felipe?) can give me some clues about what's going on with the platform resource handling. Sorry this is not a report against 3.4 but I haven't got that working. :/ I configure and build musb_hdrc.ko and davinci.ko. musb-davinci device with resources is added by the board, using mach-davinci/usb.c. On first "modprobe davinci", things load and work OK. Then I can rmmod davinci and it unloads. If I try to modprobe davinci again, I get root@H:/# modprobe davinci musb-hdrc: version 6.0, cppi-dma, otg (peripheral+host) musb-hdrc: failed to claim resource 0 musb-davinci musb-davinci: failed to register musb device musb-davinci: probe of musb-davinci failed with error -16 /proc/iomem is interesting: After boot, before loading any modules there is a musb region in the list: 01c64000-01c645ff : musb-davinci After loading the modules, an identical line appears (a child?), but on unloading the modules, BOTH musb-davinci lines disappear. I tweaked kernel/resource.c to also print the pointer to the resource in question: Clean boot: 01c64000-01c645ff : musb-davinci (c046c470) Module(s) loaded: 01c64000-01c645ff : musb-davinci (c23e9900) 01c64000-01c645ff : musb-davinci (c046c470) Module unloaded: (lines are gone). Note that the new copy of the resource created when adding the musb-hdrc device has ended up as the PARENT of the original allocation. That looks like a bug to me. At unload time the copy gets removed and the original allocation disappears (leaks memory?) I don't understand the platform resource code very well, but I don't see how it's supposed to make sense to assign the same resource structs to two devices; the musb-davinci glue device and the "real" musb-hdrc. I will continue to try some very ugly hacks to manipulate the iomem resource tree, but I am starting to go cross-eyed on this, hence this plea for help. Does musb as module work correctly with load/unload/reload for any of the supported glue layers, does anyone know? Happy to reciprocate with some testing/patches! Thanks, -- Jon Povey jon.povey@xxxxxxxxxxxxxxx Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
