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-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
