On Thu, Nov 14, 2013 at 5:24 PM, Guenter Roeck <[email protected]> wrote: > > On Thu, Nov 14, 2013 at 02:51:01PM +0000, Laszlo Papp wrote: > > It is necessary for end users when they are using the gpio pins connected > > to the > > fan controller. There is a separate gpiodef register provided, but it is > > unused > > under the usual circumstances and that is probably the reason why this > > feature > > has not been added before. It is necessary for our board to function > > properly. > > > > Signed-off-by: Laszlo Papp <[email protected]> > > --- > > Documentation/hwmon/max6650 | 5 +++ > > drivers/hwmon/max6650.c | 107 > > ++++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 112 insertions(+) > > > > diff --git a/Documentation/hwmon/max6650 b/Documentation/hwmon/max6650 > > index 58d9644..32c69a8 100644 > > --- a/Documentation/hwmon/max6650 > > +++ b/Documentation/hwmon/max6650 > > @@ -39,6 +39,11 @@ pwm1 rw relative speed (0-255), > > 255=max. speed. > > fan1_div rw sets the speed range the inputs can handle. Legal > > values are 1, 2, 4, and 8. Use lower values for > > faster fans. > > +gpio0 rw sets the gpio 0 PIN. Legal values are 0, 1, 2, and 3. > > +gpio1 rw sets the gpio 1 PIN. Legal values are 0, 1, 2, and 3. > > +gpio2 rw sets the gpio 2 PIN. Legal values are 0, 1, 2, and 3. > > +gpio3 rw sets the gpio 3 PIN. Legal values are 0, and 1. > > +gpio4 rw sets the gpio 4 PIN. Legal values are 0, and 1. > > > gpio pins should be exported through the gpio subsystem, usually with a gpio > driver. In this case, it may be acceptable to have the driver register with > the gpio subsystem to export the pins. Using local sysfs attributes is wrong > and unacceptable.
In short: I am not sure. My concern is that these are not generic gpio pins. They seem to have chip specific functionality, like alarm, full-on, and clock (internal and external). Strictly speaking, one could even mention that to expose the GPIODEF register as is without splitting it into five separate gpio pin entries. Even those five pins behave slightly differently. I considered both, but these are the reasons why I decided to keep it chip specific rather than separately in a generic subsystem. Cheers, Laszlo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
