> This is just one use case of those, you could also use it for > non-generic gpio functionality, like alarm, "full-on", internal clock, > external clock, etc. I believe it is always a bit tricky with MFD. I > personally prefer to put it into the chip driver because this is not > clearly a generic gpio interface here, and I need to drive it > dynamically. I agree. I think the solution with expose the "GPIOs" in sysfs is the right way to go. The chip-function is of a dynamic nature and should therefor not be set in platform data / devicetree. As mentioned before, GPIOs should use the gpio subsystem whenever possible, but the the gpio-functionality is just a subset of functions these pins may be set to. Also, the I think the *real* reason why the entries is called "gpio" is that it is so the registers are are mentioned in the datasheet. Everyone that is working with the device will know what it is all about. I see it more as an register expose than a gpio interface... I agree that the entries does not really fit here. But they does not fit better elsewhere either. And I don't think they fit worse than the alarm-entries that is already in mainline. Anyway, I think the documentation file should mention what function each valid value represent. Cheers Marcus Folkesson _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
