public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nathan Bryant <nbryant@optonline.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
	Pavel Machek <pavel@ucw.cz>
Subject: Re: device_suspend() levels [was Re: [patch] ACPI work on aic7xxx]
Date: Sat, 24 Jul 2004 11:31:53 -0400	[thread overview]
Message-ID: <410280E9.5040001@optonline.net> (raw)
In-Reply-To: <1090357324.1993.15.camel@gaston>

Benjamin Herrenschmidt wrote:

>save_state is a nonsense, didn't we kill it ? queue quiescing must be
>done by the upper level, which is a bit nasty with things like md &
>multipath... basically, the low level driver must have a way to notify
>it's functional parent (as opposed to it's bus parent) that it's going
>to sleep, and any path using this low level driver must then be
>quiesced, the parent must resume only when all the drivers it relies
>on are back up.
>
Isn't sysfs supposed to take care of this for us? IOW, I shouldn't have 
to call up to the SCSI midlayer from pcidev->suspend in order to notify 
it of a suspend, the midlayer should call the driver before we ever try 
to suspend. This may become important some day when the upper layers 
need to decide which order to bring pci devices down

Looking in /sys/devices shows that sysfs already knows that 'host0' is a 
child of a SCSI PCI device.

$ ls 
/sys/devices/pci0000\:00/0000\:00\:1e.0/0000\:02\:02.0/host0/0\:0\:0\:0/
block   detach_state    model  queue_depth  rev         state    type
delete  device_blocked  power  rescan       scsi_level  timeout  vendor


  reply	other threads:[~2004-07-24 15:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <40FD38A0.3000603@optonline.net>
     [not found] ` <20040720155928.GC10921@atrey.karlin.mff.cuni.cz>
     [not found]   ` <40FD4CFA.6070603@optonline.net>
2004-07-20 17:46     ` device_suspend() levels [was Re: [patch] ACPI work on aic7xxx] Pavel Machek
2004-07-20 18:10       ` Nathan Bryant
2004-07-20 18:25         ` Benjamin Herrenschmidt
2004-07-20 18:34           ` Nathan Bryant
2004-07-20 19:10             ` Benjamin Herrenschmidt
2004-07-20 19:23               ` Pavel Machek
     [not found]               ` <40FD82B1.8030704@optonline.net>
2004-07-20 20:41                 ` Benjamin Herrenschmidt
2004-07-20 20:50                   ` Nathan Bryant
2004-07-20 21:02                     ` Benjamin Herrenschmidt
2004-07-24 15:31                       ` Nathan Bryant [this message]
2004-07-24 16:00                         ` Benjamin Herrenschmidt
2004-07-24 16:45                           ` Nathan Bryant
2004-07-24 18:35                             ` Benjamin Herrenschmidt

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=410280E9.5040001@optonline.net \
    --to=nbryant@optonline.net \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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