> If the host wants to own the fan status from gpio pins, it has to live up to > it and own it entirely. The kernel hwmon driver does not have access in that > case. > In a more "normal" world, the hwmon driver would "own" the gpio pin(s) > and user space would listen to associated hwmon attribute events (presumably > fan_enable and fan_fault), either by listening for sysfs attribute events > or via udev or both. Again, if you don't want to do that, and want user space > to have access to the raw gpio pins, you'll have to live with the consequences. > I don't see the need to bypass existing mechanisms just because user space > programmers want direct access to gpio pins. Greetings Guenter, 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. 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. Thanks, -Nick Hawkins
