[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.01.0910301335570.31845@localhost.localdomain>
Date: Fri, 30 Oct 2009 13:40:23 -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:
> On Friday 30 October 2009, Linus Torvalds wrote:
> > 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,
>
> Well, there's nothing wrong with doing the PCI stuff and restoring the state at
> the _noirq stage IMO, so instead of reverting it altogether, I'd add
> yenta_dev_suspend|resume() that would just call
> pcmcia_socket_dev_suspend|resume() during "regular" suspend|resume.
Oh, that sounds fine too. I didn't mean that we had to do an outright
revert, since we'd still need to do something else to fix the original
issue.
> > 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.
>
> In fact I thought about that.
>
> It looks like I need to find a CardBus adapter somewhere and clean that thing up.
>
> That said, I'd really like to know what's going on in there. :-)
I have to admit that my last two laptops haven't even _had_ a PCMCIA slot,
so I'm unlikely to be able to help much. But I could dig out an old one,
and try to find the one wireless card I know I have in some corner.
And partly exactly _because_ even Cardbus is starting to be "legacy", I'd
personally prefer to try to simplify the model to the point where we don't
have to think about all the subtle interactions. Just making suspend act
as an eject would mean that we'd never have to worry about how the CardBus
bridge interacts with the PCI layer at suspend/resume time.
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