[deleted answer by OP:] I would still like to know: what exactly is making nct6775 available now?
There are a lot of attempts at answering the general question in the following link. Unfortunately none of them are comprehensive, so I will try to improve on them. Linux: How to find the device driver used for a device?
In your case, the sensor device can be found as one of the links shown in
ls -l /sys/class/hwmon/*. You could try to extend that command, and find your kernel module immediately:
ls -l /sys/class/hwmon/*/device/driver/module
However, this command makes some assumptions. It will not work in every case. If the command does not work, narrow it down by checking each individual link in the chain. There are three possible cases.
You have a
driver link, but no
This means the driver is built in to the kernel! Which would kind of answer your question :-).
It is equally possible to
ls -l on the
driver link. I.e. to see the name of the driver, change the above command to remove the
/module part. Often the driver name is the same as the name of the loadable module, but sometimes they are different.
driver link is not immediately under
If the above command does not work, you might need to replace
device/device, or so on.
device link takes you to the parent device. But sometimes the driver is on the grandparent device instead, or even further :-).
None of the parent
device(s) have a
driver link, or there is no parent
device link at all.
device link takes you to the parent device. For example, you might have a network device
/sys/class/wlan0/device might point to a PCI card which provides
In your case, I can imagine it not having anything like a device on the standard
pci bus. In this case the driver is supposed to define its own custom device, in
/sys/devices/platform/. This is exactly what the
coretemp driver for my Intel CPU does.
But if your driver got this wrong, it would create a device with no parent, and hence no
device link. Sensors (
hwmon devices) are one of the more obscure child devices; I've seen this happen several times before. Looking in
ls /sys/devices/virtual/*, I seem to have three devices that get this wrong, and all of them are
If there is no "physical" / parent
device - then there can be no
driver. This is expected behaviour for genuinely virtual devices, like loopback (
bridge networking devices. It reflects the device model of the Linux kernel. On a physical device, you can remove the driver that is bound to a it, and potentially bind a different driver. It wouldn't make sense to support this without having a physical device. It's just unfortunate because there is no equivalent method like this, to find the module that implements a virtual device.
- Example results looking in /sys
- I found the module name, now...
1. Example results looking in /sys
$ cd /sys/class/hwmon/
$ ls -l *
lrwxrwxrwx. 1 root root 0 Dec 2 17:50 hwmon0 -> ../../devices/virtual/thermal/thermal_zone0/hwmon0
lrwxrwxrwx. 1 root root 0 Dec 2 17:50 hwmon1 -> ../../devices/virtual/hwmon/hwmon1
lrwxrwxrwx. 1 root root 0 Dec 2 17:50 hwmon2 -> ../../devices/virtual/thermal/thermal_zone8/hwmon2
lrwxrwxrwx. 1 root root 0 Dec 2 17:50 hwmon3 -> ../../devices/platform/coretemp.0/hwmon/hwmon3
$ ls -l hwmon3/device/driver/module
lrwxrwxrwx. 1 root root 0 Dec 2 18:32 /sys/class/hwmon/hwmon3/device/driver/module -> ../../../../module/coretemp
But the other results did not look so helpful :-). What is
hwmon devices (and some other types) also have a
name. E.g. the
iwlwifi sensor, which is really provided by my Intel Wi-Fi card. But the driver is buggy and declared it as a virtual device.
$ head */name
==> hwmon0/name <==
==> hwmon1/name <==
==> hwmon2/name <==
==> hwmon3/name <==
Here's a different device, where the driver is on the "grandparent":
$ ls -l */device/device/driver
lrwxrwxrwx. 1 root root 0 Dec 2 18:33 /sys/class/hwmon/hwmon0/device/device/driver -> ../../../../bus/acpi/drivers/thermal
Also there is no module for this driver, because this one is built-in to the kernel. You can confirm this if you can find the corresponding option in the kernel build configuration. This is not necessarily named the same as the module though.
$ ls -l */device/device/driver/module
ls: cannot access '*/device/device/driver/module': No such file or directory
$ grep CORETEMP= /boot/config-$(uname -r)
$ grep ACPI_THERMAL= /boot/config-$(uname -r)
2. I found the module name, now...
You said you're not 100% sure what you've done. If you've found the module name, but you were worried because you can't remember if you installed it from an unknown website, here are some things you could look at.
You can reload a module and check the path your module was reloaded from:
$ modprobe --remove coretemp
$ modprobe -v coretemp
Then you can query your package manager to confirm the module file came from the distribution kernel package. E.g. for RPM:
$ rpm -q --whatprovides /lib/modules/4.19.4-200.fc28.x86_64/kernel/drivers/hwmon/coretemp.ko.xz
$ rpm -q --whatprovides /boot/vmlinuz-$(uname -r)
Your package manager should also let you verify the installed package files have not been modified.
It's not so simple to confirm where the package came from :-). Usually you look at the package name and guess :-). You can get a list of available packages and where they come from e.g. with
dnf info kernel, but I don't think dnf can show the checksum of the RPM file that was installed or of the available RPMs.