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. 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
