On Tue, Sep 25, 2012 at 03:02:29PM +0400, James Bottomley wrote:
On Tue, 2012-09-25 at 16:18 +0800, Aaron Lu wrote:
A example patch would be something like the following, I didn't seperate
these ACPI calls in sr.c as this is just a concept proof, if this is the
right thing to do, I will
On Mon, Sep 24, 2012 at 11:46:03PM +0200, Rafael J. Wysocki wrote:
On Monday, September 24, 2012, Aaron Lu wrote:
On Mon, Sep 24, 2012 at 03:06:11PM +0200, Rafael J. Wysocki wrote:
On Monday, September 24, 2012, Aaron Lu wrote:
need_eject:
First consider how the device will be
On Tue, 2012-09-25 at 16:18 +0800, Aaron Lu wrote:
A example patch would be something like the following, I didn't seperate
these ACPI calls in sr.c as this is just a concept proof, if this is the
right thing to do, I will separate them into another file sr-acpi.c and
make empty stubs for them
On Tue, Sep 25, 2012 at 03:02:29PM +0400, James Bottomley wrote:
On Tue, 2012-09-25 at 16:18 +0800, Aaron Lu wrote:
A example patch would be something like the following, I didn't seperate
these ACPI calls in sr.c as this is just a concept proof, if this is the
right thing to do, I will
On Monday, September 24, 2012, Aaron Lu wrote:
On Fri, Sep 21, 2012 at 11:18:27PM +0200, Rafael J. Wysocki wrote:
On Friday, September 21, 2012, Aaron Lu wrote:
On Thu, Sep 20, 2012 at 10:00:51PM +0200, Rafael J. Wysocki wrote:
On Wednesday, September 19, 2012, Aaron Lu wrote:
On Mon, Sep 24, 2012 at 03:06:11PM +0200, Rafael J. Wysocki wrote:
On Monday, September 24, 2012, Aaron Lu wrote:
On Fri, Sep 21, 2012 at 11:18:27PM +0200, Rafael J. Wysocki wrote:
On Friday, September 21, 2012, Aaron Lu wrote:
On Thu, Sep 20, 2012 at 10:00:51PM +0200, Rafael J. Wysocki
[CC: list trimmed somewhat]
On Mon, 24 Sep 2012, Aaron Lu wrote:
I've tried to do a disk_block_events call on its suspend callback when
it is ready to be powered off, but there is a race that I don't know how
to solve:
pm_runtime_suspenddisk_events_workfn
On Monday, September 24, 2012, Aaron Lu wrote:
On Mon, Sep 24, 2012 at 03:06:11PM +0200, Rafael J. Wysocki wrote:
On Monday, September 24, 2012, Aaron Lu wrote:
On Fri, Sep 21, 2012 at 11:18:27PM +0200, Rafael J. Wysocki wrote:
On Friday, September 21, 2012, Aaron Lu wrote:
On Thu,
On Fri, Sep 21, 2012 at 11:18:27PM +0200, Rafael J. Wysocki wrote:
On Friday, September 21, 2012, Aaron Lu wrote:
On Thu, Sep 20, 2012 at 10:00:51PM +0200, Rafael J. Wysocki wrote:
On Wednesday, September 19, 2012, Aaron Lu wrote:
Thanks Rafael, and if there is any question/problem,
On Friday 21 September 2012 23:18:27 Rafael J. Wysocki wrote:
Now, James says he doesn't like the way ready_to_power_off is used. Sure
enough, it is totally irrelevant to the majority of SCSI devices. It actually
is totally irrelevant to everything in the SCSI subsystem except for the sr
On Saturday, September 22, 2012, Oliver Neukum wrote:
On Friday 21 September 2012 23:18:27 Rafael J. Wysocki wrote:
Now, James says he doesn't like the way ready_to_power_off is used. Sure
enough, it is totally irrelevant to the majority of SCSI devices. It
actually
is totally
On Sat, 22 Sep 2012, Rafael J. Wysocki wrote:
There are sd devices with removable media.
OK. Does the SCSI layer distinguish them from devices without removable
media?
Yes, it does. struct scsi_device has a .removable member, and the
Removable flag is part of the response data to the
On Saturday, September 22, 2012, Alan Stern wrote:
On Sat, 22 Sep 2012, Rafael J. Wysocki wrote:
There are sd devices with removable media.
OK. Does the SCSI layer distinguish them from devices without removable
media?
Yes, it does. struct scsi_device has a .removable member,
On Sat, 22 Sep 2012, Rafael J. Wysocki wrote:
I see. So the sr's runtime suspend may be useful even without the
power-off
feature, right?
Exactly. Even though the drive itself may not be powered off, by
putting it into runtime suspend we gain the ability to suspend the
On Saturday, September 22, 2012, Alan Stern wrote:
On Sat, 22 Sep 2012, Rafael J. Wysocki wrote:
I see. So the sr's runtime suspend may be useful even without the
power-off
feature, right?
Exactly. Even though the drive itself may not be powered off, by
putting it into
On Friday, September 21, 2012, Aaron Lu wrote:
On Thu, Sep 20, 2012 at 10:00:51PM +0200, Rafael J. Wysocki wrote:
On Wednesday, September 19, 2012, Aaron Lu wrote:
Thanks Rafael, and if there is any question/problem,
please kindly let me know.
Well, unfortunately my initial review
On Wednesday, September 19, 2012, Aaron Lu wrote:
On 09/19/2012 08:50 PM, Rafael J. Wysocki wrote:
On Wednesday, September 19, 2012, James Bottomley wrote:
On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
Hi James,
May I know if this patchset will enter v3.7?
Sigh, well, I was
On Wednesday, September 19, 2012, James Bottomley wrote:
On Wed, 2012-09-19 at 14:50 +0200, Rafael J. Wysocki wrote:
On Wednesday, September 19, 2012, James Bottomley wrote:
On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
Hi James,
May I know if this patchset will enter v3.7?
On Thu, Sep 20, 2012 at 10:00:51PM +0200, Rafael J. Wysocki wrote:
On Wednesday, September 19, 2012, Aaron Lu wrote:
Thanks Rafael, and if there is any question/problem,
please kindly let me know.
Well, unfortunately my initial review indicates that the patchset is not
quite ready to go
Hi James,
May I know if this patchset will enter v3.7?
Thanks,
Aaron
On Wed, Sep 12, 2012 at 04:29:51PM +0800, Aaron Lu wrote:
v7:
Re work of runtime pm of sr driver, based on ideas of Alan Stern and
Oliver Neukum.
Jeff, due to the ready_to_power_off flag added, there is a small
change
On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
Hi James,
May I know if this patchset will enter v3.7?
Sigh, well, I was hoping to persuade the PM people to sort this out
first.
The first observation is that all this looks to be too specific. ZPO
may be ACPI specific, but the property it
On Wednesday, September 19, 2012, James Bottomley wrote:
On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
Hi James,
May I know if this patchset will enter v3.7?
Sigh, well, I was hoping to persuade the PM people to sort this out
first.
The first observation is that all this looks
On Wednesday 19 September 2012 13:27:47 James Bottomley wrote:
On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
Hi James,
May I know if this patchset will enter v3.7?
Sigh, well, I was hoping to persuade the PM people to sort this out
first.
The first observation is that all this
On 09/19/2012 08:50 PM, Rafael J. Wysocki wrote:
On Wednesday, September 19, 2012, James Bottomley wrote:
On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
Hi James,
May I know if this patchset will enter v3.7?
Sigh, well, I was hoping to persuade the PM people to sort this out
first.
On Wed, 2012-09-19 at 14:50 +0200, Rafael J. Wysocki wrote:
On Wednesday, September 19, 2012, James Bottomley wrote:
On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
Hi James,
May I know if this patchset will enter v3.7?
Sigh, well, I was hoping to persuade the PM people to
On Wed, 2012-09-19 at 13:27 +0100, James Bottomley wrote:
I think we could do this with a couple of flags sitting inside struct
device itself: one for pm state and capabilities defined at a generic
level and one for device specific pm state. The latter would be for
things like the door lock
On Wed, 2012-09-19 at 13:27 +0100, James Bottomley wrote:
I think we could do this with a couple of flags sitting inside struct
device itself: one for pm state and capabilities defined at a generic
level and one for device specific pm state. The latter would be for
things like the door
v7:
Re work of runtime pm of sr driver, based on ideas of Alan Stern and
Oliver Neukum.
Jeff, due to the ready_to_power_off flag added, there is a small
change in [PATCH v7 6/6] libata: acpi: respect may_power_off flag,
please check if I can still get your ack, thanks.
v6:
When user changes
28 matches
Mail list logo
