> processor throttling state I/F > As processor T-state is used for thermal control only, > processor t-state is mapped to a cooling_device's cooling_state > in the generic thermal driver, combined with the processor's p-state. > # ls -l /sys/class/thermal/cooling_device0/ When I scribble into cur_state I do not see anything reflected in /proc/acpi/processor/*/throttling Also, max_state is 10, when surely my processor has only 8 T-states. If user-space can not provoke processor T-states via this I/F, then those using the old /proc I/F will flag it as a regression when it goes away. (even if few should ever need it) > wakeup control, > /sys/devices/.../wakeup should be in the todo list. :) I thought that Rafael said the wakeup file in the device tree was working now -- at least for PCI devices, no? I think the biggest problem with sysfs wakeup is that every device in the tree gets a wakeup file, even if it has no wakeup capability... > oops, I forget to add the dynamic tables... will do it soon, :) That would be good. For when we have dynamic tables, we'll be able to enhance acpidump to collect them and we'll not have to do this manually like we've been doing. > button sys I/F can be found at /sys/class/input/. > e.g. > # cat /sys/class/input/input*/device/hid > LNXPWRBN > PNP0C0C The /proc files for power and sleep buttons simply told us what kind of button they were, just info, not API. The functional one is PNP0C0D, the lid switch. It is also reflected in /sys/class/input, but I don't see a way to find from /sys the open/closed state like we have in /proc. (I ran into this when I tried to delete the button /proc I/F some time ago). re: ec and power_resource, I agree, they can go. thanks, -Len -- 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
