I couldn't trace that down to be 100% sure and it's better to conform to
design than implementation, so I'll ask:
Do the probe and remove functions of a pci_driver have to be able to
work in interrupt context? (i.e. GFP_ATOMIC and stuff)
I expect so, since CardBus handling doesn't start a thread and would
call these functions from the context it got the insertion message
(interrupt context).
--
Andreas E. Bombe <[email protected]> DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/
Andreas Bombe wrote:
>
> I couldn't trace that down to be 100% sure and it's better to conform to
> design than implementation, so I'll ask:
>
> Do the probe and remove functions of a pci_driver have to be able to
> work in interrupt context? (i.e. GFP_ATOMIC and stuff)
No, no interrupt context to worry about. It would really suck if you
couldn't sleep in pci_driver::probe :)
For CardBus, it calls schedule_task ..
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
On Sun, Mar 11, 2001 at 10:18:18PM -0500, Jeff Garzik wrote:
> Andreas Bombe wrote:
> >
> > I couldn't trace that down to be 100% sure and it's better to conform to
> > design than implementation, so I'll ask:
> >
> > Do the probe and remove functions of a pci_driver have to be able to
> > work in interrupt context? (i.e. GFP_ATOMIC and stuff)
>
> No, no interrupt context to worry about. It would really suck if you
> couldn't sleep in pci_driver::probe :)
Very good. I wasn't sure since I saw GFP_ATOMIC allocations somewhere
in the cardbus code which looked like it was in card initialization.
But it's also confusing and somewhere was a note saying that some of
this is obsolete code which is replaced elsewhere...
> For CardBus, it calls schedule_task ..
Another thing learned, thanks.
--
Andreas E. Bombe <[email protected]> DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/