On Mon, 20 Aug 2007, David Brownell wrote:
>
> MMF basically means the "Transaction Translating" (TT) hub had data
> for the host, but the host didn't collect it in time ... so that some
> data was lost.
>
> Unfortunately, that's the type of fault that's especially hard to
> recover from.
Fair enough. However, it still seems particularly idiotic to
- penalize everybody
- mix up two totally unrelated areas (cpufreq and USB) for a bug that is
extremely rare and could be handled differently.
For example, if it really ends up being practically impossible to recover
from split transaction errors, I would still suggest reverting that horrid
commit, and then just black-listing the known-broken EHCI controllers and
simply not *do* any split transactions on them. That way there's no
complexity.
As far as I know, split transactions aren't required anyway, they are just
a performance optimization.
Basically, we not only know that the commit has caused problems, it's
fundamentally ugly, fragile, and not very maintainable, and the whole
reason for doing it is pretty dubious.
Why not just admit that certain hardware is broken (and the vendor isn't
worth even bothering to be polite with, since they try to screw us every
chance they get) and cannot reliably do split transactions? Problem
solved, no real downside, and nobody will even *notice*.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
