| Message ID | 20240120-ktd2801-v3-1-fe2cbafffb21@skole.hr |
|---|---|
| State | New |
| Headers | show |
| Series | Kinetic ExpressWire library and KTD2801 backlight driver | expand |
On Sat, Jan 20, 2024 at 10:27 PM Duje Mihanović <duje.mihanovic@skole.hr> wrote: > The ExpressWire protocol is shared between at least KTD2692 and KTD2801 > with slight differences such as timings and the former not having a > defined set of pulses for enabling the protocol (possibly because it > does not support PWM unlike KTD2801). Despite these differences the > ExpressWire handling code can be shared between the two, so move it into > a library in preparation for adding KTD2801 support. > > Suggested-by: Daniel Thompson <daniel.thompson@linaro.org> > Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr> This is great stuff. I looked at my KTD253 driver but AFAICT it uses a different method: instead of transferring a numeral, it increases/decreases a counter, so it can't use the library. > +extern void expresswire_power_off(struct expresswire_common_props *props); > +extern void expresswire_enable(struct expresswire_common_props *props); > +extern void expresswire_start(struct expresswire_common_props *props); > +extern void expresswire_end(struct expresswire_common_props *props); > +extern void expresswire_set_bit(struct expresswire_common_props *props, bool bit); I would skip the keyword "extern" since it is default I think even checkpatch complains about it these days? Anyway, no big deal: Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Sunday, January 21, 2024 3:35:46 PM CET Linus Walleij wrote: > > +extern void expresswire_power_off(struct expresswire_common_props *props); > > +extern void expresswire_enable(struct expresswire_common_props *props); > > +extern void expresswire_start(struct expresswire_common_props *props); > > +extern void expresswire_end(struct expresswire_common_props *props); > > +extern void expresswire_set_bit(struct expresswire_common_props *props, > > bool bit); > I would skip the keyword "extern" since it is default I think even > checkpatch complains about it these days? Doesn't seem to, I tried it myself: $ git format-patch HEAD~3 0001-leds-ktd2692-move-ExpressWire-code-to-library.patch 0002-dt-bindings-backlight-add-Kinetic-KTD2801-binding.patch 0003-backlight-Add-Kinetic-KTD2801-backlight-support.patch $ ./scripts/checkpatch.pl 0001-leds-ktd2692-move-ExpressWire-code-to- library.patch total: 0 errors, 0 warnings, 291 lines checked 0001-leds-ktd2692-move-ExpressWire-code-to-library.patch has no obvious style problems and is ready for submission. I'll keep that in mind if a v4 is needed though. Regards, -- Duje
On Sat, Jan 20, 2024 at 10:26:43PM +0100, Duje Mihanović wrote: > The ExpressWire protocol is shared between at least KTD2692 and KTD2801 > with slight differences such as timings and the former not having a > defined set of pulses for enabling the protocol (possibly because it > does not support PWM unlike KTD2801). Despite these differences the > ExpressWire handling code can be shared between the two, so move it into > a library in preparation for adding KTD2801 support. > > Suggested-by: Daniel Thompson <daniel.thompson@linaro.org> > Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr> > --- > MAINTAINERS | 7 +++ > drivers/leds/Kconfig | 3 ++ > drivers/leds/Makefile | 3 ++ > drivers/leds/flash/Kconfig | 1 + > drivers/leds/flash/leds-ktd2692.c | 91 +++++++++++---------------------------- > drivers/leds/leds-expresswire.c | 59 +++++++++++++++++++++++++ > include/linux/leds-expresswire.h | 35 +++++++++++++++ > 7 files changed, 132 insertions(+), 67 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index a7c4cf8201e0..87b12d2448a0 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7902,6 +7902,13 @@ S: Maintained > T: git git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat.git > F: fs/exfat/ > > +EXPRESSWIRE PROTOCOL LIBRARY > +M: Duje Mihanović <duje.mihanovic@skole.hr> > +L: linux-leds@vger.kernel.org > +S: Maintained > +F: drivers/leds/leds-expresswire.c > +F: include/linux/leds-expresswire.h > + > EXT2 FILE SYSTEM > M: Jan Kara <jack@suse.com> > L: linux-ext4@vger.kernel.org > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > index 6292fddcc55c..d29b6823e7d1 100644 > --- a/drivers/leds/Kconfig > +++ b/drivers/leds/Kconfig > @@ -181,6 +181,9 @@ config LEDS_EL15203000 > To compile this driver as a module, choose M here: the module > will be called leds-el15203000. > > +config LEDS_EXPRESSWIRE > + bool > + Shouldn't there be a "select GPIOLIB" here? It seems odd to make the clients responsible for the dependencies. BTW there seems to be very little consistency across the kernel between "depends on GPIOLIB" and "select GPIOLIB".. but select is marginally more popular (283 vs. 219 in the kernel I checked). > diff --git a/drivers/leds/flash/leds-ktd2692.c b/drivers/leds/flash/leds-ktd2692.c > index 598eee5daa52..8c17de3d621f 100644 > --- a/drivers/leds/flash/leds-ktd2692.c > +++ b/drivers/leds/flash/leds-ktd2692.c > <snip> > static void ktd2692_expresswire_write(struct ktd2692_context *led, u8 value) > { > int i; > > - ktd2692_expresswire_start(led); > + expresswire_start(&led->props); > for (i = 7; i >= 0; i--) > - ktd2692_expresswire_set_bit(led, value & BIT(i)); > - ktd2692_expresswire_end(led); > + expresswire_set_bit(&led->props, value & BIT(i)); > + expresswire_end(&led->props); > } Is there any reason not to have an expresswire_write_u8() method in the library code? It is a concept that appears in both drivers. Daniel.
On Monday, January 22, 2024 11:19:26 AM CET Daniel Thompson wrote: > On Sat, Jan 20, 2024 at 10:26:43PM +0100, Duje Mihanović wrote: > > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > > index 6292fddcc55c..d29b6823e7d1 100644 > > --- a/drivers/leds/Kconfig > > +++ b/drivers/leds/Kconfig > > @@ -181,6 +181,9 @@ config LEDS_EL15203000 > > > > To compile this driver as a module, choose M here: the module > > will be called leds-el15203000. > > > > +config LEDS_EXPRESSWIRE > > + bool > > + > > Shouldn't there be a "select GPIOLIB" here? It seems odd to make the > clients responsible for the dependencies. > > BTW there seems to be very little consistency across the kernel between > "depends on GPIOLIB" and "select GPIOLIB".. but select is marginally > more popular (283 vs. 219 in the kernel I checked). I believe a "select" would be more appropriate here unless these backlights should be hidden if GPIOLIB is disabled. The catch with "select" is that there seems to be no way to throw in the "|| COMPILE_TEST" other GPIO-based backlights have and I'm not sure what to do about that. > > diff --git a/drivers/leds/flash/leds-ktd2692.c > > b/drivers/leds/flash/leds-ktd2692.c index 598eee5daa52..8c17de3d621f 100644 > > --- a/drivers/leds/flash/leds-ktd2692.c > > +++ b/drivers/leds/flash/leds-ktd2692.c > > > > <snip> > > static void ktd2692_expresswire_write(struct ktd2692_context *led, u8 > > value) > > { > > > > int i; > > > > - ktd2692_expresswire_start(led); > > + expresswire_start(&led->props); > > > > for (i = 7; i >= 0; i--) > > > > - ktd2692_expresswire_set_bit(led, value & BIT(i)); > > - ktd2692_expresswire_end(led); > > + expresswire_set_bit(&led->props, value & BIT(i)); > > + expresswire_end(&led->props); > > > > } > > Is there any reason not to have an expresswire_write_u8() method in the > library code? It is a concept that appears in both drivers. Not really, I'll add it in v4. Regards, -- Duje
On Mon, Jan 22, 2024 at 05:24:51PM +0100, Duje Mihanović wrote: > On Monday, January 22, 2024 11:19:26 AM CET Daniel Thompson wrote: > > On Sat, Jan 20, 2024 at 10:26:43PM +0100, Duje Mihanović wrote: > > > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > > > index 6292fddcc55c..d29b6823e7d1 100644 > > > --- a/drivers/leds/Kconfig > > > +++ b/drivers/leds/Kconfig > > > @@ -181,6 +181,9 @@ config LEDS_EL15203000 > > > > > > To compile this driver as a module, choose M here: the module > > > will be called leds-el15203000. > > > > > > +config LEDS_EXPRESSWIRE > > > + bool > > > + > > > > Shouldn't there be a "select GPIOLIB" here? It seems odd to make the > > clients responsible for the dependencies. > > > > BTW there seems to be very little consistency across the kernel between > > "depends on GPIOLIB" and "select GPIOLIB".. but select is marginally > > more popular (283 vs. 219 in the kernel I checked). > > I believe a "select" would be more appropriate here unless these backlights > should be hidden if GPIOLIB is disabled. The catch with "select" is that there > seems to be no way to throw in the "|| COMPILE_TEST" other GPIO-based > backlights have and I'm not sure what to do about that. I think the "|| COMPILE_TEST" might just be a copy 'n paste'ism (in fact I may even have been guilty off propagating it in reviews when checking for inconsistencies). AFAICT nothing will inhibit setting GPIOLIB so allyes- and allmodconfig builds will always end up with GPIOLIB enabled. If we are happy to select it then I think that is enough! Daniel.
diff --git a/MAINTAINERS b/MAINTAINERS index a7c4cf8201e0..87b12d2448a0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7902,6 +7902,13 @@ S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat.git F: fs/exfat/ +EXPRESSWIRE PROTOCOL LIBRARY +M: Duje Mihanović <duje.mihanovic@skole.hr> +L: linux-leds@vger.kernel.org +S: Maintained +F: drivers/leds/leds-expresswire.c +F: include/linux/leds-expresswire.h + EXT2 FILE SYSTEM M: Jan Kara <jack@suse.com> L: linux-ext4@vger.kernel.org diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index 6292fddcc55c..d29b6823e7d1 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -181,6 +181,9 @@ config LEDS_EL15203000 To compile this driver as a module, choose M here: the module will be called leds-el15203000. +config LEDS_EXPRESSWIRE + bool + config LEDS_TURRIS_OMNIA tristate "LED support for CZ.NIC's Turris Omnia" depends on LEDS_CLASS_MULTICOLOR diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index d7348e8bc019..a63a07d01c6f 100644 --- a/drivers/leds/Makefile +++ b/drivers/leds/Makefile @@ -89,6 +89,9 @@ obj-$(CONFIG_LEDS_WM831X_STATUS) += leds-wm831x-status.o obj-$(CONFIG_LEDS_WM8350) += leds-wm8350.o obj-$(CONFIG_LEDS_WRAP) += leds-wrap.o +# Kinetic ExpressWire Protocol +obj-$(CONFIG_LEDS_EXPRESSWIRE) += leds-expresswire.o + # LED SPI Drivers obj-$(CONFIG_LEDS_CR0014114) += leds-cr0014114.o obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o diff --git a/drivers/leds/flash/Kconfig b/drivers/leds/flash/Kconfig index 4e08dbc05709..526c1d063cd8 100644 --- a/drivers/leds/flash/Kconfig +++ b/drivers/leds/flash/Kconfig @@ -24,6 +24,7 @@ config LEDS_KTD2692 tristate "LED support for Kinetic KTD2692 flash LED controller" depends on OF depends on GPIOLIB || COMPILE_TEST + select LEDS_EXPRESSWIRE help This option enables support for Kinetic KTD2692 LED flash connected through ExpressWire interface. diff --git a/drivers/leds/flash/leds-ktd2692.c b/drivers/leds/flash/leds-ktd2692.c index 598eee5daa52..8c17de3d621f 100644 --- a/drivers/leds/flash/leds-ktd2692.c +++ b/drivers/leds/flash/leds-ktd2692.c @@ -9,6 +9,7 @@ #include <linux/delay.h> #include <linux/err.h> #include <linux/gpio/consumer.h> +#include <linux/leds-expresswire.h> #include <linux/led-class-flash.h> #include <linux/module.h> #include <linux/mutex.h> @@ -48,11 +49,6 @@ /* KTD2692 default length of name */ #define KTD2692_NAME_LENGTH 20 -enum ktd2692_bitset { - KTD2692_LOW = 0, - KTD2692_HIGH, -}; - /* Movie / Flash Mode Control */ enum ktd2692_led_mode { KTD2692_MODE_DISABLE = 0, /* default */ @@ -71,7 +67,19 @@ struct ktd2692_led_config_data { enum led_brightness max_brightness; }; +const struct expresswire_timing ktd2692_timing = { + .poweroff_us = KTD2692_TIME_RESET_US, + .data_start_us = KTD2692_TIME_DATA_START_TIME_US, + .end_of_data_low_us = KTD2692_TIME_LOW_END_OF_DATA_US, + .end_of_data_high_us = KTD2692_TIME_HIGH_END_OF_DATA_US, + .short_bitset_us = KTD2692_TIME_SHORT_BITSET_US, + .long_bitset_us = KTD2692_TIME_LONG_BITSET_US +}; + struct ktd2692_context { + /* Common ExpressWire properties (ctrl GPIO and timing) */ + struct expresswire_common_props props; + /* Related LED Flash class device */ struct led_classdev_flash fled_cdev; @@ -80,7 +88,6 @@ struct ktd2692_context { struct regulator *regulator; struct gpio_desc *aux_gpio; - struct gpio_desc *ctrl_gpio; enum ktd2692_led_mode mode; enum led_brightness torch_brightness; @@ -92,65 +99,14 @@ static struct ktd2692_context *fled_cdev_to_led( return container_of(fled_cdev, struct ktd2692_context, fled_cdev); } -static void ktd2692_expresswire_start(struct ktd2692_context *led) -{ - gpiod_direction_output(led->ctrl_gpio, KTD2692_HIGH); - udelay(KTD2692_TIME_DATA_START_TIME_US); -} - -static void ktd2692_expresswire_reset(struct ktd2692_context *led) -{ - gpiod_direction_output(led->ctrl_gpio, KTD2692_LOW); - udelay(KTD2692_TIME_RESET_US); -} - -static void ktd2692_expresswire_end(struct ktd2692_context *led) -{ - gpiod_direction_output(led->ctrl_gpio, KTD2692_LOW); - udelay(KTD2692_TIME_LOW_END_OF_DATA_US); - gpiod_direction_output(led->ctrl_gpio, KTD2692_HIGH); - udelay(KTD2692_TIME_HIGH_END_OF_DATA_US); -} - -static void ktd2692_expresswire_set_bit(struct ktd2692_context *led, bool bit) -{ - /* - * The Low Bit(0) and High Bit(1) is based on a time detection - * algorithm between time low and time high - * Time_(L_LB) : Low time of the Low Bit(0) - * Time_(H_LB) : High time of the LOW Bit(0) - * Time_(L_HB) : Low time of the High Bit(1) - * Time_(H_HB) : High time of the High Bit(1) - * - * It can be simplified to: - * Low Bit(0) : 2 * Time_(H_LB) < Time_(L_LB) - * High Bit(1) : 2 * Time_(L_HB) < Time_(H_HB) - * HIGH ___ ____ _.. _________ ___ - * |_________| |_.. |____| |__| - * LOW <L_LB> <H_LB> <L_HB> <H_HB> - * [ Low Bit (0) ] [ High Bit(1) ] - */ - if (bit) { - gpiod_direction_output(led->ctrl_gpio, KTD2692_LOW); - udelay(KTD2692_TIME_SHORT_BITSET_US); - gpiod_direction_output(led->ctrl_gpio, KTD2692_HIGH); - udelay(KTD2692_TIME_LONG_BITSET_US); - } else { - gpiod_direction_output(led->ctrl_gpio, KTD2692_LOW); - udelay(KTD2692_TIME_LONG_BITSET_US); - gpiod_direction_output(led->ctrl_gpio, KTD2692_HIGH); - udelay(KTD2692_TIME_SHORT_BITSET_US); - } -} - static void ktd2692_expresswire_write(struct ktd2692_context *led, u8 value) { int i; - ktd2692_expresswire_start(led); + expresswire_start(&led->props); for (i = 7; i >= 0; i--) - ktd2692_expresswire_set_bit(led, value & BIT(i)); - ktd2692_expresswire_end(led); + expresswire_set_bit(&led->props, value & BIT(i)); + expresswire_end(&led->props); } static int ktd2692_led_brightness_set(struct led_classdev *led_cdev, @@ -163,7 +119,7 @@ static int ktd2692_led_brightness_set(struct led_classdev *led_cdev, if (brightness == LED_OFF) { led->mode = KTD2692_MODE_DISABLE; - gpiod_direction_output(led->aux_gpio, KTD2692_LOW); + gpiod_direction_output(led->aux_gpio, 0); } else { ktd2692_expresswire_write(led, brightness | KTD2692_REG_MOVIE_CURRENT_BASE); @@ -191,10 +147,10 @@ static int ktd2692_led_flash_strobe_set(struct led_classdev_flash *fled_cdev, | KTD2692_REG_FLASH_TIMEOUT_BASE); led->mode = KTD2692_MODE_FLASH; - gpiod_direction_output(led->aux_gpio, KTD2692_HIGH); + gpiod_direction_output(led->aux_gpio, 1); } else { led->mode = KTD2692_MODE_DISABLE; - gpiod_direction_output(led->aux_gpio, KTD2692_LOW); + gpiod_direction_output(led->aux_gpio, 0); } ktd2692_expresswire_write(led, led->mode | KTD2692_REG_MODE_BASE); @@ -247,8 +203,8 @@ static void ktd2692_init_flash_timeout(struct led_classdev_flash *fled_cdev, static void ktd2692_setup(struct ktd2692_context *led) { led->mode = KTD2692_MODE_DISABLE; - ktd2692_expresswire_reset(led); - gpiod_direction_output(led->aux_gpio, KTD2692_LOW); + expresswire_power_off(&led->props); + gpiod_direction_output(led->aux_gpio, 0); ktd2692_expresswire_write(led, (KTD2692_MM_MIN_CURR_THRESHOLD_SCALE - 1) | KTD2692_REG_MM_MIN_CURR_THRESHOLD_BASE); @@ -277,8 +233,8 @@ static int ktd2692_parse_dt(struct ktd2692_context *led, struct device *dev, if (!np) return -ENXIO; - led->ctrl_gpio = devm_gpiod_get(dev, "ctrl", GPIOD_ASIS); - ret = PTR_ERR_OR_ZERO(led->ctrl_gpio); + led->props.ctrl_gpio = devm_gpiod_get(dev, "ctrl", GPIOD_ASIS); + ret = PTR_ERR_OR_ZERO(led->props.ctrl_gpio); if (ret) return dev_err_probe(dev, ret, "cannot get ctrl-gpios\n"); @@ -412,6 +368,7 @@ static struct platform_driver ktd2692_driver = { module_platform_driver(ktd2692_driver); +MODULE_IMPORT_NS(EXPRESSWIRE); MODULE_AUTHOR("Ingi Kim <ingi2.kim@samsung.com>"); MODULE_DESCRIPTION("Kinetic KTD2692 LED driver"); MODULE_LICENSE("GPL v2"); diff --git a/drivers/leds/leds-expresswire.c b/drivers/leds/leds-expresswire.c new file mode 100644 index 000000000000..88e76c968cf0 --- /dev/null +++ b/drivers/leds/leds-expresswire.c @@ -0,0 +1,59 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Shared library for Kinetic's ExpressWire protocol. + * This protocol works by pulsing the ExpressWire IC's control GPIO. + * ktd2692 and ktd2801 are known to use this protocol. + */ + +#include <linux/delay.h> +#include <linux/gpio/consumer.h> +#include <linux/leds-expresswire.h> + +void expresswire_power_off(struct expresswire_common_props *props) +{ + gpiod_set_value_cansleep(props->ctrl_gpio, 0); + usleep_range(props->timing.poweroff_us, props->timing.poweroff_us * 2); +} +EXPORT_SYMBOL_NS_GPL(expresswire_power_off, EXPRESSWIRE); + +void expresswire_enable(struct expresswire_common_props *props) +{ + gpiod_set_value(props->ctrl_gpio, 1); + udelay(props->timing.detect_delay_us); + gpiod_set_value(props->ctrl_gpio, 0); + udelay(props->timing.detect_us); + gpiod_set_value(props->ctrl_gpio, 1); +} +EXPORT_SYMBOL_NS_GPL(expresswire_enable, EXPRESSWIRE); + +void expresswire_start(struct expresswire_common_props *props) +{ + gpiod_set_value(props->ctrl_gpio, 1); + udelay(props->timing.data_start_us); +} +EXPORT_SYMBOL_NS_GPL(expresswire_start, EXPRESSWIRE); + +void expresswire_end(struct expresswire_common_props *props) +{ + gpiod_set_value(props->ctrl_gpio, 0); + udelay(props->timing.end_of_data_low_us); + gpiod_set_value(props->ctrl_gpio, 1); + udelay(props->timing.end_of_data_high_us); +} +EXPORT_SYMBOL_NS_GPL(expresswire_end, EXPRESSWIRE); + +void expresswire_set_bit(struct expresswire_common_props *props, bool bit) +{ + if (bit) { + gpiod_set_value(props->ctrl_gpio, 0); + udelay(props->timing.short_bitset_us); + gpiod_set_value(props->ctrl_gpio, 1); + udelay(props->timing.long_bitset_us); + } else { + gpiod_set_value(props->ctrl_gpio, 0); + udelay(props->timing.long_bitset_us); + gpiod_set_value(props->ctrl_gpio, 1); + udelay(props->timing.short_bitset_us); + } +} +EXPORT_SYMBOL_NS_GPL(expresswire_set_bit, EXPRESSWIRE); diff --git a/include/linux/leds-expresswire.h b/include/linux/leds-expresswire.h new file mode 100644 index 000000000000..b5aad0556cb8 --- /dev/null +++ b/include/linux/leds-expresswire.h @@ -0,0 +1,35 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Shared library for Kinetic's ExpressWire protocol. + * This protocol works by pulsing the ExpressWire IC's control GPIO. + * ktd2692 and ktd2801 are known to use this protocol. + */ + +#ifndef _LEDS_EXPRESSWIRE_H +#define _LEDS_EXPRESSWIRE_H + +#include <linux/gpio/consumer.h> + +struct expresswire_timing { + unsigned long poweroff_us; + unsigned long detect_delay_us; + unsigned long detect_us; + unsigned long data_start_us; + unsigned long end_of_data_low_us; + unsigned long end_of_data_high_us; + unsigned long short_bitset_us; + unsigned long long_bitset_us; +}; + +struct expresswire_common_props { + struct gpio_desc *ctrl_gpio; + struct expresswire_timing timing; +}; + +extern void expresswire_power_off(struct expresswire_common_props *props); +extern void expresswire_enable(struct expresswire_common_props *props); +extern void expresswire_start(struct expresswire_common_props *props); +extern void expresswire_end(struct expresswire_common_props *props); +extern void expresswire_set_bit(struct expresswire_common_props *props, bool bit); + +#endif /* _LEDS_EXPRESSWIRE_H */
The ExpressWire protocol is shared between at least KTD2692 and KTD2801 with slight differences such as timings and the former not having a defined set of pulses for enabling the protocol (possibly because it does not support PWM unlike KTD2801). Despite these differences the ExpressWire handling code can be shared between the two, so move it into a library in preparation for adding KTD2801 support. Suggested-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr> --- MAINTAINERS | 7 +++ drivers/leds/Kconfig | 3 ++ drivers/leds/Makefile | 3 ++ drivers/leds/flash/Kconfig | 1 + drivers/leds/flash/leds-ktd2692.c | 91 +++++++++++---------------------------- drivers/leds/leds-expresswire.c | 59 +++++++++++++++++++++++++ include/linux/leds-expresswire.h | 35 +++++++++++++++ 7 files changed, 132 insertions(+), 67 deletions(-)