Seems like a UHCI-specific expectation, so it's UHCI that should
be adding the extra reference count. (Rather than breaking the
other HCDs, which just rely on the URB having a valid device ptr.)
If they make that assumption too, then they should be using reference
counting too.
They don't make that assumption (don't reference devices that way),
so they don't need to. So that change should be UHCI-specific.
I don't think setting dev->bus to NULL is the right way, simply because
the bandwidth is not available to the rest of the system until all of
the URBs have been fully removed. To handle the bandwidth correctly, we
need that pointer to the end.
I think it's the best way in the current system to flag a device that's
gone. The whole of usbcore already checks for null pointers, and it's
a classic solution. DEVICE_GONE in <linux/device.h> enum device_state
doesn't seem to help, and needs a more solid backup anyway.
But with reference counting, NULL pointers aren't really needed. Just
keep the proper reference count.
It's not "just" that ... but if it were, then surely having those
unusable pointers become null could not matter, right? Since no
non-erroneous code would ever be using them. :)
2.4 used NULL pointers to denote things like the URB is done which is
kinda wacky.
The problem was that 2.4 has very fuzzy notions of "done". Like in
particular the automagic resubmissions, and unlink-before-automagic
cases. "usb-uhci" did more than its fair share of oopsing, and there
was no other way (at that time) to dis-entangle the various states.
Since 2.5 has a much cleaner notion of "done" -- URB given back to the
device driver, HCD is completely finished -- that issue doesn't come
up any more.
I'm really surprised that usb-ohci.c still gets this wrong in 2.4, even
after our "discussion" months ago.
Considering that discussion was about 2.5, I'm not at all surprised that
the 2.4 code didn't change. (Except for the historical digression, where
I pointed out that the original bus->op->deallocate logic, in 2.2.early,
was designed to work exactly as I described; so the bug crept in later.)
What surprises me is that you have such strong opinions about methods
that your UHCI code doesn't use, and have been so "reluctant" to recognize
the problems which came from the approach you've pushed.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
