PSUSensorMain Creates PWM Sensors with paths to RPM hwmon File

[kaehnd]

PSUSensorMain tries to create a PWM Sensor for PSU fans if it can find a corresponding fan*_target file to a fan*_input sysfs file.
https://github.com/openbmc/dbus-sensors/blob/master/src/PSUSensorMain.cpp#L256

However, the kernel documentation indicates that the _target file is for fan speed in RPM.
https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface

Posting this issue here rather than just submitting a Gerrit PR since it appears that some EntityManger configurations do exist for PSUs that appear to be using phosphor-pid-control to control the PSU fans. Would changing the behavior of PSUSensorMain to search for pwm* instead of fan*_target break any existing platforms / configurations (a.e. do those PSUs have non-standard interfaces / drivers which require sending fan speed in PWM while in RPM mode?)

If this is indeed a bug, would we want to try to instantiate the PWMSensor using the pwm* file if it exists? I ask this because it seems the only driver in the mainline or openbmc linux kernel which provides pwm control over pmbus is the max31785 fancontroller driver -- all pmbus PSU drivers appear to only support configuring the fan speed in RPM. Would we want to add support for the xyz.openbmc_project.Control.FanSpeed interface to TachSensor, and use that instead for PSU fans?

A separate but related issue is that this PwmSensor is instantiated at the fan*_target regardless of if this file is readonly -- which is the case when pmbus_core determines that the pmbus device is write protected.

[kaehnd]

I finally did a little brute-force investigating on this one...

These PRs imply that this was indeed a well-tested feature, and that there are some driver / hardware idiosyncrasies that don't match up with what the sysfs interface seems to imply...

This first PR implies that it was expected that fan PWM for a PSU was controlled through fanX_target...
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/20372

And further, here, that the range is 0-100 instead of 0-255 for some/all of these PSU sysfs interfaces...
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/36050

Searching through the OpenBMC-forked or upstream kernel, I wasn't able to find any drivers under drivers/hwmon that explicitly expose the fanX_target as a PWM control file instead of an RPM control file (though I did not truly read every driver, mostly just did grepping and one-off passes through drivers...) Further it appears that all of the Entity Manager configurations with use fan PID loops for PSUs use the generic PMBus driver (a.e. this one)

My only hypothesis about how this could be working for some hardware / use-cases is that those PSUs only support fan speed configuration in PWM, and so the FAN_CONFIG_X command which pmbus_update_fan sends to change between PWM and RPM mode if requested is ignored by the PSU (shown here), allowing the driver to think it's writing an RPM value, when it's actually writing a PWM value, and allowing someone from userspace to use the fanX_target file as a PWM control file...

Unfortunately, I wasn't able to find datasheets containing the supported PMBus commands for any of the PSUs which have Entity Manager configurations that imply PSU fan control, so I wasn't able to confirm if this is the case, or if maybe the users of this feature are using proprietary patches / drivers which change the pmbus_core functionality...

Would either @cyang29 or @kuiyingw (authors of the above PRs) possibly be able to shed any light on this? (or confirm whether the PSUs that the changes were tested with supported the FAN_CONFIG_X command?)