From: Arjan van de Ven <arjanv@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Jeff Garzik <jgarzik@mandrakesoft.com>,
Anders Gustafsson <andersg@0x63.nu>,
arjanv@redhat.com, linux-kernel@vger.kernel.org, mochel@osdl.org
Subject: Re: [PATCH] devexit fixes in i82092.c
Date: Sat, 16 Mar 2002 04:40:53 -0500 [thread overview]
Message-ID: <20020316044053.A11660@devserv.devel.redhat.com> (raw)
In-Reply-To: <3C92AD1F.30909@mandrakesoft.com> <Pine.LNX.4.33.0203152339200.31551-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.33.0203152339200.31551-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Fri, Mar 15, 2002 at 11:40:30PM -0800
On Fri, Mar 15, 2002 at 11:40:30PM -0800, Linus Torvalds wrote:
>
> On Fri, 15 Mar 2002, Jeff Garzik wrote:
> >
> > I wonder if mochel already code for this, or has thought about this...
> > Just like suspend, IMO we ideally should use the device tree to
> > shutdown the system, agreed?
>
> Ideally we should, yes. Although if we really turn off power, it doesn't
> much matter.
It kind of does for warm reboots. I'm getting more and more reports that
on warm reboot, the bios then can't boot again because we left some
hardware (usually the scsi or ide controller) in a state the bios didn't expect.
While I consider it a bios duty to reset the hw, using the device-tree for
clean shutdown of hardware at least would allow us to make it work.
> This is what I want. Those reboot/shutdown notifiers are completely and
> utterly buggy, and cannot sanely handle any kind of device hierarchy.
Device owned notifiers could indeed go; the question is if
non-device owned ones (the only purpose of those would
probably cluster filesystems) should make a "fake" device or
keep using the current mechanism.
Greetings,
Arjan van de Ven
next prev parent reply other threads:[~2002-03-16 9:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-16 0:57 [PATCH] devexit fixes in i82092.c Anders Gustafsson
2002-03-16 1:00 ` Linus Torvalds
2002-03-16 2:25 ` Jeff Garzik
2002-03-16 7:40 ` Linus Torvalds
2002-03-16 7:51 ` Keith Owens
2002-03-16 8:13 ` Linus Torvalds
2002-03-16 9:00 ` Jeff Garzik
2002-03-16 9:50 ` Keith Owens
2002-03-25 19:15 ` Patrick Mochel
2002-03-16 8:51 ` Jeff Garzik
2002-03-16 17:35 ` Alan Cox
2002-03-16 17:31 ` Jeff Garzik
2002-03-25 19:19 ` Patrick Mochel
2002-03-16 9:40 ` Arjan van de Ven [this message]
2002-03-22 15:47 ` Pavel Machek
2002-03-16 10:32 ` David Woodhouse
2002-03-16 19:27 ` Eric W. Biederman
2002-03-16 21:00 ` Alan Cox
2002-03-16 22:03 ` Eric W. Biederman
2002-03-16 22:28 ` Alan Cox
2002-03-16 22:16 ` Eric W. Biederman
2002-03-16 22:26 ` Linus Torvalds
2002-03-16 23:00 ` Eric W. Biederman
2002-03-16 23:15 ` Dave Jones
2002-03-21 15:12 ` Pavel Machek
2002-03-25 19:02 ` Patrick Mochel
-- strict thread matches above, loose matches on Subject: below --
2002-03-24 23:36 Alexander Stohr
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=20020316044053.A11660@devserv.devel.redhat.com \
--to=arjanv@redhat.com \
--cc=andersg@0x63.nu \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
--cc=torvalds@transmeta.com \
/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