yup. But what happens if someone removes the module whileOk, got it.
ohci_free_dma_work_fn() is still pending?
Suggestions:
- The work_struct cannot be on the stack. The code as you have it will
read gunk from the stack when the delayed work executes. The work_struct
needs to be placed into some ohci data structure which has the appropriate
lifetime. That might be struct ti_ohci. Or not.
- We'll need a flush_workqueue() in the teardown function for that dataBy saying flush_workqueue did you intend to suggest using separate work queue for ohci1394? I think that might be the way to go since otherwise ohci1394 would have to wait on all other irrelevant work elements in the global queue to be finished. This will help in solving the other problem of dma_pool_create as well - we could then schedule_work for all create_pools and just do a flush_workqueue before starting to actually use the device. (Might help in reducing those sound skips when I attach my camcorder :) Error handling has to change a good amount (right now the init function returns ENOMEM if dma_pool_create fails and all is done. With this approach of asynch alloc , init function will not know if the allocation failed / succeeded. All other functions (like say resulting from sys_read) will have to explicitly check and return error to user if the pool create had failed.)
structure to ensure that any pending callbacks have completed before we
free the storage.
Care needs to be taken to ensure that the work_struct is suitablyDidn't understand this one - Is this about properly NULL'ing elements in work queue so flush_workqueue doesn't touch them? Can you elaborate please?
initialised so that the flush_workqueue() will work OK even if the
callback has never been scheduled.
- You have several typecasts between struct pci_pool* and void*. TheseWill leave them out.
defeat typechecking. It's better to leave these casts out.