* Re: [lm-sensors] [PATCH v2 2/2] hwmon: Add notification and uevent
2011-09-20 17:55 [lm-sensors] [PATCH v2 2/2] hwmon: Add notification and uevent Guenter Roeck
@ 2011-09-21 8:57 ` Jonathan Cameron
2011-09-21 10:24 ` Guenter Roeck
2011-09-22 3:43 ` R, Durgadoss
2 siblings, 0 replies; 4+ messages in thread
From: Jonathan Cameron @ 2011-09-21 8:57 UTC (permalink / raw)
To: lm-sensors
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?
> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
> ---
> 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
> -------------------------------------
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [lm-sensors] [PATCH v2 2/2] hwmon: Add notification and uevent
2011-09-20 17:55 [lm-sensors] [PATCH v2 2/2] hwmon: Add notification and uevent Guenter Roeck
2011-09-21 8:57 ` Jonathan Cameron
@ 2011-09-21 10:24 ` Guenter Roeck
2011-09-22 3:43 ` R, Durgadoss
2 siblings, 0 replies; 4+ messages in thread
From: Guenter Roeck @ 2011-09-21 10:24 UTC (permalink / raw)
To: lm-sensors
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@ericsson.com>
> > ---
> > 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
> > -------------------------------------
> >
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [lm-sensors] [PATCH v2 2/2] hwmon: Add notification and uevent
2011-09-20 17:55 [lm-sensors] [PATCH v2 2/2] hwmon: Add notification and uevent Guenter Roeck
2011-09-21 8:57 ` Jonathan Cameron
2011-09-21 10:24 ` Guenter Roeck
@ 2011-09-22 3:43 ` R, Durgadoss
2 siblings, 0 replies; 4+ messages in thread
From: R, Durgadoss @ 2011-09-22 3:43 UTC (permalink / raw)
To: lm-sensors
Hi Guenter,
This patch looks fine for me.
Please add:
Reviewed-by: R Durgadoss <durgadoss.r@intel.com>
> > > Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
> > > ---
> > > 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
> > > -------------------------------------
> > >
> >
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 4+ messages in thread