Re: [RFC PATCH 14/17] input: RMI4 F30 GPIO/LED control
On 08/27/2012 03:58 PM, Linus Walleij wrote: GPIO/LED, nice since I'm a GPIO maintainer I'll take a closer look. If the bus will start doing a lot of non-input business it should live under drivers/mfd but I think this is just one exception, right? On Fri, Aug 17, 2012 at 3:17 PM, Christopher Heiny wrote: (...) diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c +#include +#include +#include +#include +#include "rmi_driver.h" The non-existance of and tells us that something is very wrong. You should not model these GPIOs and LEDs by a set of obscure sysfs attributes, instead use the proper kernel subsystems that already exist for handling this! LEDs and GPIOs already have their own (standardized) userspace sysfs interfaces. Reading the code I see that this is what happens here, so please rewrite this to be a real GPIO+LED driver using struct gpio_chip and the same for LEDs. Be inspired by drivers/gpio/* and drivers/leds/* Roger. We'll rework this and resubmit at a later date. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 14/17] input: RMI4 F30 GPIO/LED control
On 08/27/2012 03:58 PM, Linus Walleij wrote: GPIO/LED, nice since I'm a GPIO maintainer I'll take a closer look. If the bus will start doing a lot of non-input business it should live under drivers/mfd but I think this is just one exception, right? On Fri, Aug 17, 2012 at 3:17 PM, Christopher Heiny che...@synaptics.com wrote: (...) diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c +#include linux/kernel.h +#include linux/rmi.h +#include linux/input.h +#include linux/slab.h +#include rmi_driver.h The non-existance of linux/gpio.h and linux/leds.h tells us that something is very wrong. You should not model these GPIOs and LEDs by a set of obscure sysfs attributes, instead use the proper kernel subsystems that already exist for handling this! LEDs and GPIOs already have their own (standardized) userspace sysfs interfaces. Reading the code I see that this is what happens here, so please rewrite this to be a real GPIO+LED driver using struct gpio_chip and the same for LEDs. Be inspired by drivers/gpio/* and drivers/leds/* Roger. We'll rework this and resubmit at a later date. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 14/17] input: RMI4 F30 GPIO/LED control
GPIO/LED, nice since I'm a GPIO maintainer I'll take a closer look. If the bus will start doing a lot of non-input business it should live under drivers/mfd but I think this is just one exception, right? On Fri, Aug 17, 2012 at 3:17 PM, Christopher Heiny wrote: (...) > diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c > +#include > +#include > +#include > +#include > +#include "rmi_driver.h" The non-existance of and tells us that something is very wrong. You should not model these GPIOs and LEDs by a set of obscure sysfs attributes, instead use the proper kernel subsystems that already exist for handling this! LEDs and GPIOs already have their own (standardized) userspace sysfs interfaces. Reading the code I see that this is what happens here, so please rewrite this to be a real GPIO+LED driver using struct gpio_chip and the same for LEDs. Be inspired by drivers/gpio/* and drivers/leds/* Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 14/17] input: RMI4 F30 GPIO/LED control
GPIO/LED, nice since I'm a GPIO maintainer I'll take a closer look. If the bus will start doing a lot of non-input business it should live under drivers/mfd but I think this is just one exception, right? On Fri, Aug 17, 2012 at 3:17 PM, Christopher Heiny che...@synaptics.com wrote: (...) diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c +#include linux/kernel.h +#include linux/rmi.h +#include linux/input.h +#include linux/slab.h +#include rmi_driver.h The non-existance of linux/gpio.h and linux/leds.h tells us that something is very wrong. You should not model these GPIOs and LEDs by a set of obscure sysfs attributes, instead use the proper kernel subsystems that already exist for handling this! LEDs and GPIOs already have their own (standardized) userspace sysfs interfaces. Reading the code I see that this is what happens here, so please rewrite this to be a real GPIO+LED driver using struct gpio_chip and the same for LEDs. Be inspired by drivers/gpio/* and drivers/leds/* Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
