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 wi
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 wi
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 t
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 w
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:
> >
[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 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.
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 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/prob
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
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 suspen
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 .removabl
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 th
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 total
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 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 initi
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
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
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?
> >>
> >
>
> 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
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 loc
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 P
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
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 tha
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
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
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
> cha
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 may_p
28 matches
Mail list logo
