On Wed, Nov 07, 2018 at 05:51:22AM -0800, Guenter Roeck wrote: > On 11/7/18 1:18 AM, Borislav Petkov wrote: > > On Tue, Nov 06, 2018 at 05:20:41PM -0600, Bjorn Helgaas wrote: > > > Or maybe even drivers/acpi/thermal.c, which claims every Thermal Zone > > > (ACPI 6.2, sec 11), would be sufficient. I don't know what the > > > relationship between hwmon and other thermal stuff, e.g., > > > Documentation/thermal/sysfs-api.txt is. acpi/thermal.c looks tied > > > into the drivers/thermal stuff (it registers "thermal_zone" devices), > > > but not to hwmon. > > > > Err, I still don't think I'm catching your drift but let me stop you > > right there: amd_nb is not there only for hwmon/k10temp. It is a small > > interface glue if you will, which exports the CPU functionality in PCI > > config space to other consumers. > > Also, thermal and hwmon are orthogonal, just like hwmon and iio. One would > typically have a driver in one subsystem, in some cases bridging to the > other subsystem, but one would not have drivers in both subsystems. > I think Bjorn is suggesting that the k10temp driver should move to the > thermal subsystem, though I don't really understand what that has to do > with finding the correct PCI device(s) to query. Or maybe I misunderstand. Not really; I'm suggesting that it's possible to make k10temp work in a way that requires less knowledge about the AMD topology and hence fewer changes for new platforms. Today, k10temp needs CPU/PCI topology info from amd_nb to read the sensors via PCI registers. k10temp could conceivably read the sensors via ACPI methods, which means that topology info would be in the firmware and k10temp wouldn't depend on amd_nb. Bjorn
