Dear all,
I am currently involved in the implementation of my master thesis, for what I
am trying to create a user space power management tool. As a part of this work
I am developing a kernel module, and one of the first things I need to do is
getting the current power state of some devices of my computer, essentially
hard drives and network devices (ethernet and wireless cards).
For the hard drives, I get the pointers to the struct device that represents
each one iterating over scsi_bus_type and selecting those whose driver is named
"sd". Then, I obtain the runtime power state:
dev->power.runtime_status;
I did a test with an external USB hard drive, checking the runtime power state
before and after issuing a sleep command with hdparm -Y. The drive effectively
spinned down, but the runtime power state didn't change from active to
suspended.
In the case of net devices, I get the corresponding structures this way:
struct net_device *netdev = first_net_device(&init_net);
while (netdev) {
struct device *dev = &netdev->dev;
/* code... */
netdev = next_net_device(netdev);
}
For every net_device I get its embedded struct device and then I check the same
field as before, but in this case runtime power management is disabled, so I
always get the device is suspended, even though it is configured and working
properly. In fact, the whole device struct seems to be empty.
Taking this into account, my questions are:
- Is it possible that I am not getting the correct struct device for every
hardware device?
- Am I checking the correct field of the struct dev_pm_info?
- Do scsi device drivers implement the runtime_status updates when drives
effectively change their state?
- Is runtime power management supported by net devices?
Any answer would be really appreciated. Thanks in advance.
Best regards,
Alejandra Morales Ruiz
Master Thesis Student
Technische Universität München
Fakultät für Informatik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
