[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.01.0910301228430.31845@localhost.localdomain>
Date: Fri, 30 Oct 2009 12:47:38 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Rafael J. Wysocki" <rjw@...k.pl>
cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kernel Testers List <kernel-testers@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...e.de>,
Jose Marino <braket@...mail.com>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Linux PCI <linux-pci@...r.kernel.org>,
Dominik Brodowski <linux@...inikbrodowski.net>
Subject: Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from
2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
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.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists