Re: device_suspend() levels [was Re: [patch] ACPI work on aic7xxx]

From: Nathan Bryant (nbryant_at_optonline.net)
Date: 07/24/04

  • Next message: Jesse Barnes: "Re: [RFC] Patch for isolated scheduler domains" 
    Date:	Sat, 24 Jul 2004 11:31:53 -0400
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>

    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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Jesse Barnes: "Re: [RFC] Patch for isolated scheduler domains"

    Relevant Pages

    • Re: device_suspend() levels [was Re: [patch] ACPI work on aic7xxx]
      ... > quiesce, and then refuse to suspend if we happen to be busy. ... it's functional parent that it's going ... and any path using this low level driver must then be ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)
      ... This is my libata compatible low level driver for ... I would prefer to have it tested, before accepting this patch... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC][PATCH 2.6.13] Marvell SATA support (PIO mode)
      ... > This is the first public release of my libata compatible low level driver for ... Currently it successfully runs in PIO mode on a 6081 ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] libata queue updated
      ... whole patchset such that higher level driving logic has a say on whether a device is online or not, not the low level driver. ... It might be technically possible to set ->class directly and fix it up in high level logic, ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
      (Linux-Kernel)
    • Re: udev is too slow creating devices
      ... > But the low level driver, ... eventually the discovery will end with a call into userspace, ... enough to wait4 and wakeup a waitqueue when the wait4 returns. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)