> > > > No, a code inspection shook out the fact that it didn't even
> > > > play by the 2.4 rules, which require HCDs to clean up their
> > > > device state when bus->op->deallocate() is called.
> > >
> > > That was never a rule for 2.4. Reference counting takes care of making
> > > sure things work correctly after deallocate().
> >
> > What can I say but "news to me". It clearly did not do that in
> > more than a few cases I've had to work through.
>
> Clearly? It's always worked for me
"uhci.c" doen't even use bus->op->deallocate() ... what did
you ever do with it other than implement it as a NOP?
> You really need to take a couple of days off and revisit this. You are
> clearly missing a couple of significant points in this discussion.
I think I understand your claims, but since they don't appear to
reflect experience using bus->op->{de,}allocate() I can't give
them much credence in areas that relate to those calls.
One of the important points I certainly missed is your answer to
a question I raised, which I repeat below.
> > > > Do you mean uhci_free_dev()? The NOP? Remember that
> > > > method must be called when it can sleep ...
> > >
> > > Looking now, I don't even see why bus->op->deallocate() is necessary.
> > > OHCI doesn't even appear to need it.
> >
> > Look harder ... :) ...
>
> But if you used reference counting like it was intended that wouldn't be
> a problem.
I've described code that other people wrote, actually. It's observed
behavior, and attributing anything to me except a desire to make
all the HCDs be more consistent (so that device drivers, or usbcore,
won't be tripping over HCD-specific behaviors) is wrong.
Regardless, to the extent that you're arguing it's fine for an HCD to
keep device state around after deallocate() finishes, I've got to laugh.
And then repeat my earlier question, which you never answered:
IF deallocate() isn't supposed to get rid of device state, THEN what
is it supposed to do instead? And if that's not it's job, when DOES
that state get removed?
I've summarized my own answers there. What are yours?
> Seriously, take a look at the rest of the kernel.
What -- like pci_driver->remove() having a "called with thread context"
guarantee? And like never calling net_device->stop() in_interrupt()?
I think the precedent is clear, personally.
Although the name of that method hasn't matched its purpose (let's
avoid a flamewar on that issue) it's clear that "device going away"
calls like that are normally given guarantees that they can sleep.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
