The case looks pretty good now, and I'm almost ready to issue a +1, but
I have one question, which concerns the pm-capable attribute. I think
other HBAs might be using this property. Has the project team verified
that no other consumers exist? Or if the 16-th bit is not set in the
new mask value, does it behave in the old fashion?
- Garrett
Terry (Sarito) Whatley wrote:
> I'm restarting this case as a fast-track, timing out
> 7/1/09.
>
> The project team has removed all of the interfaces which
> do not have current consumers from this case.
> In particular the pm-* properties which described the
> attributes of the different power states, and the new
> argument "dip" to pm_trans_check(9F) are removed.
>
> The case now just brings the disk IO stack power
> management up to date with new transport types
> (particularly SATA).
>
> Below is a summary and some explanation to help make
> the case more obvious.
>
> Summary
>
> This case is now composed of 4 parts.
> 1. a property used to communicate between the transport layer
> and the target driver code (sd) about what support the
> device has for power management features,
> eliminating the need for the target driver to know which
> transport is being used and which commands it supports.
> 2. extend pm_trans_check(9F) support to SATA devices
> 3. a tunable used to override information that disk/transport
> HW might present;
> 4. a USCSI flag to allow power management to stop FMA from
> bringing up a power managed disk to see if it is ok.
>
> Explanation
>
> 1. target-transport communication property (pm-capable)
>
> The sd/scsa system is designed to allow the target driver (sd)
> not to have to know about the details ofthe transport used to
> control the drive (one of SCSI, SATA, SAS, FCAL, IEEEE-1394,
> USB, etc.), and the transport driver not to have to know
> the details of the target device.
>
> Unfortunately, there are several different schemes for
> identifying and controlling the power states of a disk,
> depending on the transport and the set of power states supported
> by the disk, and to provide access to information about how many
> power cycles the disk has experienced (so that they can be meted
> out over the desired lifetime of the disk and not squandered
> immediately upon putting the disk in service).
>
> In particular, for control the current options are the
> Start field of the Start Stop Unit command, and the
> Power Condition field of the Start Stop Unit command.
> For getting the start-stop history information, the options
> are check or ignore log page 0Eh, and to expect (if not
> ignored) for log page 0Eh to contain SMART attribute data
> or SCSI native log page 0Eh information.
>
> The pm-capable property is extended to communicate this
> information to the target driver.
>
> This information is needed to allow the sd driver to
> support the existing autopm framework behavior on the new
> transports.
>
> This scheme was worked out by/in collaboration with the owners of
> all of the drivers involved. While the specific values in
> this property may not be obvious to those not familiar with the
> detailed specs of the various transports, I submit that using
> a property which already conveys related information to convey
> this info rather than perturbing the scsa/sd interface is obvious.
>
>
> 2. pm_trans_check change
>
> The modification of pm_trans_check() allows for the slightly
> different flavor of information (native SCSI vs. SMART)
> provided by different transports to be used in making power
> down decisions.
>
>
> 3. tunable
>
> Sometimes the firmware is buggy and lies about the capabilities
> of the device. The "power-condition" tunable allows a way to
> override the information presented by firmware for a specific
> device identified by Product ID and Vendor ID.
>
>
> 4. USCSI_PMFAILFAST flag
>
> There is a problem where an FMA disk health checking thread spins
> up disks periodically to test device status. This flag allows
> for the device driver to not spin up the device to get this
> information.
>
> The full text of the new proposal is in the materials directory as
> "proposal".
>
> thanks,
> sarito
>
