Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264506AbTEPRDV (ORCPT ); Fri, 16 May 2003 13:03:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264508AbTEPRDV (ORCPT ); Fri, 16 May 2003 13:03:21 -0400 Received: from ida.rowland.org ([192.131.102.52]:30212 "HELO ida.rowland.org") by vger.kernel.org with SMTP id S264506AbTEPRDT (ORCPT ); Fri, 16 May 2003 13:03:19 -0400 Date: Fri, 16 May 2003 13:16:11 -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: <1053101890.2606.5.camel@toshiba> 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: 1585 Lines: 37 On 16 May 2003, Paul Fulghum wrote: > 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? It might not be that bad. What will happen is that the controller will assert FGR and interrupt the host. The driver will see the global RD, but will also see that it's present only on OC ports, so the driver will never leave the SUSPENDED state and will never write a 0 to FGR and EGSM. Hence the controller will never become active -- the wakeup won't finish. Of course, it's necessary to worry about what happens if one port is OC, so the controller is in this permanently-waking-up state, when a device is plugged into the other port. I think this will re-assert global RD and generate another interrupt. This time the driver will see that the RD is for real, so it will complete the wakeup sequence. Neither of us can easily test that, because it requires one port to be broken and the other to be working. But if everything else is okay, I think this will work too. 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/