Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday, November 30, 2012 04:55:56 PM Aaron Lu wrote:
> On 11/28/2012 09:39 AM, Tejun Heo wrote:
> > Hey, Rafael.
> > 
> > On Wed, Nov 28, 2012 at 01:51:00AM +0100, Rafael J. Wysocki wrote:
> >> Having considered that a bit more I'm now thinking that in fact the power state
> >> the device is in at the moment doesn't really matter, so the polling code need
> >> not really know what PM is doing.  What it needs to know is that the device
> >> will generate a hardware event when something interesting happens, so it is not
> >> necessary to poll it.
> >>
> >> In this particular case it is related to power management (apparently, hardware
> >> events will only be generated after the device has been put into ACPI D3cold,
> >> or so Aaron seems to be claiming), but it need not be in general, at least in
> >> principle.
> >>
> >> It looks like we need an "event driven" flag that the can be set in the lower
> >> layers and read by the upper layers.  I suppose this means it would need to be
> >> in struct device, but not necessarily in the PM-specific part of it.
> > 
> > We already have that.  That's what gendisk->async_events is for (as
> > opposed to gendisk->events).  If all events are async_events, block
> > won't poll for events, but I'm not sure that's the golden bullet.
> > 
> > * None implements async_events yet and an API is missing -
> >   disk_check_events() - which is trivial to add, but it's the same
> >   story.  We'll need a mechanism to shoot up notification from libata
> >   to block layer.  It's admittedly easier to justify routing through
> 
> I don't see a way to do this, since libata has no chance of accessing
> the gendisk pointer. Or we can add a new field to struct device,
> something like no_poll, but I don't think it is the right thing to do,
> as not all devices are block ones.
> 
> Any other suggestions/ideas please?

I think you can follow the James' suggestion:

http://www.spinics.net/lists/linux-acpi/msg40257.html

and see how that goes.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux