aboutsummaryrefslogtreecommitdiff
path: root/drivers/leds
AgeCommit message (Collapse)AuthorFilesLines
2023-06-08leds: cht-wcove: Remove unneeded semicolonJiapeng Chong1-1/+1
No functional modification involved. ./drivers/leds/leds-cht-wcove.c:193:2-3: Unneeded semicolon. Reported-by: Abaci Robot <[email protected]> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5343 Signed-off-by: Jiapeng Chong <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-06-08leds: cht-wcove: Fix an unsigned comparison which can never be negativeYang Li1-2/+1
The return value from the call to cht_wc_leds_find_freq() is int. However, the return value is being assigned to an unsigned int variable 'ctrl', so making it an int. Eliminate the following warning: drivers/leds/leds-cht-wcove.c:236 cht_wc_leds_set_effect() warn: unsigned 'ctrl' is never less than zero. Reported-by: Abaci Robot <[email protected]> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5341 Signed-off-by: Yang Li <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-06-08leds: cht-wcove: Mark cht_wc_leds_brightness_get() staticHans de Goede1-1/+1
cht_wc_leds_brightness_get() is only used internally, mark it static. Cc: Yauhen Kharuzhy <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-06-03leds: qcom-lpg: Fix PWM period limitsBjorn Andersson1-4/+4
The introduction of high resolution PWM support changed the order of the operations in the calculation of min and max period. The result in both divisions is in most cases a truncation to 0, which limits the period to the range of [0, 0]. Both numerators (and denominators) are within 64 bits, so the whole expression can be put directly into the div64_u64, instead of doing it partially. Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM") Reviewed-by: Caleb Connolly <[email protected]> Tested-by: Steev Klimaszewski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Acked-by: Lee Jones <[email protected]> Tested-by: Johan Hovold <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johan Hovold <[email protected]>
2023-06-01leds: Add AW20xx driverMartin Kurbanov3-0/+608
This commit adds support for AWINIC AW20036/AW20054/AW20072 LED driver. This driver supports following AW200XX features: - Individual 64-level DIM currents Signed-off-by: Martin Kurbanov <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-31leds: trigger: netdev: expose netdev trigger modes in linux includeChristian Marangi1-9/+0
Expose netdev trigger modes to make them accessible by LED driver that will support netdev trigger for hw control. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-05-31leds: trigger: netdev: init mode if hw control already activeChristian Marangi1-0/+17
On netdev trigger activation, hw control may be already active by default. If this is the case and a device is actually provided by hw_control_get_device(), init the already active mode and set the bool to hw_control bool to true to reflect the already set mode in the trigger_data. Co-developed-by: Andrew Lunn <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-05-31leds: trigger: netdev: validate configured netdevAndrew Lunn1-2/+22
The netdev which the LED should blink for is configurable in /sys/class/led/foo/device_name. Ensure when offloading that the configured netdev is the same as the netdev the LED is associated with. If it is not, only perform software blinking. Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-05-31leds: trigger: netdev: add support for LED hw controlChristian Marangi1-2/+41
Add support for LED hw control for the netdev trigger. The trigger on calling set_baseline_state to configure a new mode, will do various check to verify if hw control can be used for the requested mode in can_hw_control() function. It will first check if the LED driver supports hw control for the netdev trigger, then will use hw_control_is_supported() and finally will call hw_control_set() to apply the requested mode. To use such mode, interval MUST be set to the default value and net_dev MUST be set. If one of these 2 value are not valid, hw control will never be used and normal software fallback is used. The default interval value is moved to a define to make sure they are always synced. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-05-31leds: trigger: netdev: reject interval store for hw_controlChristian Marangi1-0/+3
Reject interval store with hw_control enabled. It's are currently not supported and MUST be set to the default value with hw control enabled. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-05-31leds: trigger: netdev: add basic check for hw control supportChristian Marangi1-0/+14
Add basic check for hw control support. Check if the required API are defined and check if the defined trigger supported in hw control for the LED driver match netdev. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-05-31leds: trigger: netdev: introduce check for possible hw controlChristian Marangi1-0/+8
Introduce function to check if the requested mode can use hw control in preparation for hw control support. Currently everything is handled in software so can_hw_control will always return false. Add knob with the new value hw_control in trigger_data struct to set hw control possible. Useful for future implementation to implement in set_baseline_state() the required function to set the requested mode using LEDs hw control ops and in other function to reject set if hw control is currently active. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-05-31leds: trigger: netdev: refactor code setting device nameAndrew Lunn1-9/+20
Move the code into a helper, ready for it to be called at other times. No intended behaviour change. Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-05-25led: qcom-lpg: Fix resource leaks in for_each_available_child_of_node() loopsLu Hongfei1-2/+6
Ensure child node references are decremented properly in the error path. Signed-off-by: Lu Hongfei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: as3645a: Replace strlcpy with strscpyAzeem Shaikh1-2/+2
Part of a tree-wide effort to remove deprecated strlcpy()[1] and replace it with strscpy()[2]. No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89 Signed-off-by: Azeem Shaikh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: gpio: Configure per-LED pin controlMarek Vasut1-0/+18
Each gpio-leds DT node DT subnode can have a pinctrl property assigned to it, parse the DT subnode pinctrl properties and configure each pin accordingly. Tested-by: Christoph Niedermaier <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: Replace all non-returning strlcpy with strscpyAzeem Shaikh3-3/+3
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89 Signed-off-by: Azeem Shaikh <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: blinkm: Replace all non-returning strlcpy with strscpyAzeem Shaikh1-1/+1
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89 Signed-off-by: Azeem Shaikh <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: Add HAS_IOPORT dependenciesNiklas Schnelle1-1/+1
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by: Arnd Bergmann <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Niklas Schnelle <[email protected]> Acked-by: Pavel Machek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: trigger: netdev: Remove NULL check before dev_{put, hold}Yang Li1-4/+2
The call netdev_{put, hold} of dev_{put, hold} will check NULL, so there is no need to check before using dev_{put, hold}, remove it to silence the warnings: ./drivers/leds/trigger/ledtrig-netdev.c:291:3-10: WARNING: NULL check before dev_{put, hold} functions is not needed. ./drivers/leds/trigger/ledtrig-netdev.c:401:2-9: WARNING: NULL check before dev_{put, hold} functions is not needed. Reported-by: Abaci Robot <[email protected]> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=4929 Signed-off-by: Yang Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: Clear LED_INIT_DEFAULT_TRIGGER when clearing current triggerHans de Goede1-0/+1
Not all triggers use LED_INIT_DEFAULT_TRIGGER, which means that it will not get cleared when the default trigger is a trigger which does not use it such as "default-on". If the default trigger then later gets replaced by a trigger which does check LED_INIT_DEFAULT_TRIGGER, such as "timer" then that trigger will behave as if it is the default trigger which it should not do. To fix this clear the LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger, so that it will not be set for any subsequently set (non default) triggers. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Jacek Anaszewski <[email protected]> Tested-by: Yauhen Kharuzhy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: Fix oops about sleeping in led_trigger_blink()Hans de Goede2-1/+25
led_trigger_blink() calls led_blink_set() from a RCU read-side critical section so led_blink_set() must not sleep. Note sleeping was not allowed before the switch to RCU either because a spinlock was held before. led_blink_set() does not sleep when sw-blinking is used, but many LED controller drivers with hw blink support have a blink_set function which may sleep, leading to an oops like this one: [ 832.605062] ------------[ cut here ]------------ [ 832.605085] Voluntary context switch within RCU read-side critical section! [ 832.605119] WARNING: CPU: 2 PID: 370 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x4ee/0x690 <snip> [ 832.606453] Call Trace: [ 832.606466] <TASK> [ 832.606487] __schedule+0x9f/0x1480 [ 832.606527] schedule+0x5d/0xe0 [ 832.606549] schedule_timeout+0x79/0x140 [ 832.606572] ? __pfx_process_timeout+0x10/0x10 [ 832.606599] wait_for_completion_timeout+0x6f/0x140 [ 832.606627] i2c_dw_xfer+0x101/0x460 [ 832.606659] ? psi_group_change+0x168/0x400 [ 832.606680] __i2c_transfer+0x172/0x6d0 [ 832.606709] i2c_smbus_xfer_emulated+0x27d/0x9c0 [ 832.606732] ? __schedule+0x430/0x1480 [ 832.606753] ? preempt_count_add+0x6a/0xa0 [ 832.606778] ? get_nohz_timer_target+0x18/0x190 [ 832.606796] ? lock_timer_base+0x61/0x80 [ 832.606817] ? preempt_count_add+0x6a/0xa0 [ 832.606842] __i2c_smbus_xfer+0xa2/0x3f0 [ 832.606862] i2c_smbus_xfer+0x66/0xf0 [ 832.606882] i2c_smbus_read_byte_data+0x41/0x70 [ 832.606901] ? _raw_spin_unlock_irqrestore+0x23/0x40 [ 832.606922] ? __pm_runtime_suspend+0x46/0xc0 [ 832.606946] cht_wc_byte_reg_read+0x2e/0x60 [ 832.606972] _regmap_read+0x5c/0x120 [ 832.606997] _regmap_update_bits+0x96/0xc0 [ 832.607023] regmap_update_bits_base+0x5b/0x90 [ 832.607053] cht_wc_leds_brightness_get+0x412/0x910 [leds_cht_wcove] [ 832.607094] led_blink_setup+0x28/0x100 [ 832.607119] led_trigger_blink+0x40/0x70 [ 832.607145] power_supply_update_leds+0x1b7/0x1c0 [ 832.607174] power_supply_changed_work+0x67/0xe0 [ 832.607198] process_one_work+0x1c8/0x3c0 [ 832.607222] worker_thread+0x4d/0x380 [ 832.607243] ? __pfx_worker_thread+0x10/0x10 [ 832.607258] kthread+0xe9/0x110 [ 832.607279] ? __pfx_kthread+0x10/0x10 [ 832.607300] ret_from_fork+0x2c/0x50 [ 832.607337] </TASK> [ 832.607344] ---[ end trace 0000000000000000 ]--- Add a new led_blink_set_nosleep() function which defers the actual led_blink_set() call to a workqueue when necessary to fix this. This also fixes an existing race where a pending led_set_brightness() has been deferred to set_brightness_work and might then race with a later led_cdev->blink_set() call. Note this race is only an issue with triggers mixing led_trigger_event() and led_trigger_blink() calls, sysfs API calls and led_trigger_blink_oneshot() are not affected. Note rather then adding a separate blink_set_blocking callback this uses the presence of the already existing brightness_set_blocking callback to detect if the blinking call should be deferred to set_brightness_work. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Jacek Anaszewski <[email protected]> Tested-by: Yauhen Kharuzhy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: Fix set_brightness_delayed() raceHans de Goede1-13/+44
When a trigger wants to switch from blinking to LED on it needs to call: led_set_brightness(LED_OFF); led_set_brightness(LED_FULL); To first call disables blinking and the second then turns the LED on (the power-supply charging-blink-full-solid triggers do this). These calls happen immediately after each other, so it is possible that set_brightness_delayed() from the first call has not run yet when the led_set_brightness(LED_FULL) call finishes. If this race hits then this is causing problems for both sw- and hw-blinking: For sw-blinking set_brightness_delayed() clears delayed_set_value when LED_BLINK_DISABLE is set causing the led_set_brightness(LED_FULL) call effects to get lost when hitting the race, resulting in the LED turning off instead of on. For hw-blinking if the race hits delayed_set_value has been set to LED_FULL by the time set_brightness_delayed() runs. So led_cdev->brightness_set_blocking() is never called with LED_OFF as argument and the hw-blinking is never disabled leaving the LED blinking instead of on. Fix both issues by adding LED_SET_BRIGHTNESS and LED_SET_BRIGHTNESS_OFF work_flags making this 2 separate actions to be run by set_brightness_delayed(). Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Jacek Anaszewski <[email protected]> Tested-by: Yauhen Kharuzhy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-valueHans de Goede3-20/+13
led_blink_set[_oneshot]()'s delay_on and delay_off function parameters are pass by reference, so that hw-blink implementations can report back the actual achieved delays when the values have been rounded to something the hw supports. This is really only interesting for the sysfs API / the timer trigger. Other triggers don't really care about this and none of the callers of led_trigger_blink[_oneshot]() do anything with the returned delay values. Change the led_trigger_blink[_oneshot]() delay parameters to pass-by-value, there are 2 reasons for this: 1. led_cdev->blink_set() may sleep, while led_trigger_blink() may not. So on hw where led_cdev->blink_set() sleeps the call needs to be deferred to a workqueue, in which case the actual achieved delays are unknown (this is a preparation patch for the deferring). 2. Since the callers don't care about the actual achieved delays, allowing callers to directly pass a value leads to simpler code for most callers. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Jacek Anaszewski <[email protected]> Tested-by: Yauhen Kharuzhy <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Sebastian Reichel <[email protected]> Acked-by: Florian Westphal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: Switch i2c drivers back to use .probe()Uwe Kleine-König30-30/+30
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: Make LEDS_TI_LMU_COMMON invisibleGeert Uytterhoeven1-6/+5
Currently, LEDS_LM3697 and LEDS_LM36274 depend on LEDS_TI_LMU_COMMON, which contains the common code to support TI LMU devices. This means the user is asked about the common code first, followed by the individual drivers, if their dependencies are met. Simplify this, and reduce the number of questions by making LEDS_TI_LMU_COMMON invisible, and letting it be selected when needed. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Pavel Machek <[email protected]> Link: https://lore.kernel.org/r/91f6efaa48c36320e58b6a312025ae9b39ee206b.1683644796.git.geert+renesas@glider.be Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: flash: leds-qcom-flash: Disable LED when changing brightnessDylan Van Assche1-0/+8
The Qualcomm PMI8998 PMIC requires the LED to be disabled when configuring the brightness. Always disable the LED when setting the brightness and re-enable it afterwards. Signed-off-by: Dylan Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: flash: leds-qcom-flash: Add PMI8998 supportDylan Van Assche1-2/+3
Add subtype for the Qualcomm PMI8998 PMIC to support it besides the PM8150 PMIC which has the same registers. Adjust the driver to recognize both PMIC subtypes as a 3 channel LED driver. Signed-off-by: Dylan Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: cht-wcove: Use breathing when LED_INIT_DEFAULT_TRIGGER is setHans de Goede1-1/+15
The desired default behavior of LED1 / the charge LED is breathing while charging and on/solid when full. Since triggers cannot select breathing, blink_set() gets called when charging. Use breathing when the default "charging-blink-full-solid" trigger is used to achieve the desired default behavior. Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: cht-wcove: Set default trigger for charging LEDHans de Goede1-0/+16
Set a default trigger for the charging LED based on the machine-model as set by the PMIC MFD driver. Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: cht-wcove: Add support for breathing mode use hw_pattern sysfs APIHans de Goede1-4/+38
The hw-blinking of the LED controller in the Whiskey Cove PMIC can also be used for a hw-breathing effect. As discussed during review of v2 of the submission of the new leds-cht-wcove driver, the LED subsystem already supports breathing mode on several other LED controllers using the hw_pattern interface. Implement a pattern_set callback to implement breathing mode modelled after the breathing mode supported by the SC27xx breathing light and Crane EL15203000 LED drivers. The Whiskey Cove PMIC's breathing mode is closer to the EL15203000 one then to the SC27xx one since it does not support staying high / low for a specific time, it only supports rise and fall times. As such the supported hw_pattern and the documentation for this is almost a 1:1 copy of the pattern/docs for the EL15203000 breathing mode. Suggested-by: Jacek Anaszewski <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: cht-wcove: Add suspend/resume handlingHans de Goede1-0/+33
When LED1 is showing the tablet is charging and then the device gets suspended followed by unplugging the charger, then it will incorrectly still show it is charging. To avoid this turn both LEDs off on suspend, just like the PMIC always turns them off when the tablet is powered off (even if the tablet is charging). If hw-control is supported for LED1, then restore the initial hw-control settings to let the hw control LED1 while suspended. To restore the state the LEDs had before suspending, save it before turning the LEDs off and restore it on resume. Acked-by: Pavel Machek <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: Add Intel Cherry Trail Whiskey Cove PMIC LED driverYauhen Kharuzhy3-0/+392
Add support for LEDs connected to the Intel Cherry Trail Whiskey Cove PMIC. Charger and general-purpose LEDs are supported. Hardware blinking is implemented, breathing is not. This driver was tested with Lenovo Yoga Book notebook. Changes by Hans de Goede (in response to review of v2): - Since the PMIC is connected to the battery any changes we make to the LED settings are permanent, even surviving reboot / poweroff. Save LED1 register settings on probe() and if auto-/hw-control was enabled on probe() restore the settings on remove() and shutdown(). - Delay switching LED1 to software control mode to first brightness write. - Use dynamically allocated drvdata instead of a global drvdata variable. - Ensure the LED is on when activating blinking. - Fix CHT_WC_LED_EFF_BREATHING val ((3 << 1) rather then BIT(3)). Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Yauhen Kharuzhy <[email protected]> Co-developed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: qcom-lpg: Add support for PMI632 LPGLuca Weiss1-0/+15
The PMI632 PMIC contains 5 PWM channels, 3 of which can be used for LEDs. For the LED pattern it doesn't have LUT like other PMICs but uses SDAM instead. This is not currently implemented in the driver but since LPG works fine without it, add support for the PMIC now. Signed-off-by: Luca Weiss <[email protected]> Acked-by: Pavel Machek <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-25leds: lp55xx: Configure internal charge pumpMaarten Zanders4-14/+28
The LP55xx range of devices have an internal charge pump which can (automatically) increase the output voltage towards the LED's, boosting the output voltage to 4.5V. Implement this option from the devicetree. When the setting is not present it will operate in automatic mode as before. Tested on LP55231. Datasheet analysis shows that LP5521, LP5523 and LP8501 are identical in topology and are modified in the same way. Signed-off-by: Maarten Zanders <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-25leds: trigger: netdev: Use mutex instead of spinlocksChristian Marangi1-9/+9
Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-25leds: trigger: netdev: Convert device attr to macroChristian Marangi1-41/+16
Convert link tx and rx device attr to a common macro to reduce common code and in preparation for additional attr. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-25leds: trigger: netdev: Rename add namespace to netdev trigger enum modesChristian Marangi1-33/+25
Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-25leds: trigger: netdev: Drop NETDEV_LED_MODE_LINKUP from modeChristian Marangi1-11/+8
Putting NETDEV_LED_MODE_LINKUP in the same list of the netdev trigger modes is wrong as it's used to set the link state of the device and not to set a blink mode as it's done by NETDEV_LED_LINK, NETDEV_LED_TX and NETDEV_LED_RX. It's also wrong to put this state in the same bitmap of the netdev trigger mode and should be external to it. Drop NETDEV_LED_MODE_LINKUP from mode list and convert to a simple bool that will be true or false based on the carrier link. No functional change intended. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-25leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev renameChristian Marangi1-0/+3
Dev can be renamed also while up for supported device. We currently wrongly clear the NETDEV_LED_MODE_LINKUP flag on NETDEV_CHANGENAME event. Fix this by rechecking if the carrier is ok on NETDEV_CHANGENAME and correctly set the NETDEV_LED_MODE_LINKUP bit. Fixes: 5f820ed52371 ("leds: trigger: netdev: fix handling on interface rename") Cc: [email protected] # v5.5+ Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-02Merge tag 'leds-next-6.4' of ↵Linus Torvalds16-58/+2702
git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds Pull LED updates from Lee Jones: "New Drivers: - Add support for MediaTek MT6370 LED Indicator - Add support for MediaTek MT6370 Flashlight - Add support for QCOM PMIC Flash - Add support for Rohm BD2606MVV Charge Pump LED New Device Support: - Add support for PMK8550 PWM to QCOM LPG New Functionality: - Add support for high resolution PWM to QCOM LPG Fix-ups: - Kconfig 'depends' and 'select' dependency changes - Remove unused / irrelevant includes - Remove unnecessary checks (already performed further into the call stack) - Trivial: Fix commentary, simplify error messages - Rid 'defined but not used' warnings - Provide documentation - Explicitly provide include files Bug Fixes: - Mark GPIO LED as BROKEN - Fix Kconfig entries - Fix various Smatch staticify reports - Fix error handling (or a lack there of)" * tag 'leds-next-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (30 commits) leds: bd2606mvv: Driver for the Rohm 6 Channel i2c LED driver dt-bindings: leds: Add ROHM BD2606MVV LED docs: leds: ledtrig-oneshot: Fix spelling mistake leds: pwm-multicolor: Simplify an error message dt-bindings: leds: Convert PCA9532 to dtschema leds: rgb: leds-qcom-lpg: Add support for PMK8550 PWM leds: rgb: leds-qcom-lpg: Add support for high resolution PWM dt-bindings: leds-qcom-lpg: Add qcom,pmk8550-pwm compatible string leds: tca6507: Fix error handling of using fwnode_property_read_string leds: flash: Set variables mvflash_{3,4}ch_regs storage-class-specifier to static leds: rgb: mt6370: Correct config name to select in LEDS_MT6370_RGB MAINTAINERS: Add entry for LED devices documentation Documentation: leds: MT6370: Use bullet lists for timing variables Documentation: leds: mt6370: Properly wrap hw_pattern chart Documentation: leds: Add MT6370 doc to the toctree leds: rgb: mt6370: Fix implicit declaration for FIELD_GET docs: leds: Add MT6370 RGB LED pattern document leds: flash: mt6370: Add MediaTek MT6370 flashlight support leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support dt-bindings: leds: spmi-flash-led: Add pm6150l compatible ...
2023-04-27leds: bd2606mvv: Driver for the Rohm 6 Channel i2c LED driverAndreas Kemnade3-0/+175
The device provides 6 channels which can be individually turned off and on but groups of two channels share a common brightness register. Limitation: The GPIO to enable the device is not used yet. Signed-off-by: Andreas Kemnade <[email protected]> Reviewed-by: Matti Vaittinen <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-04-20leds: pwm-multicolor: Simplify an error messageChristophe JAILLET1-2/+2
dev_err_probe() already display the error code. There is no need to duplicate it explicitly in the error message. While at it, add a missing \n at the end of the message. Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/07d35e221faaa380fd11cd4597e42354c8eb350c.1681576017.git.christophe.jaillet@wanadoo.fr
2023-04-20leds: rgb: leds-qcom-lpg: Add support for PMK8550 PWMAnjelique Melendez1-0/+9
Add support for pmk8550 compatible and lpg_data. Signed-off-by: Anjelique Melendez <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-04-20leds: rgb: leds-qcom-lpg: Add support for high resolution PWMAnjelique Melendez1-45/+106
Certain PMICs like PMK8550 have a high resolution PWM module which can support from 8-bit to 15-bit PWM. Add support for it. Signed-off-by: Anjelique Melendez <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-04-05leds: tca6507: Fix error handling of using fwnode_property_read_stringH. Nikolaus Schaller1-2/+3
Commit 96f524105b9c ("leds: tca6507: use fwnode API instead of OF") changed to fwnode API but did not take into account that a missing property "linux,default-trigger" now seems to return an error and as a side effect sets value to -1. This seems to be different from of_get_property() which always returned NULL in any case of error. Neglecting this side-effect leads to [ 11.201965] Unable to handle kernel paging request at virtual address ffffffff when read in the strcmp() of led_trigger_set_default() if there is no led-trigger defined in the DTS. I don't know if this was recently introduced somewhere in the fwnode lib or if the effect was missed in initial testing. Anyways it seems to be a bug to ignore the error return value of an optional value here in the driver. Fixes: 96f524105b9c ("leds: tca6507: use fwnode API instead of OF") Signed-off-by: H. Nikolaus Schaller <[email protected]> Acked-by: Pavel Machek <[email protected]> Reviewed-by: Marek Behún <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/cbae7617db83113de726fcc423a805ebaa1bfca6.1680433978.git.hns@goldelico.com
2023-03-30leds: flash: Set variables mvflash_{3,4}ch_regs storage-class-specifier to ↵Tom Rix1-2/+2
static Smatch reports: drivers/leds/flash/leds-qcom-flash.c:103:18: warning: symbol 'mvflash_3ch_regs' was not declared. Should it be static? drivers/leds/flash/leds-qcom-flash.c:115:18: warning: symbol 'mvflash_4ch_regs' was not declared. Should it be static? These variables are only used locally, so it should be static. Signed-off-by: Tom Rix <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-03-30leds: rgb: mt6370: Correct config name to select in LEDS_MT6370_RGBLukas Bulwahn1-1/+1
Commit 55a8a5c16eb3 ("leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support") introduces the config LEDS_MT6370_RGB, which selects the non-existing config LINEAR_RANGE. As the driver includes linux/linear_range.h, it is a safe guess that the config actually intends to select LINEAR_RANGES, which provides the library implementation for the function prototypes defined in the linear_range header file. Correct this naming confusion in the LEDS_MT6370_RGB config definition. Fixes: 55a8a5c16eb3 ("leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support") Signed-off-by: Lukas Bulwahn <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-03-23leds: rgb: mt6370: Fix implicit declaration for FIELD_GETChiYuan Huang1-0/+1
0-DAY CI Kernel Test Service reported the implicit declaration error below: drivers/leds/rgb/leds-mt6370-rgb.c: In function'mt6370_check_vendor_info': >> drivers/leds/rgb/leds-mt6370-rgb.c:889:15: error: implicit declaration of function 'FIELD_GET' [-Werror=implicit-function-declaration] 889 | vid = FIELD_GET(MT6370_VENDOR_ID_MASK, devinfo); | Add the missing header 'bitfield.h' to fix it. Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 55a8a5c16eb3 ("leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support") Signed-off-by: ChiYuan Huang <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-03-23leds: flash: mt6370: Add MediaTek MT6370 flashlight supportChiYuan Huang3-0/+587
The MediaTek MT6370 is a highly-integrated smart power management IC, which includes a single cell Li-Ion/Li-Polymer switching battery charger, a USB Type-C & Power Delivery (PD) controller, dual Flash LED current sources, a RGB LED driver, a backlight WLED driver, a display bias driver and a general LDO for portable devices. Add support for the MT6370 Flash LED driver. Flash LED in MT6370 has 2 channels and support torch/strobe mode. Co-developed-by: Alice Chen <[email protected]> Signed-off-by: Alice Chen <[email protected]> Signed-off-by: ChiYuan Huang <[email protected]> Signed-off-by: ChiaEn Wu <[email protected]> Acked-by: Jacek Anaszewski <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/52480420a160e5a4c71715fbbf105e684a16e7c2.1678430444.git.chiaen_wu@richtek.com
Powered by cgit, Gruvboxed by Blaster4385.