Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 20 Aug 2007, David Brownell wrote:

> On Monday 13 August 2007, Michal Piotrowski wrote:
> > Subject         : EHCI Regression in 2.6.23-rc2
> > References      : http://lkml.org/lkml/2007/8/10/81
> > Last known good : ?
> > Submitter       : Daniel Exner <dex@dragonslave.de>
> > Caused-By       : Stuart_Hayes@Dell.com <Stuart_Hayes@Dell.com>
> > Â  Â  Â  Â  Â  Â  Â  Â  Â  commit 196705c9bbc03540429b0f7cf9ee35c2f928a534
> > Handled-By      : ?
> > Status          : unknown
> 
> Fixed I believe by Stuart's patch:
> 
> http://marc.info/?l=linux-usb-devel&m=118765934722610&w=2

Quite frankly, I'd personally prefer to just revert commit 
196705c9bbc03540429b0f7cf9ee35c2f928a534 entirely instead.

The whole dependency on cpufreq seems totally bogus. Would it not be a lot 
more natural to handle the *result* of the problem (ie the MMF errors by 
broken EHCI controllers?) rather than add totally insane workarounds for 
this case to try to hide them in the first place?

There can be *other* delays in reading memory that have nothing to do with 
cpu frequency shifting, and everything to do with exteme situations on the 
bus. If the stupid EHCI controller has some tight latency issues, that's a 
generic problem.

That commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 just exemplifies what 
is wrong with USB, but it does so by adding incredibly ugly code. I'd 
rather not add even *more* ugly code - especially not for a case where we 
then seem to blame the wrong party (ie a VIA controller that didn't need 
the ugly code in the first place).

Serverworks/Broadcom makes totally crap chips (not just in USB) and then 
doesn't even document their buggy crap hardware. But that is NOT a reason 
for then making the kernel have buggy crap software in it.

So really - is there any reason why we just don't say "Broadcom chips 
suck, and get MMF errors under normal circumstances because they are 
crap". And from *that*, the obvious solution would seem to not be to 
penalize everybody else, but to just say that "We will try to recover from 
MMF errors gracefully by retrying the transaction". Hmm?

			Linus
-
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/