On 01/30/2018 03:40 AM, Denis OSTERLAND wrote:
Am Dienstag, den 30.01.2018, 11:27 +0100 schrieb Alexandre Belloni:
On 29/01/2018 at 13:59:19 -0800, Guenter Roeck wrote:
On Wed, Jan 24, 2018 at 10:03:33AM +0100, Michael Grzeschik wrote:
[ ... ]
+
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index fc337c317c673..a12b3c2b2a18c 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -702,6 +702,13 @@ intrusion[0-*]_alarm
the user. This is done by writing 0 to the file. Writing
other values is unsupported.
+intrusion[0-*]_timestamp
+ Chassis intrusion detection
+ YYYY-MM-DD HH:MM:SS UTC (ts.sec): intrusion detected
+ RO
+ The corresponding timestamp on which the intrustion
+ was detected.
+
Sneaky. Nack. You don't just add attributes to the ABI because you want it,
without serious discussion, and much less so hidden in an RTC driver
(and even less as unparseable attribute).
Right; but it was not meant to be sneaky. I should have stick to my first
thought and label this patch RFC. Sorry for that.
In addition to that, I consider the attribute unnecessary. The intrusion
already generates an event which should be sufficient for all practical
purposes.
Would it make sense in between the other sysfs attributes of this driver?
I don't understand what you mean with that, sorry.
From an ABI perspective, the attibute doesn't add value since it is
highly device specific (or at least it is the only chip I am aware of
which reports such a time stamp). Feel free to add the attribute to the
driver and document it, but not as part of the hwmon ABI. In that
case I would be inclined to accept it. However, keep in mind that
your version, reporting a human readable date/time, would effectively
preclude it from ever making it into the ABI.
Actually, there are many RTCs that are able to register one or more
timestamps. My plan was to add support for that soon but I was not
planning to do so in the hwmon ABI as this may be used for something
that is not intrusion detection (interval timers for example).
What would you suggest?
I think about something like this:
event[0-*]_timestamp: timestamp in seconds since epoch or empty if not triggered
event[0-*]_alarm: 1 if event was triggered, else 0; write 0 to clear event
Sure, that makes sense if the events are not specifically related
to intrusion detection. Question is if there would ever be more than one
or if event_timestamp and event_alarm would be sufficient.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
