On 12/26/2012 01:17 AM, Tejun Heo wrote:
> Hello, Aaron.
>
> On Thu, Dec 20, 2012 at 02:07:25PM +0800, Aaron Lu wrote:
>> +static int is_gendisk_part0(struct device *dev, void *data)
>> +{
>> + struct device **child = data;
>> +
>> + if (dev->class == &block_class && dev->type == &disk_type) {
>> + *child = dev;
>> + return 1;
>> + } else
>> + return 0;
>> +}
>> +
>> +/**
>> + * disk_from_device - Get the gendisk pointer for this device.
>> + * @dev: the device this gendisk is created for, i.e. gendisk->driverfs_dev
>> + *
>> + * LLD sometimes need to play with the gendisk without HLD's aware,
>> + * this routine gives LLD the required access to gendisk.
>> + *
>> + * CONTEXT:
>> + * Don't care.
>> + */
>> +struct gendisk *disk_from_device(struct device *dev)
>> +{
>> + struct device *child;
>> +
>> + if (device_for_each_child(dev, &child, is_gendisk_part0))
>> + return dev_to_disk(child);
>> + else
>> + return NULL;
>> +}
>> +EXPORT_SYMBOL(disk_from_device);
>
> This is really a round-about way to find out the matching device and
> it wouldn't work if the disk device nests deeper. Doesn't really look
> like a good idea to me.
I don't quite understand the 'disk device nests deeper' case, can you
please elaborate? My understanding is, as long as the disk's part0
device has a parent, this function should work. For LLDs want to take
advantage of this function, it should pass the device that is the parent
of part0 as the param, this function itself doesn't try to dig further.
The only problem I can see is when there are multiple gendisks created
for a single device, which I don't know if there is such a case?
>
>> Then together with disk_try_block_events and disk_unblock_events, we can
>> avoid touching SCSI layer to let ODD stay in zero power state.
>
> Also, I'd much prefer something along the line of
> block_events_nowait() instead of try_block.
Sure, no problem.
Thanks,
Aaron
--
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
