Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43 |
|
#
c7d80059 |
| 28-Jul-2023 |
Jean-Jacques Hiblot <jjhiblot@traphandler.com> |
leds: class: Store the color index in struct led_classdev
Store the color of the LED so that it is not lost after the LED's name has been composed. This color information can then be exposed to the
leds: class: Store the color index in struct led_classdev
Store the color of the LED so that it is not lost after the LED's name has been composed. This color information can then be exposed to the user space or used by the LED consumer.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Link: https://lore.kernel.org/r/20230728153731.3742339-3-jjhiblot@traphandler.com Signed-off-by: Lee Jones <lee@kernel.org>
show more ...
|
#
afb48153 |
| 28-Jul-2023 |
Jean-Jacques Hiblot <jjhiblot@traphandler.com> |
leds: Provide devm_of_led_get_optional()
Add an optional variant of devm_of_led_get(). It behaves the same as devm_of_led_get() except where the LED doesn't exist. In this case, instead of returning
leds: Provide devm_of_led_get_optional()
Add an optional variant of devm_of_led_get(). It behaves the same as devm_of_led_get() except where the LED doesn't exist. In this case, instead of returning -ENOENT, the function returns NULL.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230728153731.3742339-2-jjhiblot@traphandler.com Signed-off-by: Lee Jones <lee@kernel.org>
show more ...
|
Revision tags: v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35 |
|
#
f22f95b9 |
| 19-Jun-2023 |
Christian Marangi <ansuelsmth@gmail.com> |
leds: trigger: netdev: add additional specific link duplex mode
Add additional modes for specific link duplex. Use ethtool APIs to get the current link duplex and enable the LED accordingly. Under n
leds: trigger: netdev: add additional specific link duplex mode
Add additional modes for specific link duplex. Use ethtool APIs to get the current link duplex and enable the LED accordingly. Under netdev event handler the rtnl lock is already held and is not needed to be set to access ethtool APIs.
This is especially useful for PHY and Switch that supports LEDs hw control for specific link duplex.
Add additional modes: - half_duplex: Turn on LED when link is half duplex - full_duplex: Turn on LED when link is full duplex
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
d5e01266 |
| 19-Jun-2023 |
Christian Marangi <ansuelsmth@gmail.com> |
leds: trigger: netdev: add additional specific link speed mode
Add additional modes for specific link speed. Use ethtool APIs to get the current link speed and enable the LED accordingly. Under netd
leds: trigger: netdev: add additional specific link speed mode
Add additional modes for specific link speed. Use ethtool APIs to get the current link speed and enable the LED accordingly. Under netdev event handler the rtnl lock is already held and is not needed to be set to access ethtool APIs.
This is especially useful for PHY and Switch that supports LEDs hw control for specific link speed. (example scenario a PHY that have 2 LED connected one green and one orange where the green is turned on with 1000mbps speed and orange is turned on with 10mpbs speed)
On mode set from sysfs we check if we have enabled split link speed mode and reject enabling generic link mode to prevent wrong and redundant configuration.
Rework logic on the set baseline state to support these new modes to select if we need to turn on or off the LED.
Add additional modes: - link_10: Turn on LED when link speed is 10mbps - link_100: Turn on LED when link speed is 100mbps - link_1000: Turn on LED when link speed is 1000mbps
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
Revision tags: v6.1.34, v6.1.33, v6.1.32, v6.1.31 |
|
#
947acaca |
| 29-May-2023 |
Christian Marangi <ansuelsmth@gmail.com> |
leds: trigger: netdev: expose netdev trigger modes in linux include
Expose netdev trigger modes to make them accessible by LED driver that will support netdev trigger for hw control.
Signed-off-by:
leds: trigger: netdev: expose netdev trigger modes in linux include
Expose netdev trigger modes to make them accessible by LED driver that will support netdev trigger for hw control.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
052c38eb |
| 29-May-2023 |
Andrew Lunn <andrew@lunn.ch> |
leds: add API to get attached device for LED hw control
Some specific LED triggers blink the LED based on events from a device or subsystem. For example, an LED could be blinked to indicate a networ
leds: add API to get attached device for LED hw control
Some specific LED triggers blink the LED based on events from a device or subsystem. For example, an LED could be blinked to indicate a network device is receiving packets, or a disk is reading blocks. To correctly enable and request the hw control of the LED, the trigger has to check if the network interface or block device configured via a /sys/class/led file match the one the LED driver provide for hw control for.
Provide an API call to get the device which the LED blinks for.
Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
ed554d3f |
| 29-May-2023 |
Christian Marangi <ansuelsmth@gmail.com> |
leds: add APIs for LEDs hw control
Add an option to permit LED driver to declare support for a specific trigger to use hw control and setup the LED to blink based on specific provided modes.
Add AP
leds: add APIs for LEDs hw control
Add an option to permit LED driver to declare support for a specific trigger to use hw control and setup the LED to blink based on specific provided modes.
Add APIs for LEDs hw control. These functions will be used to activate hardware control where a LED will use the provided flags, from an unique defined supported trigger, to setup the LED to be driven by hardware.
Add hw_control_is_supported() to ask the LED driver if the requested mode by the trigger are supported and the LED can be setup to follow the requested modes.
Deactivate hardware blink control by setting brightness to LED_OFF via the brightness_set() callback.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v6.1.30, v6.1.29, v6.1.28 |
|
#
22720a87 |
| 10-May-2023 |
Hans de Goede <hdegoede@redhat.com> |
leds: Fix oops about sleeping in led_trigger_blink()
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
leds: Fix oops about sleeping in led_trigger_blink()
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 <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Tested-by: Yauhen Kharuzhy <jekhor@gmail.com> Link: https://lore.kernel.org/r/20230510162234.291439-4-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
show more ...
|
#
fa15d8c6 |
| 10-May-2023 |
Hans de Goede <hdegoede@redhat.com> |
leds: Fix set_brightness_delayed() race
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
leds: Fix set_brightness_delayed() race
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 <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Tested-by: Yauhen Kharuzhy <jekhor@gmail.com> Link: https://lore.kernel.org/r/20230510162234.291439-3-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
show more ...
|
#
e298d8a3 |
| 10-May-2023 |
Hans de Goede <hdegoede@redhat.com> |
leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value
led_blink_set[_oneshot]()'s delay_on and delay_off function parameters are pass by reference, so that hw-blink implementa
leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value
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 <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Tested-by: Yauhen Kharuzhy <jekhor@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Florian Westphal <fw@strlen.de> Link: https://lore.kernel.org/r/20230510162234.291439-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
show more ...
|
Revision tags: v6.1.27, v6.1.26, v6.3, v6.1.25 |
|
#
e5029edd |
| 17-Apr-2023 |
Andrew Lunn <andrew@lunn.ch> |
leds: Provide stubs for when CLASS_LED & NEW_LEDS are disabled
Provide stubs for devm_led_classdev_register_ext() and led_init_default_state_get() so that LED drivers embedded within other drivers s
leds: Provide stubs for when CLASS_LED & NEW_LEDS are disabled
Provide stubs for devm_led_classdev_register_ext() and led_init_default_state_get() so that LED drivers embedded within other drivers such as PHYs and Ethernet switches still build when LEDS_CLASS or NEW_LEDS are disabled. This also helps with Kconfig dependencies, which are somewhat hairy for phylib and mdio and only get worse when adding a dependency on LED_CLASS.
Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2 |
|
#
8af70e20 |
| 18-Feb-2023 |
Thomas Weißschuh <linux@weissschuh.net> |
leds: Fix reference to led_set_brightness() in doc
The referenced function led_classdev_brightness_set() never existed.
Fixes: 5ada28bf7675 ("led-class: always implement blinking") Signed-off-by: T
leds: Fix reference to led_set_brightness() in doc
The referenced function led_classdev_brightness_set() never existed.
Fixes: 5ada28bf7675 ("led-class: always implement blinking") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230218-typo-led-set-v1-1-3c35362a2f2d@weissschuh.net
show more ...
|
Revision tags: v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17 |
|
#
156a5bb8 |
| 03-Jan-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
leds: Move led_init_default_state_get() to the global header
There are users inside and outside LED framework that have implemented a local copy of led_init_default_state_get(). In order to deduplic
leds: Move led_init_default_state_get() to the global header
There are users inside and outside LED framework that have implemented a local copy of led_init_default_state_get(). In order to deduplicate that, as the first step move the declaration from LED header to the global one.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230103131256.33894-3-andriy.shevchenko@linux.intel.com
show more ...
|
#
d35d0c9d |
| 03-Jan-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
leds: Add missing includes and forward declarations in leds.h
Add missing includes and forward declarations to leds.h. While at it, replace headers by forward declarations and vise versa.
Signed-of
leds: Add missing includes and forward declarations in leds.h
Add missing includes and forward declarations to leds.h. While at it, replace headers by forward declarations and vise versa.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230103131256.33894-2-andriy.shevchenko@linux.intel.com
show more ...
|
#
abc3100f |
| 20-Jan-2023 |
Hans de Goede <hdegoede@redhat.com> |
leds: led-class: Add generic [devm_]led_get()
Add a generic [devm_]led_get() method which can be used on both devicetree and non devicetree platforms to get a LED classdev associated with a specific
leds: led-class: Add generic [devm_]led_get()
Add a generic [devm_]led_get() method which can be used on both devicetree and non devicetree platforms to get a LED classdev associated with a specific function on a specific device, e.g. the privacy LED associated with a specific camera sensor.
Note unlike of_led_get() this takes a string describing the function rather then an index. This is done because e.g. camera sensors might have a privacy LED, or a flash LED, or both and using an index approach leaves it unclear what the function of index 0 is if there is only 1 LED.
This uses a lookup-table mechanism for non devicetree platforms. This allows the platform code to map specific LED class_dev-s to a specific device,function combinations this way.
For devicetree platforms getting the LED by function-name could be made to work using the standard devicetree pattern of adding a -names string array to map names to the indexes.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230120114524.408368-5-hdegoede@redhat.com
show more ...
|
Revision tags: v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5 |
|
#
2a5a8fa8 |
| 15-Sep-2021 |
Johannes Berg <johannes.berg@intel.com> |
leds: trigger: use RCU to protect the led_cdevs list
Even with the previous commit 27af8e2c90fb ("leds: trigger: fix potential deadlock with libata") to this file, we still get lockdep unhappy, and
leds: trigger: use RCU to protect the led_cdevs list
Even with the previous commit 27af8e2c90fb ("leds: trigger: fix potential deadlock with libata") to this file, we still get lockdep unhappy, and Boqun explained the report here: https://lore.kernel.org/r/YNA+d1X4UkoQ7g8a@boqun-archlinux
Effectively, this means that the read_lock_irqsave() isn't enough here because another CPU might be trying to do a write lock, and thus block the readers.
This is all pretty messy, but it doesn't seem right that the LEDs framework imposes some locking requirements on users, in particular we'd have to make the spinlock in the iwlwifi driver always disable IRQs, even if we don't need that for any other reason, just to avoid this deadlock.
Since writes to the led_cdevs list are rare (and are done by userspace), just switch the list to RCU. This costs a synchronize_rcu() at removal time so we can ensure things are correct, but that seems like a small price to pay for getting lock-free iterations and no deadlocks (nor any locking requirements imposed on users.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
show more ...
|
Revision tags: v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43 |
|
#
791bc411 |
| 08-Jun-2021 |
Denis Osterland-Heim <Denis.Osterland@diehl.com> |
leds: move default_state read from fwnode to core
This patch introduces a new function to read initial default_state from fwnode.
Suggested-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Denis Oste
leds: move default_state read from fwnode to core
This patch introduces a new function to read initial default_state from fwnode.
Suggested-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
show more ...
|
Revision tags: v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
af0bfab9 |
| 11-Dec-2020 |
Abanoub Sameh <abanoubsameh8@gmail.com> |
leds: led-core: Get rid of enum led_brightness
This gets rid of enum led_brightness in the main led files, because it is deprecated, and an unsigned int can be used instead.
We can get rid of led_b
leds: led-core: Get rid of enum led_brightness
This gets rid of enum led_brightness in the main led files, because it is deprecated, and an unsigned int can be used instead.
We can get rid of led_brightness completely and patches can also be supplied for the other drivers' files.
Signed-off-by: Abanoub Sameh <abanoubsameh@protonmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53 |
|
#
93690cdf |
| 16-Jul-2020 |
Marek Behún <marek.behun@nic.cz> |
leds: trigger: add support for LED-private device triggers
Some LED controllers may come with an internal HW triggering mechanism for the LED and the ability to switch between SW control and the int
leds: trigger: add support for LED-private device triggers
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 <pavel@ucw.cz> and Ondřej Jirman <megous@megous.com>.
Signed-off-by: Marek Behún <marek.behun@nic.cz> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
show more ...
|
Revision tags: v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28 |
|
#
c7e4ea68 |
| 21-Mar-2020 |
Pavel Machek <pavel@ucw.cz> |
leds: old enums are not really applicable to new code
Warn about old defines that probably should not be used.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
Revision tags: v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3 |
|
#
e389240a |
| 03-Oct-2019 |
Jean-Jacques Hiblot <jjhiblot@ti.com> |
leds: Add managed API to get a LED from a device driver
If the LED is acquired by a consumer device with devm_led_get(), it is automatically released when the device is detached.
Signed-off-by: Jea
leds: Add managed API to get a LED from a device driver
If the LED is acquired by a consumer device with devm_led_get(), it is automatically released when the device is detached.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz>
show more ...
|
#
699a8c7c |
| 03-Oct-2019 |
Tomi Valkeinen <tomi.valkeinen@ti.com> |
leds: Add of_led_get() and led_put()
This patch adds basic support for a kernel driver to get a LED device. This will be used by the led-backlight driver.
Only OF version is implemented for now, an
leds: Add of_led_get() and led_put()
This patch adds basic support for a kernel driver to get a LED device. This will be used by the led-backlight driver.
Only OF version is implemented for now, and the behavior is similar to PWM's of_pwm_get() and pwm_put().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz>
show more ...
|
#
9cc93be7 |
| 02-Oct-2019 |
Dan Murphy <dmurphy@ti.com> |
leds: core: Fix leds.h structure documentation
Update the leds.h structure documentation to define the correct arguments.
Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pav
leds: core: Fix leds.h structure documentation
Update the leds.h structure documentation to define the correct arguments.
Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
show more ...
|
#
ec28a8cf |
| 02-Oct-2019 |
Dan Murphy <dmurphy@ti.com> |
leds: core: Remove extern from header
extern is implied and is not needed in the header file. Remove the extern keyword and re-align the code.
Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-
leds: core: Remove extern from header
extern is implied and is not needed in the header file. Remove the extern keyword and re-align the code.
Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
show more ...
|
Revision tags: v5.3.2 |
|
#
11f70002 |
| 29-Sep-2019 |
Akinobu Mita <akinobu.mita@gmail.com> |
leds: remove PAGE_SIZE limit of /sys/class/leds/<led>/trigger
Reading /sys/class/leds/<led>/trigger returns all available LED triggers. However, the size of this file is limited to PAGE_SIZE because
leds: remove PAGE_SIZE limit of /sys/class/leds/<led>/trigger
Reading /sys/class/leds/<led>/trigger returns all available LED triggers. However, the size of this file is limited to PAGE_SIZE because of the limitation for sysfs attribute.
Enabling LED CPU trigger on systems with thousands of CPUs easily hits PAGE_SIZE limit, and makes it impossible to see all available LED triggers and which trigger is currently activated.
We work around it here by converting /sys/class/leds/<led>/trigger to binary attribute, which is not limited by length. This is _not_ good design, do not copy it.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com>A Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
show more ...
|