summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorJean Delvare <khali@linux-fr.org>2007-12-06 23:13:42 +0100
committerMark M. Hoffman <mhoffman@lightlink.com>2008-02-07 20:39:42 -0500
commit67b671bceb4a8340a30929e9642620d99ed5ad76 (patch)
treed302333633bdbd752151933366aaaabfdc60e719 /include
parentb20ff13a6ad64f07ce78c75e6a335c185270d73c (diff)
downloadop-kernel-dev-67b671bceb4a8340a30929e9642620d99ed5ad76.zip
op-kernel-dev-67b671bceb4a8340a30929e9642620d99ed5ad76.tar.gz
hwmon: Let the user override the detected Super-I/O device ID
While it is possible to force SMBus-based hardware monitoring chip drivers to drive a not officially supported device, we do not have this possibility for Super-I/O-based drivers. That's unfortunate because sometimes newer chips are fully compatible and just forcing the driver to load would work. Instead of that we have to tell the users to recompile the kernel driver, which isn't an easy task for everyone. So, I propose that we add a module parameter to all Super-I/O based hardware monitoring drivers, letting advanced users force the driver to load on their machine. The user has to provide the device ID of a supposedly compatible device. This requires looking at the source code or a datasheet, so I am confident that users can't randomly force a driver without knowing what they are doing. Thus this should be relatively safe. As you can see from the code, the implementation is pretty simple and unintrusive. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud