On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > > > For example, device
> > > > > > drivers that hang on to references after their disconnect()
> > > > > > methods complete. (Which can make "rmmod" break, for
> > > > > > example completion callbacks going to where the module
> > > > > > used to be loaded.)
> > ...
> >
> > No, I think this should be allowed.
>
> Surely you didn't mean rmmod oopses? I think you're saying
> that you're OK with some kind of new "zombie" device state
> in such cases, but not the behavior found in Johannes' patch
> (which allows oopses by calling into recycled memory).
Of course it can allow for that happen, but only for drivers which are
buggy. It's not implicit in the use of the patch.
> > > The HCD is most _certainly_ allowed to block when cleaning up
> > > device state. Every device management API I've had reason to
> > > look at in Linux guarantees that the the "clean up after this device"
> > > call can block.
> > >
> > > I don't care at all about the memory management, except that as I
> > > said elsewhere, I can't see any case where the device memory
> > > should reasonably be kept around after the cleanup call is made.
> >
> > Ok, a BUG() call if in_interrupt() is ok with you?
>
> Not really, since those avoidable BUG() calls would be
> appearing at non-reproducible times. That's a clear
> step backwards.
>
> I just proposed an even simpler solution, moving the
> call to dev->bus->op->deallocate(dev) call out of
> the memory management path entirely, and put it at
> the end of the usb_disconnect() code. (Which is
> where it's now firing for everything except "uhci",
> which isn't happy with 2.5.15.)
>
> Then there'd be no BUG() checks at all, and the only
> substantive change of Johannes' patch is to formalize
> (partially :) this new "zombie device" state so that
> "uhci.c" can provide/use it. (Or so that buggy device
> drivers can leave devices in that state.)
So you don't like changing how to do things? I'm trying to understand
what the argument is in here.
It makes little difference to me where deallocate() is called
If you really need it in a thread context, do it in usb_disconnect()
Looking at the code for usb-ohci right now, it looks like ohci_free_dev
could be reduced down to this:
static int sohci_free_dev (struct usb_device * usb_dev)
{
struct ohci_device * dev = usb_to_ohci (usb_dev);
ohci_t * ohci = usb_dev->bus->hcpriv;
pci_pool_free (ohci->dev_cache, dev, dev->dma);
return 0;
}
Which doesn't need to block.
Why does it need to be called in thread context?
JE
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
