On 4/26/22 08:26, Eddie James wrote:
On 4/26/22 10:01, Guenter Roeck wrote:
On 4/26/22 07:45, Eddie James wrote:
Instead of polling the OCC during the probe, use the "occ_active"
sysfs file to control when the driver polls the OCC for sensor data.
The reason for this change is that the SBE, which is the device by
which the driver communicates with the OCC, cannot handle communications
during certain system state transitions.
This is hackish, to say the least. Why not just instantiate the driver
manually instead if userspace interaction is indeed needed, and there
is no means to auto-instantiate it only after the hardware is ready ?
Well, the occ-hwmon platform devices are currently created by the parent FSI occ device (that's a bit of a hack too). I poked through the platform/device/bus interfaces but couldn't work out how to create the device but not probe it, so that userspace could later bind the device to the driver. The current userspace does just that, but it relies on the the initial probe failing since SBE can't handle the communications yet. The error scenario is that the SBE can get into a bad state, so communications shouldn't even be attempted.
So to answer your question, there's no reason not to just instantiate the driver manually, but I don't actually know how to do so with these drivers.
On the other side, what means does userspace have to determine that
the SBE/OCC is ready ? Can't that same mechanism not be used in the
kernel to auto-instantiate the driver ?
No it's impossible, it's not just some bit we can check in HW unfortunately, the signal is PLDM (platform level data model) over the network.
What a mess.
The subject and description are misleading. The code doesn't
"avoid polling during probe", it delays hwmon registration until
directed to do it by writing into a new sysfs attribute.
Please update accordingly.
Thanks,
Guenter
