Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264138AbTEOR6z (ORCPT ); Thu, 15 May 2003 13:58:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264139AbTEOR6z (ORCPT ); Thu, 15 May 2003 13:58:55 -0400 Received: from ida.rowland.org ([192.131.102.52]:31492 "HELO ida.rowland.org") by vger.kernel.org with SMTP id S264138AbTEOR6y (ORCPT ); Thu, 15 May 2003 13:58:54 -0400 Date: Thu, 15 May 2003 14:11:44 -0400 (EDT) From: Alan Stern X-X-Sender: stern@ida.rowland.org To: Paul Fulghum cc: Greg KH , Andrew Morton , "linux-kernel@vger.kernel.org" , Arnd Bergmann , , USB development list Subject: Re: Test Patch: 2.5.69 Interrupt Latency In-Reply-To: <1053012368.2026.6.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: 1911 Lines: 47 On 15 May 2003, Paul Fulghum wrote: > I think I found the key to this whole problem: > > Note:I mistakenly referred to the chipset as PIIX3 > in previous messages, in fact it is the PIIX4 (BX) > > The PIIX4 errata states that false resume indications > can be generated if CLK48 is active during an > overcondition indication (OC[1..0]). > > Sure enough, the USBPORTSC[12] registers constantly > report a status of 0C80 which shows that both > ports are showing overcurrent condition (which > disables the associated port). > > My guess is that HP deliberately tied the OC[1..0] > inputs active to force the ports to a disabled state. > > So checking for the case of both ports constantly > in OC condition and disabled may be a reasonable > way to either disable the controller altogether or > at least not do the wakeup/suspend shuffle. > > Any comments? That sounds like a believable explanation. My copy of the generic UHCI specification does not include the OC port status bits. I'm guessing from your mail they are either bit 10 or bit 11 of the PORTSC registers, can't tell which. Maybe they are an Intel-specific addition? Or perhaps a more recent version of the spec has more information -- the one I've got is 1.1 (March 1996). Can you suggest a good way of detecting whether or not a controller is part of a PIIX4 chipset, to indicate whether or not the OC bits are valid? Maybe the PCI vendor and product codes will have that information? I'm not sure it's safe to assume that any old host controller will have meaningful values there; the spec just says "reserved" and doesn't stipulate that they will always read as 0's. 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/