Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753412AbXHUEQk (ORCPT ); Tue, 21 Aug 2007 00:16:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750818AbXHUEQa (ORCPT ); Tue, 21 Aug 2007 00:16:30 -0400 Received: from smtp2.linux-foundation.org ([207.189.120.14]:47153 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750808AbXHUEQ3 (ORCPT ); Tue, 21 Aug 2007 00:16:29 -0400 Date: Mon, 20 Aug 2007 21:15:58 -0700 (PDT) From: Linus Torvalds To: David Brownell cc: Michal Piotrowski , linux-usb-devel@lists.sourceforge.net, Greg KH , LKML , "Stuart_Hayes@Dell.com" , Andrew Morton , Daniel Exner Subject: Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions In-Reply-To: <200708202102.58508.david-b@pacbell.net> Message-ID: References: <46C098FD.1030601@googlemail.com> <200708201841.51366.david-b@pacbell.net> <200708202102.58508.david-b@pacbell.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1629 Lines: 40 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 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/