public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-usb-devel@lists.sourceforge.net
Cc: Pavel Machek <pavel@ucw.cz>, Greg KH <greg@kroah.com>,
	Amit Gud <gud@eth.net>, Alan Stern <stern@rowland.harvard.edu>,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	akpm@osdl.org, jgarzik@pobox.com, cramerj@intel.com
Subject: Re: [linux-usb-devel] Re: [PATCH] PCI: Add pci shutdown ability
Date: Mon, 25 Apr 2005 14:13:21 -0700	[thread overview]
Message-ID: <200504251413.21996.david-b@pacbell.net> (raw)
In-Reply-To: <20050425204207.GA23724@elf.ucw.cz>

> > So here's a patch for the PCI core that allows pci drivers to now just
> > add a "shutdown" notifier function that will be called when the system
> > is being shutdown.  It happens just after the reboot notifier happens,
> > and it should happen in the proper device tree order, so everyone should
> > be happy.

Both kexec and sys_shutdown always call notifiers first, then the
device shutdown stuff, as I understand.  (I didn't see the patch,
so I don't know what it should do...)

If there's going to be a "shutdown" primitive, I certainly think
that it should work for PCI devices.

There's a separate issue about needing to clone such stuff into
every version of bus glue.  For example, OHCI runs on PCI ... but
also on lots of non-PCI hardware.  It's actually cleaner to use
a notifier than to write almost-identical shutdown methods for
each different bus it may be glued to.  Same thing with EHCI;
other bus-neutral register APIs will have the same issue.


> > Any objections to this patch?
> 
> Yes.
> 
> I believe it should just do suspend(PMSG_SUSPEND) before system
> shutdown. If you think distintion between shutdown and suspend is
> important (I am not 100% convinced it is), we can just add flag
> saying "this is system shutdown".

I've made that point before -- essentially that shutdown() in
the driver model itself is superfluous, either remove() or
maybe suspend() would achieve the same result, without adding
any special code that's run/tested rather infrequently ...

That is:  if shutdown() isn't going to be removed, then the
code that shuts down devices should invoke remove() or even
suspend() in cases that there's no shutdown() method.

But the pushback was that shutdown() methods are allowed to
be much lighter weight, and really ought to work even when
big parts of the system are misbehaving.  So they'd just do
stuff like resetting chips, sanitizing GPIOs, and so on ...
and nothing that'd be likely to break if significant parts
of kernel memory were corrupted.

- Dave



  parent reply	other threads:[~2005-04-25 21:16 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.44L0.0504251128070.5751-100000@iolanthe.rowland.org>
     [not found] ` <SVLXCHCON1syWVLEFN00000099e@SVLXCHCON1.enterprise.veritas.com>
     [not found]   ` <20050425182951.GA23209@kroah.com>
     [not found]     ` <20050425185113.GC23209@kroah.com>
2005-04-25 19:06       ` [PATCH] PCI: Add pci shutdown ability Greg KH
2005-04-25 19:23         ` Jeff Garzik
2005-04-25 20:07           ` Greg KH
2005-04-25 20:11           ` Adam Belay
2005-04-25 19:45         ` Alexander Nyberg
2005-04-25 20:12           ` Greg KH
2005-04-26  3:59             ` Benjamin Herrenschmidt
2005-04-25 20:14           ` Alan Stern
2005-04-25 20:52             ` Alexander Nyberg
2005-04-25 21:12               ` Alan Stern
2005-04-26 15:49                 ` Grant Grundler
2005-04-26 16:04                   ` Alan Stern
2005-04-26 16:37                     ` Grant Grundler
2005-04-26 17:14                       ` Alan Stern
2005-04-26 17:41                         ` Grant Grundler
2005-05-11  5:33                 ` Vivek Goyal
2005-05-11 14:38                   ` Alan Stern
2005-04-25 21:58             ` Andrew Morton
2005-04-25 22:13               ` Dave Jones
2005-04-25 23:23                 ` Adam Belay
2005-04-26  4:32                   ` Benjamin Herrenschmidt
2005-04-26  6:23                     ` Adam Belay
2005-04-26  7:14                       ` [linux-pm] " Nigel Cunningham
2005-04-26  9:16                       ` Pavel Machek
2005-04-26  9:41                   ` Pavel Machek
2005-04-26  3:52                 ` Benjamin Herrenschmidt
2005-04-26 15:14                   ` Alan Stern
2005-04-26  9:39                 ` Pavel Machek
2005-04-26 17:50                   ` Dave Jones
2005-04-26 20:23                     ` Pavel Machek
2005-04-26  3:45               ` Benjamin Herrenschmidt
2005-04-26 15:11               ` Alan Stern
2005-04-26 16:01                 ` Alexander Nyberg
2005-04-26 15:41             ` Grant Grundler
2005-04-26 16:07               ` Richard B. Johnson
2005-04-26 16:19                 ` Grant Grundler
2005-04-26 17:12                   ` Alan Stern
2005-04-26 17:19                     ` Lee Revell
2005-04-25 20:08         ` Adam Belay
2005-04-25 20:19           ` Greg KH
2005-04-25 20:24             ` Adam Belay
2005-04-25 20:42         ` Pavel Machek
2005-04-25 20:55           ` Adam Belay
2005-04-25 21:06             ` Pavel Machek
2005-04-26  4:30               ` Benjamin Herrenschmidt
2005-04-26 16:12                 ` Grant Grundler
2005-04-26 13:44               ` [linux-usb-devel] " David Brownell
2005-04-26 21:15                 ` Pavel Machek
2005-04-25 21:00           ` Greg KH
2005-04-25 21:13             ` Pavel Machek
2005-04-26  3:41             ` Benjamin Herrenschmidt
2005-04-26 10:11               ` Pavel Machek
2005-04-25 21:13           ` David Brownell [this message]
2005-04-26  3:39           ` [linux-usb-devel] " Benjamin Herrenschmidt
2005-04-26  6:33             ` Adam Belay
2005-04-26  6:44               ` Greg KH

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=200504251413.21996.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@osdl.org \
    --cc=cramerj@intel.com \
    --cc=greg@kroah.com \
    --cc=gud@eth.net \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=pavel@ucw.cz \
    --cc=stern@rowland.harvard.edu \
    /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