Messages in this thread | | | Date | Tue, 19 Nov 2013 16:42:49 +0000 | Subject | Re: [PATCH] hwmon: (max6650) Add support for gpiodef | From | Laszlo Papp <> |
| |
On Fri, Nov 15, 2013 at 7:52 PM, Marcus Folkesson <marcus.folkesson@gmail.com> wrote: > >> 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.
Yes, makes sense to make the documentation more comprehensive. Thanks.
Any other issues from anyone before submitting a polished version?
| |