On Fri, 23 Sep 2005, Andy Chuo wrote:
> Hi alan,
> Ok here's the revised version:
> static void /*__exit or __init? */ __exit cleanup(void)
> {
> struct socle_lp2a_udc *dev = the_controller;
>
> if (!dev)
> return;
>
> udc_disable(dev);
> remove_proc_files();
> usb_gadget_unregister_driver(dev->driver);
> if (dev->got_irq) {
> free_irq(INO_UDC, dev);
> dev->got_irq = 0;
> }
>
> the_controller = 0;
> release_mem_region(REGISTER_FIRST, REGISTER_LENGTH);
> }
> module_exit (cleanup);
>
> static int __init init (void)
> {
> struct socle_lp2a_udc *dev;
> int retval;
>
> INFO(KERN_DEBUG "%s: version %s\n", driver_name, DRIVER_VERSION);
>
> /* allocate resources */
> if (!request_mem_region(REGISTER_FIRST, REGISTER_LENGTH,
> driver_name))
> //return -EBUSY;
> goto failed;
>
> /* initialize data */
> dev = &memory;
>
> the_controller = dev;
> udc_reinit(dev);
>
> /* irq setup after old hardware state is cleaned up */
> retval = request_irq(INO_UDC, socle_lp2a_udc_irq,
> SA_INTERRUPT, driver_name, dev);
> if (retval != 0) {
> printk(KERN_ERR "%s: can't get irq %i, err %d\n",
> driver_name, INO_UDC, retval);
> goto failed;
> }
> dev->got_irq = 1;
>
> dev->setup_countdown = DEFAULT_SETUP_COUNT;
>
> INFO("socle udc got irq\n");
>
> create_proc_files();
>
> failed:
> cleanup();
> return 0;
> }
> module_init (init);
In general, your cleanup routine wants to undo the effects of the init
routine. That means doing everything backwards, in the reverse order.
So cleanup should start by removing the proc files, then release the irq,
call udc_disable, and finally release the memory region. And of course,
it should unregister the gadget driver first thing, since the driver gets
registered _after_ the init routine runs.
> I actually did. I monitored the /proc/interrupt and /proc/iomem when before
> insmod, after insmod and rmmod. No activities under both /proc entries at
> all.
That makes it sound like your init routine didn't run. Do you see the
output from the INFO lines in the system log? What else shows up in the
log?
> What's the major difference between loading the module during system boots
> and insmod after the system boots? Both using the same kinda init() and
> exit() function right? Making the module built-in and loading it during the
> system boots works perfect for me (both registered irq and requested iomem)
> but insmod just don't do me any good.
What do you mean, loading it during the system boot? That's just running
insmod, right? So why do you say that insmod doesn't do any good? And
why do you say that nothing showed up in /proc/interrupt?
> Anything I need to be aware of when compiling the source? What I did was
> just simply copy the my_udc.o file off the driver/usb/gadget folder which
> was compiled by the make command from the source root directory. Then I
> compiled the kernel with my UDC driver set to <M> as well as the gadget zero
> set to <M> in the menuconfig. After loading the kernel, system boots, NFS
> mounted, then I just do the insmod for myudc.o as usual. But again.. failed.
> I mean it was inserted but again, no entries under /proc/interrupts and
> /proc/iomem.
What appeared in the system log?
If your module is able to run correctly at all, you're probably building
it the right way.
Alan Stern
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
