RFC: SMC hwmon driver

[chadmed]

As it says on the tin, just an RFC for an improved hwmon driver which pulls data from the SMC.

The only real major issue is that there seems to be no reliable or accurate source of information
for which keys are present on which machine. The data in this MR comes mostly from poking
around with m1n1 on various devices. Some additional sensors come from exelban/stats,
however granularity at the SoC level seems insufficient as many devices are missing sensors which
are supposed to be there (e.g. random CPU core temperatures).

My preferred approach for this would be to simply ditch the attempt to keep SMC sensors in .dtsi files
and just experimentally determine which are present on each device (or class of device) and populate
&smc at that level.

[jannau]

use of_get_child_by_name(pdev->dev.parent->of_node, "macsmc-hwmon"); the "macsmc-" isn't really needed in the name.
I would put the device_node into hwmon struct

[chadmed]

Is there a reason to keep a reference to it around? We don't use it after the sensors have been populated.

[jannau]

this function can be replaced by memset32, it's already 0-termination though the kzalloc

[chadmed]

Getting rid of the 0 assignment makes sense, but I don't see how we do away with the loop since we need the config flag mask set for every sensor/channel. We can't just memset32 one location.

[chadmed]

I am very unhappy with how we are handling the "shared" keys here. There doesn't seem to be much at all in common between logic boards, even keys you'd expect wouldn't change. I don't think having a series of cascaded includes is worth it given how wildly the boards seem to differ, and we should probably just specify the keys directly at the highest level we can empirically demonstrate that they are shared, e.g. t600x-j314-j416.dtsi

[chadmed]

I have pulled in @jannau's fixes and squashed the fan changes into a single commit adding all the "common" files. I have also split out each SoC into a separate commit and completely removed keys that were not readable on any of the machines I have access to.

EDIT: also rebased

[jannau]

I've pulled the code into bits/110-smc but haven't merged any of the hwmon devicetree changes. Mostly over the CPU core temp sensors. I still not convinced that there are temp sensors for the efficiency cores. I can't identify any temp sensor with a clear temp increase signal when running a CPU stressor on any of the efficiency cores. I would expect that ~0.6 W power use on the area of an efficiency core would be clearly identifiable.

misc issues spotted so far: hwmon-t8112.dtsi has only 7 CPU core sensors, we can't use t600x / t602x as includes since we need to handle M1 / M2 Ultra separately, we should think about how we can handle disabled CPU cores like on M1/M2 Pro.

[chadmed]

I agree with not merging the DT changes until we figure out more stuff. FWIW, the reason t8112 lost a sensor is because I have no t8112 devices where the dropped CPU temp sensor was able to be read, and part of the final cleanup I did was getting rid of stuff that I could not verify as working on any hardware.

Same deal with the ecore sensors on t8112 - I could not get them to light up with an ecore load however they did materially change when burning even one of the pcores... The only solution here may be to brute force every T*** combination with a m1n1 experiment or something :/