On 04/11/2024 15:03, Guenter Roeck wrote:
On 11/2/24 10:46, Ahmad Khalifa wrote:
Add a userspace-configured driver that can receive IOCTRL
commands to monitor devices over IO or ACPI access.
- registers a miscdevice at /dev/trim-control
- awaits attach/detach ioctrl commands with device details
- reads sensor values from: 1. IO select registers, 2. IO direct
registers or 3. ACPI method calls (single arg)
- applies basic conversions: multiply, divide, dividend divisor
Useful when there is prior knowledge of the device or when
experimenting with newer devices using old device info.
Another use is for debugging other drivers when raw reg values
need to be compared with what the full driver prints out.
Drawbacks: Not aware of any device. It's readonly. Readonly does
not make it safe as it still writes for address select and bank
select. Needs an ioctrl and cannot be modloaded through config
or modalias
[ ... ]
diff --git a/trivialmon.c b/trivialmon.c
new file mode 100644
index 0000000..11e5829
--- /dev/null
+++ b/trivialmon.c
@@ -0,0 +1,844 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * trivialmon - Trivial Hardware Monitor Driver (Trim)
+ *
+ * Userspace-configured monitor controlled through IOCTL
+ *
+ * DISCLAIMER: Don't run this with other hwmon modules for the same
device.
+ * You could easily FRY your motherboard! You could also easily FRY
YOUR CPU!
+ *
This is way too risky to add to the kernel. I think it is much better kept
out-of-tree, with lots of disclaimers and users (hopefully) understanding
what they get into when loading this module.
Understood. Could be considered a "safe" tool if in tree.
I had thought about something similar some time ago, though limited to i2c
devices and using some kind of command language, not open ended ioctls.
I gave up on it for the same reason: For some i2c devices, just reading
from
a register may be understood as command, such as "restore factory
configuration".
If such a command is executed on the wrong chip, such as a power controller
or a display controller, it can easily make the hardware unusable. It is
bad
enough that this can happen with a kernel driver as well, or with someone
executing i2c commands from userspace directly. I really don't want to
make that
even easier.
Just curious, how were you thinking of passing those commands? sysfs?
over i2c-dev?
Looking around, the documentation for configfs seemed like it would
could useful for this, but that's not in much use as I can see. (And
involves lots of text parsing)
--
Regards,
Ahmad
