>>usb-ohci.c: bogus NDP=255 for OHCI usb - 09:00.1
>>(the above two statements are repeated ~4x's)
And the OHCI driver hits a related problem too ...
> IMHO sequence in cs driver should be reverted - it is not polite to remove
> hardware before giving driver a chance to cleanup :-)
Yes, absolutely. It's turning a "clean shutdown" scenario into a
"dirty shutdown" ... a normal "rmmod" works, correctly, and from the
perspective of a device driver (if not the CardBus code) those should
be exactly the same: two ways to start the same driver shutdown.
That current sequence (powerdown before pci_dev->remove) violates the
device tree sequencing requirement ... which I recall was one of the
key features of the original 2.4 CardBus support. Did it change rather
recently, or has this bug really been lurking for a very long time?
I'd expect to have heard about that OHCI problem (seemingly the same root
cause) before, since there are folk using Cardbus OHCI (more using EHCI!),
but nobody's reported it that I know of.
I'll hope that problem appears only in 2.4.18-6mdk, and isn't found in
other kernels. In particular, if it's in 2.5.17 then there's a big
hole in the "new driver model" work (struct device etc)!
>
Irrespectively,
> endless loop in ehci_stop does not look nice.
I partially agree. For a clean shutdown, it's guaranteed not to be
endless. For a dirty shutdown -- physically ejecting the card, or
the hardware having truly nasty failure mode (one I've not seen but
which could conceivably happen) -- it's a problem to fix.
Is there a clean way to detect the "card ejected before anything calls
pci_dev->remove()" case? I don't really like the idea of wrapping code
around every PCI register access to detect such cases.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/