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
next prev parent 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