06 Aug, 2020

1 commit

  • Pull LED updates from Pavel Machek:
    "Okay, so... this one is interesting. RGB LEDs are very common, and we
    need to have some kind of support for them. Multicolor is for
    arbitrary set of LEDs in one package, RGB is for LEDs that can produce
    full range of colors. We do not have real multicolor LED that is not
    RGB in the pipeline, so that one is disabled for now.

    You can expect this saga to continue with next pull requests"

    * tag 'leds-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: (37 commits)
    MAINTAINERS: Remove myself as LED subsystem maintainer
    leds: disallow /sys/class/leds/*:multi:* for now
    leds: add RGB color option, as that is different from multicolor.
    Make LEDS_LP55XX_COMMON depend on I2C to fix build errors:
    Documentation: ABI: leds-turris-omnia: document sysfs attribute
    leds: initial support for Turris Omnia LEDs
    dt-bindings: leds: add cznic,turris-omnia-leds binding
    leds: pattern trigger -- check pattern for validity
    leds: Replace HTTP links with HTTPS ones
    leds: trigger: add support for LED-private device triggers
    leds: lp5521: Add multicolor framework multicolor brightness support
    leds: lp5523: Update the lp5523 code to add multicolor brightness function
    leds: lp55xx: Add multicolor framework support to lp55xx
    leds: lp55xx: Convert LED class registration to devm_*
    dt-bindings: leds: Convert leds-lp55xx to yaml
    leds: multicolor: Introduce a multicolor class definition
    leds: Add multicolor ID to the color ID list
    dt: bindings: Add multicolor class dt bindings documention
    leds: lp5523: Fix various formatting issues in the code
    leds: lp55xx: Fix file permissions to use DEVICE_ATTR macros
    ...

    Linus Torvalds
     

03 Aug, 2020

2 commits

  • All the LEDs in the queue are RGB, so they should not use multi for
    their color.

    Make sure we don't add such LED by mistake (and make it part of ABI).

    Signed-off-by: Pavel Machek

    Pavel Machek
     
  • Multicolor is a bit too abstract. Yes, we can have
    Green-Magenta-Ultraviolet LED, but so far all the LEDs we support are
    RGB, and not even RGB-White or RGB-Yellow variants emerged.

    Multicolor is not a good fit for RGB LED. It does not really know
    about LED color. In particular, there's no way to make LED "white".

    Userspace is interested in knowing "this LED can produce arbitrary
    color", which not all multicolor LEDs can.

    Signed-off-by: Pavel Machek

    Pavel Machek
     

28 Jul, 2020

1 commit

  • leds-lp55xx-common.c:(.text+0x9d): undefined reference to `i2c_smbus_read_byte_data'
    leds-lp55xx-common.c:(.text+0x8fc): undefined reference to `i2c_smbus_write_byte_data'

    These errors happened when I2C=m and LEDS_LP55XX_COMMON=y, so
    prevent that from being possible.

    Signed-off-by: Randy Dunlap
    Cc: Jacek Anaszewski
    Cc: Pavel Machek
    Cc: Dan Murphy
    Cc: linux-leds@vger.kernel.org
    Cc: Milo Kim
    Cc: Mathias Nyman
    Signed-off-by: Pavel Machek

    Randy Dunlap
     

24 Jul, 2020

2 commits


22 Jul, 2020

7 commits

  • Rationale:
    Reduces attack surface on kernel devs opening the links for MITM
    as HTTPS traffic is much harder to manipulate.

    Deterministic algorithm:
    For each file:
    If not .svg:
    For each line:
    If doesn't contain `\bxmlns\b`:
    For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
    If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
    If both the HTTP and HTTPS versions
    return 200 OK and serve the same content:
    Replace HTTP with HTTPS.

    Signed-off-by: Alexander A. Klimov
    Acked-by: Rob Herring
    Acked-by: Dan Murphy
    Signed-off-by: Pavel Machek

    Alexander A. Klimov
     
  • Some LED controllers may come with an internal HW triggering mechanism
    for the LED and the ability to switch between SW control and the
    internal HW control. This includes most PHYs, various ethernet switches,
    the Turris Omnia LED controller or AXP20X PMIC.

    This adds support for registering such triggers.

    This code is based on work by Pavel Machek and
    Ondřej Jirman .

    Signed-off-by: Marek Behún
    Acked-by: Jacek Anaszewski
    Signed-off-by: Pavel Machek

    Marek Behún
     
  • Add the multicolor brightness call back to support the multicolor
    framework. This function allows setting the brightness across
    grouped LED channels in a single call.

    Acked-by: Pavel Machek
    Acked-by: Jacek Anaszewski
    Signed-off-by: Dan Murphy
    Signed-off-by: Pavel Machek

    Dan Murphy
     
  • Add the multicolor brightness call back to support the multicolor
    framework. This call back allows setting brightness on grouped channels
    in a single function.

    Acked-by: Pavel Machek
    Acked-by: Jacek Anaszewski
    Signed-off-by: Dan Murphy
    Signed-off-by: Pavel Machek

    Dan Murphy
     
  • Add multicolor framework support for the lp55xx family.

    Acked-by: Pavel Machek
    Acked-by: Jacek Anaszewski
    Signed-off-by: Dan Murphy
    Signed-off-by: Pavel Machek

    Dan Murphy
     
  • Convert the LED class registration calls to the LED devm_*
    registration calls.

    Acked-by: Jacek Anaszewski
    Acked-by: Pavel Machek
    Signed-off-by: Dan Murphy
    Signed-off-by: Pavel Machek

    Dan Murphy
     
  • Introduce a multicolor class that groups colored LEDs
    within a LED node.

    The multicolor class groups monochrome LEDs and allows controlling two
    aspects of the final combined color: hue and lightness. The former is
    controlled via the intensity file and the latter is controlled
    via brightness file.

    Signed-off-by: Dan Murphy
    Acked-by: Jacek Anaszewski
    Signed-off-by: Pavel Machek
    [squashed leds: multicolor: Fix camel case in documentation in]

    Dan Murphy
     

16 Jul, 2020

3 commits

  • Add a new color ID that is declared as MULTICOLOR as with the
    multicolor framework declaring a definitive color is not accurate
    as the node can contain multiple colors.

    Signed-off-by: Dan Murphy
    Reviewed-by: Marek Behún
    Signed-off-by: Pavel Machek

    Dan Murphy
     
  • Fix checkpatch errors and warnings for the LP5523.c device
    driver.

    Acked-by: Pavel Machek
    Acked-by: Jacek Anaszewski
    Signed-off-by: Dan Murphy
    Reviewed-by: Marek Behún
    Signed-off-by: Pavel Machek

    Dan Murphy
     
  • Fix the checkpatch warnings for the use of the file permission macros.
    In converting the file permissions to the DEVICE_ATTR_XX macros the
    call back function names needed to be updated within the code.

    This means that the lp55xx_ needed to be dropped in the name to keep in
    harmony with the ABI documentation.

    Acked-by: Pavel Machek
    Acked-by: Jacek Anaszewski
    Signed-off-by: Dan Murphy
    Reviewed-by: Marek Behún
    Signed-off-by: Pavel Machek

    Dan Murphy
     

12 Jul, 2020

8 commits

  • Make use of the struct_size() helper instead of an open-coded version
    in order to avoid any potential type mistakes. Also, remove unnecessary
    function sizeof_gpio_leds_priv().

    This code was detected with the help of Coccinelle and, audited and
    fixed manually.

    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: Pavel Machek

    Gustavo A. R. Silva
     
  • Make use of the struct_size() helper instead of an open-coded version
    in order to avoid any potential type mistakes. Also, remove unnecessary
    function sizeof_ns2_led_priv().

    This code was detected with the help of Coccinelle and, audited and
    fixed manually.

    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: Pavel Machek

    Gustavo A. R. Silva
     
  • The leds-gpio driver mixes up the legacy GPIO flags with the
    GPIO descriptor flags and passes a legacy flag to
    devm_gpiod_get_index().

    Fix this by replacing the flags variable with the strict
    descriptor flag.

    Fixes: 45d4c6de4e49 ("leds: gpio: Try to lookup gpiod from device")
    Signed-off-by: Linus Walleij
    Signed-off-by: Pavel Machek

    Linus Walleij
     
  • Sometimes LED won't be turned off by LED_CORE_SUSPENDRESUME flag upon
    system suspend.

    led_set_brightness_nopm() uses schedule_work() to set LED brightness.
    However, there's no guarantee that the scheduled work gets executed
    because no one flushes the work.

    So flush the scheduled work to make sure LED gets turned off.

    Signed-off-by: Kai-Heng Feng
    Acked-by: Jacek Anaszewski
    Fixes: 81fe8e5b73e3 ("leds: core: Add led_set_brightness_nosleep{nopm} functions")
    Signed-off-by: Pavel Machek

    Kai-Heng Feng
     
  • If the GPIO has not been configured yet, writing to inverted will raise
    a kernel warning.

    Signed-off-by: Jan Kiszka
    Signed-off-by: Pavel Machek

    Jan Kiszka
     
  • Fix typo: "Tigger" --> "Trigger"

    Signed-off-by: Flavio Suligoi
    Reviewed-by: Alexander Dahl
    Signed-off-by: Pavel Machek

    Flavio Suligoi
     
  • This driver provides a GPIO chip, so include
    and not the legacy header.

    Cc: Andrew Jeffery
    Cc: Joel Stanley
    Cc: Matt Spinler
    Cc: Cédric Le Goater
    Signed-off-by: Linus Walleij
    Signed-off-by: Pavel Machek

    Linus Walleij
     
  • The LP55xx driver is already using the of_gpio() functions to
    pick a global GPIO number for "enable" from the device tree and
    request the line. Simplify it by just using a GPIO descriptor.

    Make sure to keep the enable GPIO line optional, change the
    naming from "lp5523_enable" to "LP55xx enable" to reflect that
    this is used on all LP55xx LED drivers.

    Cc: Milo Kim
    Signed-off-by: Linus Walleij
    Signed-off-by: Pavel Machek

    Linus Walleij
     

09 Jul, 2020

1 commit

  • This converts the s3c24xx LED driver to use GPIO descriptors
    and also modify all board files to account for these changes
    by registering the appropriate GPIO tables for each board.

    The driver was using a custom flag to indicate open drain
    (tristate) but this can be handled by standard descriptor
    machine tables.

    The driver was setting non-pull-up for the pin using the custom
    S3C24xx GPIO API, but this is a custom pin control system used
    by the S3C24xx and no generic GPIO function, so this has simply
    been pushed back into the respective board files.

    Signed-off-by: Linus Walleij
    Acked-by: Jacek Anaszewski
    Signed-off-by: Krzysztof Kozlowski

    Linus Walleij
     

22 Jun, 2020

8 commits

  • Right now the driver uses only 3 LED modes:
    0: On
    1: HW Blinking (Interval 1)
    3: Off

    However, the controller supports a second HW blinking interval, which results
    in 4 possible LED modes:
    0: On
    1: HW Blinking (Interval 1)
    2: HW Blinking (Interval 2)
    3: Off

    Signed-off-by: Álvaro Fernández Rojas
    Signed-off-by: Pavel Machek

    Álvaro Fernández Rojas
     
  • Drop the pointless and needlessly confusing casts of struct-device
    pointers.

    Signed-off-by: Johan Hovold
    Signed-off-by: Pavel Machek

    Johan Hovold
     
  • Several MFD child drivers register their class devices directly under
    the parent device. This means you cannot blindly do devres conversions
    so that deregistration ends up being tied to the parent device,
    something which leads to use-after-free on driver unbind when the class
    device is released while still being registered.

    Fixes: 8d3b6a4001ce ("leds: wm831x-status: Use devm_led_classdev_register")
    Cc: stable # 4.6
    Cc: Amitoj Kaur Chawla
    Signed-off-by: Johan Hovold
    Signed-off-by: Pavel Machek

    Johan Hovold
     
  • Several MFD child drivers register their class devices directly under
    the parent device. This means you cannot use devres so that
    deregistration ends up being tied to the parent device, something which
    leads to use-after-free on driver unbind when the class device is
    released while still being registered.

    Fixes: 11e1bbc116a7 ("leds: lm36274: Introduce the TI LM36274 LED driver")
    Cc: stable # 5.3
    Cc: Dan Murphy
    Signed-off-by: Johan Hovold
    Signed-off-by: Pavel Machek

    Johan Hovold
     
  • Several MFD child drivers register their class devices directly under
    the parent device. This means you cannot blindly do devres conversions
    so that deregistration ends up being tied to the parent device,
    something which leads to use-after-free on driver unbind when the class
    device is released while still being registered.

    Fixes: 50154e29e5cc ("leds: lm3533: Use devm_led_classdev_register")
    Cc: stable # 4.6
    Cc: Amitoj Kaur Chawla
    Signed-off-by: Johan Hovold
    Signed-off-by: Pavel Machek

    Johan Hovold
     
  • Several MFD child drivers register their class devices directly under
    the parent device. This means you cannot blindly do devres conversions
    so that deregistration ends up being tied to the parent device,
    something which leads to use-after-free on driver unbind when the class
    device is released while still being registered.

    Fixes: eed16255d66b ("leds: da903x: Use devm_led_classdev_register")
    Cc: stable # 4.6
    Cc: Amitoj Kaur Chawla
    Signed-off-by: Johan Hovold
    Signed-off-by: Pavel Machek

    Johan Hovold
     
  • Several MFD child drivers register their class devices directly under
    the parent device. This means you cannot blindly do devres conversions
    so that deregistration ends up being tied to the parent device,
    something which leads to use-after-free on driver unbind when the class
    device is released while still being registered.

    Fixes: 375446df95ee ("leds: 88pm860x: Use devm_led_classdev_register")
    Cc: stable # 4.6
    Cc: Amitoj Kaur Chawla
    Signed-off-by: Johan Hovold
    Signed-off-by: Pavel Machek

    Johan Hovold
     
  • clang points out that doing arithmetic between diffent enums is usually
    a mistake:

    drivers/leds/leds-lm355x.c:167:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion]
    reg_val = pdata->pin_tx2 | pdata->ntc_pin;
    ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
    drivers/leds/leds-lm355x.c:178:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion]
    reg_val = pdata->pin_tx2 | pdata->ntc_pin | pdata->pass_mode;
    ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~

    In this driver, it is intentional, so add a cast to hide the false-positive
    warning. It appears to be the only instance of this warning at the moment.

    Fixes: b98d13c72592 ("leds: Add new LED driver for lm355x chips")
    Signed-off-by: Arnd Bergmann
    Signed-off-by: Pavel Machek

    Arnd Bergmann
     

05 Jun, 2020

1 commit

  • Pull LED updates from Pavel Machek:
    "New drivers: aw2013, sgm3140, some fixes

    Nothing much to see here, next release should be more interesting"

    * tag 'leds-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds:
    leds: add aw2013 driver
    dt-bindings: leds: Add binding for aw2013
    leds: trigger: remove redundant assignment to variable ret
    leds: netxbig: Convert to use GPIO descriptors
    leds: add sgm3140 driver
    dt-bindings: leds: Add binding for sgm3140
    leds: ariel: Add driver for status LEDs on Dell Wyse 3020
    leds: pwm: check result of led_pwm_set() in led_pwm_add()
    leds: tlc591xxt: hide error on EPROBE_DEFER
    leds: tca6507: Include the right header
    leds: lt3593: Drop surplus include
    leds: lp3952: Include the right header
    leds: lm355x: Drop surplus include

    Linus Torvalds
     

26 May, 2020

1 commit


25 May, 2020

1 commit

  • This commit adds support for AWINIC AW2013 3-channel LED driver.
    The chip supports 3 PWM channels and is controlled with I2C.

    Signed-off-by: Nikita Travkin
    Signed-off-by: Pavel Machek

    Nikita Travkin
     

27 Apr, 2020

4 commits