On Wed, Sep 21, 2011 at 05:03:33AM -0400, Jonathan Cameron wrote: > On 09/20/11 18:55, Guenter Roeck wrote: > > Some hwmon drivers start adding support for alarm attribute notifications and > > generate uevents. Standardize the ABI to be used for this purpose. > > > Perhaps some guidance on when uevents make sense rather than notifications? > Also, why would you do both? uevents enable script handling. An application or script is started after a uevent is generated to handle the event. Notifications are useful for running applications which wait in poll or epoll for an event on a file descriptor. Both are useful and reflect that application developers have different approaches on how to handle events. Thanks, Guenter > > 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 > > ------------------------------------- > > > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
