public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Shaohua Li <shaohua.li@intel.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, ambx1@neo.rr.com,
	torvalds@osdl.org, pavel@ucw.cz, hugh@veritas.com,
	linux@dominikbrodowski.net, daniel.ritz@gmx.ch,
	len.brown@intel.com
Subject: Re: revert yenta free_irq on suspend
Date: Mon, 01 Aug 2005 10:22:23 +0800	[thread overview]
Message-ID: <1122862943.3235.7.camel@linux-hp.sh.intel.com> (raw)
In-Reply-To: <20050731190645.748f57e9.akpm@osdl.org>

On Sun, 2005-07-31 at 19:06 -0700, Andrew Morton wrote:
> Shaohua Li <shaohua.li@intel.com> wrote:
> >
> > Hi,
> > > In general, I think that calling free_irq is the right behavior.
> > > Although irqs changing after suspend is rare, there are also some
> > > more serious issues.  This has been discussed in the past, and a
> > > summary is as follows:
> >
> > irqs actually isn't changed after suspend currently, it's a considering
> > for future usage like hotplug.
> > Calling free_irq actually isn't a complete ACPI issue, but ACPI requires
> > it to solve nasty 'sleep in atomic' warning.
> 
> Is that the only problem?  If so, then surely we can make free_irq() run
> happily with interrupts disabled: unlink the IRQ handler synchronously,
> defer the /proc teardown or something like that.
The problem is we are going to use ACPI interpreter with interrupt
disabled. The interpreter itself might use kmalloc, semaphore, iomap,
msleep and etc, depends on BIOS. Fixing interpreter is hard. Originally
we think to introduce a new system state for suspend/resume to avoid
warning, but later we found drivers calling pci_disable_irq/free_irq is
better and safer not just for the issue at hand. We might reconsider
previous option (a new system state) if free_irq is rejected.

Thanks,
Shaohua


  reply	other threads:[~2005-08-01  2:22 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-31 20:34 revert yenta free_irq on suspend ambx1
2005-07-31 21:20 ` Pavel Machek
2005-08-01  8:56   ` Benjamin Herrenschmidt
2005-07-31 22:55 ` Linus Torvalds
2005-07-31 23:05   ` Pavel Machek
2005-07-31 23:24     ` Linus Torvalds
2005-07-31 23:27       ` Pavel Machek
2005-07-31 23:44         ` Linus Torvalds
2005-07-31 23:59           ` Dave Airlie
2005-08-01  0:19             ` Linus Torvalds
2005-08-01  0:44               ` Dave Airlie
2005-08-01  1:07                 ` Linus Torvalds
2005-08-01  7:15                   ` Pavel Machek
2005-08-01  7:01               ` Sanjoy Mahajan
2005-08-01  7:25           ` Pavel Machek
2005-07-31 23:10   ` Dave Airlie
2005-08-01  1:59 ` Shaohua Li
2005-08-01  2:06   ` Andrew Morton
2005-08-01  2:22     ` Shaohua Li [this message]
2005-08-01  7:19     ` Pavel Machek
2005-08-01 21:38     ` Rafael J. Wysocki
  -- strict thread matches above, loose matches on Subject: below --
2005-08-01  3:03 ambx1
2005-08-01  4:53 ` Linus Torvalds
2005-08-01  8:49 ` Benjamin Herrenschmidt
2005-08-02 10:56   ` Pavel Machek
2005-08-03 11:42     ` Benjamin Herrenschmidt
2005-07-31  5:03 Brown, Len
2005-07-31  5:31 ` Linus Torvalds
2005-07-31  9:49 ` Rafael J. Wysocki
2005-07-31 22:27 ` Dave Jones
2005-08-01  0:00   ` Andreas Steinmetz
2005-08-01  0:06     ` Dave Jones
2005-08-01  0:09       ` Andreas Steinmetz
2005-08-03  9:23   ` Pavel Machek
2005-08-01  8:51 ` Matthew Garrett
2005-07-30 19:10 Hugh Dickins
2005-07-30 20:03 ` Russell King
2005-07-30 20:36   ` Linus Torvalds
2005-07-30 20:54     ` Russell King
2005-07-30 21:10       ` Linus Torvalds
2005-07-30 21:30         ` Russell King
2005-07-30 22:28         ` Rafael J. Wysocki
2005-07-31  4:49           ` Linus Torvalds
2005-08-01  9:06         ` Benjamin Herrenschmidt
2005-07-30 21:20       ` Rafael J. Wysocki
2005-07-30 20:34 ` Linus Torvalds
2005-07-31 13:29   ` Pavel Machek
2005-07-31 15:53     ` Linus Torvalds
2005-07-31 17:09       ` Linus Torvalds
2005-07-30 20:49 ` Rafael J. Wysocki
2005-07-30 21:08   ` Daniel Ritz
2005-07-30 21:32   ` Hugh Dickins
2005-07-30 22:00     ` Rafael J. Wysocki
2005-07-30 22:24       ` Hugh Dickins
2005-07-30 23:09         ` Rafael J. Wysocki
2005-07-31 20:15           ` Rafael J. Wysocki
2005-08-01 20:34             ` Hugh Dickins
2005-08-01 21:54               ` 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=1122862943.3235.7.camel@linux-hp.sh.intel.com \
    --to=shaohua.li@intel.com \
    --cc=akpm@osdl.org \
    --cc=ambx1@neo.rr.com \
    --cc=daniel.ritz@gmx.ch \
    --cc=hugh@veritas.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=pavel@ucw.cz \
    --cc=torvalds@osdl.org \
    /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