On Thu, Sep 13, 2012 at 12:24:46PM -0400, Alan Stern wrote:
> > > Disk runtime power states are defined in the standard and so we rely on
> > > the standard taking care of the cache. I suspect the most efficient use
> > > may be via the power management mode page, which does everything
> > > autom
On Thu, Sep 13, 2012 at 10:26:44AM +0100, James Bottomley wrote:
> On Thu, 2012-09-13 at 17:07 +0800, Aaron Lu wrote:
> > So I think this is basically 2 things, one is the runtime suspend of the
> > disk, another is when it is runtime suspended, how to remove its power.
> > I'm currently doing the
On Thu 13 Sep 2012 03:32:50 PM PDT, Chris Leech wrote:
> anymore>
>
>>> That being said, I'm glad this is being reworked. Do you have any
>>> other functionality in mind that this is laying the groundwork for?
>>>
>>
>> I have one feature and a few ideas. I currently have a patch that adds
>> a f
>> That being said, I'm glad this is being reworked. Do you have any
>> other functionality in mind that this is laying the groundwork for?
>>
>
> I have one feature and a few ideas. I currently have a patch that adds
> a fabric selection feature. I add another RW attribute to the ctlr_X
> devic
On Thu, 13 Sep 2012, Oliver Neukum wrote:
> On Thursday 13 September 2012 12:24:46 Alan Stern wrote:
> > On Thu, 13 Sep 2012, Oliver Neukum wrote:
>
> > > Yes, but this confusion is necessary. The driver core is supposed to
> > > be generic and knows strictly speaking only suspended and active.
>
From: David Miller
Date: Tue, 11 Sep 2012 18:48:46 -0400 (EDT)
> From: ebied...@xmission.com (Eric W. Biederman)
> Date: Tue, 11 Sep 2012 15:40:08 -0700
>
>> So just for curiosity I searched the entire git history for scsi_nl_add_
>> and the only commit that I found was the addition of that code
On Thursday 13 September 2012 12:24:46 Alan Stern wrote:
> On Thu, 13 Sep 2012, Oliver Neukum wrote:
> > Yes, but this confusion is necessary. The driver core is supposed to
> > be generic and knows strictly speaking only suspended and active.
> > It is a driver's job to do what needs to be done a
Hello,
On Thu, Sep 13, 2012 at 08:27:29PM +0200, Bart Van Assche wrote:
> If I do not receive further feedback I'll start testing the patch below
> (on top of the patch at the start of this thread):
Yeah, it generally seems fine to me. This makes Chanho's patch
unnecessary, right? Just some min
On 09/13/12 18:53, Tejun Heo wrote:
> Oh yeah, I definitely think this is something which needs to be solved
> from the block layer but I'm hoping this could cover the case Chanho
> is trying to solve too. They're different but similar problems - you
> don't want blk_cleanup_queue() to finish whil
Hello, Bart.
On Thu, Sep 13, 2012 at 09:26:59AM +0200, Bart Van Assche wrote:
> On 09/12/12 22:53, Tejun Heo wrote:
> > The problem at hand IIUC is ->request_fn() being invoked when
> > request_queue itself is alive but the underlying driver is gone. We
> > already make sure that a new request is
On Thu, 13 Sep 2012, Oliver Neukum wrote:
> > > > Well, I don't like the way the interaction of the patches is going.
> > > > You're the one proposing powering down the device outside of the
> > > > standards defined transitions, so you need to be responsible for the
> > > > actions that necessita
On Fri, Sep 07, 2012 at 11:14:33AM +0200, Thomas Schwinge wrote:
> I have now finally been able to check this, and yes, I'm already using
> the latest version of the BIOS, which is Phoenix cME FirstBIOS Desktop
> Pro version 5.00 R1.07.2264.A1 (a.k.a. 5.00.1.07, 25.04.2006) for
> Fujitsu Siemens E
On Thursday 13 September 2012 11:51:07 James Bottomley wrote:
> On Thu, 2012-09-13 at 12:16 +0200, Oliver Neukum wrote:
> > On Thursday 13 September 2012 10:26:44 James Bottomley wrote:
> > > On Thu, 2012-09-13 at 17:07 +0800, Aaron Lu wrote:
> >
> > > > So I think this is basically 2 things, one
On Thu, 2012-09-13 at 12:16 +0200, Oliver Neukum wrote:
> On Thursday 13 September 2012 10:26:44 James Bottomley wrote:
> > On Thu, 2012-09-13 at 17:07 +0800, Aaron Lu wrote:
>
> > > So I think this is basically 2 things, one is the runtime suspend of the
> > > disk, another is when it is runtime
On Thursday 13 September 2012 10:26:44 James Bottomley wrote:
> On Thu, 2012-09-13 at 17:07 +0800, Aaron Lu wrote:
> > So I think this is basically 2 things, one is the runtime suspend of the
> > disk, another is when it is runtime suspended, how to remove its power.
> > I'm currently doing the la
On Thu, 2012-09-13 at 17:07 +0800, Aaron Lu wrote:
> On 09/13/2012 04:56 PM, James Bottomley wrote:
> > So what's the target audience for the feature. If it isn't laptops or
> > standard desktops, is it the enterprise?
>
> To make this feature useful for normal laptop user, a better mechanism
> f
On 09/13/2012 05:12 PM, Jack Wang wrote:
>>
>> When scsi disk is runtime suspended, the ata port it attached to will be
>> runtime suspended, and then the power will be removed through ACPI.
>>
>> Please check libata-acpi.c, function ata_acpi_set_state.
>>
>> The parent/child relationship of the de
>
> When scsi disk is runtime suspended, the ata port it attached to will be
> runtime suspended, and then the power will be removed through ACPI.
>
> Please check libata-acpi.c, function ata_acpi_set_state.
>
> The parent/child relationship of the devices:
> ata_host
> ata_port
> scsi_hos
On 09/13/2012 04:56 PM, James Bottomley wrote:
> On Thu, 2012-09-13 at 16:49 +0800, Aaron Lu wrote:
>> On 09/13/2012 04:37 PM, James Bottomley wrote:
>>> On Thu, 2012-09-13 at 16:23 +0800, Aaron Lu wrote:
On 09/13/2012 04:14 PM, James Bottomley wrote:
> On Thu, 2012-09-13 at 15:40 +0800, A
On Thu, 2012-09-13 at 16:56 +0800, Aaron Lu wrote:
> If you have more questions on how it works, please send email only
> to me, other people might be too busy to read such emails :-)
No, please don't. One of the points of mailing lists is to accumulate
information. The reason we always ask for
On Thu, 2012-09-13 at 16:49 +0800, Aaron Lu wrote:
> On 09/13/2012 04:37 PM, James Bottomley wrote:
> > On Thu, 2012-09-13 at 16:23 +0800, Aaron Lu wrote:
> >> On 09/13/2012 04:14 PM, James Bottomley wrote:
> >>> On Thu, 2012-09-13 at 15:40 +0800, Aaron Lu wrote:
> The ready_to_power_off flag
On 09/13/2012 04:39 PM, Jack Wang wrote:
> For hard disk runtime power off, Is there (hardware?) requirement for
>>> hard
> drive to support similar feature?
No requirement for hard drive, as it does not need to remote wake up
itself while powered off.
Please note t
On 09/13/2012 04:37 PM, James Bottomley wrote:
> On Thu, 2012-09-13 at 16:23 +0800, Aaron Lu wrote:
>> On 09/13/2012 04:14 PM, James Bottomley wrote:
>>> On Thu, 2012-09-13 at 15:40 +0800, Aaron Lu wrote:
The ready_to_power_off flag is used to give indication to ATA layer
if this device's
> >>> For hard disk runtime power off, Is there (hardware?) requirement for
> > hard
> >>> drive to support similar feature?
> >>
> >> No requirement for hard drive, as it does not need to remote wake up
> >> itself while powered off.
> >>
> >> Please note that there is a v7 sent yesterday, you may
On Thu, 2012-09-13 at 16:23 +0800, Aaron Lu wrote:
> On 09/13/2012 04:14 PM, James Bottomley wrote:
> > On Thu, 2012-09-13 at 15:40 +0800, Aaron Lu wrote:
> >> The ready_to_power_off flag is used to give indication to ATA layer
> >> if this device's power can be removed when runtime suspended.
> >>
On 09/13/2012 04:15 PM, Jack Wang wrote:
>>> For hard disk runtime power off, Is there (hardware?) requirement for
> hard
>>> drive to support similar feature?
>>
>> No requirement for hard drive, as it does not need to remote wake up
>> itself while powered off.
>>
>> Please note that there is a v
On 09/13/2012 04:14 PM, James Bottomley wrote:
> On Thu, 2012-09-13 at 15:40 +0800, Aaron Lu wrote:
>> The ready_to_power_off flag is used to give indication to ATA layer
>> if this device's power can be removed when runtime suspended.
>>
>> This flag is determined by individual SCSI driver like sr
> > For hard disk runtime power off, Is there (hardware?) requirement for
hard
> > drive to support similar feature?
>
> No requirement for hard drive, as it does not need to remote wake up
> itself while powered off.
>
> Please note that there is a v7 sent yesterday, you may want to take a
> loo
On Thu, 2012-09-13 at 15:40 +0800, Aaron Lu wrote:
> The ready_to_power_off flag is used to give indication to ATA layer
> if this device's power can be removed when runtime suspended.
>
> This flag is determined by individual SCSI driver like sr, sd.
>
> This flag is introduced to support zero p
On 09/12/12 22:53, Tejun Heo wrote:
> The problem at hand IIUC is ->request_fn() being invoked when
> request_queue itself is alive but the underlying driver is gone. We
> already make sure that a new request is not queued once drain is
> complete but there's no guarantee about calling into ->requ
The ready_to_power_off flag is used to give indication to ATA layer
if this device's power can be removed when runtime suspended.
This flag is determined by individual SCSI driver like sr, sd.
This flag is introduced to support zero power ODD. When ODD
is runtime suspended, it may not be OK to re
Hard disk may also be runtime powered off, so set can_power_off flag
for it too if condition satisfies so that the may_power_off sysfs file
will be created for it to give user a chance to disable runtime power
off.
Signed-off-by: Aaron Lu
Acked-by: Jeff Garzik
---
drivers/ata/libata-acpi.c | 25
This patch set is baed on v7 ZPODD patches.
Aaron Lu (2):
scsi: sd: set ready_to_power_off for scsi disk
libata: acpi: set can_power_off for both ODD and HDD
drivers/ata/libata-acpi.c | 25 +
drivers/scsi/sd.c | 1 +
2 files changed, 18 insertions(+), 8 delet
33 matches
Mail list logo
