On 6/1/23 10:11, Linus Walleij wrote:
On Thu, Jun 1, 2023 at 5:48 PM Hawkins, Nick <nick.hawkins@xxxxxxx> wrote:
Thank you for your valuable feedback with the solutions you have provided.
Before I proceed though I have a quick query about the fan driver.
If I were to let the user space "own" gpio pins, would it be permissible for
the userspace to feed a kernel driver data via sysfs?
Ex:
GPIO Driver -> (OpenBMC) -> Fandriver (sysfs).
Here the GPIO driver would provide fan presence information to OpenBMC
and then OpenBMC would provide fan presence info to the fan driver.
But why? Don't be so obsessed about userspace doing stuff using
sysfs, usually it is a better idea to let the kernel handle hardware.
I think this is a simple thermal zone you can define in the device
tree as indicated in my previous comment.
If it were permissible to provide data to the driver via this method I could
apply it to the PSU driver as well. the PSU driver which requires presence
info to verify a PSU is inserted / removed.
It feels like you are looking for a way for two drivers to communicate
with each other.
This can be done several ways, the most straight-forward is notifiers.
include/linux/notifier.h
This is all unnecessary. The hwmon driver could register a gpio pin,
including interrupt, and then report state changes to userspace with
sysfs or udev events on the registered hwmon sysfs attributes.
If they really want to use userspace for everything, they should
just use userspace for everything and not bother with a kernel driver.
Guenter
