Hi Thomas,
> enum events {
> > THERMAL_CRITICAL,
> > /* user defined thermal events */
> > THERMAL_USER_AUX0,
> > THERMAL_USER_AUX1,
> > THERMAL_DEV_FAULT,
> > };
> Something else...
> I've now seen your HW specific core/pkg temp threshold support.
> I didn't look at it that closely, but if you introduce generic
> thermal netlink events in the thermal driver those should match
> all kind of possible thermal events, not only the once introduced
> by the driver you added.
>
> For example it would be great to get the ACPI specific thermal
> events which are currently exported as ACPI driven ones:
> drivers/acpi/thermal.c:acpi_thermal_notify()
> integrated there as well. So there should also be events like:
> > THERMAL_CRITICAL,
> > /* user defined thermal events */
> > THERMAL_USER_AUX0,
> > THERMAL_USER_AUX1,
> > THERMAL_DEV_FAULT,
> THERMAL_PASSIVE
> THERMAL_ACTIVE
> THERMAL_HOT
>
I am fine with adding these events also to the enum here..
> At some point of time we should be able
> to get rid of the ACPI specific thermal events at all?
> There seem to be nothing like a kind of
> "available netlink events and their format" API in Documentation.
> Each driver seem to do this and document it itself.
> But as it is an interface to userspace, these thermal netlink events
> should get documented in:
> Documentation/thermal
>
I did add a simple documentation to Documentation/thermal/sysfs_api.txt.
This is under 4.Event Notification..But I did not account for _PASSIVE,
_HOT etc.. May if we all agree to merge all events under this one enum,
I can add more description there.
> Currently you only export one of the above 4 thermal events as a
> number via netlink, right?
Right.
> Are there any userspace programs you have in mind which should make
> use of it?
Yes. I am working on a simple user space program to catch these netlink events.
> Some data which should get exported as well:
> - The temperature if available
> - The number of the thermal zone, e.g. if 0, userspace can look
> up sysfs for further info in:
> /sys/devices/virtual/thermal/thermal_zone0/*
> - The trip point affected if any, e.g. if 0, userspace can look it up
> in sysfs for further info:
> /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_{temp,type}
> - more?
>
> Ehh, this core and package thermal driver you added threshold support,
> does this somehow register as a thermal driver?
> I can see that it registers for hwmon: hwmon_device_register(&pdev->dev);
> But is it somehow connected to thermal_sys.c other than that it just
> throws your newly introduced thermal_netlink_events?
> This driver should first register as a thermal driver, export
> trip points to:
> /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_{temp,type}
> e.g.
> cat trip_point_0_type
> critical
> cat trip_point_1_type
> user_aux0
>
> The thermal_netlink_events could then only be declared for
> thermal_sys.c scope, so that other drivers cannot misuse them
> and the netlink event can then get triggered by the driver through
> thermal driver callbacks.
>
Yep!! This was my initial idea, with which I added the netlink support here.
If we make the coretemp register with the thermal framework, we have to modify
the sysfs _store and _show functions a bit. Hence, the coretemp people were not
very happy with the idea of making coretemp register with the thermal framework.
So, I just added support to the core thresholds, and when current
temperature crosses them, it sends a netlink event.
Moreover, I thought by making the coretemp register with the framework,
We can aggregate all thermal related components in one place.
This way, /sys/class/thermal/thermal_zone[0-n] will give information on
every thermal sensor on the system.
The second point to this is, any sensor can send a thermal netlink event,
With a unique id(when any driver registers with the framework..it
gives a unique id). If there is a user land code that can catch netlink events,
it can differentiate the sensors with the id, and take actions based on that.
> Rui: What do you think?
> This implementation looks much too static, could you help to better
> adjust it to the generic thermal driver needs, you know this stuff best.
Rui helped me a lot in cleaning up the netlink code and getting it in.
But to make this approach work, we need support from coretemp code also.
Copying Guenter and Fenghua who maintain the coretemp code.
Guenter and Fenghua, kindly let us know your opinion on this..
Thanks,
Durga
ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶›¡Ü}©ž²ÆzÚj:+v‰¨þø®w¥þŠàÞ¨è&¢)ß«a¶Úÿûz¹ÞúŽŠÝjÿŠwèf
