Hi Linus,
Please pull LED updates for 4.6 merge cycle.
The following changes since commit b562e44f507e863c6792946e4e1b1449fbbac85d:
Linux 4.5 (2016-03-13 21:28:54 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git tags/leds_for_4.6
for you to fetch changes up to 7296c33ed12ef13de50e03c76643382123766f96:
leds: triggers: simplify led_trigger_store (2016-03-14 09:22:23 +0100)
----------------------------------------------------------------
LED core improvements:
- Fix misleading comment after workqueue removal from drivers.
- Avoid error message when a USB LED device is unplugged.
- Add helpers for calling brightness_set(_blocking)
LED triggers:
- Simplify led_trigger_store by using sysfs_streq().
LED class drivers improvements:
- Improve wording and formatting in a comment: lp3944.
- Fix return value check in create_gpio_led(): leds-gpio.
- Use GPIOF_OUT_INIT_LOW instead of hardcoded zero: leds-gpio.
- Use devm_led_classdev_register(): leds-lm3533, leds-lm3533, leds-lp8788,
leds-wm831x-status, leds-s3c24xx, leds-s3c24xx, leds: max8997.
New LED class driver:
- Add driver for the ISSI IS31FL32xx family of LED controllers.
Device Tree documentation:
- of: Add vendor prefixes for Integrated Silicon Solutions Inc. (issi)
and Si-En Technology (si-en).
- DT: Add common bindings for Si-En Technology SN3216/18 and IS31FL32xx
family of LED controllers, since they seem to be the same hardware,
just rebranded.
----------------------------------------------------------------
Amitoj Kaur Chawla (7):
leds: lm3533: Use devm_led_classdev_register
leds: 88pm860x: Use devm_led_classdev_register
leds: lp8788: Use devm_led_classdev_register
leds: wm831x-status: Use devm_led_classdev_register
leds: s3c24xx: Use devm_led_classdev_register
leds: da903x: Use devm_led_classdev_register
leds: max8997: Use devm_led_classdev_register
Antonio Ospite (1):
leds: lp3944: improve wording and formatting in a comment
David Rivshin (4):
DT: Add vendor prefix for Integrated Silicon Solutions Inc.
DT: leds: Add binding for the ISSI IS31FL32xx family of LED controllers
leds: Add driver for the ISSI IS31FL32xx family of LED controllers
leds: Add SN3218 and SN3216 support to the IS31FL32XX driver
Geert Uytterhoeven (1):
leds: gpio: Use GPIOF_OUT_INIT_LOW instead of hardcoded zero
Heiner Kallweit (4):
leds: core: fix misleading comment after workqueue removal from drivers
leds: core: avoid error message when a USB LED device is unplugged
leds: core: add helpers for calling brightness_set(_blocking)
leds: triggers: simplify led_trigger_store
Stefan Wahren (1):
of: Add vendor prefix for Si-En Technology
Wei Yongjun (1):
leds: leds-gpio: Fix return value check in create_gpio_led()
.../devicetree/bindings/leds/leds-is31fl32xx.txt | 52 ++
.../devicetree/bindings/vendor-prefixes.txt | 2 +
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
drivers/leds/led-class.c | 2 +
drivers/leds/led-core.c | 45 +-
drivers/leds/led-triggers.c | 13 +-
drivers/leds/leds-88pm860x.c | 12 +-
drivers/leds/leds-da903x.c | 12 +-
drivers/leds/leds-gpio.c | 6 +-
drivers/leds/leds-is31fl32xx.c | 508 ++++++++++++++++++++
drivers/leds/leds-lm3533.c | 12 +-
drivers/leds/leds-lp3944.c | 7 +-
drivers/leds/leds-lp8788.c | 14 +-
drivers/leds/leds-max8997.c | 14 +-
drivers/leds/leds-s3c24xx.c | 19 +-
drivers/leds/leds-wm831x-status.c | 13 +-
include/linux/leds.h | 8 +-
18 files changed, 628 insertions(+), 120 deletions(-)
create mode 100644 Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
create mode 100644 drivers/leds/leds-is31fl32xx.c
Hi Jacek,
On Mon, 14 Mar 2016 11:24:57 +0100 Jacek Anaszewski <[email protected]> wrote:
>
> Please pull LED updates for 4.6 merge cycle.
>
> The following changes since commit b562e44f507e863c6792946e4e1b1449fbbac85d:
>
> Linux 4.5 (2016-03-13 21:28:54 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git tags/leds_for_4.6
>
> for you to fetch changes up to 7296c33ed12ef13de50e03c76643382123766f96:
>
> leds: triggers: simplify led_trigger_store (2016-03-14 09:22:23 +0100)
All rebased since yesterday for some reason?
--
Cheers,
Stephen Rothwell
Hi Stephen,
On 03/15/2016 12:36 AM, Stephen Rothwell wrote:
> Hi Jacek,
>
> On Mon, 14 Mar 2016 11:24:57 +0100 Jacek Anaszewski <[email protected]> wrote:
>>
>> Please pull LED updates for 4.6 merge cycle.
>>
>> The following changes since commit b562e44f507e863c6792946e4e1b1449fbbac85d:
>>
>> Linux 4.5 (2016-03-13 21:28:54 -0700)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git tags/leds_for_4.6
>>
>> for you to fetch changes up to 7296c33ed12ef13de50e03c76643382123766f96:
>>
>> leds: triggers: simplify led_trigger_store (2016-03-14 09:22:23 +0100)
>
> All rebased since yesterday for some reason?
>
I just wanted to make sure that no unexpected problem has occurred
after rebasing onto 4.5 release. Is it in some way more advantageous to
base a pull request on rc7, than on a final release?
--
Best regards,
Jacek Anaszewski
On Tue, Mar 15, 2016 at 12:51 AM, Jacek Anaszewski
<[email protected]> wrote:
>
> I just wanted to make sure that no unexpected problem has occurred
> after rebasing onto 4.5 release. Is it in some way more advantageous to
> base a pull request on rc7, than on a final release?
I'd rather see the pull request based on whatever it has been tested
on, and just keep it that way.
Any rebasing will inevitably mean that you are basically throwing all
previous testing out the window (or at least make it dubious).
Rebasing also makes it much harder to see the history (for example,
compare it against previous linux-next trees), so the rule really
should be that you should never rebase unless you have a major reason
to do so.
So for example, if you actually find a problem, and you notice that
that problem comes not from your own changes, but from the base you
picked - *then* you'd want to rebase to a more stable base. But a
rebase "just because" is not a good idea.
I'll pull it, since it looks fairly harmless, but basically please
don't do that again.
Linus
On Mon, Mar 14, 2016 at 3:24 AM, Jacek Anaszewski
<[email protected]> wrote:
>
> New LED class driver:
>
> - Add driver for the ISSI IS31FL32xx family of LED controllers.
Grr. This has apparently not gotten with the program, and causes a few
annoying warnings:
drivers/leds/leds-is31fl32xx.c: In function ‘is31fl32xx_parse_child_dt’:
drivers/leds/leds-is31fl32xx.c:345:30: warning: passing argument 1 of
‘of_property_read_string’ discards ‘const’ qualifier from pointer
target type [-Wdiscarded-qualifiers]
if (of_property_read_string(child, "label", &cdev->name))
^
(there's another at line 357)
I've pulled, but I'll expect this to be fixed.
Linus
On 03/16/2016 06:04 AM, Linus Torvalds wrote:
> On Tue, Mar 15, 2016 at 12:51 AM, Jacek Anaszewski
> <[email protected]> wrote:
>>
>> I just wanted to make sure that no unexpected problem has occurred
>> after rebasing onto 4.5 release. Is it in some way more advantageous to
>> base a pull request on rc7, than on a final release?
>
> I'd rather see the pull request based on whatever it has been tested
> on, and just keep it that way.
>
> Any rebasing will inevitably mean that you are basically throwing all
> previous testing out the window (or at least make it dubious).
>
> Rebasing also makes it much harder to see the history (for example,
> compare it against previous linux-next trees), so the rule really
> should be that you should never rebase unless you have a major reason
> to do so.
>
> So for example, if you actually find a problem, and you notice that
> that problem comes not from your own changes, but from the base you
> picked - *then* you'd want to rebase to a more stable base. But a
> rebase "just because" is not a good idea.
>
> I'll pull it, since it looks fairly harmless, but basically please
> don't do that again.
Thanks for the explanation. I'll proceed accordingly.
--
Best regards,
Jacek Anaszewski
On 03/16/2016 06:15 AM, Linus Torvalds wrote:
> On Mon, Mar 14, 2016 at 3:24 AM, Jacek Anaszewski
> <[email protected]> wrote:
>>
>> New LED class driver:
>>
>> - Add driver for the ISSI IS31FL32xx family of LED controllers.
>
> Grr. This has apparently not gotten with the program, and causes a few
> annoying warnings:
>
> drivers/leds/leds-is31fl32xx.c: In function ‘is31fl32xx_parse_child_dt’:
> drivers/leds/leds-is31fl32xx.c:345:30: warning: passing argument 1 of
> ‘of_property_read_string’ discards ‘const’ qualifier from pointer
> target type [-Wdiscarded-qualifiers]
> if (of_property_read_string(child, "label", &cdev->name))
> ^
The warnings will disappear after merging the patch [1].
I was to mention it in the pull request but eventually forgot.
Sorry about that.
> (there's another at line 357)
>
> I've pulled, but I'll expect this to be fixed.
>
> Linus
>
>
[1]
https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/commit/?h=for-next&id=fe99c707fc7bb0baba75b26ed585ee3464612dbe
--
Best regards,
Jacek Anaszewski