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? Thanks, Aaron > SCSI tho. So, we're mostly shifting the problem. Given that async > events is nice to have, so it isn't a bad idea. > > * Still dunno much about zpodd but IIUC the notification from > zero-power is via ACPI. To advertise that the device doesn't need > polling, it should also be able to do async notification while > powered up, which isn't covered by zpodd but ATA async notification. > So, ummm... that's another obstacle. If zpodd requires the device > to support ATA async notification, it might not be too bad tho. > > Thanks. > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
