From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jesse Barnes <jesse.barnes@intel.com>,
Andreas Schwab <schwab@suse.de>, Len Brown <lenb@kernel.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: PCI PM: Restore standard config registers of all devices early
Date: Mon, 2 Feb 2009 15:59:44 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.0902021551050.3247@localhost.localdomain> (raw)
In-Reply-To: <200902030045.19416.rjw@sisk.pl>
On Tue, 3 Feb 2009, Rafael J. Wysocki wrote:
>
> So, perhaps we can just loop over the interrupt links and disable them all
> at this point?
Well, we could, but I think it's actually inferior. Why? Because timer
interrupts can come over those too.
So we're really better off just looping over our own software irq_desc
arrays. That has the feature that
(a) we can easily mark the individual irqs if we want to - in ways that
we can never do if we end up looping over some hardware concept like
the IO-APIC inputs.
IOW, we can easily add a magic flag for registering a timer
interrupt (in fact, I guess we already have IRQF_TIMER), but we can
also expand on this in the future with other purely software
interrupt flags - ie a driver that knows it is irq-safe could just
tell us so, and we wouldn't need to disable that irq if there are
only irq-safe drivers registered on it.
(b) it's portable, and handles re-sending the interrupts correctly
(unlike just turning the interrupts off), and doesn't have any issues
with worrying about polarity etc complicating issues.
Looping over the irq links is really quite hard. Sure, we can do the
ACPI thing, but that's platform-specific, _and_ it's not actually
guaranteed to hit everything anyway (ie it likely only disables the
mapped ones, not necessarily at all directly connected ones - IDE
and USB tend to be direct irq's because they are often on the same
chip as the irq controller).
> > @@ -1419,7 +1419,7 @@ int pci_restore_standard_config(struct pci_dev *dev)
> > - dev->current_state = PCI_D0;
> > + pci_update_current_state(dev, PCI_D0);
>
> Good idea anyway.
Yeah, it probably makes sense to do this regardless of any PPC issues.
Exactly because we don't call the platform code.
> Or perhaps put
>
> current_state = PCI_UNKNOWN;
>
> under that 'if (machine_is(powermac))' ?
Yes. That would be ok, but in _theory_ ACPI could hit the same thing, and
then the pci_restore_standard_config() really needs to do that anyway.
Linus
next prev parent reply other threads:[~2009-02-03 0:00 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200901261904.n0QJ4Q9c016709@hera.kernel.org>
2009-02-02 9:54 ` Benjamin Herrenschmidt
2009-02-02 17:06 ` Linus Torvalds
2009-02-02 20:29 ` Benjamin Herrenschmidt
2009-02-02 20:41 ` Linus Torvalds
2009-02-02 21:00 ` Benjamin Herrenschmidt
2009-02-02 21:32 ` Rafael J. Wysocki
2009-02-02 20:33 ` Benjamin Herrenschmidt
2009-02-02 20:50 ` Linus Torvalds
2009-02-02 20:55 ` Linus Torvalds
2009-02-02 21:19 ` Benjamin Herrenschmidt
2009-02-02 21:39 ` Rafael J. Wysocki
2009-02-02 22:05 ` Linus Torvalds
2009-02-02 22:09 ` Linus Torvalds
2009-02-02 22:31 ` Rafael J. Wysocki
2009-02-02 23:18 ` Linus Torvalds
2009-02-02 23:45 ` Rafael J. Wysocki
2009-02-02 23:59 ` Linus Torvalds [this message]
2009-02-03 0:15 ` Rafael J. Wysocki
2009-02-03 0:28 ` Linus Torvalds
2009-02-03 1:12 ` Benjamin Herrenschmidt
2009-02-03 1:32 ` Linus Torvalds
2009-02-03 1:46 ` Benjamin Herrenschmidt
2009-02-03 3:30 ` Benjamin Herrenschmidt
2009-02-03 3:47 ` Linus Torvalds
2009-02-03 4:03 ` Benjamin Herrenschmidt
2009-02-03 6:07 ` Benjamin Herrenschmidt
2009-02-03 15:48 ` Linus Torvalds
2009-02-03 22:59 ` Benjamin Herrenschmidt
2009-02-03 23:23 ` Rafael J. Wysocki
2009-02-03 16:33 ` Jesse Barnes
2009-02-03 0:15 ` Linus Torvalds
2009-02-03 0:58 ` Benjamin Herrenschmidt
2009-02-03 3:51 ` Benjamin Herrenschmidt
2009-02-03 3:55 ` Benjamin Herrenschmidt
2009-02-03 4:09 ` Linus Torvalds
2009-02-03 4:21 ` Benjamin Herrenschmidt
2009-02-03 9:26 ` Rafael J. Wysocki
2009-02-03 17:04 ` Reworking suspend-resume sequence (was: Re: PCI PM: Restore standard config registers of all devices early) Rafael J. Wysocki
2009-02-03 17:59 ` Linus Torvalds
2009-02-03 18:31 ` Linus Torvalds
2009-02-03 18:41 ` Ingo Molnar
2009-02-03 18:32 ` Jesse Barnes
2009-02-03 18:46 ` Linus Torvalds
2009-02-03 19:03 ` Linus Torvalds
2009-02-03 19:13 ` Ingo Molnar
2009-02-03 19:38 ` Linus Torvalds
2009-02-03 19:53 ` Ingo Molnar
2009-02-03 20:04 ` Ingo Molnar
2009-02-03 20:18 ` Linus Torvalds
2009-02-03 20:57 ` Ingo Molnar
2009-02-03 21:04 ` Ingo Molnar
2009-02-03 21:12 ` Thomas Gleixner
2009-02-04 10:07 ` Russell King
2009-02-03 21:18 ` Linus Torvalds
2009-02-03 19:19 ` Linus Torvalds
2009-02-03 21:11 ` Benjamin Herrenschmidt
2009-02-03 21:53 ` Rafael J. Wysocki
2009-02-03 22:33 ` Benjamin Herrenschmidt
2009-02-03 22:44 ` Rafael J. Wysocki
2009-02-03 23:05 ` Benjamin Herrenschmidt
2009-02-03 23:18 ` Linus Torvalds
2009-02-04 0:27 ` Benjamin Herrenschmidt
2009-03-04 8:02 ` Pavel Machek
2009-03-04 23:25 ` Benjamin Herrenschmidt
2009-03-05 8:19 ` Pavel Machek
2009-03-05 19:09 ` Rafael J. Wysocki
2009-02-03 23:25 ` Rafael J. Wysocki
2009-02-04 0:46 ` Linus Torvalds
2009-02-03 21:02 ` Benjamin Herrenschmidt
2009-02-03 21:56 ` Rafael J. Wysocki
2009-02-03 17:53 ` PCI PM: Restore standard config registers of all devices early Linus Torvalds
2009-02-03 21:57 ` Rafael J. Wysocki
2009-02-02 22:48 ` Benjamin Herrenschmidt
2009-02-02 23:00 ` Rafael J. Wysocki
2009-02-03 0:23 ` Benjamin Herrenschmidt
2009-02-03 0:29 ` Rafael J. Wysocki
2009-02-03 0:44 ` Linus Torvalds
2009-02-03 1:32 ` Benjamin Herrenschmidt
2009-02-03 5:06 ` Ingo Molnar
2009-02-03 11:06 ` Peter Zijlstra
2009-02-03 12:09 ` Ingo Molnar
2009-02-02 23:49 ` Ingo Molnar
2009-02-03 22:09 ` Rafael J. Wysocki
2009-02-03 23:13 ` Linus Torvalds
2009-02-02 22:28 ` Benjamin Herrenschmidt
2009-02-02 21:07 ` Benjamin Herrenschmidt
2009-02-02 21:49 ` Rafael J. Wysocki
2009-02-02 22:15 ` Linus Torvalds
2009-02-02 22:33 ` Rafael J. Wysocki
2009-02-02 22:56 ` Rafael J. Wysocki
2009-02-03 0:11 ` Benjamin Herrenschmidt
2009-02-03 0:21 ` Linus Torvalds
2009-02-10 20:25 ` Pavel Machek
2009-02-02 22:57 ` Benjamin Herrenschmidt
2009-02-02 23:22 ` Rafael J. Wysocki
2009-02-03 1:03 ` Benjamin Herrenschmidt
2009-02-10 20:25 ` kmalloc during suspend, was " Pavel Machek
2009-02-02 17:20 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.0902021551050.3247@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=jesse.barnes@intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rjw@sisk.pl \
--cc=schwab@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome