[PATCH v2 2/2] hwmon: Add notification and uevent support to sysfs ABI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Some hwmon drivers start adding support for alarm attribute notifications and
generate uevents. Standardize the ABI to be used for this purpose.

Signed-off-by: Guenter Roeck <guenter.roeck@xxxxxxxxxxxx>
---
v2: Fixed typos.
    Added faults to attributes triggering notifications.
    Generate uevent on hwmon device kobject.

 Documentation/hwmon/sysfs-interface |   32 ++++++++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index e65e7e8..35b09d6 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -97,6 +97,17 @@ update_interval	The interval at which the chip will update readings.
 		Some devices have a variable update rate or interval.
 		This attribute can be used to change it to the desired value.
 
+notification	This attribute exists if the driver supports notifications on
+		alarm, fault, and trigger attributes. Valid attribute values
+		are:
+		0: The driver does not support notifications or uevents.
+		1: The driver supports notifications.
+		2: The driver generates a uevent if an alarm, fault, or trigger
+		   status changes.
+		3: The driver suports notifications and generates a uevent if
+		   an alarm, fault, or trigger status changes.
+		RO
+
 
 ************
 * Voltages *
@@ -706,6 +717,27 @@ intrusion[0-*]_beep
 		RW
 
 
+Notifications and uevents
+-------------------------
+
+Hwmon drivers may support generating notification on sysfs alarm, fault, and
+trigger attributes. This support is reflected in the existence of the
+"notification" attribute described above.
+
+If a driver supports notifications, applications do not have to manually poll
+alarm, fault, and trigger attributes, but can use poll(2) or epoll(4) instead.
+
+If a driver supports notifications, it shall support it for all alarm and
+trigger attributes, and should support it for all fault attributes.
+Notifications shall be generated for all state transistions (0->1 as well as
+1->0).
+
+In addition to notifications, drivers may also support uevents. If so, a uevent
+shall be generated whenever an alarm or trigger attribute changes its state, and
+should be generated whenever a fault attribute changes its state. The uevent
+shall be generated on the driver's hwmon device kobject.
+
+
 sysfs attribute writes interpretation
 -------------------------------------
 
-- 
1.7.3.1


_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors


[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux