Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264265AbTEOVBA (ORCPT ); Thu, 15 May 2003 17:01:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264266AbTEOVBA (ORCPT ); Thu, 15 May 2003 17:01:00 -0400 Received: from ida.rowland.org ([192.131.102.52]:7940 "HELO ida.rowland.org") by vger.kernel.org with SMTP id S264265AbTEOVA7 (ORCPT ); Thu, 15 May 2003 17:00:59 -0400 Date: Thu, 15 May 2003 17:13:40 -0400 (EDT) From: Alan Stern X-X-Sender: stern@ida.rowland.org To: Paul Fulghum cc: "linux-kernel@vger.kernel.org" , , USB development list Subject: Re: Test Patch: 2.5.69 Interrupt Latency In-Reply-To: <1053027740.2095.44.camel@diemos> Message-ID: 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: 1137 Lines: 30 On 15 May 2003, Paul Fulghum wrote: > The erratum is only for the PIIX4, and it is > triggered only when the OC inputs are active, > so limiting the check to that device should > be OK. > > Probably the least intrusive thing to do > is to disable suspending the uhci controller > if it is a PIIX4 *and* either port has an > over current condition. This will catch the case > of a functional USB controller that has one > or more real over current conditions and the > case of a deliberately disabled (by hardwiring > the OC inputs) controller. The erratum will > pop up in both cases causing suspend<->wake > thrashing. My intention was to avoid resuming if the resume-detect bit is set only on ports in an over-current condition, since that is the case mentioned in the erratum. Of course, this isn't as failsafe as your suggestion. Which do you think would work better? Alan Stern - 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/