Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933125AbZJ3X5g (ORCPT ); Fri, 30 Oct 2009 19:57:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933100AbZJ3X5d (ORCPT ); Fri, 30 Oct 2009 19:57:33 -0400 Received: from gate.crashing.org ([63.228.1.57]:34558 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933077AbZJ3X5c (ORCPT ); Fri, 30 Oct 2009 19:57:32 -0400 Subject: Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m From: Benjamin Herrenschmidt To: Linus Torvalds Cc: "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Greg Kroah-Hartman , Jose Marino , ACPI Devel Maling List , Linux PCI , Dominik Brodowski In-Reply-To: References: <6dRYo8ss7vL.A.EqH.Nse5KB@chimera> <200910301948.24473.rjw@sisk.pl> Content-Type: text/plain; charset="UTF-8" Date: Sat, 31 Oct 2009 10:57:21 +1100 Message-ID: <1256947041.6372.165.camel@pasglop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1641 Lines: 41 On Fri, 2009-10-30 at 12:47 -0700, Linus Torvalds wrote: > > On Fri, 30 Oct 2009, Rafael J. Wysocki wrote: > > > > > > 1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular" > > resume phase, after resume_device_irqs(). > > Hmm. We really probably shouldn't call pcmcia_socket_dev_resume() in > early_resume. It takes mutexes etc, and it calls "socket_resume()", which > sleeps etc. That per se should be ok these days (since we don't actualyl > disable CPU irq's, just device irqs), but it also does that whole card > insertion events etc. And _that_ code I wouldn't trust at all. > > The PCMCIA code is better than it used to be a long time ago, but some of > it is still pretty crazy. > > I get the feeling that we should just revert that commit 0c570cdeb, and > instead always do PCMCIA suspend as a "eject" event. That way we have no > driver behind it to resume at resume time - and we'll see any plugged-in > device as just a new insertion. To me the proper approach would be to split it so that - early_resume() restores power & config space etc... so that existing devices can move on (might check for removal). There's no other hotplug activity - normal resume() restarts handling of events such as insertions Now, while I do have some cardbus & pcmcia stuff somewhere, I also don't have much time to hack on this right now... Cheers, Ben. -- 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/