summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorGuenter Roeck <linux@roeck-us.net>2022-01-09 14:19:01 -0800
committerGuenter Roeck <linux@roeck-us.net>2022-07-13 08:38:17 -0700
commitf6d0775119fb905fb02eafa98d575cf8ee792d46 (patch)
tree253adb247addb2826ac68b69e234b5a160a018ab /tools/perf/scripts/python/export-to-postgresql.py
parenteaf87c006f03266d4203f0a62e8c8a1cde417152 (diff)
hwmon: (lm90) Rework alarm/status handling
Many chips supported by this driver clear status registers after it is read and update it in the next measurement cycle. Normally this falls under the radar because all registers are only read once per measurement cycle. However, there is an exception: Status registers are always read during interrupt and laert handling. This can result in invalid status reports if userspace reads an alarm attribute immediately afterwards. Rework alarm/status handling by keeping a shadow register with 'current' alarms, and by ensuring that the register is either only updated once per measurement cycle or not cleared. A second problem is related to alert handling: Alert handling is disabled for chips with broken alert after an alert was reported, but only re-enabled if attributes are read by the user. This means that alert conditions may appear and disappear unnoticed. Remedy the situation by introducing a worker to periodically read the status register(s) while alert handling is disabled, and re-enable alerts after the alert condition clears. Yet another problem is that sysfs and udev events are currently only reported to userspace if an alarm is raised, but not if an alarm condition clears. Use the new worker to detect that situation and also generate sysfs and udev events in that case. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions