Re: [PATCH 05/16] arch: remove blackfin port
Personally Blackfin Linux is my most special memory. Thanks a lot for the folks from community and contributors from all over the world. Acked-by: Bryan Wu <coolo...@gmail.com> On Wed, Mar 14, 2018 at 10:36 PM, Arnd Bergmann <a...@arndb.de> wrote: > The Analog Devices Blackfin port was added in 2007 and was rather > active for a while, but all work on it has come to a standstill > over time, as Analog have changed their product line-up. > > Aaron Wu confirmed that the architecture port is no longer relevant, > and multiple people suggested removing blackfin independently because > of some of its oddities like a non-working SMP port, and the amount of > duplication between the chip variants, which cause extra work when > doing cross-architecture changes. > > Link: https://docs.blackfin.uclinux.org/ > Acked-by: Wu, Aaron <aaron...@analog.com> > Cc: Bryan Wu <coolo...@gmail.com> > Cc: Steven Miao <real...@gmail.com> > Cc: Mike Frysinger <vap...@chromium.org> > Signed-off-by: Arnd Bergmann <a...@arndb.de> > --- > Documentation/00-INDEX |2 - > Documentation/admin-guide/kernel-parameters.rst|1 - > Documentation/admin-guide/kernel-parameters.txt|2 +- > Documentation/blackfin/00-INDEX|6 - > Documentation/blackfin/bfin-gpio-notes.txt | 71 - > Documentation/blackfin/bfin-spi-notes.txt | 16 - > MAINTAINERS| 45 - > arch/blackfin/Clear_BSD.txt| 33 - > arch/blackfin/Kconfig | 1463 > arch/blackfin/Kconfig.debug| 258 -- > arch/blackfin/Makefile | 168 - > arch/blackfin/boot/.gitignore |3 - > arch/blackfin/boot/Makefile| 71 - > arch/blackfin/boot/install.sh | 57 - > arch/blackfin/configs/BF518F-EZBRD_defconfig | 121 - > arch/blackfin/configs/BF526-EZBRD_defconfig| 158 - > arch/blackfin/configs/BF527-AD7160-EVAL_defconfig | 104 - > arch/blackfin/configs/BF527-EZKIT-V2_defconfig | 188 - > arch/blackfin/configs/BF527-EZKIT_defconfig| 181 - > arch/blackfin/configs/BF527-TLL6527M_defconfig | 178 - > arch/blackfin/configs/BF533-EZKIT_defconfig| 114 - > arch/blackfin/configs/BF533-STAMP_defconfig| 124 - > arch/blackfin/configs/BF537-STAMP_defconfig| 136 - > arch/blackfin/configs/BF538-EZKIT_defconfig| 133 - > arch/blackfin/configs/BF548-EZKIT_defconfig| 207 -- > arch/blackfin/configs/BF561-ACVILON_defconfig | 149 - > arch/blackfin/configs/BF561-EZKIT-SMP_defconfig| 112 - > arch/blackfin/configs/BF561-EZKIT_defconfig| 114 - > arch/blackfin/configs/BF609-EZKIT_defconfig| 154 - > arch/blackfin/configs/BlackStamp_defconfig | 108 - > arch/blackfin/configs/CM-BF527_defconfig | 129 - > arch/blackfin/configs/CM-BF533_defconfig | 76 - > arch/blackfin/configs/CM-BF537E_defconfig | 107 - > arch/blackfin/configs/CM-BF537U_defconfig | 96 - > arch/blackfin/configs/CM-BF548_defconfig | 170 - > arch/blackfin/configs/CM-BF561_defconfig | 104 - > arch/blackfin/configs/DNP5370_defconfig| 118 - > arch/blackfin/configs/H8606_defconfig | 87 - > arch/blackfin/configs/IP0X_defconfig | 91 - > arch/blackfin/configs/PNAV-10_defconfig| 111 - > arch/blackfin/configs/SRV1_defconfig | 88 - > arch/blackfin/configs/TCM-BF518_defconfig | 131 - > arch/blackfin/configs/TCM-BF537_defconfig | 95 - > arch/blackfin/include/asm/Kbuild | 28 - > arch/blackfin/include/asm/asm-offsets.h|1 - > arch/blackfin/include/asm/atomic.h | 47 - > arch/blackfin/include/asm/barrier.h| 86 - > arch/blackfin/include/asm/bfin-global.h| 95 - > arch/blackfin/include/asm/bfin-lq035q1.h | 40 - > arch/blackfin/include/asm/bfin5xx_spi.h| 86 - > arch/blackfin/include/asm/bfin_can.h | 728 > arch/blackfin/include/asm/bfin_dma.h | 165 - > arch/blackfin/include/asm/bfin_pfmon.h | 44 - > arch/blackfin/include/asm/bfin_ppi.h | 181 - > arch/blackfin/include/asm/bfin_sdh.h | 161 - > arch/blackfin/include/asm/bfin_serial.h| 429 --- > arch/blackfin/include/asm/bfin_simple_timer.h | 27 - > arch/blackfin/include/asm/bfin_sport.h | 71 - > arch/blackfin/inc
Re: [PATCH 05/16] arch: remove blackfin port
Personally Blackfin Linux is my most special memory. Thanks a lot for the folks from community and contributors from all over the world. Acked-by: Bryan Wu On Wed, Mar 14, 2018 at 10:36 PM, Arnd Bergmann wrote: > The Analog Devices Blackfin port was added in 2007 and was rather > active for a while, but all work on it has come to a standstill > over time, as Analog have changed their product line-up. > > Aaron Wu confirmed that the architecture port is no longer relevant, > and multiple people suggested removing blackfin independently because > of some of its oddities like a non-working SMP port, and the amount of > duplication between the chip variants, which cause extra work when > doing cross-architecture changes. > > Link: https://docs.blackfin.uclinux.org/ > Acked-by: Wu, Aaron > Cc: Bryan Wu > Cc: Steven Miao > Cc: Mike Frysinger > Signed-off-by: Arnd Bergmann > --- > Documentation/00-INDEX |2 - > Documentation/admin-guide/kernel-parameters.rst|1 - > Documentation/admin-guide/kernel-parameters.txt|2 +- > Documentation/blackfin/00-INDEX|6 - > Documentation/blackfin/bfin-gpio-notes.txt | 71 - > Documentation/blackfin/bfin-spi-notes.txt | 16 - > MAINTAINERS| 45 - > arch/blackfin/Clear_BSD.txt| 33 - > arch/blackfin/Kconfig | 1463 > arch/blackfin/Kconfig.debug| 258 -- > arch/blackfin/Makefile | 168 - > arch/blackfin/boot/.gitignore |3 - > arch/blackfin/boot/Makefile| 71 - > arch/blackfin/boot/install.sh | 57 - > arch/blackfin/configs/BF518F-EZBRD_defconfig | 121 - > arch/blackfin/configs/BF526-EZBRD_defconfig| 158 - > arch/blackfin/configs/BF527-AD7160-EVAL_defconfig | 104 - > arch/blackfin/configs/BF527-EZKIT-V2_defconfig | 188 - > arch/blackfin/configs/BF527-EZKIT_defconfig| 181 - > arch/blackfin/configs/BF527-TLL6527M_defconfig | 178 - > arch/blackfin/configs/BF533-EZKIT_defconfig| 114 - > arch/blackfin/configs/BF533-STAMP_defconfig| 124 - > arch/blackfin/configs/BF537-STAMP_defconfig| 136 - > arch/blackfin/configs/BF538-EZKIT_defconfig| 133 - > arch/blackfin/configs/BF548-EZKIT_defconfig| 207 -- > arch/blackfin/configs/BF561-ACVILON_defconfig | 149 - > arch/blackfin/configs/BF561-EZKIT-SMP_defconfig| 112 - > arch/blackfin/configs/BF561-EZKIT_defconfig| 114 - > arch/blackfin/configs/BF609-EZKIT_defconfig| 154 - > arch/blackfin/configs/BlackStamp_defconfig | 108 - > arch/blackfin/configs/CM-BF527_defconfig | 129 - > arch/blackfin/configs/CM-BF533_defconfig | 76 - > arch/blackfin/configs/CM-BF537E_defconfig | 107 - > arch/blackfin/configs/CM-BF537U_defconfig | 96 - > arch/blackfin/configs/CM-BF548_defconfig | 170 - > arch/blackfin/configs/CM-BF561_defconfig | 104 - > arch/blackfin/configs/DNP5370_defconfig| 118 - > arch/blackfin/configs/H8606_defconfig | 87 - > arch/blackfin/configs/IP0X_defconfig | 91 - > arch/blackfin/configs/PNAV-10_defconfig| 111 - > arch/blackfin/configs/SRV1_defconfig | 88 - > arch/blackfin/configs/TCM-BF518_defconfig | 131 - > arch/blackfin/configs/TCM-BF537_defconfig | 95 - > arch/blackfin/include/asm/Kbuild | 28 - > arch/blackfin/include/asm/asm-offsets.h|1 - > arch/blackfin/include/asm/atomic.h | 47 - > arch/blackfin/include/asm/barrier.h| 86 - > arch/blackfin/include/asm/bfin-global.h| 95 - > arch/blackfin/include/asm/bfin-lq035q1.h | 40 - > arch/blackfin/include/asm/bfin5xx_spi.h| 86 - > arch/blackfin/include/asm/bfin_can.h | 728 > arch/blackfin/include/asm/bfin_dma.h | 165 - > arch/blackfin/include/asm/bfin_pfmon.h | 44 - > arch/blackfin/include/asm/bfin_ppi.h | 181 - > arch/blackfin/include/asm/bfin_sdh.h | 161 - > arch/blackfin/include/asm/bfin_serial.h| 429 --- > arch/blackfin/include/asm/bfin_simple_timer.h | 27 - > arch/blackfin/include/asm/bfin_sport.h | 71 - > arch/blackfin/include/asm/bfin_sport3.h| 107 - > arch/blackfin/include/asm/bfin_twi.h | 214 -- > arch/blackfin/include/asm/bfin_watchdog.h
Re: [PATCH] MAINTAINERS: Change LED subsystem git tree URL
On Wed, Aug 19, 2015 at 3:47 AM, Jacek Anaszewski wrote: > This patch removes Bryan Wu from the list of LED subsystem > maintainers and replaces related git tree URL with the one > maintained by Jacek Anaszewski. > > Signed-off-by: Jacek Anaszewski > Cc: Bryan Wu > Cc: Richard Purdie Acked-by: Bryan Wu > --- > MAINTAINERS |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 569568f..f8ebbef 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6040,11 +6040,10 @@ F: Documentation/scsi/53c700.txt > F: drivers/scsi/53c700* > > LED SUBSYSTEM > -M: Bryan Wu > M: Richard Purdie > M: Jacek Anaszewski > L: linux-l...@vger.kernel.org > -T: git > git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git > +T: git > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git > S: Maintained > F: drivers/leds/ > F: include/linux/leds.h > -- > 1.7.9.5 > -- 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: [PATCH] MAINTAINERS: Change LED subsystem git tree URL
On Wed, Aug 19, 2015 at 3:47 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: This patch removes Bryan Wu from the list of LED subsystem maintainers and replaces related git tree URL with the one maintained by Jacek Anaszewski. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Acked-by: Bryan Wu coolo...@gmail.com --- MAINTAINERS |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 569568f..f8ebbef 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6040,11 +6040,10 @@ F: Documentation/scsi/53c700.txt F: drivers/scsi/53c700* LED SUBSYSTEM -M: Bryan Wu coolo...@gmail.com M: Richard Purdie rpur...@rpsys.net M: Jacek Anaszewski j.anaszew...@samsung.com L: linux-l...@vger.kernel.org -T: git git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git S: Maintained F: drivers/leds/ F: include/linux/leds.h -- 1.7.9.5 -- 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/
[GIT PULL] LED subsystem updates for 4.2
Hi Linus, In this cycle, we finished to merge patches for LED Flash class driver. Other than that we have some bug fixes and new drivers for LED controllers. So please consider to pull the following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22: Linux 4.1-rc2 (2015-05-03 19:22:23 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git for-next for you to fetch changes up to b67893206fc0a0e8af87130e67f3d8ae553fc87c: leds:lp55xx: fix firmware loading error (2015-06-29 10:10:57 -0700) Andrew Lunn (2): leds: tlc591xx: Document binding for the TI 8/16 Channel i2c LED driver leds: tlc591xx: Driver for the TI 8/16 Channel i2c LED driver Geert Uytterhoeven (3): gpiolib: Add missing dummies for the unified device properties interface leds: leds-gpio: Add missing #include leds: leds-gpio: Allow compile test if !GPIOLIB Ingi Kim (3): of: Add vendor prefix for Kinetic technologies leds: ktd2692: add device tree bindings for ktd2692 leds: Add ktd2692 flash LED driver Jacek Anaszewski (11): leds: gpio: Fix error handling for led name null pointer case leds: unify the location of led-trigger API leds: Add support for max77693 mfd flash cell DT: Add documentation for the Skyworks AAT1290 leds: Add driver for AAT1290 flash LED controller Documentation: leds: Add description of v4l2-flash sub-device media: Add registration helpers for V4L2 flash sub-devices leds: max77693: add support for V4L2 Flash sub-device DT: aat1290: Document handling external strobe sources leds: aat1290: add support for V4L2 Flash sub-device leds: fix max77693-led build errors Milo Kim (1): leds:lp55xx: fix firmware loading error Paul Gortmaker (1): drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c Randy Dunlap (1): leds: fix aat1290 build errors Sakari Ailus (1): v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it Sebastian Hesselbarth (1): leds: gpio: Fix device teardown on probe deferral Stas Sergeev (1): leds: fix brightness changing when software blinking is active Toshi Kikuchi (2): leds: lp5523: add master_fader support Documentation: leds-lp5523: describe master fader attributes Uwe Kleine-König (2): leds: ktd2692: pass flags parameter to devm_gpiod_get leds: aat1290: pass flags parameter to devm_gpiod_get Álvaro Fernández Rojas (4): leds: add DT binding for BCM6328 LED controller leds: add BCM6328 LED driver leds: add DT binding for BCM6358 LED controller leds: add BCM6358 LED driver .../devicetree/bindings/leds/leds-aat1290.txt | 73 ++ .../devicetree/bindings/leds/leds-bcm6328.txt | 309 ++ .../devicetree/bindings/leds/leds-bcm6358.txt | 145 +++ .../devicetree/bindings/leds/leds-ktd2692.txt | 50 + .../devicetree/bindings/leds/leds-tlc591xx.txt | 40 + .../devicetree/bindings/vendor-prefixes.txt|1 + Documentation/leds/leds-class-flash.txt| 51 + Documentation/leds/leds-lp5523.txt | 30 + drivers/leds/Kconfig | 57 +- drivers/leds/Makefile |6 + drivers/leds/led-class.c |5 + drivers/leds/led-core.c|5 +- drivers/leds/leds-aat1290.c| 576 ++ drivers/leds/leds-bcm6328.c| 413 drivers/leds/leds-bcm6358.c| 243 + drivers/leds/leds-cobalt-raq.c | 15 +- drivers/leds/leds-gpio.c | 12 +- drivers/leds/leds-ktd2692.c| 443 drivers/leds/leds-lp5523.c | 148 +++ drivers/leds/leds-lp55xx-common.c |2 +- drivers/leds/leds-max77693.c | 1097 drivers/leds/leds-tlc591xx.c | 300 ++ drivers/leds/leds.h| 24 - drivers/media/v4l2-core/Kconfig| 11 + drivers/media/v4l2-core/Makefile |2 + drivers/media/v4l2-core/v4l2-async.c | 39 +- drivers/media/v4l2-core/v4l2-flash-led-class.c | 710 + include/linux/gpio/consumer.h | 15 + include/linux/leds.h | 25 + include/media/v4l2-flash-led-class.h | 148 +++ include/media/v4l2-subdev.h|2 + 31 files changed, 4939 insertions(+), 58 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/leds-aat1290.txt create mode 100644 Documentation/devicetree/bindings/leds/leds-bcm6328.txt create mode 100644
[GIT PULL] LED subsystem updates for 4.2
Hi Linus, In this cycle, we finished to merge patches for LED Flash class driver. Other than that we have some bug fixes and new drivers for LED controllers. So please consider to pull the following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22: Linux 4.1-rc2 (2015-05-03 19:22:23 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git for-next for you to fetch changes up to b67893206fc0a0e8af87130e67f3d8ae553fc87c: leds:lp55xx: fix firmware loading error (2015-06-29 10:10:57 -0700) Andrew Lunn (2): leds: tlc591xx: Document binding for the TI 8/16 Channel i2c LED driver leds: tlc591xx: Driver for the TI 8/16 Channel i2c LED driver Geert Uytterhoeven (3): gpiolib: Add missing dummies for the unified device properties interface leds: leds-gpio: Add missing #include linux/of.h leds: leds-gpio: Allow compile test if !GPIOLIB Ingi Kim (3): of: Add vendor prefix for Kinetic technologies leds: ktd2692: add device tree bindings for ktd2692 leds: Add ktd2692 flash LED driver Jacek Anaszewski (11): leds: gpio: Fix error handling for led name null pointer case leds: unify the location of led-trigger API leds: Add support for max77693 mfd flash cell DT: Add documentation for the Skyworks AAT1290 leds: Add driver for AAT1290 flash LED controller Documentation: leds: Add description of v4l2-flash sub-device media: Add registration helpers for V4L2 flash sub-devices leds: max77693: add support for V4L2 Flash sub-device DT: aat1290: Document handling external strobe sources leds: aat1290: add support for V4L2 Flash sub-device leds: fix max77693-led build errors Milo Kim (1): leds:lp55xx: fix firmware loading error Paul Gortmaker (1): drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c Randy Dunlap (1): leds: fix aat1290 build errors Sakari Ailus (1): v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it Sebastian Hesselbarth (1): leds: gpio: Fix device teardown on probe deferral Stas Sergeev (1): leds: fix brightness changing when software blinking is active Toshi Kikuchi (2): leds: lp5523: add master_fader support Documentation: leds-lp5523: describe master fader attributes Uwe Kleine-König (2): leds: ktd2692: pass flags parameter to devm_gpiod_get leds: aat1290: pass flags parameter to devm_gpiod_get Álvaro Fernández Rojas (4): leds: add DT binding for BCM6328 LED controller leds: add BCM6328 LED driver leds: add DT binding for BCM6358 LED controller leds: add BCM6358 LED driver .../devicetree/bindings/leds/leds-aat1290.txt | 73 ++ .../devicetree/bindings/leds/leds-bcm6328.txt | 309 ++ .../devicetree/bindings/leds/leds-bcm6358.txt | 145 +++ .../devicetree/bindings/leds/leds-ktd2692.txt | 50 + .../devicetree/bindings/leds/leds-tlc591xx.txt | 40 + .../devicetree/bindings/vendor-prefixes.txt|1 + Documentation/leds/leds-class-flash.txt| 51 + Documentation/leds/leds-lp5523.txt | 30 + drivers/leds/Kconfig | 57 +- drivers/leds/Makefile |6 + drivers/leds/led-class.c |5 + drivers/leds/led-core.c|5 +- drivers/leds/leds-aat1290.c| 576 ++ drivers/leds/leds-bcm6328.c| 413 drivers/leds/leds-bcm6358.c| 243 + drivers/leds/leds-cobalt-raq.c | 15 +- drivers/leds/leds-gpio.c | 12 +- drivers/leds/leds-ktd2692.c| 443 drivers/leds/leds-lp5523.c | 148 +++ drivers/leds/leds-lp55xx-common.c |2 +- drivers/leds/leds-max77693.c | 1097 drivers/leds/leds-tlc591xx.c | 300 ++ drivers/leds/leds.h| 24 - drivers/media/v4l2-core/Kconfig| 11 + drivers/media/v4l2-core/Makefile |2 + drivers/media/v4l2-core/v4l2-async.c | 39 +- drivers/media/v4l2-core/v4l2-flash-led-class.c | 710 + include/linux/gpio/consumer.h | 15 + include/linux/leds.h | 25 + include/media/v4l2-flash-led-class.h | 148 +++ include/media/v4l2-subdev.h|2 + 31 files changed, 4939 insertions(+), 58 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/leds-aat1290.txt create mode 100644 Documentation/devicetree/bindings/leds/leds-bcm6328.txt create mode
Re: [PATCH -next] leds: fix aat1290 build errors
On Mon, Jun 29, 2015 at 7:44 AM, Jacek Anaszewski wrote: > Hi Randy, > > Thanks for the patch. > > > On 06/26/2015 09:00 PM, Randy Dunlap wrote: >> >> From: Randy Dunlap >> >> Fix build errors when LEDS_AAT1290=y and V4L2_FLASH_LED_CLASS=m >> by restricting LEDS_AAT1290 to =m if V4L2_FLASH_LED_CLASS=m. >> >> drivers/built-in.o: In function `aat1290_led_remove': >> leds-aat1290.c:(.text+0xe5d77): undefined reference to >> `v4l2_flash_release' >> drivers/built-in.o: In function `aat1290_led_probe': >> leds-aat1290.c:(.text+0xe6494): undefined reference to `v4l2_flash_init' >> >> Signed-off-by: Randy Dunlap >> Cc: Jacek Anaszewski >> Cc: Bryan Wu >> Cc: Richard Purdie >> --- >> drivers/leds/Kconfig |1 + >> 1 file changed, 1 insertion(+) >> >> --- linux-next-20150626.orig/drivers/leds/Kconfig >> +++ linux-next-20150626/drivers/leds/Kconfig >> @@ -42,6 +42,7 @@ config LEDS_88PM860X >> config LEDS_AAT1290 >> tristate "LED support for the AAT1290" >> depends on LEDS_CLASS_FLASH >> + depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS >> depends on GPIOLIB >> depends on OF >> depends on PINCTRL >> > > Acked-by: Jacek Anaszewski > Good fix. thanks. I merged into my tree. -Bryan -- 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: [PATCH -next] leds: fix aat1290 build errors
On Mon, Jun 29, 2015 at 7:44 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: Hi Randy, Thanks for the patch. On 06/26/2015 09:00 PM, Randy Dunlap wrote: From: Randy Dunlap rdun...@infradead.org Fix build errors when LEDS_AAT1290=y and V4L2_FLASH_LED_CLASS=m by restricting LEDS_AAT1290 to =m if V4L2_FLASH_LED_CLASS=m. drivers/built-in.o: In function `aat1290_led_remove': leds-aat1290.c:(.text+0xe5d77): undefined reference to `v4l2_flash_release' drivers/built-in.o: In function `aat1290_led_probe': leds-aat1290.c:(.text+0xe6494): undefined reference to `v4l2_flash_init' Signed-off-by: Randy Dunlap rdun...@infradead.org Cc: Jacek Anaszewski j.anaszew...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net --- drivers/leds/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20150626.orig/drivers/leds/Kconfig +++ linux-next-20150626/drivers/leds/Kconfig @@ -42,6 +42,7 @@ config LEDS_88PM860X config LEDS_AAT1290 tristate LED support for the AAT1290 depends on LEDS_CLASS_FLASH + depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS depends on GPIOLIB depends on OF depends on PINCTRL Acked-by: Jacek Anaszewski j.anaszew...@samsung.com Good fix. thanks. I merged into my tree. -Bryan -- 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: [PATCH] drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c
On Tue, Jun 16, 2015 at 1:23 AM, Jacek Anaszewski wrote: > Hi Paul, > > > On 06/16/2015 12:12 AM, Paul Gortmaker wrote: >> >> This file is built for a bool Kconfig variable, and hence this >> code is either present or absent. It currently can never be >> modular, so using module_init as an alias for __initcall can be >> somewhat misleading. >> >> Fix this up now, so that we can relocate module_init from >> init.h into module.h in the future. If we don't do this, we'd >> have to add module.h to obviously non-modular code, and that >> would be a worse thing. >> >> Note that direct use of __initcall is discouraged, vs. one >> of the priority categorized subgroups. As __initcall gets >> mapped onto device_initcall, our use of device_initcall >> directly in this change means that the runtime impact is >> zero -- it will remain at level 6 in initcall ordering. >> >> And since it can't be modular, we remove all the __exitcall >> stuff related to module_exit() -- it is dead code that won't >> ever be executed. >> >> Cc: Bryan Wu >> Cc: Richard Purdie >> Cc: Jacek Anaszewski >> Cc: linux-l...@vger.kernel.org >> Signed-off-by: Paul Gortmaker >> --- >> [ >> To be appended to the branch content originally sent as: >> "Replace module_init with device_initcall in non modules" >> >> https://lkml.kernel.org/r/1432860493-23831-1-git-send-email-paul.gortma...@windriver.com >> ] >> >> drivers/leds/leds-cobalt-raq.c | 15 +-- >> 1 file changed, 1 insertion(+), 14 deletions(-) > > > Acked-by: Jacek Anaszewski > Thanks, merged. -Bryan -- 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: [PATCH] drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c
On Tue, Jun 16, 2015 at 1:23 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: Hi Paul, On 06/16/2015 12:12 AM, Paul Gortmaker wrote: This file is built for a bool Kconfig variable, and hence this code is either present or absent. It currently can never be modular, so using module_init as an alias for __initcall can be somewhat misleading. Fix this up now, so that we can relocate module_init from init.h into module.h in the future. If we don't do this, we'd have to add module.h to obviously non-modular code, and that would be a worse thing. Note that direct use of __initcall is discouraged, vs. one of the priority categorized subgroups. As __initcall gets mapped onto device_initcall, our use of device_initcall directly in this change means that the runtime impact is zero -- it will remain at level 6 in initcall ordering. And since it can't be modular, we remove all the __exitcall stuff related to module_exit() -- it is dead code that won't ever be executed. Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Jacek Anaszewski j.anaszew...@samsung.com Cc: linux-l...@vger.kernel.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- [ To be appended to the branch content originally sent as: Replace module_init with device_initcall in non modules https://lkml.kernel.org/r/1432860493-23831-1-git-send-email-paul.gortma...@windriver.com ] drivers/leds/leds-cobalt-raq.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) Acked-by: Jacek Anaszewski j.anaszew...@samsung.com Thanks, merged. -Bryan -- 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: [PATCH v2] leds: fix brightness changing when software blinking is active
On Fri, May 15, 2015 at 7:41 AM, Jacek Anaszewski wrote: > On 05/15/2015 04:11 PM, Stas Sergeev wrote: >> >> 15.05.2015 17:09, Jacek Anaszewski пишет: >>> >>> On 05/15/2015 10:12 AM, Jacek Anaszewski wrote: Hi Stas, On 05/14/2015 05:24 PM, Stas Sergeev wrote: > > > The following sequence: > echo timer >/sys/class/leds//trigger > echo 1 >/sys/class/leds//brightness > should change the ON brightness for blinking. > The function led_set_brightness() was mistakenly initiating the > delayed blink stop procedure, which resulted in no blinking with > the timer trigger still active. > > This patch fixes the problem by changing led_set_brightness() > to not initiate the delayed blink stop when brightness is not 0. >>> >>> >>> This commit message is not valid for this version of the patch. >> >> Why do you think so? >> --- >> - schedule_work(_cdev->set_brightness_work); >> + if (brightness == LED_OFF) >> + schedule_work(_cdev->set_brightness_work); >> --- >> >> LED_OFF is a 0 define. >> > > You're right, I was just looking at the issue from different > perspective. > Applied into my tree. Thanks, -Bryan -- 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: [PATCH v2] leds: fix brightness changing when software blinking is active
On Fri, May 15, 2015 at 7:41 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: On 05/15/2015 04:11 PM, Stas Sergeev wrote: 15.05.2015 17:09, Jacek Anaszewski пишет: On 05/15/2015 10:12 AM, Jacek Anaszewski wrote: Hi Stas, On 05/14/2015 05:24 PM, Stas Sergeev wrote: The following sequence: echo timer /sys/class/leds/name/trigger echo 1 /sys/class/leds/name/brightness should change the ON brightness for blinking. The function led_set_brightness() was mistakenly initiating the delayed blink stop procedure, which resulted in no blinking with the timer trigger still active. This patch fixes the problem by changing led_set_brightness() to not initiate the delayed blink stop when brightness is not 0. This commit message is not valid for this version of the patch. Why do you think so? --- - schedule_work(led_cdev-set_brightness_work); + if (brightness == LED_OFF) + schedule_work(led_cdev-set_brightness_work); --- LED_OFF is a 0 define. You're right, I was just looking at the issue from different perspective. Applied into my tree. Thanks, -Bryan -- 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: [PATCH] leds: remove redundant SET_BRIGHTNESS_SYNC flag
On Thu, May 14, 2015 at 2:11 AM, Jacek Anaszewski
wrote:
> I personally can't find any strong argument against this optimization.
> I added both flags on Bryan's request while implementing LED Flash class
> extension. I can see a few occurrences in the include/linux directory
> where both SYNC and ASYNC flags are implemented. The argument in favour
> could be the fact that the flags influence the core functionality of
> the subsystem.
>
> Bryan, could you express your opinion, please?
>
Please keep this flag and although it's redundant at this point I
think it's still make code more clear and easy to understand.
Thanks,
-Bryan
>
> On 05/13/2015 05:41 PM, Stas Sergeev wrote:
>>
>>
>> There is a complimentary flag called SET_BRIGHTNESS_ASYNC.
>> Having both is redundant. This patch removes the unneeded flag
>> without any functionality change.
>>
>> CC: Bryan Wu
>> CC: Richard Purdie
>> CC: linux-l...@vger.kernel.org
>> CC: linux-kernel@vger.kernel.org
>>
>> Signed-off-by: Stas Sergeev
>> ---
>> drivers/leds/led-class-flash.c |1 -
>> drivers/leds/led-core.c|4 +---
>> include/linux/leds.h |2 +-
>> 3 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/leds/led-class-flash.c
>> b/drivers/leds/led-class-flash.c
>> index 3b25734..bb67364 100644
>> --- a/drivers/leds/led-class-flash.c
>> +++ b/drivers/leds/led-class-flash.c
>> @@ -318,7 +318,6 @@ int led_classdev_flash_register(struct device *parent,
>>
>> /* Setting a torch brightness needs to have immediate effect */
>> led_cdev->flags &= ~SET_BRIGHTNESS_ASYNC;
>> - led_cdev->flags |= SET_BRIGHTNESS_SYNC;
>>
>> return 0;
>> }
>> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
>> index 9886dac..356e851 100644
>> --- a/drivers/leds/led-core.c
>> +++ b/drivers/leds/led-core.c
>> @@ -129,10 +129,8 @@ void led_set_brightness(struct led_classdev
>> *led_cdev,
>> if (led_cdev->flags & SET_BRIGHTNESS_ASYNC) {
>> led_set_brightness_async(led_cdev, brightness);
>> return;
>> - } else if (led_cdev->flags & SET_BRIGHTNESS_SYNC)
>> + } else
>> ret = led_set_brightness_sync(led_cdev, brightness);
>> - else
>> - ret = -EINVAL;
>>
>> if (ret < 0)
>> dev_dbg(led_cdev->dev, "Setting LED brightness failed
>> (%d)\n",
>> diff --git a/include/linux/leds.h b/include/linux/leds.h
>> index 9a2b000..c9e6e5d 100644
>> --- a/include/linux/leds.h
>> +++ b/include/linux/leds.h
>> @@ -45,7 +45,7 @@ struct led_classdev {
>> #define LED_BLINK_INVERT (1 << 19)
>> #define LED_SYSFS_DISABLE (1 << 20)
>> #define SET_BRIGHTNESS_ASYNC (1 << 21)
>> -#define SET_BRIGHTNESS_SYNC(1 << 22)
>> +/* bit 22 unused, take it */
>> #define LED_DEV_CAP_FLASH (1 << 23)
>>
>> /* Set LED brightness level */
>>
>
>
> --
> Best Regards,
> Jacek Anaszewski
--
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: [PATCH] leds: remove redundant SET_BRIGHTNESS_SYNC flag
On Thu, May 14, 2015 at 2:11 AM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
I personally can't find any strong argument against this optimization.
I added both flags on Bryan's request while implementing LED Flash class
extension. I can see a few occurrences in the include/linux directory
where both SYNC and ASYNC flags are implemented. The argument in favour
could be the fact that the flags influence the core functionality of
the subsystem.
Bryan, could you express your opinion, please?
Please keep this flag and although it's redundant at this point I
think it's still make code more clear and easy to understand.
Thanks,
-Bryan
On 05/13/2015 05:41 PM, Stas Sergeev wrote:
There is a complimentary flag called SET_BRIGHTNESS_ASYNC.
Having both is redundant. This patch removes the unneeded flag
without any functionality change.
CC: Bryan Wu coolo...@gmail.com
CC: Richard Purdie rpur...@rpsys.net
CC: linux-l...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Stas Sergeev s...@users.sourceforge.net
---
drivers/leds/led-class-flash.c |1 -
drivers/leds/led-core.c|4 +---
include/linux/leds.h |2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/leds/led-class-flash.c
b/drivers/leds/led-class-flash.c
index 3b25734..bb67364 100644
--- a/drivers/leds/led-class-flash.c
+++ b/drivers/leds/led-class-flash.c
@@ -318,7 +318,6 @@ int led_classdev_flash_register(struct device *parent,
/* Setting a torch brightness needs to have immediate effect */
led_cdev-flags = ~SET_BRIGHTNESS_ASYNC;
- led_cdev-flags |= SET_BRIGHTNESS_SYNC;
return 0;
}
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 9886dac..356e851 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -129,10 +129,8 @@ void led_set_brightness(struct led_classdev
*led_cdev,
if (led_cdev-flags SET_BRIGHTNESS_ASYNC) {
led_set_brightness_async(led_cdev, brightness);
return;
- } else if (led_cdev-flags SET_BRIGHTNESS_SYNC)
+ } else
ret = led_set_brightness_sync(led_cdev, brightness);
- else
- ret = -EINVAL;
if (ret 0)
dev_dbg(led_cdev-dev, Setting LED brightness failed
(%d)\n,
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 9a2b000..c9e6e5d 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -45,7 +45,7 @@ struct led_classdev {
#define LED_BLINK_INVERT (1 19)
#define LED_SYSFS_DISABLE (1 20)
#define SET_BRIGHTNESS_ASYNC (1 21)
-#define SET_BRIGHTNESS_SYNC(1 22)
+/* bit 22 unused, take it */
#define LED_DEV_CAP_FLASH (1 23)
/* Set LED brightness level */
--
Best Regards,
Jacek Anaszewski
--
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: [PATCH] Documentation: leds-lp5523: describe master fader attributes
On Wed, May 13, 2015 at 2:57 AM, Jacek Anaszewski wrote: > Hi Toshi, > > On 05/13/2015 03:15 AM, Toshi Kikuchi wrote: >> >> Add the usage of the new attributes for master faders. >> >> Signed-off-by: Toshi Kikuchi >> --- >> Documentation/leds/leds-lp5523.txt | 30 ++ >> 1 file changed, 30 insertions(+) > > > Acked-by: Jacek Anaszewski > Merged with Milo and Jacek's Acks. Thanks, -Bryan -- 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: [PATCH] Documentation: leds-lp5523: describe master fader attributes
On Wed, May 13, 2015 at 2:57 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: Hi Toshi, On 05/13/2015 03:15 AM, Toshi Kikuchi wrote: Add the usage of the new attributes for master faders. Signed-off-by: Toshi Kikuchi tos...@chromium.org --- Documentation/leds/leds-lp5523.txt | 30 ++ 1 file changed, 30 insertions(+) Acked-by: Jacek Anaszewski j.anaszew...@samsung.com Merged with Milo and Jacek's Acks. Thanks, -Bryan -- 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: [PATCH] leds: lp5523: add master_fader support
On Tue, May 12, 2015 at 1:51 AM, Jacek Anaszewski wrote: > On 05/12/2015 10:25 AM, Kim, Milo wrote: >> >> Hi Jacek and Toshi, >> >> On 5/12/2015 4:25 PM, Jacek Anaszewski wrote: >>> >>> Hi Toshi, >>> >>> On 05/11/2015 09:10 PM, Toshi Kikuchi wrote: This patch introduces 4 new attributes: master_fader_leds master_fader1 master_fader2 master_fader3 Fo example, to map channel 0,6 to master_fader1, map channel 1,7 to master_fader2, map channel 2,8 to master_fader3, and map channel 3,4,5 to none >>> >>> > echo "123000123" > master_fader_leds >>> >>> >>> I propose to add ABI documentation for this driver. It already exposes >>> many custom attributes but I can't find documentation for them. >> >> >> I agree with Jacek's comment but it would be better if we could see the >> description in lp5523 driver >> documentation(Documentation/leds/leds-lp5523.txt). > > > Right, I missed that file. > > Toshi, I merged this patch into my tree with Milo and Jacek Acks. But please follow their advice and provide a patch to update those document files. Thanks, -Bryan -- 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: [PATCH 3/3] leds: leds-gpio: Allow compile test if !GPIOLIB
On Tue, May 12, 2015 at 3:23 AM, Linus Walleij wrote: > On Thu, May 7, 2015 at 10:08 AM, Geert Uytterhoeven > wrote: > >> The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is >> not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer >> functionality only, can still be compiled if GPIOLIB is not enabled. >> >> Relax the dependency of LEDS_GPIO on GPIOLIB if COMPILE_TEST is >> enabled. >> >> Signed-off-by: Geert Uytterhoeven > > Acked-by: Linus Walleij > > Yours, > Linus Walleij Merged, thanks. -Bryan -- 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: [PATCH 2/3] leds: leds-gpio: Add missing #include
On Thu, May 7, 2015 at 5:15 AM, Jacek Anaszewski wrote: > On 05/07/2015 10:08 AM, Geert Uytterhoeven wrote: >> >> drivers/leds/leds-gpio.c: In function ‘gpio_leds_create’: >> drivers/leds/leds-gpio.c:194: error: implicit declaration of function >> ‘of_node’ >> drivers/leds/leds-gpio.c:194: warning: assignment makes pointer from >> integer without a cast >> drivers/leds/leds-gpio.c:200: error: dereferencing pointer to incomplete >> type >> >> Signed-off-by: Geert Uytterhoeven >> --- >> drivers/leds/leds-gpio.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c >> index 15eb3f86f670ffe4..89d981e8f8cacf55 100644 >> --- a/drivers/leds/leds-gpio.c >> +++ b/drivers/leds/leds-gpio.c >> @@ -16,6 +16,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> > > Acked-by: Jacek Anaszewski > Merged, thanks. -Bryan -- 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: [PATCH 1/3] gpiolib: Add missing dummies for the unified device properties interface
On Tue, May 12, 2015 at 3:31 AM, Linus Walleij wrote:
> On Thu, May 7, 2015 at 10:08 AM, Geert Uytterhoeven
> wrote:
>
>> If GPIOLIB=n:
>>
>> drivers/leds/leds-gpio.c: In function ‘gpio_leds_create’:
>> drivers/leds/leds-gpio.c:187: error: implicit declaration of function
>> ‘devm_get_gpiod_from_child’
>> drivers/leds/leds-gpio.c:187: warning: assignment makes pointer from
>> integer without a cast
>>
>> Add dummies for fwnode_get_named_gpiod() and devm_get_gpiod_from_child()
>> for the !GPIOLIB case to fix this.
>>
>> Signed-off-by: Geert Uytterhoeven
>> Fixes: 40b7318319281b1b ("gpio: Support for unified device properties
>> interface")
>
> Acked-by: Linus Walleij
>
> Counting on this to go through the LEDs tree as discussed.
>
> Yours,
> Linus Walleij
OK, merged with Alex and Linus Acks. Thanks,
-Bryan
--
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: [PATCH v9 1/3] of: Add vendor prefix for Kinetic technologies
On Tue, May 12, 2015 at 1:37 AM, Ingi Kim wrote: > This patch adds vendor prefix for Kinetic technologies > > Signed-off-by: Ingi Kim > Acked-by: Rob Herring > Acked-by: Seung-Woo Kim > Reviewed-by: Varka Bhadram Merged into my tree with DT reviewer's acks. Thanks, -Bryan > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index b6682ab..0a50533 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -108,6 +108,7 @@ iseeISEE 2007 S.L. > isil Intersil > karo Ka-Ro electronics GmbH > keymileKeymile GmbH > +kinetic Kinetic Technologies > lacie LaCie > lantiq Lantiq Semiconductor > lenovo Lenovo Group Ltd. > -- > 2.0.5 > -- 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: [PATCH v9 3/3] leds: Add ktd2692 flash LED driver
On Tue, May 12, 2015 at 5:40 AM, Jacek Anaszewski wrote: > Hi Ingi, > > On 05/12/2015 10:37 AM, Ingi Kim wrote: >> >> This patch adds a driver to support the ktd2692 flash LEDs. >> ktd2692 can control flash current by ExpressWire interface. >> >> Signed-off-by: Ingi Kim >> Acked-by: Seung-Woo Kim >> Reviewed-by: Varka Bhadram >> --- >> drivers/leds/Kconfig| 9 + >> drivers/leds/Makefile | 1 + >> drivers/leds/leds-ktd2692.c | 443 >> >> 3 files changed, 453 insertions(+) >> create mode 100644 drivers/leds/leds-ktd2692.c > > > Acked-by: Jacek Anaszewski > Merged, thanks. -Bryan > -- > Best Regards, > Jacek Anaszewski -- 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: [PATCH v9 2/3] leds: ktd2692: add device tree bindings for ktd2692
On Tue, May 12, 2015 at 5:39 AM, Jacek Anaszewski wrote: > Hi Ingi, > > On 05/12/2015 10:37 AM, Ingi Kim wrote: >> >> This patch adds the device tree bindings for ktd2692 flash LEDs. >> Add Optional properties of child node for Flash LED >> >> Signed-off-by: Ingi Kim >> Acked-by: Seung-Woo Kim >> Reviewed-by: Varka Bhadram >> --- >> .../devicetree/bindings/leds/leds-ktd2692.txt | 50 >> ++ >> 1 file changed, 50 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/leds/leds-ktd2692.txt > > > Acked-by: Jacek Anaszewski > Merged, thanks. -Bryan > -- > Best Regards, > Jacek Anaszewski -- 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: [PATCH 2/3] leds: leds-gpio: Add missing #include linux/of.h
On Thu, May 7, 2015 at 5:15 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: On 05/07/2015 10:08 AM, Geert Uytterhoeven wrote: drivers/leds/leds-gpio.c: In function ‘gpio_leds_create’: drivers/leds/leds-gpio.c:194: error: implicit declaration of function ‘of_node’ drivers/leds/leds-gpio.c:194: warning: assignment makes pointer from integer without a cast drivers/leds/leds-gpio.c:200: error: dereferencing pointer to incomplete type Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- drivers/leds/leds-gpio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c index 15eb3f86f670ffe4..89d981e8f8cacf55 100644 --- a/drivers/leds/leds-gpio.c +++ b/drivers/leds/leds-gpio.c @@ -16,6 +16,7 @@ #include linux/kernel.h #include linux/leds.h #include linux/module.h +#include linux/of.h #include linux/platform_device.h #include linux/property.h #include linux/slab.h Acked-by: Jacek Anaszewski j.anaszew...@samsung.com Merged, thanks. -Bryan -- 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: [PATCH v9 2/3] leds: ktd2692: add device tree bindings for ktd2692
On Tue, May 12, 2015 at 5:39 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: Hi Ingi, On 05/12/2015 10:37 AM, Ingi Kim wrote: This patch adds the device tree bindings for ktd2692 flash LEDs. Add Optional properties of child node for Flash LED Signed-off-by: Ingi Kim ingi2@samsung.com Acked-by: Seung-Woo Kim sw0312@samsung.com Reviewed-by: Varka Bhadram varkabhad...@gmail.com --- .../devicetree/bindings/leds/leds-ktd2692.txt | 50 ++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt Acked-by: Jacek Anaszewski j.anaszew...@samsung.com Merged, thanks. -Bryan -- Best Regards, Jacek Anaszewski -- 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: [PATCH v9 1/3] of: Add vendor prefix for Kinetic technologies
On Tue, May 12, 2015 at 1:37 AM, Ingi Kim ingi2@samsung.com wrote: This patch adds vendor prefix for Kinetic technologies Signed-off-by: Ingi Kim ingi2@samsung.com Acked-by: Rob Herring r...@kernel.org Acked-by: Seung-Woo Kim sw0312@samsung.com Reviewed-by: Varka Bhadram varkabhad...@gmail.com Merged into my tree with DT reviewer's acks. Thanks, -Bryan --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index b6682ab..0a50533 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -108,6 +108,7 @@ iseeISEE 2007 S.L. isil Intersil karo Ka-Ro electronics GmbH keymileKeymile GmbH +kinetic Kinetic Technologies lacie LaCie lantiq Lantiq Semiconductor lenovo Lenovo Group Ltd. -- 2.0.5 -- 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: [PATCH 1/3] gpiolib: Add missing dummies for the unified device properties interface
On Tue, May 12, 2015 at 3:31 AM, Linus Walleij linus.wall...@linaro.org wrote: On Thu, May 7, 2015 at 10:08 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote: If GPIOLIB=n: drivers/leds/leds-gpio.c: In function ‘gpio_leds_create’: drivers/leds/leds-gpio.c:187: error: implicit declaration of function ‘devm_get_gpiod_from_child’ drivers/leds/leds-gpio.c:187: warning: assignment makes pointer from integer without a cast Add dummies for fwnode_get_named_gpiod() and devm_get_gpiod_from_child() for the !GPIOLIB case to fix this. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org Fixes: 40b7318319281b1b (gpio: Support for unified device properties interface) Acked-by: Linus Walleij linus.wall...@linaro.org Counting on this to go through the LEDs tree as discussed. Yours, Linus Walleij OK, merged with Alex and Linus Acks. Thanks, -Bryan -- 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: [PATCH 3/3] leds: leds-gpio: Allow compile test if !GPIOLIB
On Tue, May 12, 2015 at 3:23 AM, Linus Walleij linus.wall...@linaro.org wrote: On Thu, May 7, 2015 at 10:08 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote: The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer functionality only, can still be compiled if GPIOLIB is not enabled. Relax the dependency of LEDS_GPIO on GPIOLIB if COMPILE_TEST is enabled. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij Merged, thanks. -Bryan -- 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: [PATCH v9 3/3] leds: Add ktd2692 flash LED driver
On Tue, May 12, 2015 at 5:40 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: Hi Ingi, On 05/12/2015 10:37 AM, Ingi Kim wrote: This patch adds a driver to support the ktd2692 flash LEDs. ktd2692 can control flash current by ExpressWire interface. Signed-off-by: Ingi Kim ingi2@samsung.com Acked-by: Seung-Woo Kim sw0312@samsung.com Reviewed-by: Varka Bhadram varkabhad...@gmail.com --- drivers/leds/Kconfig| 9 + drivers/leds/Makefile | 1 + drivers/leds/leds-ktd2692.c | 443 3 files changed, 453 insertions(+) create mode 100644 drivers/leds/leds-ktd2692.c Acked-by: Jacek Anaszewski j.anaszew...@samsung.com Merged, thanks. -Bryan -- Best Regards, Jacek Anaszewski -- 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: [PATCH] leds: lp5523: add master_fader support
On Tue, May 12, 2015 at 1:51 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: On 05/12/2015 10:25 AM, Kim, Milo wrote: Hi Jacek and Toshi, On 5/12/2015 4:25 PM, Jacek Anaszewski wrote: Hi Toshi, On 05/11/2015 09:10 PM, Toshi Kikuchi wrote: This patch introduces 4 new attributes: master_fader_leds master_fader1 master_fader2 master_fader3 Fo example, to map channel 0,6 to master_fader1, map channel 1,7 to master_fader2, map channel 2,8 to master_fader3, and map channel 3,4,5 to none echo 123000123 master_fader_leds I propose to add ABI documentation for this driver. It already exposes many custom attributes but I can't find documentation for them. I agree with Jacek's comment but it would be better if we could see the description in lp5523 driver documentation(Documentation/leds/leds-lp5523.txt). Right, I missed that file. Toshi, I merged this patch into my tree with Milo and Jacek Acks. But please follow their advice and provide a patch to update those document files. Thanks, -Bryan -- 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: [PATCH 1/3] gpiolib: Add missing dummies for the unified device properties interface
On Thu, May 7, 2015 at 1:08 AM, Geert Uytterhoeven wrote:
> If GPIOLIB=n:
>
> drivers/leds/leds-gpio.c: In function ‘gpio_leds_create’:
> drivers/leds/leds-gpio.c:187: error: implicit declaration of function
> ‘devm_get_gpiod_from_child’
> drivers/leds/leds-gpio.c:187: warning: assignment makes pointer from
> integer without a cast
>
> Add dummies for fwnode_get_named_gpiod() and devm_get_gpiod_from_child()
> for the !GPIOLIB case to fix this.
>
Geert,
This patch looks good to me. Do you mind merging it through LED tree
with other 2 more LED patches?
Thanks,
-Bryan
> Signed-off-by: Geert Uytterhoeven
> Fixes: 40b7318319281b1b ("gpio: Support for unified device properties
> interface")
> ---
> include/linux/gpio/consumer.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
> index 3a7c9ffd5ab930b4..da042657dc31d7f5 100644
> --- a/include/linux/gpio/consumer.h
> +++ b/include/linux/gpio/consumer.h
> @@ -406,6 +406,21 @@ static inline int desc_to_gpio(const struct gpio_desc
> *desc)
> return -EINVAL;
> }
>
> +/* Child properties interface */
> +struct fwnode_handle;
> +
> +static inline struct gpio_desc *fwnode_get_named_gpiod(
> + struct fwnode_handle *fwnode, const char *propname)
> +{
> + return ERR_PTR(-ENOSYS);
> +}
> +
> +static inline struct gpio_desc *devm_get_gpiod_from_child(
> + struct device *dev, const char *con_id, struct fwnode_handle *child)
> +{
> + return ERR_PTR(-ENOSYS);
> +}
> +
> #endif /* CONFIG_GPIOLIB */
>
> /*
> --
> 1.9.1
>
--
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: [PATCH 1/3] gpiolib: Add missing dummies for the unified device properties interface
On Thu, May 7, 2015 at 1:08 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote:
If GPIOLIB=n:
drivers/leds/leds-gpio.c: In function ‘gpio_leds_create’:
drivers/leds/leds-gpio.c:187: error: implicit declaration of function
‘devm_get_gpiod_from_child’
drivers/leds/leds-gpio.c:187: warning: assignment makes pointer from
integer without a cast
Add dummies for fwnode_get_named_gpiod() and devm_get_gpiod_from_child()
for the !GPIOLIB case to fix this.
Geert,
This patch looks good to me. Do you mind merging it through LED tree
with other 2 more LED patches?
Thanks,
-Bryan
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Fixes: 40b7318319281b1b (gpio: Support for unified device properties
interface)
---
include/linux/gpio/consumer.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 3a7c9ffd5ab930b4..da042657dc31d7f5 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -406,6 +406,21 @@ static inline int desc_to_gpio(const struct gpio_desc
*desc)
return -EINVAL;
}
+/* Child properties interface */
+struct fwnode_handle;
+
+static inline struct gpio_desc *fwnode_get_named_gpiod(
+ struct fwnode_handle *fwnode, const char *propname)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+static inline struct gpio_desc *devm_get_gpiod_from_child(
+ struct device *dev, const char *con_id, struct fwnode_handle *child)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
#endif /* CONFIG_GPIOLIB */
/*
--
1.9.1
--
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: [PATCH] MAINTAINERS: Add co-maintainer for LED subsystem
On Thu, Apr 16, 2015 at 10:09 AM, Bryan Wu wrote: > On Thu, Apr 9, 2015 at 10:30 AM, Bryan Wu wrote: >> On Thu, Apr 9, 2015 at 1:01 AM, Jacek Anaszewski >> wrote: >>> This patch adds myself (Jacek Anaszewski) as a co-maintainer for >>> LED subsystem. >>> >> >> Jacek will start to help maintain LED subsystem. >> >> Acked-by: Bryan Wu >> > > Hi Linus, > > Can we merge this patch? Then Jacek can receive patches directly. > Hi Andrew and Linus, Can you help this? Jacek starts reviewing the patches now. Thanks, -Bryan > >>> Signed-off-by: Jacek Anaszewski >>> --- >>> MAINTAINERS |1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 201280a..222f53a 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -5815,6 +5815,7 @@ F:drivers/scsi/53c700* >>> LED SUBSYSTEM >>> M: Bryan Wu >>> M: Richard Purdie >>> +M: Jacek Anaszewski >>> L: linux-l...@vger.kernel.org >>> T: git >>> git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git >>> S: Maintained >>> -- >>> 1.7.9.5 >>> -- 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: [PATCH] MAINTAINERS: Add co-maintainer for LED subsystem
On Thu, Apr 16, 2015 at 10:09 AM, Bryan Wu coolo...@gmail.com wrote: On Thu, Apr 9, 2015 at 10:30 AM, Bryan Wu coolo...@gmail.com wrote: On Thu, Apr 9, 2015 at 1:01 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: This patch adds myself (Jacek Anaszewski) as a co-maintainer for LED subsystem. Jacek will start to help maintain LED subsystem. Acked-by: Bryan Wu coolo...@gmail.com Hi Linus, Can we merge this patch? Then Jacek can receive patches directly. Hi Andrew and Linus, Can you help this? Jacek starts reviewing the patches now. Thanks, -Bryan Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com --- MAINTAINERS |1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 201280a..222f53a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5815,6 +5815,7 @@ F:drivers/scsi/53c700* LED SUBSYSTEM M: Bryan Wu coolo...@gmail.com M: Richard Purdie rpur...@rpsys.net +M: Jacek Anaszewski j.anaszew...@samsung.com L: linux-l...@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git S: Maintained -- 1.7.9.5 -- 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: [PATCH] leds: gpio: Fix device teardown on probe deferral
On Wed, Apr 15, 2015 at 2:11 AM, Jacek Anaszewski wrote: > Hi Sebastian, > > On 04/14/2015 11:23 PM, Sebastian Hesselbarth wrote: >> >> In gpio_leds_create(), when devm_get_gpiod_from_child() fails with >> -EPROBE_DEFER on the second gpio led to be created, the first already >> registered led is not torn down properly. This causes create_gpio_led() >> to fail for the first led on re-probe(). >> >> Fix this misbehaviour by incrementing num_leds only if all >> potentially failing calls completed successfully. >> >> Signed-off-by: Sebastian Hesselbarth >> --- >> Cc: Bryan Wu >> Cc: Richard Purdie >> Cc: linux-l...@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> --- >> drivers/leds/leds-gpio.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) > > > For this patch: > > Acked-by: Jacek Anaszewski > Thanks, I merged it. -Bryan > I have a question regarding the sequence above on line 201: > > if (!led.name) > return ERR_PTR(-EINVAL); > > Shouldn't this be also 'goto err"? > > -- > Best Regards, > Jacek Anaszewski -- 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: [PATCH] leds: gpio: Fix device teardown on probe deferral
On Wed, Apr 15, 2015 at 2:11 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: Hi Sebastian, On 04/14/2015 11:23 PM, Sebastian Hesselbarth wrote: In gpio_leds_create(), when devm_get_gpiod_from_child() fails with -EPROBE_DEFER on the second gpio led to be created, the first already registered led is not torn down properly. This causes create_gpio_led() to fail for the first led on re-probe(). Fix this misbehaviour by incrementing num_leds only if all potentially failing calls completed successfully. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: linux-l...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/leds/leds-gpio.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) For this patch: Acked-by: Jacek Anaszewski j.anaszew...@samsung.com Thanks, I merged it. -Bryan I have a question regarding the sequence above on line 201: if (!led.name) return ERR_PTR(-EINVAL); Shouldn't this be also 'goto err? -- Best Regards, Jacek Anaszewski -- 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: [PATCH] MAINTAINERS: Add co-maintainer for LED subsystem
On Thu, Apr 9, 2015 at 10:30 AM, Bryan Wu wrote: > On Thu, Apr 9, 2015 at 1:01 AM, Jacek Anaszewski > wrote: >> This patch adds myself (Jacek Anaszewski) as a co-maintainer for >> LED subsystem. >> > > Jacek will start to help maintain LED subsystem. > > Acked-by: Bryan Wu > Hi Linus, Can we merge this patch? Then Jacek can receive patches directly. Thanks, -Bryan >> Signed-off-by: Jacek Anaszewski >> --- >> MAINTAINERS |1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 201280a..222f53a 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -5815,6 +5815,7 @@ F:drivers/scsi/53c700* >> LED SUBSYSTEM >> M: Bryan Wu >> M: Richard Purdie >> +M: Jacek Anaszewski >> L: linux-l...@vger.kernel.org >> T: git >> git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git >> S: Maintained >> -- >> 1.7.9.5 >> -- 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: [PATCH] MAINTAINERS: Add co-maintainer for LED subsystem
On Thu, Apr 9, 2015 at 10:30 AM, Bryan Wu coolo...@gmail.com wrote: On Thu, Apr 9, 2015 at 1:01 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: This patch adds myself (Jacek Anaszewski) as a co-maintainer for LED subsystem. Jacek will start to help maintain LED subsystem. Acked-by: Bryan Wu coolo...@gmail.com Hi Linus, Can we merge this patch? Then Jacek can receive patches directly. Thanks, -Bryan Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com --- MAINTAINERS |1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 201280a..222f53a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5815,6 +5815,7 @@ F:drivers/scsi/53c700* LED SUBSYSTEM M: Bryan Wu coolo...@gmail.com M: Richard Purdie rpur...@rpsys.net +M: Jacek Anaszewski j.anaszew...@samsung.com L: linux-l...@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git S: Maintained -- 1.7.9.5 -- 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/
[GIT PULL] LED subsystem updates for 4.1
Hi Linus, In this cycle, we merged some fix and update for LED Flash class driver. Then the core code of LED Flash class driver is in the kernel now. Moreover, we also got some bug fixes, code cleanup and new drivers for LED controllers. So please consider to pull the following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git for-next for you to fetch changes up to ccdc45075aeaaa144af4177b85570eb26c2f5a8b: leds: Don't treat the LED name as a format string (2015-03-30 14:26:32 -0700) Bjorn Andersson (1): leds: Introduce devres helper for led_classdev_register Courtney Cavin (2): leds: add DT binding for Qualcomm PM8941 WLED block leds: add Qualcomm PM8941 WLED driver Geert Uytterhoeven (1): leds: pca963x: Add missing initialiation of struct led_info.flags Jacek Anaszewski (7): leds: flash: remove stray include directive leds: flash: Remove synchronized flash strobe feature leds: flash: document sysfs interface Documentation: leds: Add description of LED Flash class extension leds: flash: Fix the size of sysfs_groups array dt-binding: leds: Add common LED DT bindings macros DT: leds: Add uniqueness requirement for 'label' property. Masanari Iida (2): leds: lp8501: Fix typo in MODULE_DESCRIPTION in leds-lp8501.c leds: lp8860: Fix typo in MODULE_DESCRIPTION in leds-lp8860.c Olliver Schinagl (1): leds: Let the binding document example for leds-gpio follow the gpio bindings Ricardo Ribalda Delgado (1): leds/led-class: Handle LEDs with the same name Sakari Ailus (2): leds: Use log level warn instead of info when telling about a name clash leds: Don't treat the LED name as a format string Sebastian Andrzej Siewior (1): leds: leds-pwm: drop one pwm_get_period() call Uwe Kleine-König (1): leds: lp8860: make use of devm_gpiod_get_optional Documentation/ABI/testing/sysfs-class-led-flash| 80 Documentation/devicetree/bindings/leds/common.txt | 6 +- .../devicetree/bindings/leds/leds-gpio.txt | 12 +- .../devicetree/bindings/leds/leds-pm8941-wled.txt | 43 ++ Documentation/driver-model/devres.txt | 4 + Documentation/leds/leds-class-flash.txt| 22 ++ drivers/leds/Kconfig | 8 + drivers/leds/Makefile | 1 + drivers/leds/led-class-flash.c | 82 drivers/leds/led-class.c | 96 - drivers/leds/leds-lp8501.c | 2 +- drivers/leds/leds-lp8860.c | 14 +- drivers/leds/leds-pca963x.c| 2 +- drivers/leds/leds-pm8941-wled.c| 435 + drivers/leds/leds-pwm.c| 3 - include/dt-bindings/leds/common.h | 21 + include/linux/led-class-flash.h| 19 +- include/linux/leds.h | 5 +- 18 files changed, 735 insertions(+), 120 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-led-flash create mode 100644 Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt create mode 100644 Documentation/leds/leds-class-flash.txt create mode 100644 drivers/leds/leds-pm8941-wled.c create mode 100644 include/dt-bindings/leds/common.h -- 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/
[GIT PULL] LED subsystem updates for 4.1
Hi Linus, In this cycle, we merged some fix and update for LED Flash class driver. Then the core code of LED Flash class driver is in the kernel now. Moreover, we also got some bug fixes, code cleanup and new drivers for LED controllers. So please consider to pull the following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git for-next for you to fetch changes up to ccdc45075aeaaa144af4177b85570eb26c2f5a8b: leds: Don't treat the LED name as a format string (2015-03-30 14:26:32 -0700) Bjorn Andersson (1): leds: Introduce devres helper for led_classdev_register Courtney Cavin (2): leds: add DT binding for Qualcomm PM8941 WLED block leds: add Qualcomm PM8941 WLED driver Geert Uytterhoeven (1): leds: pca963x: Add missing initialiation of struct led_info.flags Jacek Anaszewski (7): leds: flash: remove stray include directive leds: flash: Remove synchronized flash strobe feature leds: flash: document sysfs interface Documentation: leds: Add description of LED Flash class extension leds: flash: Fix the size of sysfs_groups array dt-binding: leds: Add common LED DT bindings macros DT: leds: Add uniqueness requirement for 'label' property. Masanari Iida (2): leds: lp8501: Fix typo in MODULE_DESCRIPTION in leds-lp8501.c leds: lp8860: Fix typo in MODULE_DESCRIPTION in leds-lp8860.c Olliver Schinagl (1): leds: Let the binding document example for leds-gpio follow the gpio bindings Ricardo Ribalda Delgado (1): leds/led-class: Handle LEDs with the same name Sakari Ailus (2): leds: Use log level warn instead of info when telling about a name clash leds: Don't treat the LED name as a format string Sebastian Andrzej Siewior (1): leds: leds-pwm: drop one pwm_get_period() call Uwe Kleine-König (1): leds: lp8860: make use of devm_gpiod_get_optional Documentation/ABI/testing/sysfs-class-led-flash| 80 Documentation/devicetree/bindings/leds/common.txt | 6 +- .../devicetree/bindings/leds/leds-gpio.txt | 12 +- .../devicetree/bindings/leds/leds-pm8941-wled.txt | 43 ++ Documentation/driver-model/devres.txt | 4 + Documentation/leds/leds-class-flash.txt| 22 ++ drivers/leds/Kconfig | 8 + drivers/leds/Makefile | 1 + drivers/leds/led-class-flash.c | 82 drivers/leds/led-class.c | 96 - drivers/leds/leds-lp8501.c | 2 +- drivers/leds/leds-lp8860.c | 14 +- drivers/leds/leds-pca963x.c| 2 +- drivers/leds/leds-pm8941-wled.c| 435 + drivers/leds/leds-pwm.c| 3 - include/dt-bindings/leds/common.h | 21 + include/linux/led-class-flash.h| 19 +- include/linux/leds.h | 5 +- 18 files changed, 735 insertions(+), 120 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-led-flash create mode 100644 Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt create mode 100644 Documentation/leds/leds-class-flash.txt create mode 100644 drivers/leds/leds-pm8941-wled.c create mode 100644 include/dt-bindings/leds/common.h -- 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: [PATCH v2] leds: fix redundant trigger API #ifdef
On Thu, Apr 9, 2015 at 8:37 AM, Valentin Rothberg
wrote:
> Commit 5a15d172057c ("leds: unify the location of led-trigger API")
> moved the leds trigger API to led.h. Moving the function definitions
> caused a logical problem regarding the visibility of #idef blocks. As
> listed in the code snippet below, the inner #else block will never see a
> compiler since CONFIG_LEDS_TRIGGERS is always true for the second #ifdef.
>
> #ifdef CONFIG_LEDS_TRIGGERS
> [...]
> #ifdef CONFIG_LEDS_TRIGGERS
> [...]
> #else
> #define led_trigger_set_default(x) do {} while (0)
> #define led_trigger_set(x, y) do {} while (0)
> #define led_trigger_remove(x) do {} while (0)
> #define led_get_trigger_data(x) (NULL)
> #endif
> #else
> [...]
> #endif
>
> This patch removes the second, redundant #ifdef and moves the code of
> the #else branch to its proper place.
>
Thanks for patching this. Jacek got a fix then.
-Bryan
> Signed-off-by: Valentin Rothberg
> ---
> I found this issue with undertaker-checkpatch from the Undertaker
> toolsuite. See undertaker.cs.fau.de for more information.
>
> v2: Add the code snippet example. It has been removed by Git before.
> ---
> include/linux/leds.h | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 057970818961..96a669f93f69 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -223,7 +223,6 @@ struct led_trigger {
> struct list_head next_trig;
> };
>
> -#ifdef CONFIG_LEDS_TRIGGERS
> void led_trigger_set_default(struct led_classdev *led_cdev);
> void led_trigger_set(struct led_classdev *led_cdev,
> struct led_trigger *trigger);
> @@ -234,13 +233,6 @@ static inline void *led_get_trigger_data(struct
> led_classdev *led_cdev)
> return led_cdev->trigger_data;
> }
>
> -#else
> -#define led_trigger_set_default(x) do {} while (0)
> -#define led_trigger_set(x, y) do {} while (0)
> -#define led_trigger_remove(x) do {} while (0)
> -#define led_get_trigger_data(x) (NULL)
> -#endif
> -
> ssize_t led_trigger_store(struct device *dev, struct device_attribute *attr,
> const char *buf, size_t count);
> ssize_t led_trigger_show(struct device *dev, struct device_attribute *attr,
> @@ -282,6 +274,11 @@ extern void led_trigger_rename_static(const char *name,
>
> #else
>
> +#define led_trigger_set_default(x) do {} while (0)
> +#define led_trigger_set(x, y) do {} while (0)
> +#define led_trigger_remove(x) do {} while (0)
> +#define led_get_trigger_data(x) (NULL)
> +
> /* Trigger has no members */
> struct led_trigger {};
>
> --
> 2.1.0
>
--
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: [PATCH -next] leds: Fix build failure seen if LEDS_TRIGGERS is not configured
On Thu, Apr 9, 2015 at 8:42 AM, Guenter Roeck wrote:
> Fix:
>
> drivers/leds/led-class.c: In function 'brightness_store':
> drivers/leds/led-class.c:57: error:
> implicit declaration of function 'led_trigger_remove'
>
> seen if LEDS_TRIGGERS is not configured.
>
Thanks for patching this. Jacek got a fix then.
-Bryan
> Fixes: 5a15d172057c ("leds: unify the location of led-trigger API")
> Cc: Jacek Anaszewski
> Signed-off-by: Guenter Roeck
> ---
> include/linux/leds.h | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 0579708..96a669f 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -223,7 +223,6 @@ struct led_trigger {
> struct list_head next_trig;
> };
>
> -#ifdef CONFIG_LEDS_TRIGGERS
> void led_trigger_set_default(struct led_classdev *led_cdev);
> void led_trigger_set(struct led_classdev *led_cdev,
> struct led_trigger *trigger);
> @@ -234,13 +233,6 @@ static inline void *led_get_trigger_data(struct
> led_classdev *led_cdev)
> return led_cdev->trigger_data;
> }
>
> -#else
> -#define led_trigger_set_default(x) do {} while (0)
> -#define led_trigger_set(x, y) do {} while (0)
> -#define led_trigger_remove(x) do {} while (0)
> -#define led_get_trigger_data(x) (NULL)
> -#endif
> -
> ssize_t led_trigger_store(struct device *dev, struct device_attribute *attr,
> const char *buf, size_t count);
> ssize_t led_trigger_show(struct device *dev, struct device_attribute *attr,
> @@ -282,6 +274,11 @@ extern void led_trigger_rename_static(const char *name,
>
> #else
>
> +#define led_trigger_set_default(x) do {} while (0)
> +#define led_trigger_set(x, y) do {} while (0)
> +#define led_trigger_remove(x) do {} while (0)
> +#define led_get_trigger_data(x) (NULL)
> +
> /* Trigger has no members */
> struct led_trigger {};
>
> --
> 2.1.0
>
--
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: [PATCH] MAINTAINERS: Add co-maintainer for LED subsystem
On Thu, Apr 9, 2015 at 1:01 AM, Jacek Anaszewski wrote: > This patch adds myself (Jacek Anaszewski) as a co-maintainer for > LED subsystem. > Jacek will start to help maintain LED subsystem. Acked-by: Bryan Wu > Signed-off-by: Jacek Anaszewski > --- > MAINTAINERS |1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 201280a..222f53a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5815,6 +5815,7 @@ F:drivers/scsi/53c700* > LED SUBSYSTEM > M: Bryan Wu > M: Richard Purdie > +M: Jacek Anaszewski > L: linux-l...@vger.kernel.org > T: git > git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git > S: Maintained > -- > 1.7.9.5 > -- 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: [PATCH -next] leds: Fix build failure seen if LEDS_TRIGGERS is not configured
On Thu, Apr 9, 2015 at 8:42 AM, Guenter Roeck li...@roeck-us.net wrote:
Fix:
drivers/leds/led-class.c: In function 'brightness_store':
drivers/leds/led-class.c:57: error:
implicit declaration of function 'led_trigger_remove'
seen if LEDS_TRIGGERS is not configured.
Thanks for patching this. Jacek got a fix then.
-Bryan
Fixes: 5a15d172057c (leds: unify the location of led-trigger API)
Cc: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
include/linux/leds.h | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 0579708..96a669f 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -223,7 +223,6 @@ struct led_trigger {
struct list_head next_trig;
};
-#ifdef CONFIG_LEDS_TRIGGERS
void led_trigger_set_default(struct led_classdev *led_cdev);
void led_trigger_set(struct led_classdev *led_cdev,
struct led_trigger *trigger);
@@ -234,13 +233,6 @@ static inline void *led_get_trigger_data(struct
led_classdev *led_cdev)
return led_cdev-trigger_data;
}
-#else
-#define led_trigger_set_default(x) do {} while (0)
-#define led_trigger_set(x, y) do {} while (0)
-#define led_trigger_remove(x) do {} while (0)
-#define led_get_trigger_data(x) (NULL)
-#endif
-
ssize_t led_trigger_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count);
ssize_t led_trigger_show(struct device *dev, struct device_attribute *attr,
@@ -282,6 +274,11 @@ extern void led_trigger_rename_static(const char *name,
#else
+#define led_trigger_set_default(x) do {} while (0)
+#define led_trigger_set(x, y) do {} while (0)
+#define led_trigger_remove(x) do {} while (0)
+#define led_get_trigger_data(x) (NULL)
+
/* Trigger has no members */
struct led_trigger {};
--
2.1.0
--
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: [PATCH v2] leds: fix redundant trigger API #ifdef
On Thu, Apr 9, 2015 at 8:37 AM, Valentin Rothberg
valentinrothb...@gmail.com wrote:
Commit 5a15d172057c (leds: unify the location of led-trigger API)
moved the leds trigger API to led.h. Moving the function definitions
caused a logical problem regarding the visibility of #idef blocks. As
listed in the code snippet below, the inner #else block will never see a
compiler since CONFIG_LEDS_TRIGGERS is always true for the second #ifdef.
#ifdef CONFIG_LEDS_TRIGGERS
[...]
#ifdef CONFIG_LEDS_TRIGGERS
[...]
#else
#define led_trigger_set_default(x) do {} while (0)
#define led_trigger_set(x, y) do {} while (0)
#define led_trigger_remove(x) do {} while (0)
#define led_get_trigger_data(x) (NULL)
#endif
#else
[...]
#endif
This patch removes the second, redundant #ifdef and moves the code of
the #else branch to its proper place.
Thanks for patching this. Jacek got a fix then.
-Bryan
Signed-off-by: Valentin Rothberg valentinrothb...@gmail.com
---
I found this issue with undertaker-checkpatch from the Undertaker
toolsuite. See undertaker.cs.fau.de for more information.
v2: Add the code snippet example. It has been removed by Git before.
---
include/linux/leds.h | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 057970818961..96a669f93f69 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -223,7 +223,6 @@ struct led_trigger {
struct list_head next_trig;
};
-#ifdef CONFIG_LEDS_TRIGGERS
void led_trigger_set_default(struct led_classdev *led_cdev);
void led_trigger_set(struct led_classdev *led_cdev,
struct led_trigger *trigger);
@@ -234,13 +233,6 @@ static inline void *led_get_trigger_data(struct
led_classdev *led_cdev)
return led_cdev-trigger_data;
}
-#else
-#define led_trigger_set_default(x) do {} while (0)
-#define led_trigger_set(x, y) do {} while (0)
-#define led_trigger_remove(x) do {} while (0)
-#define led_get_trigger_data(x) (NULL)
-#endif
-
ssize_t led_trigger_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count);
ssize_t led_trigger_show(struct device *dev, struct device_attribute *attr,
@@ -282,6 +274,11 @@ extern void led_trigger_rename_static(const char *name,
#else
+#define led_trigger_set_default(x) do {} while (0)
+#define led_trigger_set(x, y) do {} while (0)
+#define led_trigger_remove(x) do {} while (0)
+#define led_get_trigger_data(x) (NULL)
+
/* Trigger has no members */
struct led_trigger {};
--
2.1.0
--
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: [PATCH] MAINTAINERS: Add co-maintainer for LED subsystem
On Thu, Apr 9, 2015 at 1:01 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: This patch adds myself (Jacek Anaszewski) as a co-maintainer for LED subsystem. Jacek will start to help maintain LED subsystem. Acked-by: Bryan Wu coolo...@gmail.com Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com --- MAINTAINERS |1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 201280a..222f53a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5815,6 +5815,7 @@ F:drivers/scsi/53c700* LED SUBSYSTEM M: Bryan Wu coolo...@gmail.com M: Richard Purdie rpur...@rpsys.net +M: Jacek Anaszewski j.anaszew...@samsung.com L: linux-l...@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git S: Maintained -- 1.7.9.5 -- 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: [PATCH] leds-gpio: Fix error handling and memory leak
On Thu, Mar 26, 2015 at 8:08 PM, Corey Minyard wrote:
> On 03/26/2015 08:20 PM, Bryan Wu wrote:
>> On Mon, Mar 9, 2015 at 5:43 PM, wrote:
>>> From: Corey Minyard
>>>
>>> The leds-gpio driver would not clean up properly if it failed in some
>>> places, and it wasn't freeing its private data.
>>>
>>> Signed-off-by: Corey Minyard
>>> ---
>>> drivers/leds/leds-gpio.c | 13 +
>>> 1 file changed, 9 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
>>> index d26af0a..32f7642 100644
>>> --- a/drivers/leds/leds-gpio.c
>>> +++ b/drivers/leds/leds-gpio.c
>>> @@ -198,8 +198,10 @@ static struct gpio_leds_priv *gpio_leds_create(struct
>>> platform_device *pdev)
>>> } else {
>>> if (IS_ENABLED(CONFIG_OF) && !led.name && np)
>>> led.name = np->name;
>>> - if (!led.name)
>>> - return ERR_PTR(-EINVAL);
>>> + if (!led.name) {
>>> + ret = -EINVAL;
>>> + goto err;
>>> + }
>>> }
>>> fwnode_property_read_string(child, "linux,default-trigger",
>>> _trigger);
>>> @@ -217,19 +219,21 @@ static struct gpio_leds_priv *gpio_leds_create(struct
>>> platform_device *pdev)
>>> if (fwnode_property_present(child,
>>> "retain-state-suspended"))
>>> led.retain_state_suspended = 1;
>>>
>>> - ret = create_gpio_led(, >leds[priv->num_leds++],
>>> + ret = create_gpio_led(, >leds[priv->num_leds],
>> Why need this change? it's correct. And your add one more line
>> "priv->num_leds++"
>
> That's actually the major source of the problem. The value of
> priv->num_leds was not correct if it failed before this point, and there
> was already one "goto err" above this code and I added another to
> properly handle not allocating the led name. If it failed there it
> would leave an LED lying around but free the memory underneath it. So
> instead, modify the failure recovery code to be priv->num_leds-1 instead
> of priv->num_leds-2 and don't increment priv->num_leds until you have
> success.
>
>>> dev, NULL);
>>> if (ret < 0) {
>>> fwnode_handle_put(child);
>>> goto err;
>>> }
>>> + priv->num_leds++;
>> Why need this?
>
> See above.
>
>>> }
>>>
>>> return priv;
>>>
>>> err:
>>> - for (count = priv->num_leds - 2; count >= 0; count--)
>>> + for (count = priv->num_leds - 1; count >= 0; count--)
>>> delete_gpio_led(>leds[count]);
>>> + devm_kfree(dev, priv);
>> priv is created by devm_kzalloc(), so if driver probing return error,
>> it will be freed automatically, you don't need call devm_free();
>
> Ah, ok. Then this is unnecessary. Do want a new patch?
>
I see, please provide a new patch. I'm going to merge this fix soon.
Thanks,
-Bryan
> Thanks,
>
> -corey
>
>>> return ERR_PTR(ret);
>>> }
>>>
>>> @@ -283,6 +287,7 @@ static int gpio_led_remove(struct platform_device *pdev)
>>>
>>> for (i = 0; i < priv->num_leds; i++)
>>> delete_gpio_led(>leds[i]);
>>> + devm_kfree(>dev, priv);
>> No need this during remove.
>>
>>> return 0;
>>> }
>>> --
>>> 1.8.3.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-leds" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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: [PATCH 0/3] Handle LEDs with the same name
On Mon, Mar 30, 2015 at 10:45 AM, Ricardo Ribalda Delgado wrote: > This is a rework of the original patch + 3 fixup patches from me. > Contains a lot of feedback from Geert Uytterhoeven > Thanks! > > Ricardo Ribalda Delgado (1): > leds/led-class: Handle LEDs with the same name > > Sakari Ailus (2): > leds: Use log level warn instead of info when telling about a name > clash > leds: Don't treat the LED name as a format string > > drivers/leds/led-class.c | 39 +-- > 1 file changed, 37 insertions(+), 2 deletions(-) > Applied again. Thanks, -Bryan -- 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: [PATCH 0/3] leds/class: Fix string handling
On Mon, Mar 30, 2015 at 10:46 AM, Ricardo Ribalda Delgado wrote: > Hello Bryan > > On Mon, Mar 30, 2015 at 7:15 PM, Bryan Wu wrote: >> Thanks, Geert and Ricardo. >> Ricardo, do you mind folding your fixing patches with original one >> together and send it out again? I will use the new one to replace that >> one in my tree, since this patch is not merged into Linus tree yet. > > Not at all, I have also added sakaris patches to my patchset so you > wont have any problem with them. > I dont know what are the conventions with s-o-b in this cases, so I > have left the defaults from git rebase > > Thanks! Good, I will handle that. Thanks, -Bryan -- 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: [PATCH 0/3] leds/class: Fix string handling
On Mon, Mar 30, 2015 at 1:55 AM, Ricardo Ribalda Delgado wrote: > Fix errors reported by Geert Uytterhoeven. > > I didn't have the chance to test the changes it in real hardware. > > Thanks, Geert and Ricardo. Ricardo, do you mind folding your fixing patches with original one together and send it out again? I will use the new one to replace that one in my tree, since this patch is not merged into Linus tree yet. -Bryan > Ricardo Ribalda Delgado (3): > leds/class: Use strlcpy instead of strncpy > leds/class: Check snprintf return value > leds/class: Set naming index as unsigned > > drivers/leds/led-class.c | 14 +++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > -- > 2.1.4 > -- 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: [PATCH 0/3] leds/class: Fix string handling
On Mon, Mar 30, 2015 at 1:55 AM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: Fix errors reported by Geert Uytterhoeven. I didn't have the chance to test the changes it in real hardware. Thanks, Geert and Ricardo. Ricardo, do you mind folding your fixing patches with original one together and send it out again? I will use the new one to replace that one in my tree, since this patch is not merged into Linus tree yet. -Bryan Ricardo Ribalda Delgado (3): leds/class: Use strlcpy instead of strncpy leds/class: Check snprintf return value leds/class: Set naming index as unsigned drivers/leds/led-class.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) -- 2.1.4 -- 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: [PATCH 0/3] leds/class: Fix string handling
On Mon, Mar 30, 2015 at 10:46 AM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: Hello Bryan On Mon, Mar 30, 2015 at 7:15 PM, Bryan Wu coolo...@gmail.com wrote: Thanks, Geert and Ricardo. Ricardo, do you mind folding your fixing patches with original one together and send it out again? I will use the new one to replace that one in my tree, since this patch is not merged into Linus tree yet. Not at all, I have also added sakaris patches to my patchset so you wont have any problem with them. I dont know what are the conventions with s-o-b in this cases, so I have left the defaults from git rebase Thanks! Good, I will handle that. Thanks, -Bryan -- 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: [PATCH 0/3] Handle LEDs with the same name
On Mon, Mar 30, 2015 at 10:45 AM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: This is a rework of the original patch + 3 fixup patches from me. Contains a lot of feedback from Geert Uytterhoeven ge...@linux-m68k.org Thanks! Ricardo Ribalda Delgado (1): leds/led-class: Handle LEDs with the same name Sakari Ailus (2): leds: Use log level warn instead of info when telling about a name clash leds: Don't treat the LED name as a format string drivers/leds/led-class.c | 39 +-- 1 file changed, 37 insertions(+), 2 deletions(-) Applied again. Thanks, -Bryan -- 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: [PATCH] leds-gpio: Fix error handling and memory leak
On Thu, Mar 26, 2015 at 8:08 PM, Corey Minyard miny...@acm.org wrote:
On 03/26/2015 08:20 PM, Bryan Wu wrote:
On Mon, Mar 9, 2015 at 5:43 PM, miny...@acm.org wrote:
From: Corey Minyard cminy...@mvista.com
The leds-gpio driver would not clean up properly if it failed in some
places, and it wasn't freeing its private data.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
drivers/leds/leds-gpio.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index d26af0a..32f7642 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -198,8 +198,10 @@ static struct gpio_leds_priv *gpio_leds_create(struct
platform_device *pdev)
} else {
if (IS_ENABLED(CONFIG_OF) !led.name np)
led.name = np-name;
- if (!led.name)
- return ERR_PTR(-EINVAL);
+ if (!led.name) {
+ ret = -EINVAL;
+ goto err;
+ }
}
fwnode_property_read_string(child, linux,default-trigger,
led.default_trigger);
@@ -217,19 +219,21 @@ static struct gpio_leds_priv *gpio_leds_create(struct
platform_device *pdev)
if (fwnode_property_present(child,
retain-state-suspended))
led.retain_state_suspended = 1;
- ret = create_gpio_led(led, priv-leds[priv-num_leds++],
+ ret = create_gpio_led(led, priv-leds[priv-num_leds],
Why need this change? it's correct. And your add one more line
priv-num_leds++
That's actually the major source of the problem. The value of
priv-num_leds was not correct if it failed before this point, and there
was already one goto err above this code and I added another to
properly handle not allocating the led name. If it failed there it
would leave an LED lying around but free the memory underneath it. So
instead, modify the failure recovery code to be priv-num_leds-1 instead
of priv-num_leds-2 and don't increment priv-num_leds until you have
success.
dev, NULL);
if (ret 0) {
fwnode_handle_put(child);
goto err;
}
+ priv-num_leds++;
Why need this?
See above.
}
return priv;
err:
- for (count = priv-num_leds - 2; count = 0; count--)
+ for (count = priv-num_leds - 1; count = 0; count--)
delete_gpio_led(priv-leds[count]);
+ devm_kfree(dev, priv);
priv is created by devm_kzalloc(), so if driver probing return error,
it will be freed automatically, you don't need call devm_free();
Ah, ok. Then this is unnecessary. Do want a new patch?
I see, please provide a new patch. I'm going to merge this fix soon.
Thanks,
-Bryan
Thanks,
-corey
return ERR_PTR(ret);
}
@@ -283,6 +287,7 @@ static int gpio_led_remove(struct platform_device *pdev)
for (i = 0; i priv-num_leds; i++)
delete_gpio_led(priv-leds[i]);
+ devm_kfree(pdev-dev, priv);
No need this during remove.
return 0;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-leds in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: [PATCH v3] led/led-class: Handle LEDs with the same name
On Fri, Mar 27, 2015 at 1:09 AM, Ricardo Ribalda Delgado wrote: > Hi Sakari > > cc: adding Greg (core and FormatGuard) and Chistopher (sparse) >> >> I just realised there was another issue --- the name is now interpreted as >> format string. Bad things will happen if there's e.g. %s in the name itself >> --- perhaps unlikely, but possible. > > Good catch! > > Would it be possible to add a sparse check to avoid this in all the kernel? > > And what about a macro protection like FormatGuard? > > https://www.usenix.org/legacy/events/sec01/full_papers/cowanbarringer/cowanbarringer.pdf > > I think Fengguang's 0-DAY kernel test infrastructure can help this. -Bryan -- 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: [PATCH v3] led/led-class: Handle LEDs with the same name
On Fri, Mar 27, 2015 at 1:09 AM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: Hi Sakari cc: adding Greg (core and FormatGuard) and Chistopher (sparse) I just realised there was another issue --- the name is now interpreted as format string. Bad things will happen if there's e.g. %s in the name itself --- perhaps unlikely, but possible. Good catch! Would it be possible to add a sparse check to avoid this in all the kernel? And what about a macro protection like FormatGuard? https://www.usenix.org/legacy/events/sec01/full_papers/cowanbarringer/cowanbarringer.pdf I think Fengguang's 0-DAY kernel test infrastructure can help this. -Bryan -- 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: [PATCH] leds-gpio: Fix error handling and memory leak
On Mon, Mar 9, 2015 at 5:43 PM, wrote:
> From: Corey Minyard
>
> The leds-gpio driver would not clean up properly if it failed in some
> places, and it wasn't freeing its private data.
>
> Signed-off-by: Corey Minyard
> ---
> drivers/leds/leds-gpio.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index d26af0a..32f7642 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -198,8 +198,10 @@ static struct gpio_leds_priv *gpio_leds_create(struct
> platform_device *pdev)
> } else {
> if (IS_ENABLED(CONFIG_OF) && !led.name && np)
> led.name = np->name;
> - if (!led.name)
> - return ERR_PTR(-EINVAL);
> + if (!led.name) {
> + ret = -EINVAL;
> + goto err;
> + }
> }
> fwnode_property_read_string(child, "linux,default-trigger",
> _trigger);
> @@ -217,19 +219,21 @@ static struct gpio_leds_priv *gpio_leds_create(struct
> platform_device *pdev)
> if (fwnode_property_present(child, "retain-state-suspended"))
> led.retain_state_suspended = 1;
>
> - ret = create_gpio_led(, >leds[priv->num_leds++],
> + ret = create_gpio_led(, >leds[priv->num_leds],
Why need this change? it's correct. And your add one more line
"priv->num_leds++"
> dev, NULL);
> if (ret < 0) {
> fwnode_handle_put(child);
> goto err;
> }
> + priv->num_leds++;
Why need this?
> }
>
> return priv;
>
> err:
> - for (count = priv->num_leds - 2; count >= 0; count--)
> + for (count = priv->num_leds - 1; count >= 0; count--)
> delete_gpio_led(>leds[count]);
> + devm_kfree(dev, priv);
priv is created by devm_kzalloc(), so if driver probing return error,
it will be freed automatically, you don't need call devm_free();
> return ERR_PTR(ret);
> }
>
> @@ -283,6 +287,7 @@ static int gpio_led_remove(struct platform_device *pdev)
>
> for (i = 0; i < priv->num_leds; i++)
> delete_gpio_led(>leds[i]);
> + devm_kfree(>dev, priv);
No need this during remove.
>
> return 0;
> }
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-leds" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: [PATCH] leds-gpio: Fix error handling and memory leak
On Mon, Mar 9, 2015 at 5:43 PM, miny...@acm.org wrote:
From: Corey Minyard cminy...@mvista.com
The leds-gpio driver would not clean up properly if it failed in some
places, and it wasn't freeing its private data.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
drivers/leds/leds-gpio.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index d26af0a..32f7642 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -198,8 +198,10 @@ static struct gpio_leds_priv *gpio_leds_create(struct
platform_device *pdev)
} else {
if (IS_ENABLED(CONFIG_OF) !led.name np)
led.name = np-name;
- if (!led.name)
- return ERR_PTR(-EINVAL);
+ if (!led.name) {
+ ret = -EINVAL;
+ goto err;
+ }
}
fwnode_property_read_string(child, linux,default-trigger,
led.default_trigger);
@@ -217,19 +219,21 @@ static struct gpio_leds_priv *gpio_leds_create(struct
platform_device *pdev)
if (fwnode_property_present(child, retain-state-suspended))
led.retain_state_suspended = 1;
- ret = create_gpio_led(led, priv-leds[priv-num_leds++],
+ ret = create_gpio_led(led, priv-leds[priv-num_leds],
Why need this change? it's correct. And your add one more line
priv-num_leds++
dev, NULL);
if (ret 0) {
fwnode_handle_put(child);
goto err;
}
+ priv-num_leds++;
Why need this?
}
return priv;
err:
- for (count = priv-num_leds - 2; count = 0; count--)
+ for (count = priv-num_leds - 1; count = 0; count--)
delete_gpio_led(priv-leds[count]);
+ devm_kfree(dev, priv);
priv is created by devm_kzalloc(), so if driver probing return error,
it will be freed automatically, you don't need call devm_free();
return ERR_PTR(ret);
}
@@ -283,6 +287,7 @@ static int gpio_led_remove(struct platform_device *pdev)
for (i = 0; i priv-num_leds; i++)
delete_gpio_led(priv-leds[i]);
+ devm_kfree(pdev-dev, priv);
No need this during remove.
return 0;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-leds in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: [PATCH v3] led/led-class: Handle LEDs with the same name
On Wed, Mar 25, 2015 at 6:53 AM, Sakari Ailus wrote: > On Wed, Mar 25, 2015 at 02:22:53PM +0100, Ricardo Ribalda Delgado wrote: >> Hi Sakari! >> >> Regarding s/dev_info/dev_warn : Do you want to send the patch or I should >> >> do it? >> > >> > Is this one merged already? If yes, sure I can. Otherwise a new version >> > would be nice. >> It is at least here >> >> https://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/?h=devel=0767f8c5c53018f8cc7d87871abb7d3290be7596 >> >> and here >> >> https://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/?h=for-next=0767f8c5c53018f8cc7d87871abb7d3290be7596 > > I'll send a patch. Thanks! > Cool, please! Thanks, -Bryan -- 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: [PATCH v3] led/led-class: Handle LEDs with the same name
On Wed, Mar 25, 2015 at 6:53 AM, Sakari Ailus sakari.ai...@iki.fi wrote: On Wed, Mar 25, 2015 at 02:22:53PM +0100, Ricardo Ribalda Delgado wrote: Hi Sakari! Regarding s/dev_info/dev_warn : Do you want to send the patch or I should do it? Is this one merged already? If yes, sure I can. Otherwise a new version would be nice. It is at least here https://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/?h=develid=0767f8c5c53018f8cc7d87871abb7d3290be7596 and here https://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/?h=for-nextid=0767f8c5c53018f8cc7d87871abb7d3290be7596 I'll send a patch. Thanks! Cool, please! Thanks, -Bryan -- 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: [PATCH v2] leds: Add arbitrary pattern trigger
On Fri, Mar 20, 2015 at 7:42 AM, Raphaël Teysseyre wrote: > Hi all, > > Following your comments about [PATCH] leds: Add arbitrary pattern trigger, > here is a revised version of this patch. > > This is intended for embedded systems without screen or network access > to show a status (or error) code to a human. > > It's been tested on an ARM architecture (Xilinx Zynq 7010 SoC, > which CPU is a dual ARM Cortex-A9), with a non-mainline > kernel (xilinx-v2014.4, based of a 3.17.0 kernel). > Unfortunately, I don't have other hardware to test it on. > It compiles fine in a 3.19.0-rc1 source tree. > Additional testing and comments would be appreciated. > > Changes since version 1: > - Fixed typos in documentation and comments. > - Fixed MODULE_LICENSE string. > - No more mutex in atomic context. > - Return EINVAL when invalid patterns are written to the "pattern" attribute. > > > > Add a new led trigger supporting arbitrary patterns. > This is useful for embedded systems with no screen or network access. > > Export two sysfs attributes: "pattern", and "repeat". > > When "repeat"=-1, repeat the pattern indefinitely. Otherwise, > repeat it the specified number of times. "pattern" specifies > the pattern as comma separated couples of "brightness duration" > values. See detailled documentation in patch. > Thanks for pushing this. But as we discussed in previous patches provided by Joe Xue, we won't merge this kind of complex trigger patch into kernel. I think we need to think about a new LED API to user space and make it easier to handle. -Bryan. > Signed-off-by: Raphaël Teysseyre > --- > Documentation/leds/ledtrig-pattern.txt | 86 +++ > drivers/leds/trigger/Kconfig | 10 + > drivers/leds/trigger/Makefile |1 + > drivers/leds/trigger/ledtrig-pattern.c | 432 > > 4 files changed, 529 insertions(+), 0 deletions(-) > create mode 100644 Documentation/leds/ledtrig-pattern.txt > create mode 100644 drivers/leds/trigger/ledtrig-pattern.c > > diff --git a/Documentation/leds/ledtrig-pattern.txt > b/Documentation/leds/ledtrig-pattern.txt > new file mode 100644 > index 000..579295e > --- /dev/null > +++ b/Documentation/leds/ledtrig-pattern.txt > @@ -0,0 +1,86 @@ > +LED Pattern Trigger > +=== > + > +This is a LED trigger allowing arbitrary pattern execution. It can do gradual > +dimming. This trigger can be configured to repeat the pattern a number of > +times or indefinitely. This is intended as a way of communication for > embedded > +systems with no screen. > + > +The trigger can be activated from user space on LED class devices as shown > +below: > + > + echo pattern > trigger > + > +This adds the following sysfs attributes to the LED: > + > + pattern - specifies the pattern. See syntax below. > + > + repeat - number of times the pattern must be repeated. > + writing -1 to this file will make the pattern > + repeat indefinitely. > + > +The pattern will be restarted each time a new value is written to > +the pattern or repeat attribute. When dimming, the LED brightness > +is set every 50 ms. > + > +pattern syntax: > +The pattern is specified in the pattern attribute with an array of comma- > +separated "brightness/length in miliseconds" values. The two components > +of each value are to be separated by a space. > + > +For example, assuming the driven LED supports > +intensity value from 0 to 255: > + > + echo 0 1000, 255 2000 > pattern > + > +Or: > + > + echo 0 1000, 255 2000, > pattern > + > +Will make the LED go gradually from zero-intensity to max (255) intensity > +in 1000 milliseconds, then back to zero intensity in 2000 milliseconds: > + > +LED brightness > +^ > +255-| / \/ \/ > +| /\ /\ / > +| / \ / \ / > +|/ \ / \ / > + 0-| / \/ \/ > ++---0123456> time (s) > + > + > + > +To make the LED go instantly from one brigntess value to another, > +use zero-time lengths. For example: > + > + echo 0 1000, 0 0, 255 2000, 255 0 > pattern > + > +Will make the LED stay off for one second, then stay at max brightness > +for two seconds: > + > +LED brightness > +^ > +255-|+-++-+ > +|| || | > +|| || | > +|| || | > + 0-| -+ ++ + > ++---0123456> time (s) > + > + > +Notes: > + > +Patterns with invalid syntax are reported with EINVAL, the > +resulting LED brightness is undefined. Reading the pattern > +back returns an empty string. > + > +Patterns with less than two values, no value with time length > 50 > +milliseconds, or no two values with differing brightnesses > +result in the LED being set at the brightness of the first value, >
Re: [PATCH v2] leds: Add arbitrary pattern trigger
On Fri, Mar 20, 2015 at 7:42 AM, Raphaël Teysseyre rteysse...@gmail.com wrote: Hi all, Following your comments about [PATCH] leds: Add arbitrary pattern trigger, here is a revised version of this patch. This is intended for embedded systems without screen or network access to show a status (or error) code to a human. It's been tested on an ARM architecture (Xilinx Zynq 7010 SoC, which CPU is a dual ARM Cortex-A9), with a non-mainline kernel (xilinx-v2014.4, based of a 3.17.0 kernel). Unfortunately, I don't have other hardware to test it on. It compiles fine in a 3.19.0-rc1 source tree. Additional testing and comments would be appreciated. Changes since version 1: - Fixed typos in documentation and comments. - Fixed MODULE_LICENSE string. - No more mutex in atomic context. - Return EINVAL when invalid patterns are written to the pattern attribute. Add a new led trigger supporting arbitrary patterns. This is useful for embedded systems with no screen or network access. Export two sysfs attributes: pattern, and repeat. When repeat=-1, repeat the pattern indefinitely. Otherwise, repeat it the specified number of times. pattern specifies the pattern as comma separated couples of brightness duration values. See detailled documentation in patch. Thanks for pushing this. But as we discussed in previous patches provided by Joe Xue, we won't merge this kind of complex trigger patch into kernel. I think we need to think about a new LED API to user space and make it easier to handle. -Bryan. Signed-off-by: Raphaël Teysseyre rteysse...@gmail.com --- Documentation/leds/ledtrig-pattern.txt | 86 +++ drivers/leds/trigger/Kconfig | 10 + drivers/leds/trigger/Makefile |1 + drivers/leds/trigger/ledtrig-pattern.c | 432 4 files changed, 529 insertions(+), 0 deletions(-) create mode 100644 Documentation/leds/ledtrig-pattern.txt create mode 100644 drivers/leds/trigger/ledtrig-pattern.c diff --git a/Documentation/leds/ledtrig-pattern.txt b/Documentation/leds/ledtrig-pattern.txt new file mode 100644 index 000..579295e --- /dev/null +++ b/Documentation/leds/ledtrig-pattern.txt @@ -0,0 +1,86 @@ +LED Pattern Trigger +=== + +This is a LED trigger allowing arbitrary pattern execution. It can do gradual +dimming. This trigger can be configured to repeat the pattern a number of +times or indefinitely. This is intended as a way of communication for embedded +systems with no screen. + +The trigger can be activated from user space on LED class devices as shown +below: + + echo pattern trigger + +This adds the following sysfs attributes to the LED: + + pattern - specifies the pattern. See syntax below. + + repeat - number of times the pattern must be repeated. + writing -1 to this file will make the pattern + repeat indefinitely. + +The pattern will be restarted each time a new value is written to +the pattern or repeat attribute. When dimming, the LED brightness +is set every 50 ms. + +pattern syntax: +The pattern is specified in the pattern attribute with an array of comma- +separated brightness/length in miliseconds values. The two components +of each value are to be separated by a space. + +For example, assuming the driven LED supports +intensity value from 0 to 255: + + echo 0 1000, 255 2000 pattern + +Or: + + echo 0 1000, 255 2000, pattern + +Will make the LED go gradually from zero-intensity to max (255) intensity +in 1000 milliseconds, then back to zero intensity in 2000 milliseconds: + +LED brightness +^ +255-| / \/ \/ +| /\ /\ / +| / \ / \ / +|/ \ / \ / + 0-| / \/ \/ ++---0123456 time (s) + + + +To make the LED go instantly from one brigntess value to another, +use zero-time lengths. For example: + + echo 0 1000, 0 0, 255 2000, 255 0 pattern + +Will make the LED stay off for one second, then stay at max brightness +for two seconds: + +LED brightness +^ +255-|+-++-+ +|| || | +|| || | +|| || | + 0-| -+ ++ + ++---0123456 time (s) + + +Notes: + +Patterns with invalid syntax are reported with EINVAL, the +resulting LED brightness is undefined. Reading the pattern +back returns an empty string. + +Patterns with less than two values, no value with time length 50 +milliseconds, or no two values with differing brightnesses +result in the LED being set at the brightness of the first value, +or zero if the pattern contains no value. EINVAL is returned, +and reading the pattern back returns an empty
Re: [PATCH/RFC v13 02/13] dt-binding: leds: Add common LED DT bindings macros
On Thu, Mar 12, 2015 at 8:45 AM, Jacek Anaszewski wrote: > Add macros for defining boost mode and trigger type properties > of flash LED devices. > Applied, thanks, -Bryan > Signed-off-by: Jacek Anaszewski > Acked-by: Kyungmin Park > Cc: Bryan Wu > Cc: Richard Purdie > --- > include/dt-bindings/leds/common.h | 21 + > 1 file changed, 21 insertions(+) > create mode 100644 include/dt-bindings/leds/common.h > > diff --git a/include/dt-bindings/leds/common.h > b/include/dt-bindings/leds/common.h > new file mode 100644 > index 000..79fcef7 > --- /dev/null > +++ b/include/dt-bindings/leds/common.h > @@ -0,0 +1,21 @@ > +/* > + * This header provides macros for the common LEDs device tree bindings. > + * > + * Copyright (C) 2015, Samsung Electronics Co., Ltd. > + * > + * Author: Jacek Anaszewski > + */ > + > +#ifndef __DT_BINDINGS_LEDS_H__ > +#define __DT_BINDINGS_LEDS_H > + > +/* External trigger type */ > +#define LEDS_TRIG_TYPE_EDGE0 > +#define LEDS_TRIG_TYPE_LEVEL 1 > + > +/* Boost modes */ > +#define LEDS_BOOST_OFF 0 > +#define LEDS_BOOST_ADAPTIVE1 > +#define LEDS_BOOST_FIXED 2 > + > +#endif /* __DT_BINDINGS_LEDS_H */ > -- > 1.7.9.5 > -- 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: [PATCH] leds: fix semicolon.cocci warnings
On Tue, Mar 17, 2015 at 12:42 PM, kbuild test robot
wrote:
> drivers/leds/leds-pm8941-wled.c:368:2-3: Unneeded semicolon
>
>
> Removes unneeded semicolon.
I fixed it and pushed again.
Thanks,
-Bryan
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Courtney Cavin
> Signed-off-by: Fengguang Wu
> ---
>
> leds-pm8941-wled.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/leds/leds-pm8941-wled.c
> +++ b/drivers/leds/leds-pm8941-wled.c
> @@ -365,7 +365,7 @@ static int pm8941_wled_configure(struct
>
> dev_dbg(dev, "'%s' = %u\n", u32_opts[i].name, c);
> *u32_opts[i].val_ptr = j;
> - };
> + }
>
> for (i = 0; i < ARRAY_SIZE(bool_opts); ++i) {
> if (of_property_read_bool(dev->of_node, bool_opts[i].name))
--
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: [PATCH v4 2/2] leds: add Qualcomm PM8941 WLED driver
On Thu, Mar 12, 2015 at 8:47 AM, Bjorn Andersson
wrote:
>
> From: Courtney Cavin
>
> This adds support for the WLED ('White' LED) block on Qualcomm's
> PM8941 PMICs.
>
Thanks, applied!
-Bryan
> Signed-off-by: Courtney Cavin
> Signed-off-by: Bjorn Andersson
> ---
> Changes since v3:
> - Use devres helper
>
> Changes since v2:
> - Fix of parser return value on error
> - Dropped THIS_MODULE
>
> Changes since v1:
> - Replace enum blob with defines
> - Merged wled_context and wled structs
> - Some style updates
>
> drivers/leds/Kconfig| 8 +
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-pm8941-wled.c | 435
>
> 3 files changed, 444 insertions(+)
> create mode 100644 drivers/leds/leds-pm8941-wled.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 25b320d..966b960 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -526,6 +526,14 @@ config LEDS_VERSATILE
> This option enabled support for the LEDs on the ARM Versatile
> and RealView boards. Say Y to enabled these.
>
> +config LEDS_PM8941_WLED
> + tristate "LED support for the Qualcomm PM8941 WLED block"
> + depends on LEDS_CLASS
> + select REGMAP
> + help
> + This option enables support for the 'White' LED block
> + on Qualcomm PM8941 PMICs.
> +
> comment "LED Triggers"
> source "drivers/leds/trigger/Kconfig"
>
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index cbba921..bf46093 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -58,6 +58,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
> obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
> obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
> obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
> +obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
>
> # LED SPI Drivers
> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
> diff --git a/drivers/leds/leds-pm8941-wled.c b/drivers/leds/leds-pm8941-wled.c
> new file mode 100644
> index 000..b4f46db
> --- /dev/null
> +++ b/drivers/leds/leds-pm8941-wled.c
> @@ -0,0 +1,435 @@
> +/* Copyright (c) 2015, Sony Mobile Communications, AB.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define PM8941_WLED_REG_VAL_BASE 0x40
> +#define PM8941_WLED_REG_VAL_MAX 0xFFF
> +
> +#define PM8941_WLED_REG_MOD_EN 0x46
> +#define PM8941_WLED_REG_MOD_EN_BITBIT(7)
> +#define PM8941_WLED_REG_MOD_EN_MASK BIT(7)
> +
> +#define PM8941_WLED_REG_SYNC 0x47
> +#define PM8941_WLED_REG_SYNC_MASK 0x07
> +#define PM8941_WLED_REG_SYNC_LED1 BIT(0)
> +#define PM8941_WLED_REG_SYNC_LED2 BIT(1)
> +#define PM8941_WLED_REG_SYNC_LED3 BIT(2)
> +#define PM8941_WLED_REG_SYNC_ALL 0x07
> +#define PM8941_WLED_REG_SYNC_CLEAR0x00
> +
> +#define PM8941_WLED_REG_FREQ 0x4c
> +#define PM8941_WLED_REG_FREQ_MASK 0x0f
> +
> +#define PM8941_WLED_REG_OVP0x4d
> +#define PM8941_WLED_REG_OVP_MASK 0x03
> +
> +#define PM8941_WLED_REG_BOOST 0x4e
> +#define PM8941_WLED_REG_BOOST_MASK0x07
> +
> +#define PM8941_WLED_REG_SINK 0x4f
> +#define PM8941_WLED_REG_SINK_MASK 0xe0
> +#define PM8941_WLED_REG_SINK_SHFT 0x05
> +
> +/* Per-'string' registers below */
> +#define PM8941_WLED_REG_STR_OFFSET 0x10
> +
> +#define PM8941_WLED_REG_STR_MOD_EN_BASE0x60
> +#define PM8941_WLED_REG_STR_MOD_MASK BIT(7)
> +#define PM8941_WLED_REG_STR_MOD_ENBIT(7)
> +
> +#define PM8941_WLED_REG_STR_SCALE_BASE 0x62
> +#define PM8941_WLED_REG_STR_SCALE_MASK0x1f
> +
> +#define PM8941_WLED_REG_STR_MOD_SRC_BASE 0x63
> +#define PM8941_WLED_REG_STR_MOD_SRC_MASK 0x01
> +#define PM8941_WLED_REG_STR_MOD_SRC_INT 0x00
> +#define PM8941_WLED_REG_STR_MOD_SRC_EXT 0x01
> +
> +#define PM8941_WLED_REG_STR_CABC_BASE 0x66
> +#define PM8941_WLED_REG_STR_CABC_MASK BIT(7)
> +#define PM8941_WLED_REG_STR_CABC_EN BIT(7)
> +
> +struct pm8941_wled_config {
> + u32 i_boost_limit;
> + u32 ovp;
> + u32 switch_freq;
> + u32 num_strings;
> + u32
Re: [PATCH] leds: fix semicolon.cocci warnings
On Tue, Mar 17, 2015 at 12:42 PM, kbuild test robot
fengguang...@intel.com wrote:
drivers/leds/leds-pm8941-wled.c:368:2-3: Unneeded semicolon
Removes unneeded semicolon.
I fixed it and pushed again.
Thanks,
-Bryan
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Courtney Cavin courtney.ca...@sonymobile.com
Signed-off-by: Fengguang Wu fengguang...@intel.com
---
leds-pm8941-wled.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/leds/leds-pm8941-wled.c
+++ b/drivers/leds/leds-pm8941-wled.c
@@ -365,7 +365,7 @@ static int pm8941_wled_configure(struct
dev_dbg(dev, '%s' = %u\n, u32_opts[i].name, c);
*u32_opts[i].val_ptr = j;
- };
+ }
for (i = 0; i ARRAY_SIZE(bool_opts); ++i) {
if (of_property_read_bool(dev-of_node, bool_opts[i].name))
--
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: [PATCH/RFC v13 02/13] dt-binding: leds: Add common LED DT bindings macros
On Thu, Mar 12, 2015 at 8:45 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: Add macros for defining boost mode and trigger type properties of flash LED devices. Applied, thanks, -Bryan Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net --- include/dt-bindings/leds/common.h | 21 + 1 file changed, 21 insertions(+) create mode 100644 include/dt-bindings/leds/common.h diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h new file mode 100644 index 000..79fcef7 --- /dev/null +++ b/include/dt-bindings/leds/common.h @@ -0,0 +1,21 @@ +/* + * This header provides macros for the common LEDs device tree bindings. + * + * Copyright (C) 2015, Samsung Electronics Co., Ltd. + * + * Author: Jacek Anaszewski j.anaszew...@samsung.com + */ + +#ifndef __DT_BINDINGS_LEDS_H__ +#define __DT_BINDINGS_LEDS_H + +/* External trigger type */ +#define LEDS_TRIG_TYPE_EDGE0 +#define LEDS_TRIG_TYPE_LEVEL 1 + +/* Boost modes */ +#define LEDS_BOOST_OFF 0 +#define LEDS_BOOST_ADAPTIVE1 +#define LEDS_BOOST_FIXED 2 + +#endif /* __DT_BINDINGS_LEDS_H */ -- 1.7.9.5 -- 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: [PATCH v4 2/2] leds: add Qualcomm PM8941 WLED driver
On Thu, Mar 12, 2015 at 8:47 AM, Bjorn Andersson
bjorn.anders...@sonymobile.com wrote:
From: Courtney Cavin courtney.ca...@sonymobile.com
This adds support for the WLED ('White' LED) block on Qualcomm's
PM8941 PMICs.
Thanks, applied!
-Bryan
Signed-off-by: Courtney Cavin courtney.ca...@sonymobile.com
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
Changes since v3:
- Use devres helper
Changes since v2:
- Fix of parser return value on error
- Dropped THIS_MODULE
Changes since v1:
- Replace enum blob with defines
- Merged wled_context and wled structs
- Some style updates
drivers/leds/Kconfig| 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-pm8941-wled.c | 435
3 files changed, 444 insertions(+)
create mode 100644 drivers/leds/leds-pm8941-wled.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 25b320d..966b960 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -526,6 +526,14 @@ config LEDS_VERSATILE
This option enabled support for the LEDs on the ARM Versatile
and RealView boards. Say Y to enabled these.
+config LEDS_PM8941_WLED
+ tristate LED support for the Qualcomm PM8941 WLED block
+ depends on LEDS_CLASS
+ select REGMAP
+ help
+ This option enables support for the 'White' LED block
+ on Qualcomm PM8941 PMICs.
+
comment LED Triggers
source drivers/leds/trigger/Kconfig
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index cbba921..bf46093 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
+obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-pm8941-wled.c b/drivers/leds/leds-pm8941-wled.c
new file mode 100644
index 000..b4f46db
--- /dev/null
+++ b/drivers/leds/leds-pm8941-wled.c
@@ -0,0 +1,435 @@
+/* Copyright (c) 2015, Sony Mobile Communications, AB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/leds.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/regmap.h
+
+#define PM8941_WLED_REG_VAL_BASE 0x40
+#define PM8941_WLED_REG_VAL_MAX 0xFFF
+
+#define PM8941_WLED_REG_MOD_EN 0x46
+#define PM8941_WLED_REG_MOD_EN_BITBIT(7)
+#define PM8941_WLED_REG_MOD_EN_MASK BIT(7)
+
+#define PM8941_WLED_REG_SYNC 0x47
+#define PM8941_WLED_REG_SYNC_MASK 0x07
+#define PM8941_WLED_REG_SYNC_LED1 BIT(0)
+#define PM8941_WLED_REG_SYNC_LED2 BIT(1)
+#define PM8941_WLED_REG_SYNC_LED3 BIT(2)
+#define PM8941_WLED_REG_SYNC_ALL 0x07
+#define PM8941_WLED_REG_SYNC_CLEAR0x00
+
+#define PM8941_WLED_REG_FREQ 0x4c
+#define PM8941_WLED_REG_FREQ_MASK 0x0f
+
+#define PM8941_WLED_REG_OVP0x4d
+#define PM8941_WLED_REG_OVP_MASK 0x03
+
+#define PM8941_WLED_REG_BOOST 0x4e
+#define PM8941_WLED_REG_BOOST_MASK0x07
+
+#define PM8941_WLED_REG_SINK 0x4f
+#define PM8941_WLED_REG_SINK_MASK 0xe0
+#define PM8941_WLED_REG_SINK_SHFT 0x05
+
+/* Per-'string' registers below */
+#define PM8941_WLED_REG_STR_OFFSET 0x10
+
+#define PM8941_WLED_REG_STR_MOD_EN_BASE0x60
+#define PM8941_WLED_REG_STR_MOD_MASK BIT(7)
+#define PM8941_WLED_REG_STR_MOD_ENBIT(7)
+
+#define PM8941_WLED_REG_STR_SCALE_BASE 0x62
+#define PM8941_WLED_REG_STR_SCALE_MASK0x1f
+
+#define PM8941_WLED_REG_STR_MOD_SRC_BASE 0x63
+#define PM8941_WLED_REG_STR_MOD_SRC_MASK 0x01
+#define PM8941_WLED_REG_STR_MOD_SRC_INT 0x00
+#define PM8941_WLED_REG_STR_MOD_SRC_EXT 0x01
+
+#define PM8941_WLED_REG_STR_CABC_BASE 0x66
+#define PM8941_WLED_REG_STR_CABC_MASK BIT(7)
+#define PM8941_WLED_REG_STR_CABC_EN BIT(7)
+
+struct pm8941_wled_config {
+ u32 i_boost_limit;
+ u32 ovp;
+ u32
Re: [PATCH/RFC v12 04/19] dt-binding: leds: Add common LED DT bindings macros
On Wed, Mar 4, 2015 at 11:56 PM, Jacek Anaszewski wrote: > On 03/04/2015 05:14 PM, Jacek Anaszewski wrote: >> >> Add macros for defining boost mode and trigger type properties >> of flash LED devices. >> >> Signed-off-by: Jacek Anaszewski >> Acked-by: Kyungmin Park >> Cc: Bryan Wu >> Cc: Richard Purdie >> --- >> include/dt-bindings/leds/max77693.h | 21 + >> 1 file changed, 21 insertions(+) >> create mode 100644 include/dt-bindings/leds/max77693.h > > > This should be obviously include/dt-bindings/leds/common.h. > It will affect also max77693-led bindings documentation patch. > I'll send the update after receiving review remarks related to the > remaining part of the mentioned patches. > OK, please update them then I will merge this patch. Thanks, -Bryan > >> >> diff --git a/include/dt-bindings/leds/max77693.h >> b/include/dt-bindings/leds/max77693.h >> new file mode 100644 >> index 000..79fcef7 >> --- /dev/null >> +++ b/include/dt-bindings/leds/max77693.h >> @@ -0,0 +1,21 @@ >> +/* >> + * This header provides macros for the common LEDs device tree bindings. >> + * >> + * Copyright (C) 2015, Samsung Electronics Co., Ltd. >> + * >> + * Author: Jacek Anaszewski >> + */ >> + >> +#ifndef __DT_BINDINGS_LEDS_H__ >> +#define __DT_BINDINGS_LEDS_H >> + >> +/* External trigger type */ >> +#define LEDS_TRIG_TYPE_EDGE0 >> +#define LEDS_TRIG_TYPE_LEVEL 1 >> + >> +/* Boost modes */ >> +#define LEDS_BOOST_OFF 0 >> +#define LEDS_BOOST_ADAPTIVE1 >> +#define LEDS_BOOST_FIXED 2 >> + >> +#endif /* __DT_BINDINGS_LEDS_H */ >> > > > -- > Best Regards, > Jacek Anaszewski -- 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: [PATCH/RFC v12 03/19] Documentation: leds: Add description of LED Flash class extension
On Wed, Mar 4, 2015 at 8:14 AM, Jacek Anaszewski wrote: > The documentation being added contains overall description of the > LED Flash Class and the related sysfs attributes. > Thanks, merged! -Bryan > Signed-off-by: Jacek Anaszewski > Acked-by: Kyungmin Park > Cc: Bryan Wu > Cc: Richard Purdie > --- > Documentation/leds/leds-class-flash.txt | 22 ++ > 1 file changed, 22 insertions(+) > create mode 100644 Documentation/leds/leds-class-flash.txt > > diff --git a/Documentation/leds/leds-class-flash.txt > b/Documentation/leds/leds-class-flash.txt > new file mode 100644 > index 000..19bb673 > --- /dev/null > +++ b/Documentation/leds/leds-class-flash.txt > @@ -0,0 +1,22 @@ > + > +Flash LED handling under Linux > +== > + > +Some LED devices provide two modes - torch and flash. In the LED subsystem > +those modes are supported by LED class (see > Documentation/leds/leds-class.txt) > +and LED Flash class respectively. The torch mode related features are enabled > +by default and the flash ones only if a driver declares it by setting > +LED_DEV_CAP_FLASH flag. > + > +In order to enable the support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol > +must be defined in the kernel config. A LED Flash class driver must be > +registered in the LED subsystem with led_classdev_flash_register function. > + > +Following sysfs attributes are exposed for controlling flash LED devices: > +(see Documentation/ABI/testing/sysfs-class-led-flash) > + - flash_brightness > + - max_flash_brightness > + - flash_timeout > + - max_flash_timeout > + - flash_strobe > + - flash_fault > -- > 1.7.9.5 > -- 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: [PATCH/RFC v12 02/19] leds: flash: document sysfs interface
On Wed, Mar 4, 2015 at 8:14 AM, Jacek Anaszewski wrote: > Add a documentation of LED Flash class specific sysfs attributes. > Thanks, merged! -Bryan > Signed-off-by: Jacek Anaszewski > Acked-by: Kyungmin Park > Cc: Bryan Wu > Cc: Richard Purdie > --- > Documentation/ABI/testing/sysfs-class-led-flash | 80 > +++ > 1 file changed, 80 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-class-led-flash > > diff --git a/Documentation/ABI/testing/sysfs-class-led-flash > b/Documentation/ABI/testing/sysfs-class-led-flash > new file mode 100644 > index 000..220a027 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-class-led-flash > @@ -0,0 +1,80 @@ > +What: /sys/class/leds//flash_brightness > +Date: March 2015 > +KernelVersion: 4.0 > +Contact: Jacek Anaszewski > +Description: read/write > + Set the brightness of this LED in the flash strobe mode, in > + microamperes. The file is created only for the flash LED > devices > + that support setting flash brightness. > + > + The value is between 0 and > + /sys/class/leds//max_flash_brightness. > + > +What: /sys/class/leds//max_flash_brightness > +Date: March 2015 > +KernelVersion: 4.0 > +Contact: Jacek Anaszewski > +Description: read only > + Maximum brightness level for this LED in the flash strobe > mode, > + in microamperes. > + > +What: /sys/class/leds//flash_timeout > +Date: March 2015 > +KernelVersion: 4.0 > +Contact: Jacek Anaszewski > +Description: read/write > + Hardware timeout for flash, in microseconds. The flash strobe > + is stopped after this period of time has passed from the start > + of the strobe. The file is created only for the flash LED > + devices that support setting flash timeout. > + > +What: /sys/class/leds//max_flash_timeout > +Date: March 2015 > +KernelVersion: 4.0 > +Contact: Jacek Anaszewski > +Description: read only > + Maximum flash timeout for this LED, in microseconds. > + > +What: /sys/class/leds//flash_strobe > +Date: March 2015 > +KernelVersion: 4.0 > +Contact: Jacek Anaszewski > +Description: read/write > + Flash strobe state. When written with 1 it triggers flash > strobe > + and when written with 0 it turns the flash off. > + > + On read 1 means that flash is currently strobing and 0 means > + that flash is off. > + > +What: /sys/class/leds//flash_fault > +Date: March 2015 > +KernelVersion: 4.0 > +Contact: Jacek Anaszewski > +Description: read only > + Space separated list of flash faults that may have occurred. > + Flash faults are re-read after strobing the flash. Possible > + flash faults: > + > + * led-over-voltage - flash controller voltage to the flash LED > + has exceeded the limit specific to the flash > controller > + * flash-timeout-exceeded - the flash strobe was still on when > + the timeout set by the user has expired; not all flash > + controllers may set this in all such conditions > + * controller-over-temperature - the flash controller has > + overheated > + * controller-short-circuit - the short circuit protection > + of the flash controller has been triggered > + * led-power-supply-over-current - current in the LED power > + supply has exceeded the limit specific to the flash > + controller > + * indicator-led-fault - the flash controller has detected > + a short or open circuit condition on the indicator LED > + * led-under-voltage - flash controller voltage to the flash > + LED has been below the minimum limit specific to > + the flash > + * controller-under-voltage - the input voltage of the flash > + controller is below the limit under which strobing the > + flash at full current will not be possible; > + the condition persists until this flag is no longer > set > + * led-over-temperature - the temperature of the LED has > exceeded > + its allowed upper limit > -- > 1.7.9.5 > -- 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: [PATCH/RFC v12 01/19] leds: flash: Remove synchronized flash strobe feature
On Wed, Mar 4, 2015 at 8:14 AM, Jacek Anaszewski
wrote:
> Synchronized flash strobe feature has been considered not fitting
> for LED subsystem sysfs interface and thus is being removed.
>
OK, I will merge this.
-Bryan
> Signed-off-by: Jacek Anaszewski
> Acked-by: Kyungmin Park
> Cc: Bryan Wu
> Cc: Richard Purdie
> ---
> drivers/leds/led-class-flash.c | 82
> ---
> include/linux/led-class-flash.h | 14 ---
> include/linux/leds.h|1 -
> 3 files changed, 97 deletions(-)
>
> diff --git a/drivers/leds/led-class-flash.c b/drivers/leds/led-class-flash.c
> index 4a19fd4..3b25734 100644
> --- a/drivers/leds/led-class-flash.c
> +++ b/drivers/leds/led-class-flash.c
> @@ -216,75 +216,6 @@ static ssize_t flash_fault_show(struct device *dev,
> }
> static DEVICE_ATTR_RO(flash_fault);
>
> -static ssize_t available_sync_leds_show(struct device *dev,
> - struct device_attribute *attr, char *buf)
> -{
> - struct led_classdev *led_cdev = dev_get_drvdata(dev);
> - struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
> - char *pbuf = buf;
> - int i, buf_len;
> -
> - buf_len = sprintf(pbuf, "[0: none] ");
> - pbuf += buf_len;
> -
> - for (i = 0; i < fled_cdev->num_sync_leds; ++i) {
> - buf_len = sprintf(pbuf, "[%d: %s] ", i + 1,
> - fled_cdev->sync_leds[i]->led_cdev.name);
> - pbuf += buf_len;
> - }
> -
> - return sprintf(buf, "%s\n", buf);
> -}
> -static DEVICE_ATTR_RO(available_sync_leds);
> -
> -static ssize_t flash_sync_strobe_store(struct device *dev,
> - struct device_attribute *attr, const char *buf, size_t size)
> -{
> - struct led_classdev *led_cdev = dev_get_drvdata(dev);
> - struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
> - unsigned long led_id;
> - ssize_t ret;
> -
> - mutex_lock(_cdev->led_access);
> -
> - if (led_sysfs_is_disabled(led_cdev)) {
> - ret = -EBUSY;
> - goto unlock;
> - }
> -
> - ret = kstrtoul(buf, 10, _id);
> - if (ret)
> - goto unlock;
> -
> - if (led_id > fled_cdev->num_sync_leds) {
> - ret = -ERANGE;
> - goto unlock;
> - }
> -
> - fled_cdev->sync_led_id = led_id;
> -
> - ret = size;
> -unlock:
> - mutex_unlock(_cdev->led_access);
> - return ret;
> -}
> -
> -static ssize_t flash_sync_strobe_show(struct device *dev,
> - struct device_attribute *attr, char *buf)
> -{
> - struct led_classdev *led_cdev = dev_get_drvdata(dev);
> - struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
> - int sled_id = fled_cdev->sync_led_id;
> - char *sync_led_name = "none";
> -
> - if (fled_cdev->sync_led_id > 0)
> - sync_led_name = (char *)
> - fled_cdev->sync_leds[sled_id - 1]->led_cdev.name;
> -
> - return sprintf(buf, "[%d: %s]\n", sled_id, sync_led_name);
> -}
> -static DEVICE_ATTR_RW(flash_sync_strobe);
> -
> static struct attribute *led_flash_strobe_attrs[] = {
> _attr_flash_strobe.attr,
> NULL,
> @@ -307,12 +238,6 @@ static struct attribute *led_flash_fault_attrs[] = {
> NULL,
> };
>
> -static struct attribute *led_flash_sync_strobe_attrs[] = {
> - _attr_available_sync_leds.attr,
> - _attr_flash_sync_strobe.attr,
> - NULL,
> -};
> -
> static const struct attribute_group led_flash_strobe_group = {
> .attrs = led_flash_strobe_attrs,
> };
> @@ -329,10 +254,6 @@ static const struct attribute_group
> led_flash_fault_group = {
> .attrs = led_flash_fault_attrs,
> };
>
> -static const struct attribute_group led_flash_sync_strobe_group = {
> - .attrs = led_flash_sync_strobe_attrs,
> -};
> -
> static void led_flash_resume(struct led_classdev *led_cdev)
> {
> struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
> @@ -361,9 +282,6 @@ static void led_flash_init_sysfs_groups(struct
> led_classdev_flash *fled_cdev)
> if (ops->fault_get)
> flash_groups[num_sysfs_groups++] = _flash_fault_group;
>
> - if (led_cdev->flags & LED_DEV_CAP_SYNC_STROBE)
> - flash_groups[num_sysfs_groups++] =
> _flash_sync_strobe_group;
> -
> led_cdev->groups = flash_groups;
> }
>
> diff --git a/include/linux/le
Re: [PATCH RFC] leds: Add status code trigger
On Thu, Feb 19, 2015 at 12:26 AM, Raphaël Teysseyre wrote: > Hi all, > > Here is a new trigger. It would allow userspace to make an LED > blink with a pattern to show a status (or error) code to a human. > This is useful for embedded systems without screen or network > access. Obviously, the LED will keep on blinking even if userspace > crashes. > Thanks for bringing up this. We did get similar idea and patches before. The problem is people are seeking more complicated applications like define a script language to do blink such as "~~~x~x~x" and there is a decoder to translate this script to program the leds. It was pointed out we need another API between kernel and user space, but I don't have such time to do that. I will add more people to review this patch and discuss this new feature. -Bryan > This trigger exports three properties to sysfs when activated: > Nblink, period, and pause. It makes the LED blink "Nblink" times > with a period of "period" milliseconds, then pause for "pause" > milliseconds, and repeat. > > It's been tested on an ARM architecture (Xilinx Zynq 7010 SoC, > which CPU is a dual ARM Cortex-A9), with a non-mainline > kernel (xilinx-v2014.4, based of a 3.17.0 kernel). > Unfortunately, I don't have other hardware to test it on. > It compiles fine in a 3.19.0-rc1 source tree. > > Additional testing and comments would be appreciated. > Do the properties names seem appropriate to you ? I hesitated > between Nblink, N_blink, nblink, and n_blink. > > Best regards, > > Signed-off-by: Raphaël Teysseyre > --- > Documentation/leds/ledtrig-statuscode.txt | 41 ++ > drivers/leds/trigger/Kconfig |9 ++ > drivers/leds/trigger/Makefile |1 + > drivers/leds/trigger/ledtrig-statuscode.c | 194 > + > 4 files changed, 245 insertions(+), 0 deletions(-) > create mode 100644 Documentation/leds/ledtrig-statuscode.txt > create mode 100644 drivers/leds/trigger/ledtrig-statuscode.c > > diff --git a/Documentation/leds/ledtrig-statuscode.txt > b/Documentation/leds/ledtrig-statuscode.txt > new file mode 100644 > index 000..f5ea3ac > --- /dev/null > +++ b/Documentation/leds/ledtrig-statuscode.txt > @@ -0,0 +1,41 @@ > +LED Status code Trigger > +=== > + > +This trigger allows userspace to make a LED blink with a pattern > +to show a status (or error) code to a human. > + > +Use case : this can be useful for an embedded system without screen > +or network access. An LED with this trigger can be used to convey > +a basic "status code" to the final user. If user space crashes, > +the LED will keep on blinking, which might help debugging the system. > + > +This trigger exports three properties : period, pause, and Nblink. > +The LED will blink "Nblink" times with a period of "period" milliseconds, > +then pause for "pause" milliseconds, and repeat. > + > +When the trigger is activated, its properties are set to default values. > + > + Nblink : Number of LED blinks per cycle. Default value : 1. > + > + period : Period length (in milliseconds). The LED will blink > + with this period, with a 50% duty cycle. > + Default value : 1000. > + > + pause : Pause duration (in milliseconds) between each cycle. > + Every Nblink blinks, the LED will stay off for this > + duration. Default value : 1000. > + > +For example, if Nblink = 3, period = 1000, and pause = 2000, > +the LED will blink with the following pattern : > + > + ...OFF | ON | OFF | ON | OFF | ON | OFF | > ON | OFF... > + < 1s> < 1s> <0.5s> <2s > > + > +To get this pattern, the user will have to do : > + echo statuscode > trigger > + echo 3 > Nblink > + echo 1000 > period > + echo 2000 > pause > + > +When ON the LED will be driven at its max_brightness property. When the > trigger > +is deactivated, the LED is returned to the OFF state. > diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig > index 49794b4..09f0df5 100644 > --- a/drivers/leds/trigger/Kconfig > +++ b/drivers/leds/trigger/Kconfig > @@ -108,4 +108,13 @@ config LEDS_TRIGGER_CAMERA > This enables direct flash/torch on/off by the driver, kernel space. > If unsure, say Y. > > +config LEDS_TRIGGER_STATUSCODE > + tristate "LED StatusCode Trigger" > + depends on LEDS_TRIGGERS > + help > + This allows LEDs blinking with a pattern. Can be useful on embedded > + systems with no screen to give out a status code to a human. > + > + If unsure, say N. > + > endif # LEDS_TRIGGERS > diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile > index 1abf48d..8c09e77 100644 > --- a/drivers/leds/trigger/Makefile > +++ b/drivers/leds/trigger/Makefile > @@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o >
Re: [PATCH v3 2/2] leds: add Qualcomm PM8941 WLED driver
On Tue, Feb 24, 2015 at 7:49 PM, Bjorn Andersson
wrote:
> From: Courtney Cavin
>
> This adds support for the WLED ('White' LED) block on Qualcomm's
> PM8941 PMICs.
>
> Signed-off-by: Courtney Cavin
> Signed-off-by: Bjorn Andersson
> ---
>
> The details surrounding the OVP spike issue that Stephen brought up during v2
> review is still unkown, the patches provided on codeaurora msm-3.10 can with
> ease be implemented as an incremental patch on top of this.
> As the severity doesn't seem to high (the fixes are not done on all active msm
> branches), I'm sending out v3 instead of waiting for a conclusion.
>
> Changes since v2:
> - Fix of parser return value on error
> - Dropped THIS_MODULE
>
> Changes since v1:
> - Replace enum blob with defines
> - Merged wled_context and wled structs
> - Some style updates
>
> drivers/leds/Kconfig| 8 +
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-pm8941-wled.c | 446
>
> 3 files changed, 455 insertions(+)
> create mode 100644 drivers/leds/leds-pm8941-wled.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index a6c3d2f..901b21a 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -516,6 +516,14 @@ config LEDS_VERSATILE
> This option enabled support for the LEDs on the ARM Versatile
> and RealView boards. Say Y to enabled these.
>
> +config LEDS_PM8941_WLED
> + tristate "LED support for the Qualcomm PM8941 WLED block"
> + depends on LEDS_CLASS
> + select REGMAP
> + help
> + This option enables support for the 'White' LED block
> + on Qualcomm PM8941 PMICs.
> +
> comment "LED Triggers"
> source "drivers/leds/trigger/Kconfig"
>
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 1c65a19..4325e49 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
> obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
> obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
> obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
> +obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
>
> # LED SPI Drivers
> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
> diff --git a/drivers/leds/leds-pm8941-wled.c b/drivers/leds/leds-pm8941-wled.c
> new file mode 100644
> index 000..9bf7358
> --- /dev/null
> +++ b/drivers/leds/leds-pm8941-wled.c
> @@ -0,0 +1,446 @@
> +/* Copyright (c) 2015, Sony Mobile Communications, AB.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define PM8941_WLED_REG_VAL_BASE 0x40
> +#define PM8941_WLED_REG_VAL_MAX 0xFFF
> +
> +#define PM8941_WLED_REG_MOD_EN 0x46
> +#define PM8941_WLED_REG_MOD_EN_BITBIT(7)
> +#define PM8941_WLED_REG_MOD_EN_MASK BIT(7)
> +
> +#define PM8941_WLED_REG_SYNC 0x47
> +#define PM8941_WLED_REG_SYNC_MASK 0x07
> +#define PM8941_WLED_REG_SYNC_LED1 BIT(0)
> +#define PM8941_WLED_REG_SYNC_LED2 BIT(1)
> +#define PM8941_WLED_REG_SYNC_LED3 BIT(2)
> +#define PM8941_WLED_REG_SYNC_ALL 0x07
> +#define PM8941_WLED_REG_SYNC_CLEAR0x00
> +
> +#define PM8941_WLED_REG_FREQ 0x4c
> +#define PM8941_WLED_REG_FREQ_MASK 0x0f
> +
> +#define PM8941_WLED_REG_OVP0x4d
> +#define PM8941_WLED_REG_OVP_MASK 0x03
> +
> +#define PM8941_WLED_REG_BOOST 0x4e
> +#define PM8941_WLED_REG_BOOST_MASK0x07
> +
> +#define PM8941_WLED_REG_SINK 0x4f
> +#define PM8941_WLED_REG_SINK_MASK 0xe0
> +#define PM8941_WLED_REG_SINK_SHFT 0x05
> +
> +/* Per-'string' registers below */
> +#define PM8941_WLED_REG_STR_OFFSET 0x10
> +
> +#define PM8941_WLED_REG_STR_MOD_EN_BASE0x60
> +#define PM8941_WLED_REG_STR_MOD_MASK BIT(7)
> +#define PM8941_WLED_REG_STR_MOD_ENBIT(7)
> +
> +#define PM8941_WLED_REG_STR_SCALE_BASE 0x62
> +#define PM8941_WLED_REG_STR_SCALE_MASK0x1f
> +
> +#define PM8941_WLED_REG_STR_MOD_SRC_BASE 0x63
> +#define PM8941_WLED_REG_STR_MOD_SRC_MASK 0x01
> +#define PM8941_WLED_REG_STR_MOD_SRC_INT 0x00
> +#define PM8941_WLED_REG_STR_MOD_SRC_EXT 0x01
> +
> +#define
Re: [PATCH v2] leds: Introduce devres helper for led_classdev_register
On Mon, Feb 23, 2015 at 4:11 PM, Bjorn Andersson
wrote:
> Suggested-by: Stephen Boyd
> Signed-off-by: Bjorn Andersson
> ---
> Changes since v1:
> - updating devres.txt
> - unregister function
I merged this patch into my tree and added _unregister function into document.
Thanks,
-Bryan
>
> Documentation/driver-model/devres.txt | 3 ++
> drivers/leds/led-class.c | 57
> +++
> include/linux/leds.h | 4 +++
> 3 files changed, 64 insertions(+)
>
> diff --git a/Documentation/driver-model/devres.txt
> b/Documentation/driver-model/devres.txt
> index b5ab416..2ae041c 100644
> --- a/Documentation/driver-model/devres.txt
> +++ b/Documentation/driver-model/devres.txt
> @@ -287,6 +287,9 @@ IRQ
>devm_request_irq()
>devm_request_threaded_irq()
>
> +LED
> + devm_led_classdev_register()
> +
> MDIO
>devm_mdiobus_alloc()
>devm_mdiobus_alloc_size()
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index dbeebac..d467969 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -285,6 +285,63 @@ void led_classdev_unregister(struct led_classdev
> *led_cdev)
> }
> EXPORT_SYMBOL_GPL(led_classdev_unregister);
>
> +static void devm_led_classdev_release(struct device *dev, void *res)
> +{
> + led_classdev_unregister(*(struct led_classdev **)res);
> +}
> +
> +/**
> + * devm_led_classdev_register - resource managed led_classdev_register()
> + * @parent: The device to register.
> + * @led_cdev: the led_classdev structure for this device.
> + */
> +int devm_led_classdev_register(struct device *parent,
> + struct led_classdev *led_cdev)
> +{
> + struct led_classdev **dr;
> + int rc;
> +
> + dr = devres_alloc(devm_led_classdev_release, sizeof(*dr), GFP_KERNEL);
> + if (!dr)
> + return -ENOMEM;
> +
> + rc = led_classdev_register(parent, led_cdev);
> + if (rc) {
> + devres_free(dr);
> + return rc;
> + }
> +
> + *dr = led_cdev;
> + devres_add(parent, dr);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(devm_led_classdev_register);
> +
> +static int devm_led_classdev_match(struct device *dev, void *res, void *data)
> +{
> + struct led_cdev **p = res;
> +
> + if (WARN_ON(!p || !*p))
> + return 0;
> +
> + return *p == data;
> +}
> +
> +/**
> + * devm_led_classdev_unregister() - resource managed
> led_classdev_unregister()
> + * @parent: The device to unregister.
> + * @led_cdev: the led_classdev structure for this device.
> + */
> +void devm_led_classdev_unregister(struct device *dev,
> + struct led_classdev *led_cdev)
> +{
> + WARN_ON(devres_release(dev,
> + devm_led_classdev_release,
> + devm_led_classdev_match, led_cdev));
> +}
> +EXPORT_SYMBOL_GPL(devm_led_classdev_unregister);
> +
> static int __init leds_init(void)
> {
> leds_class = class_create(THIS_MODULE, "leds");
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index cfceef3..6fae676 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -102,7 +102,11 @@ struct led_classdev {
>
> extern int led_classdev_register(struct device *parent,
> struct led_classdev *led_cdev);
> +extern int devm_led_classdev_register(struct device *parent,
> + struct led_classdev *led_cdev);
> extern void led_classdev_unregister(struct led_classdev *led_cdev);
> +extern void devm_led_classdev_unregister(struct device *parent,
> +struct led_classdev *led_cdev);
> extern void led_classdev_suspend(struct led_classdev *led_cdev);
> extern void led_classdev_resume(struct led_classdev *led_cdev);
>
> --
> 1.9.1
>
--
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: [PATCH v3 2/2] leds: add Qualcomm PM8941 WLED driver
On Tue, Feb 24, 2015 at 7:49 PM, Bjorn Andersson
bjorn.anders...@sonymobile.com wrote:
From: Courtney Cavin courtney.ca...@sonymobile.com
This adds support for the WLED ('White' LED) block on Qualcomm's
PM8941 PMICs.
Signed-off-by: Courtney Cavin courtney.ca...@sonymobile.com
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
The details surrounding the OVP spike issue that Stephen brought up during v2
review is still unkown, the patches provided on codeaurora msm-3.10 can with
ease be implemented as an incremental patch on top of this.
As the severity doesn't seem to high (the fixes are not done on all active msm
branches), I'm sending out v3 instead of waiting for a conclusion.
Changes since v2:
- Fix of parser return value on error
- Dropped THIS_MODULE
Changes since v1:
- Replace enum blob with defines
- Merged wled_context and wled structs
- Some style updates
drivers/leds/Kconfig| 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-pm8941-wled.c | 446
3 files changed, 455 insertions(+)
create mode 100644 drivers/leds/leds-pm8941-wled.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index a6c3d2f..901b21a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -516,6 +516,14 @@ config LEDS_VERSATILE
This option enabled support for the LEDs on the ARM Versatile
and RealView boards. Say Y to enabled these.
+config LEDS_PM8941_WLED
+ tristate LED support for the Qualcomm PM8941 WLED block
+ depends on LEDS_CLASS
+ select REGMAP
+ help
+ This option enables support for the 'White' LED block
+ on Qualcomm PM8941 PMICs.
+
comment LED Triggers
source drivers/leds/trigger/Kconfig
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1c65a19..4325e49 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
+obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-pm8941-wled.c b/drivers/leds/leds-pm8941-wled.c
new file mode 100644
index 000..9bf7358
--- /dev/null
+++ b/drivers/leds/leds-pm8941-wled.c
@@ -0,0 +1,446 @@
+/* Copyright (c) 2015, Sony Mobile Communications, AB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/leds.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/regmap.h
+
+#define PM8941_WLED_REG_VAL_BASE 0x40
+#define PM8941_WLED_REG_VAL_MAX 0xFFF
+
+#define PM8941_WLED_REG_MOD_EN 0x46
+#define PM8941_WLED_REG_MOD_EN_BITBIT(7)
+#define PM8941_WLED_REG_MOD_EN_MASK BIT(7)
+
+#define PM8941_WLED_REG_SYNC 0x47
+#define PM8941_WLED_REG_SYNC_MASK 0x07
+#define PM8941_WLED_REG_SYNC_LED1 BIT(0)
+#define PM8941_WLED_REG_SYNC_LED2 BIT(1)
+#define PM8941_WLED_REG_SYNC_LED3 BIT(2)
+#define PM8941_WLED_REG_SYNC_ALL 0x07
+#define PM8941_WLED_REG_SYNC_CLEAR0x00
+
+#define PM8941_WLED_REG_FREQ 0x4c
+#define PM8941_WLED_REG_FREQ_MASK 0x0f
+
+#define PM8941_WLED_REG_OVP0x4d
+#define PM8941_WLED_REG_OVP_MASK 0x03
+
+#define PM8941_WLED_REG_BOOST 0x4e
+#define PM8941_WLED_REG_BOOST_MASK0x07
+
+#define PM8941_WLED_REG_SINK 0x4f
+#define PM8941_WLED_REG_SINK_MASK 0xe0
+#define PM8941_WLED_REG_SINK_SHFT 0x05
+
+/* Per-'string' registers below */
+#define PM8941_WLED_REG_STR_OFFSET 0x10
+
+#define PM8941_WLED_REG_STR_MOD_EN_BASE0x60
+#define PM8941_WLED_REG_STR_MOD_MASK BIT(7)
+#define PM8941_WLED_REG_STR_MOD_ENBIT(7)
+
+#define PM8941_WLED_REG_STR_SCALE_BASE 0x62
+#define PM8941_WLED_REG_STR_SCALE_MASK0x1f
+
+#define PM8941_WLED_REG_STR_MOD_SRC_BASE 0x63
+#define PM8941_WLED_REG_STR_MOD_SRC_MASK 0x01
+#define PM8941_WLED_REG_STR_MOD_SRC_INT 0x00
+#define
Re: [PATCH v2] leds: Introduce devres helper for led_classdev_register
On Mon, Feb 23, 2015 at 4:11 PM, Bjorn Andersson
bjorn.anders...@sonymobile.com wrote:
Suggested-by: Stephen Boyd sb...@codeaurora.org
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
Changes since v1:
- updating devres.txt
- unregister function
I merged this patch into my tree and added _unregister function into document.
Thanks,
-Bryan
Documentation/driver-model/devres.txt | 3 ++
drivers/leds/led-class.c | 57
+++
include/linux/leds.h | 4 +++
3 files changed, 64 insertions(+)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index b5ab416..2ae041c 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -287,6 +287,9 @@ IRQ
devm_request_irq()
devm_request_threaded_irq()
+LED
+ devm_led_classdev_register()
+
MDIO
devm_mdiobus_alloc()
devm_mdiobus_alloc_size()
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index dbeebac..d467969 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -285,6 +285,63 @@ void led_classdev_unregister(struct led_classdev
*led_cdev)
}
EXPORT_SYMBOL_GPL(led_classdev_unregister);
+static void devm_led_classdev_release(struct device *dev, void *res)
+{
+ led_classdev_unregister(*(struct led_classdev **)res);
+}
+
+/**
+ * devm_led_classdev_register - resource managed led_classdev_register()
+ * @parent: The device to register.
+ * @led_cdev: the led_classdev structure for this device.
+ */
+int devm_led_classdev_register(struct device *parent,
+ struct led_classdev *led_cdev)
+{
+ struct led_classdev **dr;
+ int rc;
+
+ dr = devres_alloc(devm_led_classdev_release, sizeof(*dr), GFP_KERNEL);
+ if (!dr)
+ return -ENOMEM;
+
+ rc = led_classdev_register(parent, led_cdev);
+ if (rc) {
+ devres_free(dr);
+ return rc;
+ }
+
+ *dr = led_cdev;
+ devres_add(parent, dr);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(devm_led_classdev_register);
+
+static int devm_led_classdev_match(struct device *dev, void *res, void *data)
+{
+ struct led_cdev **p = res;
+
+ if (WARN_ON(!p || !*p))
+ return 0;
+
+ return *p == data;
+}
+
+/**
+ * devm_led_classdev_unregister() - resource managed
led_classdev_unregister()
+ * @parent: The device to unregister.
+ * @led_cdev: the led_classdev structure for this device.
+ */
+void devm_led_classdev_unregister(struct device *dev,
+ struct led_classdev *led_cdev)
+{
+ WARN_ON(devres_release(dev,
+ devm_led_classdev_release,
+ devm_led_classdev_match, led_cdev));
+}
+EXPORT_SYMBOL_GPL(devm_led_classdev_unregister);
+
static int __init leds_init(void)
{
leds_class = class_create(THIS_MODULE, leds);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index cfceef3..6fae676 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -102,7 +102,11 @@ struct led_classdev {
extern int led_classdev_register(struct device *parent,
struct led_classdev *led_cdev);
+extern int devm_led_classdev_register(struct device *parent,
+ struct led_classdev *led_cdev);
extern void led_classdev_unregister(struct led_classdev *led_cdev);
+extern void devm_led_classdev_unregister(struct device *parent,
+struct led_classdev *led_cdev);
extern void led_classdev_suspend(struct led_classdev *led_cdev);
extern void led_classdev_resume(struct led_classdev *led_cdev);
--
1.9.1
--
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: [PATCH RFC] leds: Add status code trigger
On Thu, Feb 19, 2015 at 12:26 AM, Raphaël Teysseyre rteysse...@gmail.com wrote: Hi all, Here is a new trigger. It would allow userspace to make an LED blink with a pattern to show a status (or error) code to a human. This is useful for embedded systems without screen or network access. Obviously, the LED will keep on blinking even if userspace crashes. Thanks for bringing up this. We did get similar idea and patches before. The problem is people are seeking more complicated applications like define a script language to do blink such as ~~~x~x~x and there is a decoder to translate this script to program the leds. It was pointed out we need another API between kernel and user space, but I don't have such time to do that. I will add more people to review this patch and discuss this new feature. -Bryan This trigger exports three properties to sysfs when activated: Nblink, period, and pause. It makes the LED blink Nblink times with a period of period milliseconds, then pause for pause milliseconds, and repeat. It's been tested on an ARM architecture (Xilinx Zynq 7010 SoC, which CPU is a dual ARM Cortex-A9), with a non-mainline kernel (xilinx-v2014.4, based of a 3.17.0 kernel). Unfortunately, I don't have other hardware to test it on. It compiles fine in a 3.19.0-rc1 source tree. Additional testing and comments would be appreciated. Do the properties names seem appropriate to you ? I hesitated between Nblink, N_blink, nblink, and n_blink. Best regards, Signed-off-by: Raphaël Teysseyre rteysse...@gmail.com --- Documentation/leds/ledtrig-statuscode.txt | 41 ++ drivers/leds/trigger/Kconfig |9 ++ drivers/leds/trigger/Makefile |1 + drivers/leds/trigger/ledtrig-statuscode.c | 194 + 4 files changed, 245 insertions(+), 0 deletions(-) create mode 100644 Documentation/leds/ledtrig-statuscode.txt create mode 100644 drivers/leds/trigger/ledtrig-statuscode.c diff --git a/Documentation/leds/ledtrig-statuscode.txt b/Documentation/leds/ledtrig-statuscode.txt new file mode 100644 index 000..f5ea3ac --- /dev/null +++ b/Documentation/leds/ledtrig-statuscode.txt @@ -0,0 +1,41 @@ +LED Status code Trigger +=== + +This trigger allows userspace to make a LED blink with a pattern +to show a status (or error) code to a human. + +Use case : this can be useful for an embedded system without screen +or network access. An LED with this trigger can be used to convey +a basic status code to the final user. If user space crashes, +the LED will keep on blinking, which might help debugging the system. + +This trigger exports three properties : period, pause, and Nblink. +The LED will blink Nblink times with a period of period milliseconds, +then pause for pause milliseconds, and repeat. + +When the trigger is activated, its properties are set to default values. + + Nblink : Number of LED blinks per cycle. Default value : 1. + + period : Period length (in milliseconds). The LED will blink + with this period, with a 50% duty cycle. + Default value : 1000. + + pause : Pause duration (in milliseconds) between each cycle. + Every Nblink blinks, the LED will stay off for this + duration. Default value : 1000. + +For example, if Nblink = 3, period = 1000, and pause = 2000, +the LED will blink with the following pattern : + + ...OFF | ON | OFF | ON | OFF | ON | OFF | ON | OFF... + 1s 1s 0.5s 2s + +To get this pattern, the user will have to do : + echo statuscode trigger + echo 3 Nblink + echo 1000 period + echo 2000 pause + +When ON the LED will be driven at its max_brightness property. When the trigger +is deactivated, the LED is returned to the OFF state. diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig index 49794b4..09f0df5 100644 --- a/drivers/leds/trigger/Kconfig +++ b/drivers/leds/trigger/Kconfig @@ -108,4 +108,13 @@ config LEDS_TRIGGER_CAMERA This enables direct flash/torch on/off by the driver, kernel space. If unsure, say Y. +config LEDS_TRIGGER_STATUSCODE + tristate LED StatusCode Trigger + depends on LEDS_TRIGGERS + help + This allows LEDs blinking with a pattern. Can be useful on embedded + systems with no screen to give out a status code to a human. + + If unsure, say N. + endif # LEDS_TRIGGERS diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile index 1abf48d..8c09e77 100644 --- a/drivers/leds/trigger/Makefile +++ b/drivers/leds/trigger/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) +=
Re: [PATCH/RFC v12 03/19] Documentation: leds: Add description of LED Flash class extension
On Wed, Mar 4, 2015 at 8:14 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: The documentation being added contains overall description of the LED Flash Class and the related sysfs attributes. Thanks, merged! -Bryan Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net --- Documentation/leds/leds-class-flash.txt | 22 ++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/leds/leds-class-flash.txt diff --git a/Documentation/leds/leds-class-flash.txt b/Documentation/leds/leds-class-flash.txt new file mode 100644 index 000..19bb673 --- /dev/null +++ b/Documentation/leds/leds-class-flash.txt @@ -0,0 +1,22 @@ + +Flash LED handling under Linux +== + +Some LED devices provide two modes - torch and flash. In the LED subsystem +those modes are supported by LED class (see Documentation/leds/leds-class.txt) +and LED Flash class respectively. The torch mode related features are enabled +by default and the flash ones only if a driver declares it by setting +LED_DEV_CAP_FLASH flag. + +In order to enable the support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol +must be defined in the kernel config. A LED Flash class driver must be +registered in the LED subsystem with led_classdev_flash_register function. + +Following sysfs attributes are exposed for controlling flash LED devices: +(see Documentation/ABI/testing/sysfs-class-led-flash) + - flash_brightness + - max_flash_brightness + - flash_timeout + - max_flash_timeout + - flash_strobe + - flash_fault -- 1.7.9.5 -- 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: [PATCH/RFC v12 04/19] dt-binding: leds: Add common LED DT bindings macros
On Wed, Mar 4, 2015 at 11:56 PM, Jacek Anaszewski j.anaszew...@samsung.com wrote: On 03/04/2015 05:14 PM, Jacek Anaszewski wrote: Add macros for defining boost mode and trigger type properties of flash LED devices. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net --- include/dt-bindings/leds/max77693.h | 21 + 1 file changed, 21 insertions(+) create mode 100644 include/dt-bindings/leds/max77693.h This should be obviously include/dt-bindings/leds/common.h. It will affect also max77693-led bindings documentation patch. I'll send the update after receiving review remarks related to the remaining part of the mentioned patches. OK, please update them then I will merge this patch. Thanks, -Bryan diff --git a/include/dt-bindings/leds/max77693.h b/include/dt-bindings/leds/max77693.h new file mode 100644 index 000..79fcef7 --- /dev/null +++ b/include/dt-bindings/leds/max77693.h @@ -0,0 +1,21 @@ +/* + * This header provides macros for the common LEDs device tree bindings. + * + * Copyright (C) 2015, Samsung Electronics Co., Ltd. + * + * Author: Jacek Anaszewski j.anaszew...@samsung.com + */ + +#ifndef __DT_BINDINGS_LEDS_H__ +#define __DT_BINDINGS_LEDS_H + +/* External trigger type */ +#define LEDS_TRIG_TYPE_EDGE0 +#define LEDS_TRIG_TYPE_LEVEL 1 + +/* Boost modes */ +#define LEDS_BOOST_OFF 0 +#define LEDS_BOOST_ADAPTIVE1 +#define LEDS_BOOST_FIXED 2 + +#endif /* __DT_BINDINGS_LEDS_H */ -- Best Regards, Jacek Anaszewski -- 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: [PATCH/RFC v12 02/19] leds: flash: document sysfs interface
On Wed, Mar 4, 2015 at 8:14 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: Add a documentation of LED Flash class specific sysfs attributes. Thanks, merged! -Bryan Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net --- Documentation/ABI/testing/sysfs-class-led-flash | 80 +++ 1 file changed, 80 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-led-flash diff --git a/Documentation/ABI/testing/sysfs-class-led-flash b/Documentation/ABI/testing/sysfs-class-led-flash new file mode 100644 index 000..220a027 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-flash @@ -0,0 +1,80 @@ +What: /sys/class/leds/led/flash_brightness +Date: March 2015 +KernelVersion: 4.0 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Set the brightness of this LED in the flash strobe mode, in + microamperes. The file is created only for the flash LED devices + that support setting flash brightness. + + The value is between 0 and + /sys/class/leds/led/max_flash_brightness. + +What: /sys/class/leds/led/max_flash_brightness +Date: March 2015 +KernelVersion: 4.0 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read only + Maximum brightness level for this LED in the flash strobe mode, + in microamperes. + +What: /sys/class/leds/led/flash_timeout +Date: March 2015 +KernelVersion: 4.0 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Hardware timeout for flash, in microseconds. The flash strobe + is stopped after this period of time has passed from the start + of the strobe. The file is created only for the flash LED + devices that support setting flash timeout. + +What: /sys/class/leds/led/max_flash_timeout +Date: March 2015 +KernelVersion: 4.0 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read only + Maximum flash timeout for this LED, in microseconds. + +What: /sys/class/leds/led/flash_strobe +Date: March 2015 +KernelVersion: 4.0 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Flash strobe state. When written with 1 it triggers flash strobe + and when written with 0 it turns the flash off. + + On read 1 means that flash is currently strobing and 0 means + that flash is off. + +What: /sys/class/leds/led/flash_fault +Date: March 2015 +KernelVersion: 4.0 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read only + Space separated list of flash faults that may have occurred. + Flash faults are re-read after strobing the flash. Possible + flash faults: + + * led-over-voltage - flash controller voltage to the flash LED + has exceeded the limit specific to the flash controller + * flash-timeout-exceeded - the flash strobe was still on when + the timeout set by the user has expired; not all flash + controllers may set this in all such conditions + * controller-over-temperature - the flash controller has + overheated + * controller-short-circuit - the short circuit protection + of the flash controller has been triggered + * led-power-supply-over-current - current in the LED power + supply has exceeded the limit specific to the flash + controller + * indicator-led-fault - the flash controller has detected + a short or open circuit condition on the indicator LED + * led-under-voltage - flash controller voltage to the flash + LED has been below the minimum limit specific to + the flash + * controller-under-voltage - the input voltage of the flash + controller is below the limit under which strobing the + flash at full current will not be possible; + the condition persists until this flag is no longer set + * led-over-temperature - the temperature of the LED has exceeded + its allowed upper limit -- 1.7.9.5 -- 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
Re: [PATCH/RFC v12 01/19] leds: flash: Remove synchronized flash strobe feature
On Wed, Mar 4, 2015 at 8:14 AM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
Synchronized flash strobe feature has been considered not fitting
for LED subsystem sysfs interface and thus is being removed.
OK, I will merge this.
-Bryan
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/leds/led-class-flash.c | 82
---
include/linux/led-class-flash.h | 14 ---
include/linux/leds.h|1 -
3 files changed, 97 deletions(-)
diff --git a/drivers/leds/led-class-flash.c b/drivers/leds/led-class-flash.c
index 4a19fd4..3b25734 100644
--- a/drivers/leds/led-class-flash.c
+++ b/drivers/leds/led-class-flash.c
@@ -216,75 +216,6 @@ static ssize_t flash_fault_show(struct device *dev,
}
static DEVICE_ATTR_RO(flash_fault);
-static ssize_t available_sync_leds_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct led_classdev *led_cdev = dev_get_drvdata(dev);
- struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
- char *pbuf = buf;
- int i, buf_len;
-
- buf_len = sprintf(pbuf, [0: none] );
- pbuf += buf_len;
-
- for (i = 0; i fled_cdev-num_sync_leds; ++i) {
- buf_len = sprintf(pbuf, [%d: %s] , i + 1,
- fled_cdev-sync_leds[i]-led_cdev.name);
- pbuf += buf_len;
- }
-
- return sprintf(buf, %s\n, buf);
-}
-static DEVICE_ATTR_RO(available_sync_leds);
-
-static ssize_t flash_sync_strobe_store(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t size)
-{
- struct led_classdev *led_cdev = dev_get_drvdata(dev);
- struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
- unsigned long led_id;
- ssize_t ret;
-
- mutex_lock(led_cdev-led_access);
-
- if (led_sysfs_is_disabled(led_cdev)) {
- ret = -EBUSY;
- goto unlock;
- }
-
- ret = kstrtoul(buf, 10, led_id);
- if (ret)
- goto unlock;
-
- if (led_id fled_cdev-num_sync_leds) {
- ret = -ERANGE;
- goto unlock;
- }
-
- fled_cdev-sync_led_id = led_id;
-
- ret = size;
-unlock:
- mutex_unlock(led_cdev-led_access);
- return ret;
-}
-
-static ssize_t flash_sync_strobe_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct led_classdev *led_cdev = dev_get_drvdata(dev);
- struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
- int sled_id = fled_cdev-sync_led_id;
- char *sync_led_name = none;
-
- if (fled_cdev-sync_led_id 0)
- sync_led_name = (char *)
- fled_cdev-sync_leds[sled_id - 1]-led_cdev.name;
-
- return sprintf(buf, [%d: %s]\n, sled_id, sync_led_name);
-}
-static DEVICE_ATTR_RW(flash_sync_strobe);
-
static struct attribute *led_flash_strobe_attrs[] = {
dev_attr_flash_strobe.attr,
NULL,
@@ -307,12 +238,6 @@ static struct attribute *led_flash_fault_attrs[] = {
NULL,
};
-static struct attribute *led_flash_sync_strobe_attrs[] = {
- dev_attr_available_sync_leds.attr,
- dev_attr_flash_sync_strobe.attr,
- NULL,
-};
-
static const struct attribute_group led_flash_strobe_group = {
.attrs = led_flash_strobe_attrs,
};
@@ -329,10 +254,6 @@ static const struct attribute_group
led_flash_fault_group = {
.attrs = led_flash_fault_attrs,
};
-static const struct attribute_group led_flash_sync_strobe_group = {
- .attrs = led_flash_sync_strobe_attrs,
-};
-
static void led_flash_resume(struct led_classdev *led_cdev)
{
struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
@@ -361,9 +282,6 @@ static void led_flash_init_sysfs_groups(struct
led_classdev_flash *fled_cdev)
if (ops-fault_get)
flash_groups[num_sysfs_groups++] = led_flash_fault_group;
- if (led_cdev-flags LED_DEV_CAP_SYNC_STROBE)
- flash_groups[num_sysfs_groups++] =
led_flash_sync_strobe_group;
-
led_cdev-groups = flash_groups;
}
diff --git a/include/linux/led-class-flash.h b/include/linux/led-class-flash.h
index 3b5b964..21ec91e 100644
--- a/include/linux/led-class-flash.h
+++ b/include/linux/led-class-flash.h
@@ -81,20 +81,6 @@ struct led_classdev_flash {
/* LED Flash class sysfs groups */
const struct attribute_group
*sysfs_groups[LED_FLASH_MAX_SYSFS_GROUPS];
-
- /* LEDs available for flash strobe synchronization */
- struct led_classdev_flash **sync_leds;
-
- /* Number of LEDs available for flash strobe synchronization
Re: [PATCH 0/3] Add ktd2692 Flash LED driver
On Mon, Mar 2, 2015 at 1:15 AM, Sakari Ailus wrote: > H Ingi, > > On Mon, Mar 02, 2015 at 04:14:39PM +0900, Ingi Kim wrote: >> Hi Jacek >> >> On 2015년 02월 27일 17:42, Jacek Anaszewski wrote: >> > Hi Ingi, >> > >> > On 02/27/2015 02:01 AM, Ingi Kim wrote: >> >> This patch supports KTD2692 flash LED driver >> >> >> >> Ingi Kim (3): >> >>of: Add vendor prefix for Kinetic technologies >> >>leds: ktd2692: add device tree bindings for ktd2692 >> >>leds: Add ktd2692 flash LED driver >> >> >> >> .../devicetree/bindings/leds/leds-ktd2692.txt | 19 ++ >> >> .../devicetree/bindings/vendor-prefixes.txt|1 + >> >> drivers/leds/Kconfig |8 + >> >> drivers/leds/Makefile |1 + >> >> drivers/leds/leds-ktd2692.c| 245 >> >> >> >> 5 files changed, 274 insertions(+) >> >> create mode 100644 >> >> Documentation/devicetree/bindings/leds/leds-ktd2692.txt >> >> create mode 100644 drivers/leds/leds-ktd2692.c >> >> >> > >> > In your device tree binding documentation there is torch-gpio mentioned, >> > but you seem not to use it in the driver. >> > >> > We have already LED Flash class (/drivers/leds/led-class-flash.c) for >> > this type of devices, which handles both torch and flash modes >> > (flash_strobe sysfs attribute is provided for strobing the flash). >> > >> > The reference drivers using LED Flash class are still pending [1], but I >> > think that at least leds-aat1290 driver is almost ready for merging. >> > It controls very similar device to yours. >> > >> > Another advantage of using LED Flash class is that it has been designed >> > to be compatible with Video for Linux 2 subsystem, which will allow for >> > registering LED Flash class devices as a V4L2 sub-devices. >> > >> > Adding Sakari. >> > >> >> Ok, I'll check LED Flash class, and add torch-gpio > > Many LED flash chips include a hardware pin for torch control but few really > need it. If you don't, i.e. you can implement the torch using the control bus > instead, I think I'd probably drop it from the chip's DT bindings. > Ingi, please follow Jacek's advice to use LED Flash class interface. I'm reviewing those leds flash drivers and probably merge them soon. Jacek and Sakari thanks for the review. Sakari, so what's the control bus your mentioned here? Thanks, -Bryan -- 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: [PATCH v2 3/4] leds: Let the binding document example for leds-gpio follow the gpio bindings
On Mon, Mar 2, 2015 at 3:24 AM, Linus Walleij wrote: > On Wed, Jan 21, 2015 at 10:33 PM, Olliver Schinagl > wrote: > >> From: Olliver Schinagl >> >> In the gpio bindings documents it is requested to use the marco's in >> include/dt-bindings/gpio/gpio.h whenever possible. The gpios in the led >> drivers don't seem to form an exception, so update the example in the >> document bindings. >> >> Signed-off-by: Olliver Schinagl >> Acked-by: Rob Herring >> Acked-by: Linus Walleij > > Bryan: please merge this patch to the LED git tree. > Merged, thanks -Bryan -- 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: [PATCH v2 3/4] leds: Let the binding document example for leds-gpio follow the gpio bindings
On Mon, Mar 2, 2015 at 3:24 AM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Jan 21, 2015 at 10:33 PM, Olliver Schinagl o.schin...@ultimaker.com wrote: From: Olliver Schinagl oli...@schinagl.nl In the gpio bindings documents it is requested to use the marco's in include/dt-bindings/gpio/gpio.h whenever possible. The gpios in the led drivers don't seem to form an exception, so update the example in the document bindings. Signed-off-by: Olliver Schinagl oli...@schinagl.nl Acked-by: Rob Herring r...@kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Bryan: please merge this patch to the LED git tree. Merged, thanks -Bryan -- 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: [PATCH 0/3] Add ktd2692 Flash LED driver
On Mon, Mar 2, 2015 at 1:15 AM, Sakari Ailus sakari.ai...@iki.fi wrote: H Ingi, On Mon, Mar 02, 2015 at 04:14:39PM +0900, Ingi Kim wrote: Hi Jacek On 2015년 02월 27일 17:42, Jacek Anaszewski wrote: Hi Ingi, On 02/27/2015 02:01 AM, Ingi Kim wrote: This patch supports KTD2692 flash LED driver Ingi Kim (3): of: Add vendor prefix for Kinetic technologies leds: ktd2692: add device tree bindings for ktd2692 leds: Add ktd2692 flash LED driver .../devicetree/bindings/leds/leds-ktd2692.txt | 19 ++ .../devicetree/bindings/vendor-prefixes.txt|1 + drivers/leds/Kconfig |8 + drivers/leds/Makefile |1 + drivers/leds/leds-ktd2692.c| 245 5 files changed, 274 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt create mode 100644 drivers/leds/leds-ktd2692.c In your device tree binding documentation there is torch-gpio mentioned, but you seem not to use it in the driver. We have already LED Flash class (/drivers/leds/led-class-flash.c) for this type of devices, which handles both torch and flash modes (flash_strobe sysfs attribute is provided for strobing the flash). The reference drivers using LED Flash class are still pending [1], but I think that at least leds-aat1290 driver is almost ready for merging. It controls very similar device to yours. Another advantage of using LED Flash class is that it has been designed to be compatible with Video for Linux 2 subsystem, which will allow for registering LED Flash class devices as a V4L2 sub-devices. Adding Sakari. Ok, I'll check LED Flash class, and add torch-gpio Many LED flash chips include a hardware pin for torch control but few really need it. If you don't, i.e. you can implement the torch using the control bus instead, I think I'd probably drop it from the chip's DT bindings. Ingi, please follow Jacek's advice to use LED Flash class interface. I'm reviewing those leds flash drivers and probably merge them soon. Jacek and Sakari thanks for the review. Sakari, so what's the control bus your mentioned here? Thanks, -Bryan -- 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: [PATCH] led/led-class: Handle LEDs with the same name
On Tue, Feb 17, 2015 at 10:55 PM, Ricardo Ribalda Delgado wrote: > Hi > > On Wed, Feb 18, 2015 at 2:36 AM, Bryan Wu wrote: > >>> >> >> I got it. In this case we need to give the leds device a unique name. >> Go back to your patch, you're adding 0, 1 at the end of the name of >> leds. It's better like GPIO I think you can pick up value of >> leds device node and put it in front of the name of leds. like >> /sys/class/leds/3004.red and /sys/class/leds/4004.red. > > Hmmm That will not solve the issue for every device. > > If I had a mmio, the gpio would be located at > > /sys/devices/pci:00/:00:05.0/:01:00.0/3004.gpio > and > /sys/devices/pci:00/:00:06.0/:01:00.0/3004.gpio > > Also it could be the case where the gpio is not memory mapped, then it > would be something like: > > /sys/devices/pci:00/:00:05.0/:01:00.0/gpio > and > /sys/devices/pci:00/:00:06.0/:01:00.0/gpio > > And at any case we should respect the old api, we can only rename the > second device, not the first one. > > What is your concern about the initial proposal? What about NAME_dup0 > instead of NAME_0? > Actually I'd like to see some meaningful unique name for each device when we create. But looks like there is no such way to find some unique properties from device tree node. > We could throw a dev_info(), so the system developer will have a > chance to fix it (if he can) and the user to ignore it safely. > Yes, this is what I want. It's good to let the user know there are multiple leds share the same name in DT. Sometime they made some mistake in the DTS file. Please update the patch, we can start to discuss the implementation, then. Actually I think we don't need the temp_name and just use the "name". And one more thing is device_find_child() will find child of the parent. But in your 2 PCI card case, these 2 parents are different then device_find_child() will return false twice even if your 2 red leds have the same name. I think the better solution is search the name in registered leds device, if found name is the same, then add a number or something. And move out this name processing code to a separated function. Thanks, -Bryan -- 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: [PATCH] led/led-class: Handle LEDs with the same name
On Tue, Feb 17, 2015 at 10:55 PM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: Hi On Wed, Feb 18, 2015 at 2:36 AM, Bryan Wu coolo...@gmail.com wrote: I got it. In this case we need to give the leds device a unique name. Go back to your patch, you're adding 0, 1 at the end of the name of leds. It's better like GPIO I think you can pick up reg value of leds device node and put it in front of the name of leds. like /sys/class/leds/3004.red and /sys/class/leds/4004.red. Hmmm That will not solve the issue for every device. If I had a mmio, the gpio would be located at /sys/devices/pci:00/:00:05.0/:01:00.0/3004.gpio and /sys/devices/pci:00/:00:06.0/:01:00.0/3004.gpio Also it could be the case where the gpio is not memory mapped, then it would be something like: /sys/devices/pci:00/:00:05.0/:01:00.0/gpio and /sys/devices/pci:00/:00:06.0/:01:00.0/gpio And at any case we should respect the old api, we can only rename the second device, not the first one. What is your concern about the initial proposal? What about NAME_dup0 instead of NAME_0? Actually I'd like to see some meaningful unique name for each device when we create. But looks like there is no such way to find some unique properties from device tree node. We could throw a dev_info(), so the system developer will have a chance to fix it (if he can) and the user to ignore it safely. Yes, this is what I want. It's good to let the user know there are multiple leds share the same name in DT. Sometime they made some mistake in the DTS file. Please update the patch, we can start to discuss the implementation, then. Actually I think we don't need the temp_name and just use the name. And one more thing is device_find_child() will find child of the parent. But in your 2 PCI card case, these 2 parents are different then device_find_child() will return false twice even if your 2 red leds have the same name. I think the better solution is search the name in registered leds device, if found name is the same, then add a number or something. And move out this name processing code to a separated function. Thanks, -Bryan -- 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: [PATCH] led/led-class: Handle LEDs with the same name
> Thanks!
On Tue, Feb 17, 2015 at 5:11 PM, Ricardo Ribalda Delgado
wrote:
> Hello Bryan
>
> On Wed, Feb 18, 2015 at 1:52 AM, Bryan Wu wrote:
>>>
>>> Lets say that we have a type of add-on card. Described by this DT
>>> overlay (card.dtb):
>>>
>>
>> I think who write this card.dtb should understand this issue. And
>> choose the right name.
>
> card.dtb just describe the hardware in the card, and it is not be
> aware of the rest of the system.
>
> I dont think it is practical to have card_HOST0_PCI1.dtb,
> card_HOST0_PCI2.dtb to HOST0_PCI16.dtb and then HOST1_, HOST2
>
>>> gpio_0: gpio_0 {
>>What happen if you just use name 'gpio: gpio {' here.? Any conflicts
>>or kernel oops?
>
> No problem here, one will create the device
>
> /sys/devices/pci:00/:00:05.0/:01:00.0/3004.gpio
>
> and the other:
>
> /sys/devices/pci:00/:00:06.0/:01:00.0/4004.gpio
>
> Name is created with hierarnchy
>
> /sys/class/gpio/ will also work fine, because the gpiochip id is
> created dynamically
>
> On the other hand all the leds are under,
>
> /sys/class/leds/NAME
>
> Do not have any dynamic naming or hierarchical name.
>
I got it. In this case we need to give the leds device a unique name.
Go back to your patch, you're adding 0, 1 at the end of the name of
leds. It's better like GPIO I think you can pick up value of
leds device node and put it in front of the name of leds. like
/sys/class/leds/3004.red and /sys/class/leds/4004.red.
Thanks,
-Bryan
--
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: [PATCH] led/led-class: Handle LEDs with the same name
On Tue, Feb 17, 2015 at 4:32 PM, Ricardo Ribalda Delgado
wrote:
> Hello Bryan
>
> On Wed, Feb 18, 2015 at 12:59 AM, Bryan Wu wrote:
>>
>> DT just describe the hardware, so if it's a different hardware, they
>> should have different name.
>> red0 for GPIO 0, red1 for GPIO 1 or choose other good name instead of 0 and
>> 1.
>
> I think I have not managed to explain myself properly.
>
> We have a host computer. with 2 pcie slots. The host is described with
> a DT that looks like:
>
> {
>
> pci0{
> reg = < 0x2000 0x1000 >
> }
>
> pci1{
> reg = < 0x3000 0x1000 >
> }
> }
>
> The user can connect anything to the pci slots. (pci0 and pci1)
>
>
> Lets say that we have a type of add-on card. Described by this DT
> overlay (card.dtb):
>
I think who write this card.dtb should understand this issue. And
choose the right name.
> {
>
> gpio_0: gpio_0 {
What happen if you just use name 'gpio: gpio {' here.? Any conflicts
or kernel oops?
> #gpio-cells = <2>;
> compatible = "xlnx,xps-gpio-1.00.a";
> reg = < 0x3004 01 >;
> };
>
>
> /*Leds*/
> leds {
> reg = < 0x3004 01 >;
> compatible = "gpio-leds";
> red {
> gpios = <_0 0 0>;
> linux,default-trigger = "drop-qt5023_video0";
> };
> }
>
> }
>
> The user connects two of those cards to the system (at locations pci0 and
> pci1).
>
> Then we have TWO gpios chip. Each of them have a led named red. When
> the second gpio-led is probed we have an error. Everything else
> (address offset, phandle, device renaming) is handled properly already
> by the kernel.
>
> On this system I cannot control card.dtb, or which type of cards will
> the user connect to the system. The DT is generated in run-time based
> on the hardware connected to the pci slots.
>
So you're supposed to get 2 card.dtb files for 2 PCI cards, right?
They should be different and you need to choose different name for the
hardware.
> I humbly believe that the issue here is that the subsystem does not
> protect ourselves against name collisions, because a month ago a
> device tree was considered immutable and in full control of the system
> designer, unfortunately this is not the case anymore.
>
>From device tree point of view, I believe different device should got
different name although they can match to same compatible string. Let
me invite DT folks for help.
Thanks,
-Bryan
--
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: [PATCH] led/led-class: Handle LEDs with the same name
On Tue, Feb 17, 2015 at 3:47 PM, Ricardo Ribalda Delgado wrote: > Hi > > On Wed, Feb 18, 2015 at 12:35 AM, Bryan Wu wrote: > >> So why not use name "red0" and name another one "red1"? since you have >> multiple different red leds here any way. > > I cannot control how many cameras the user will decide to attach to > the system, and if two similar cameras are attached to pciA and pciB, > they would try to load the same dt. > DT just describe the hardware, so if it's a different hardware, they should have different name. red0 for GPIO 0, red1 for GPIO 1 or choose other good name instead of 0 and 1. If this is true, you can just name one LED like gpio-led and let the kernel to add number after that name. I don't think this is a good idea to name the hardware. And These aren't like other devices which will create device node like /dev/video0 /dev/video1. This is from device tree to describe the hardware. Thanks, -Bryan -- 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: [PATCH] led/led-class: Handle LEDs with the same name
On Tue, Feb 17, 2015 at 2:54 PM, Ricardo Ribalda Delgado
wrote:
> Hello Bryan
>
> On Tue, Feb 17, 2015 at 11:34 PM, Bryan Wu wrote:
>>
>> Can you show me your device tree code for overlaying describing a camera?
>>
>
> The camera is composed by fpga modules. The fpga is attached via pcie
> to the host.
>
> The whole dt would be too long.
>
> Here you can see the relevant parts
>
> {
>
>
> packer_0: packer_0{
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "qtec,axi_matrix_packer-1.00.a";
> reg = < 0x3006 0x1 >;
> qtec,serial_number = "Invalid Head Serial Number";
> qtec,bitstream_version = < 0 >;
> qtec,head_i2c_address = < 0 >;
> qtec,cdma = <_0>;
> qtec,desc_mem= <_desc_mem>;
> qtec,pcie_bridge= <_bridge_0>;
> qtec,aperture-addr= < 0 4 >;
> qtec,circular_buffer= <_mem>;
> qtec,white_balance= <_0>;
> qtec,sensor = <_fg_0>;
> qtec,pll = < _0 >;
> qtec,xform = <_0>;
> qtec,testgen = <_0>;
> qtec,encoder = <_0>;
> interrupt-parent = <_intc_0>;
> interrupts = < 5 2 >;
> };
>
> gpio_0: gpio_0 {
> #gpio-cells = <2>;
> compatible = "xlnx,xps-gpio-1.00.a";
> reg = < 0x3004 01 >;
> xlnx,dout-default = < 0x >;
> xlnx,tri-default = < 0xfff8 >;
> xlnx,gpio-width = < 5 >;
> };
>
>
> /*Leds*/
> leds {
> reg = < 0x3004 01 >;
> compatible = "gpio-leds";
> red {
So why not use name "red0" and name another one "red1"? since you have
multiple different red leds here any way.
-Bryan
> gpios = <_0 0 0>;
> linux,default-trigger = "drop-qt5023_video0";
> };
> yellow {
> gpios = <_0 1 0>;
> linux,default-trigger = "packer-qt5023_video0";
> };
> green {
> gpios = <_0 2 0>;
> linux,default-trigger = "heartbeat";
> };
> };
>
>
> If there are multiple cameras, then there will be multiple red, yellow
> and green leds, throwing out the error I copied earlier.
>
>
> Thanks!
>
> --
> Ricardo Ribalda
--
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: [PATCH v2 2/2] leds: add Qualcomm PM8941 WLED driver
On Tue, Feb 17, 2015 at 2:30 PM, Bjorn Andersson wrote: > On Tue, Feb 17, 2015 at 2:14 PM, Bryan Wu wrote: >> On Thu, Feb 12, 2015 at 8:04 PM, Stephen Boyd wrote: >>> On 01/23/15 16:54, Bjorn Andersson wrote: >> >> Thanks for the review, Stephen. >> Bjorn, could you please update your patch according to Stephen's review. >> > > I will do so, do you want me to send a new patch or an incremental > patch with the changes? > Please send me a new one. -Bryan -- 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: [PATCH] led/led-class: Handle LEDs with the same name
On Thu, Feb 12, 2015 at 12:45 PM, Ricardo Ribalda Delgado
wrote:
> Hello Bryan
>
> On Thu, Feb 12, 2015 at 8:48 PM, Bryan Wu wrote:
>>
>> Could you please give me some real error message or example about this
>> device tree overlays? Looks like it's not only for LED subsystem and
>> how is it handled in other subsystem?
>
> In my case I have a device tree overlay describing a camera. This
> camera has 3 leds, named red, green and yellow. When I connect the
> second camera, kobject complains about a repeated name. The error is
> REALLY verbose. I am out of the office right now, so I cannot show you
> the error message. You can trigger the same error by trying to
> register two leds with the same name.
>
Can you show me your device tree code for overlaying describing a camera?
-Bryan
> A similar error can be triggered for example when we want to create
> two misc devices with the same name
>
> [106998.862865] [ cut here ]
> [106998.862885] WARNING: CPU: 1 PID: 12979 at
> /build/linux-CMiYW9/linux-3.16.7-ckt2/fs/sysfs/dir.c:31
> sysfs_warn_dup+0x5f/0x70()
> [106998.862890] sysfs: cannot create duplicate filename
> '/devices/virtual/misc/eudyptula'
> [106998.862894] Modules linked in: hello(O+) btrfs xor raid6_pq ufs
> qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c dm_mod bnep
> bluetooth 6lowpan_iphc mmc_block tun ctr ccm binfmt_misc nfsd
> auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc nls_utf8
> nls_cp437 vfat fat x86_pkg_temp_thermal intel_powerclamp intel_rapl
> uvcvideo coretemp videobuf2_vmalloc kvm_intel videobuf2_memops
> videobuf2_core v4l2_common videodev kvm media joydev crc32_pclmul
> ghash_clmulni_intel aesni_intel arc4 aes_x86_64 iwldvm mac80211
> iwlwifi cfg80211 lrw gf128mul glue_helper iTCO_wdt iTCO_vendor_support
> ablk_helper evdev psmouse i915 snd_hda_codec_hdmi cryptd serio_raw
> pcspkr ac shpchp efi_pstore drm_kms_helper snd_hda_codec_conexant
> snd_hda_codec_generic lpc_ich thinkpad_acpi nvram tpm_tis efivars drm
> i2c_algo_bit i2c_i801
> [106998.863005] snd_hda_intel snd_hda_controller mfd_core mei_me
> snd_hda_codec i2c_core mei wmi snd_hwdep rfkill snd_pcm tpm battery
> snd_timer snd soundcore button video processor fuse parport_pc ppdev
> lp parport autofs4 ext4 crc16 mbcache jbd2 sg sd_mod sr_mod crc_t10dif
> cdrom crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_intel
> ahci libahci libata ehci_pci ehci_hcd scsi_mod sdhci_pci sdhci
> mmc_core e1000e usbcore ptp pps_core usb_common thermal thermal_sys
> [106998.863077] CPU: 1 PID: 12979 Comm: insmod Tainted: G O
> 3.16.0-4-amd64 #1 Debian 3.16.7-ckt2-1
> [106998.863083] Hardware name: LENOVO 4180DY4/4180DY4, BIOS 83ET76WW
> (1.46 ) 07/05/2013
> [106998.863087] 0009 81507263 880021757af8
> 81065847
> [106998.863096] 880065c6d000 880021757b48 880214c1c820
>
> [106998.863103] 810658ac 8172ff20
> 0028
> [106998.863111] Call Trace:
> [106998.863125] [] ? dump_stack+0x41/0x51
> [106998.863137] [] ? warn_slowpath_common+0x77/0x90
> [106998.863145] [] ? warn_slowpath_fmt+0x4c/0x50
> [106998.863153] [] ? kernfs_path+0x43/0x50
> [106998.863161] [] ? sysfs_warn_dup+0x5f/0x70
> [106998.863169] [] ? sysfs_create_dir_ns+0x7e/0x90
> [106998.863180] [] ? kobject_add_internal+0xc6/0x3e0
> [106998.863190] [] ? string.isra.7+0x36/0xe0
> [106998.863197] [] ? kobject_add+0x65/0xb0
> [106998.863204] [] ? pointer.isra.18+0x9e/0x470
> [106998.863213] [] ? device_add+0x124/0x610
> [106998.863221] [] ? device_create_groups_vargs+0xd8/0x100
> [106998.863239] [] ? 0xa0024fff
> [106998.863247] [] ? device_create+0x41/0x50
> [106998.863257] [] ? kasprintf+0x3e/0x40
> [106998.863268] [] ? misc_register+0xc2/0x120
> [106998.863277] [] ? hello_init+0xc/0x1000 [hello]
> [106998.863285] [] ? do_one_initcall+0xcc/0x200
> [106998.863295] [] ? load_module+0x20da/0x26b0
> [106998.863303] [] ? store_uevent+0x40/0x40
> [106998.863312] [] ? SyS_finit_module+0x7d/0xa0
> [106998.863322] [] ? system_call_fast_compare_end+0x10/0x15
> [106998.863327] ---[ end trace af819f702b51bbb0 ]---
> [106998.863332] [ cut here ]
>
>
>>> +static int match_child(struct device *dev, void *data)
>>> +{
>>> + if (!dev_name(dev))
>>> + return 0;
>>> + return !strcmp(dev_name(dev), (char *)data);
>>
>> strncmp instead of strcmp?
>
> I dont think it would make it safer here. You need to know the size of
> the string, and finding out the lenght of the string will produce the
> same access error (if that is what concerns you)
Re: [PATCH v2 2/2] leds: add Qualcomm PM8941 WLED driver
On Thu, Feb 12, 2015 at 8:04 PM, Stephen Boyd wrote:
> On 01/23/15 16:54, Bjorn Andersson wrote:
Thanks for the review, Stephen.
Bjorn, could you please update your patch according to Stephen's review.
-Bryan
>> +
>> +static int pm8941_wled_configure(struct pm8941_wled *wled, struct device
>> *dev)
>> +{
>> + struct pm8941_wled_config *cfg = >cfg;
>> + u32 val;
>> + int rc;
>> + int i;
>> +
>> + const struct {
>> + const char *name;
>> + u32 *val_ptr;
>> + const struct pm8941_wled_var_cfg *cfg;
>> + } u32_opts[] = {
>> + {
>> + "qcom,current-boost-limit",
>> + >i_boost_limit,
>> + .cfg = _wled_i_boost_limit_cfg,
>> + },
>> + {
>> + "qcom,current-limit",
>> + >i_limit,
>> + .cfg = _wled_i_limit_cfg,
>> + },
>> + {
>> + "qcom,ovp",
>> + >ovp,
>> + .cfg = _wled_ovp_cfg,
>> + },
>> + {
>> + "qcom,switching-freq",
>> + >switch_freq,
>> + .cfg = _wled_switch_freq_cfg,
>> + },
>> + {
>> + "qcom,num-strings",
>> + >num_strings,
>> + .cfg = _wled_num_strings_cfg,
>> + },
>> + };
>> + const struct {
>> + const char *name;
>> + bool *val_ptr;
>> + } bool_opts[] = {
>> + { "qcom,cs-out", >cs_out_en, },
>> + { "qcom,ext-gen", >ext_gen, },
>> + { "qcom,cabc", >cabc_en, },
>> + };
>> +
>> + rc = of_property_read_u32(dev->of_node, "reg", );
>> + if (rc || val > 0x) {
>> + dev_err(dev, "invalid IO resources\n");
>> + return rc ? rc : -EINVAL;
>> + }
>> + wled->addr = val;
>> +
>> + rc = of_property_read_string(dev->of_node, "label", >cdev.name);
>> + if (rc)
>> + wled->cdev.name = dev->of_node->name;
>> +
>> + wled->cdev.default_trigger = of_get_property(dev->of_node,
>> + "linux,default-trigger", NULL);
>> +
>> + *cfg = pm8941_wled_config_defaults;
>> + for (i = 0; i < ARRAY_SIZE(u32_opts); ++i) {
>> + u32 sel, c;
>> + int j, rj;
>> +
>> + rc = of_property_read_u32(dev->of_node, u32_opts[i].name,
>> );
>> + if (rc) {
>> + if (rc != -EINVAL) {
>> + dev_err(dev, "error reading '%s'\n",
>> + u32_opts[i].name);
>> + return rc;
>> + }
>> + continue;
>> + }
>> +
>> + sel = UINT_MAX;
>> + rj = -1;
>> + c = pm8941_wled_values(u32_opts[i].cfg, 0);
>> + for (j = 0; c != UINT_MAX; ++j) {
>> + if (c <= val && (sel == UINT_MAX || c >= sel)) {
>> + sel = c;
>> + rj = j;
>> + }
>> + c = pm8941_wled_values(u32_opts[i].cfg, j + 1);
>> + }
>> + if (sel == UINT_MAX) {
>> + dev_err(dev, "invalid value for '%s'\n",
>> + u32_opts[i].name);
>> + return rc;
>
> Isn't rc always 0 here? Don't we want to return an error?
>
> Also, I find this code very convoluted given that we loop through a
> table and match based on nodes and call function pointers, etc. Why
> can't we just have a handful of if statements with of_property_read_u32
> in them? That way we don't have to jump through so many hoops, bouncing
> all around this file to figure out what's going on. If we did I imagine
> we wouldn't have missed out on rc being 0 here.
>
>> +
>> +static int pm8941_wled_remove(struct platform_device *pdev)
>> +{
>> + struct pm8941_wled *wled;
>> +
>> + wled = platform_get_drvdata(pdev);
>> + led_classdev_unregister(>cdev);
>
> Would be nice to have a devm for this one too.
>
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id pm8941_wled_match_table[] = {
>> + { .compatible = "qcom,pm8941-wled" },
>> + {}
>> +};
>> +MODULE_DEVICE_TABLE(of, pm8941_wled_match_table);
>> +
>> +static struct platform_driver pm8941_wled_driver = {
>> + .probe = pm8941_wled_probe,
>> + .remove = pm8941_wled_remove,
>> + .driver = {
>> + .name = "pm8941-wled",
>> + .owner = THIS_MODULE,
>
> THIS_MODULE should be removed.
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Re: [PATCH] led/led-class: Handle LEDs with the same name
On Tue, Feb 17, 2015 at 2:54 PM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
Hello Bryan
On Tue, Feb 17, 2015 at 11:34 PM, Bryan Wu coolo...@gmail.com wrote:
Can you show me your device tree code for overlaying describing a camera?
The camera is composed by fpga modules. The fpga is attached via pcie
to the host.
The whole dt would be too long.
Here you can see the relevant parts
axi1 {
packer_0: packer_0{
#address-cells = 1;
#size-cells = 1;
compatible = qtec,axi_matrix_packer-1.00.a;
reg = 0x3006 0x1 ;
qtec,serial_number = Invalid Head Serial Number;
qtec,bitstream_version = 0 ;
qtec,head_i2c_address = 0 ;
qtec,cdma = cdma_0;
qtec,desc_mem= cdma_desc_mem;
qtec,pcie_bridge= pcie_bridge_0;
qtec,aperture-addr= 0 4 ;
qtec,circular_buffer= video_mem;
qtec,white_balance= white_0;
qtec,sensor = ccd_fg_0;
qtec,pll = pll_0 ;
qtec,xform = xform_0;
qtec,testgen = testgen_0;
qtec,encoder = encoder_0;
interrupt-parent = xps_intc_0;
interrupts = 5 2 ;
};
gpio_0: gpio_0 {
#gpio-cells = 2;
compatible = xlnx,xps-gpio-1.00.a;
reg = 0x3004 01 ;
xlnx,dout-default = 0x ;
xlnx,tri-default = 0xfff8 ;
xlnx,gpio-width = 5 ;
};
/*Leds*/
leds {
reg = 0x3004 01 ;
compatible = gpio-leds;
red {
So why not use name red0 and name another one red1? since you have
multiple different red leds here any way.
-Bryan
gpios = gpio_0 0 0;
linux,default-trigger = drop-qt5023_video0;
};
yellow {
gpios = gpio_0 1 0;
linux,default-trigger = packer-qt5023_video0;
};
green {
gpios = gpio_0 2 0;
linux,default-trigger = heartbeat;
};
};
If there are multiple cameras, then there will be multiple red, yellow
and green leds, throwing out the error I copied earlier.
Thanks!
--
Ricardo Ribalda
--
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: [PATCH] led/led-class: Handle LEDs with the same name
On Tue, Feb 17, 2015 at 4:32 PM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
Hello Bryan
On Wed, Feb 18, 2015 at 12:59 AM, Bryan Wu coolo...@gmail.com wrote:
DT just describe the hardware, so if it's a different hardware, they
should have different name.
red0 for GPIO 0, red1 for GPIO 1 or choose other good name instead of 0 and
1.
I think I have not managed to explain myself properly.
We have a host computer. with 2 pcie slots. The host is described with
a DT that looks like:
axi1 {
pci0{
reg = 0x2000 0x1000
}
pci1{
reg = 0x3000 0x1000
}
}
The user can connect anything to the pci slots. (pci0 and pci1)
Lets say that we have a type of add-on card. Described by this DT
overlay (card.dtb):
I think who write this card.dtb should understand this issue. And
choose the right name.
pci {
gpio_0: gpio_0 {
What happen if you just use name 'gpio: gpio {' here.? Any conflicts
or kernel oops?
#gpio-cells = 2;
compatible = xlnx,xps-gpio-1.00.a;
reg = 0x3004 01 ;
};
/*Leds*/
leds {
reg = 0x3004 01 ;
compatible = gpio-leds;
red {
gpios = gpio_0 0 0;
linux,default-trigger = drop-qt5023_video0;
};
}
}
The user connects two of those cards to the system (at locations pci0 and
pci1).
Then we have TWO gpios chip. Each of them have a led named red. When
the second gpio-led is probed we have an error. Everything else
(address offset, phandle, device renaming) is handled properly already
by the kernel.
On this system I cannot control card.dtb, or which type of cards will
the user connect to the system. The DT is generated in run-time based
on the hardware connected to the pci slots.
So you're supposed to get 2 card.dtb files for 2 PCI cards, right?
They should be different and you need to choose different name for the
hardware.
I humbly believe that the issue here is that the subsystem does not
protect ourselves against name collisions, because a month ago a
device tree was considered immutable and in full control of the system
designer, unfortunately this is not the case anymore.
From device tree point of view, I believe different device should got
different name although they can match to same compatible string. Let
me invite DT folks for help.
Thanks,
-Bryan
--
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: [PATCH] led/led-class: Handle LEDs with the same name
Thanks!
On Tue, Feb 17, 2015 at 5:11 PM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
Hello Bryan
On Wed, Feb 18, 2015 at 1:52 AM, Bryan Wu coolo...@gmail.com wrote:
Lets say that we have a type of add-on card. Described by this DT
overlay (card.dtb):
I think who write this card.dtb should understand this issue. And
choose the right name.
card.dtb just describe the hardware in the card, and it is not be
aware of the rest of the system.
I dont think it is practical to have card_HOST0_PCI1.dtb,
card_HOST0_PCI2.dtb to HOST0_PCI16.dtb and then HOST1_, HOST2
gpio_0: gpio_0 {
What happen if you just use name 'gpio: gpio {' here.? Any conflicts
or kernel oops?
No problem here, one will create the device
/sys/devices/pci:00/:00:05.0/:01:00.0/3004.gpio
and the other:
/sys/devices/pci:00/:00:06.0/:01:00.0/4004.gpio
Name is created with hierarnchy
/sys/class/gpio/ will also work fine, because the gpiochip id is
created dynamically
On the other hand all the leds are under,
/sys/class/leds/NAME
Do not have any dynamic naming or hierarchical name.
I got it. In this case we need to give the leds device a unique name.
Go back to your patch, you're adding 0, 1 at the end of the name of
leds. It's better like GPIO I think you can pick up reg value of
leds device node and put it in front of the name of leds. like
/sys/class/leds/3004.red and /sys/class/leds/4004.red.
Thanks,
-Bryan
--
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: [PATCH] led/led-class: Handle LEDs with the same name
On Tue, Feb 17, 2015 at 3:47 PM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: Hi On Wed, Feb 18, 2015 at 12:35 AM, Bryan Wu coolo...@gmail.com wrote: So why not use name red0 and name another one red1? since you have multiple different red leds here any way. I cannot control how many cameras the user will decide to attach to the system, and if two similar cameras are attached to pciA and pciB, they would try to load the same dt. DT just describe the hardware, so if it's a different hardware, they should have different name. red0 for GPIO 0, red1 for GPIO 1 or choose other good name instead of 0 and 1. If this is true, you can just name one LED like gpio-led and let the kernel to add number after that name. I don't think this is a good idea to name the hardware. And These aren't like other devices which will create device node like /dev/video0 /dev/video1. This is from device tree to describe the hardware. Thanks, -Bryan -- 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: [PATCH v2 2/2] leds: add Qualcomm PM8941 WLED driver
On Thu, Feb 12, 2015 at 8:04 PM, Stephen Boyd sb...@codeaurora.org wrote:
On 01/23/15 16:54, Bjorn Andersson wrote:
Thanks for the review, Stephen.
Bjorn, could you please update your patch according to Stephen's review.
-Bryan
+
+static int pm8941_wled_configure(struct pm8941_wled *wled, struct device
*dev)
+{
+ struct pm8941_wled_config *cfg = wled-cfg;
+ u32 val;
+ int rc;
+ int i;
+
+ const struct {
+ const char *name;
+ u32 *val_ptr;
+ const struct pm8941_wled_var_cfg *cfg;
+ } u32_opts[] = {
+ {
+ qcom,current-boost-limit,
+ cfg-i_boost_limit,
+ .cfg = pm8941_wled_i_boost_limit_cfg,
+ },
+ {
+ qcom,current-limit,
+ cfg-i_limit,
+ .cfg = pm8941_wled_i_limit_cfg,
+ },
+ {
+ qcom,ovp,
+ cfg-ovp,
+ .cfg = pm8941_wled_ovp_cfg,
+ },
+ {
+ qcom,switching-freq,
+ cfg-switch_freq,
+ .cfg = pm8941_wled_switch_freq_cfg,
+ },
+ {
+ qcom,num-strings,
+ cfg-num_strings,
+ .cfg = pm8941_wled_num_strings_cfg,
+ },
+ };
+ const struct {
+ const char *name;
+ bool *val_ptr;
+ } bool_opts[] = {
+ { qcom,cs-out, cfg-cs_out_en, },
+ { qcom,ext-gen, cfg-ext_gen, },
+ { qcom,cabc, cfg-cabc_en, },
+ };
+
+ rc = of_property_read_u32(dev-of_node, reg, val);
+ if (rc || val 0x) {
+ dev_err(dev, invalid IO resources\n);
+ return rc ? rc : -EINVAL;
+ }
+ wled-addr = val;
+
+ rc = of_property_read_string(dev-of_node, label, wled-cdev.name);
+ if (rc)
+ wled-cdev.name = dev-of_node-name;
+
+ wled-cdev.default_trigger = of_get_property(dev-of_node,
+ linux,default-trigger, NULL);
+
+ *cfg = pm8941_wled_config_defaults;
+ for (i = 0; i ARRAY_SIZE(u32_opts); ++i) {
+ u32 sel, c;
+ int j, rj;
+
+ rc = of_property_read_u32(dev-of_node, u32_opts[i].name,
val);
+ if (rc) {
+ if (rc != -EINVAL) {
+ dev_err(dev, error reading '%s'\n,
+ u32_opts[i].name);
+ return rc;
+ }
+ continue;
+ }
+
+ sel = UINT_MAX;
+ rj = -1;
+ c = pm8941_wled_values(u32_opts[i].cfg, 0);
+ for (j = 0; c != UINT_MAX; ++j) {
+ if (c = val (sel == UINT_MAX || c = sel)) {
+ sel = c;
+ rj = j;
+ }
+ c = pm8941_wled_values(u32_opts[i].cfg, j + 1);
+ }
+ if (sel == UINT_MAX) {
+ dev_err(dev, invalid value for '%s'\n,
+ u32_opts[i].name);
+ return rc;
Isn't rc always 0 here? Don't we want to return an error?
Also, I find this code very convoluted given that we loop through a
table and match based on nodes and call function pointers, etc. Why
can't we just have a handful of if statements with of_property_read_u32
in them? That way we don't have to jump through so many hoops, bouncing
all around this file to figure out what's going on. If we did I imagine
we wouldn't have missed out on rc being 0 here.
+
+static int pm8941_wled_remove(struct platform_device *pdev)
+{
+ struct pm8941_wled *wled;
+
+ wled = platform_get_drvdata(pdev);
+ led_classdev_unregister(wled-cdev);
Would be nice to have a devm for this one too.
+
+ return 0;
+}
+
+static const struct of_device_id pm8941_wled_match_table[] = {
+ { .compatible = qcom,pm8941-wled },
+ {}
+};
+MODULE_DEVICE_TABLE(of, pm8941_wled_match_table);
+
+static struct platform_driver pm8941_wled_driver = {
+ .probe = pm8941_wled_probe,
+ .remove = pm8941_wled_remove,
+ .driver = {
+ .name = pm8941-wled,
+ .owner = THIS_MODULE,
THIS_MODULE should be removed.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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/
