Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264472AbTEPQFf (ORCPT ); Fri, 16 May 2003 12:05:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264473AbTEPQFf (ORCPT ); Fri, 16 May 2003 12:05:35 -0400 Received: from h-68-165-86-241.DLLATX37.covad.net ([68.165.86.241]:10803 "EHLO sol.microgate.com") by vger.kernel.org with ESMTP id S264472AbTEPQFe (ORCPT ); Fri, 16 May 2003 12:05:34 -0400 Subject: Re: Test Patch: 2.5.69 Interrupt Latency From: Paul Fulghum To: Alan Stern Cc: "linux-kernel@vger.kernel.org" , johannes@erdfelt.com, USB development list In-Reply-To: <1053100440.1948.17.camel@toshiba> References: <1053100440.1948.17.camel@toshiba> Content-Type: text/plain Organization: Message-Id: <1053101890.2606.5.camel@toshiba> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 16 May 2003 11:18:11 -0500 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 816 Lines: 25 On Fri, 2003-05-16 at 10:58, Paul Fulghum wrote: > There is also the more trivial matter of removing the > unnecessary setting of the FGR bit on wakeup. Gack! I just thought of something else: According to the 82371AB datasheet the controller itself sets the USBCMD_FGR bit when a global RD is detected. So qualifying the wakeup in software won't prevent the controller itself from starting the wakeup process on a false RD from an OC port. :-( Hmmmm.... crap Is there a way around this or are we back to preventing the suspend? -- Paul Fulghum paulkf@microgate.com - 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/