Pull LED updates from Lee Jones:
"New Drivers:
- Add support for Intel Cherry Trail Whiskey Cove PMIC LEDs
- Add support for Awinic AW20036/AW20054/AW20072 LEDs
New Device Support:
- Add support for PMI632 LPG to QCom LPG
- Add support for PMI8998 to QCom Flash
- Add support for MT6331, WLEDs and MT6332 to Mediatek MT6323 PMIC
New Functionality:
- Implement the LP55xx Charge Pump
- Add support for suspend / resume to Intel Cherry Trail Whiskey Cove PMIC
- Add support for breathing mode to Intel Cherry Trail Whiskey Cove PMIC
- Enable per-pin resolution Pinctrl in LEDs GPIO
Fix-ups:
- Allow thread to sleep by switching from spinlock to mutex
- Add lots of Device Tree bindings / support
- Adapt relationships / dependencies driven by Kconfig
- Switch I2C drivers from .probe_new() to .probe()
- Remove superfluous / duplicate code
- Replace strlcpy() with strscpy() for efficiency and overflow prevention
- Staticify various functions
- Trivial: Fixing coding style
- Simplify / reduce code
Bug Fixes:
- Prevent NETDEV_LED_MODE_LINKUP from being cleared on rename
- Repair race between led_set_brightness(LED_{OFF,FULL})
- Fix Oops relating to sleeping in critical sections
- Clear LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger
- Do not leak resources in error handling paths
- Fix unsigned comparison which can never be negative
- Provide missing NULL terminating entries in tables
- Fix misnaming issues"
* tag 'leds-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (53 commits)
leds: leds-mt6323: Adjust return/parameter types in wled get/set callbacks
leds: sgm3140: Add richtek,rt5033-led compatible
dt-bindings: leds: sgm3140: Document richtek,rt5033 compatible
dt-bindings: backlight: kinetic,ktz8866: Add missing type for "current-num-sinks"
dt-bindings: leds: Drop unneeded quotes
leds: Fix config reference for AW200xx driver
leds: leds-mt6323: Add support for WLEDs and MT6332
leds: leds-mt6323: Add support for MT6331 leds
leds: leds-mt6323: Open code and drop MT6323_CAL_HW_DUTY macro
leds: leds-mt6323: Drop MT6323_ prefix from macros and defines
leds: leds-mt6323: Specify registers and specs in platform data
dt-bindings: leds: leds-mt6323: Document mt6332 compatible
dt-bindings: leds: leds-mt6323: Document mt6331 compatible
leds: simatic-ipc-leds-gpio: Introduce more Kconfig switches
leds: simatic-ipc-leds-gpio: Split up into multiple drivers
leds: simatic-ipc-leds-gpio: Move two extra gpio pins into another table
leds: simatic-ipc-leds-gpio: Add terminating entries to gpio tables
leds: flash: leds-qcom-flash: Fix an unsigned comparison which can never be negative
leds: cht-wcove: Remove unneeded semicolon
leds: cht-wcove: Fix an unsigned comparison which can never be negative
...
Clang's kernel Control Flow Integrity (kCFI) is a compiler-based
security mitigation that ensures the target of an indirect function call
matches the expected type of the call and trapping if they do not match
exactly. The warning -Wincompatible-function-pointer-types-strict aims
to catch these issues at compile time, which reveals:
drivers/leds/leds-mt6323.c:598:49: error: incompatible function pointer types assigning to 'int (*)(struct led_classdev *, enum led_brightness)' from 'int (struct led_classdev *, unsigned int)' [-Werror,-Wincompatible-function-pointer-types-strict]
598 | leds->led[reg]->cdev.brightness_set_blocking =
| ^
599 | mt6323_wled_set_brightness;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/leds/leds-mt6323.c:600:40: error: incompatible function pointer types assigning to 'enum led_brightness (*)(struct led_classdev *)' from 'unsigned int (struct led_classdev *)' [-Werror,-Wincompatible-function-pointer-types-strict]
600 | leds->led[reg]->cdev.brightness_get =
| ^
601 | mt6323_get_wled_brightness;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
While 'unsigned int' is ABI compatible with 'enum led_brightness' (hence
no warning from -Wincompatible-function-pointer-types) and the callers
of these callbacks use/pass the values as 'unsigned int', the mismatch
between the prototype and the called function will trip kCFI at runtime.
Change the types in the implementations to match the prototypes, clearing
up the warning and avoiding kCFI failures.
Fixes: 9bb0a9e062 ("leds: leds-mt6323: Add support for WLEDs and MT6332")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230622-mt6323-wled-wincompatible-function-pointer-types-strict-v1-1-6ad256f220e8@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
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>
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>
The qca8k_cled_hw_control_get() function which implements ->hw_control_get
sets the appropriate bits but does not clear them. This leads to an
uninitialized variable bug. Fix this by setting mode to zero at the
start.
Fixes: e0256648c8 ("net: dsa: qca8k: implement hw_control ops")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cross-merge networking fixes after downstream PR.
Conflicts:
net/sched/sch_taprio.c
d636fc5dd6 ("net: sched: add rcu annotations around qdisc->qdisc_sleeping")
dced11ef84 ("net/sched: taprio: don't overwrite "sch" variable in taprio_dump_class_stats()")
net/ipv4/sysctl_net_ipv4.c
e209fee411 ("net/ipv4: ping_group_range: allow GID from 2147483648 to 4294967294")
ccce324dab ("tcp: make the first N SYN RTO backoffs linear")
https://lore.kernel.org/all/20230605100816.08d41a7b@canb.auug.org.au/
No adjacent changes.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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: b00d2ed376 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM")
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Acked-by: Lee Jones <lee@kernel.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Link: https://lore.kernel.org/r/20230515162604.649203-1-quic_bjorande@quicinc.com
Signed-off-by: Johan Hovold <johan@kernel.org>
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>
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 <andrew@lunn.ch>
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>
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 <andrew@lunn.ch>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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 <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
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 <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
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 <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
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 <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Move the code into a helper, ready for it to be called at
other times. No intended behaviour change.
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>
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 <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-5-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
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>
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>
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>
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 <geert+renesas@glider.be>
Acked-by: Pavel Machek <pavel@ucw.cz>
Link: https://lore.kernel.org/r/91f6efaa48c36320e58b6a312025ae9b39ee206b.1683644796.git.geert+renesas@glider.be
Signed-off-by: Lee Jones <lee@kernel.org>
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 <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230430195952.862527-6-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
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 <jacek.anaszewski@gmail.com>
Link: https://lore.kernel.org/all/6beed61c-1fc6-6525-e873-a8978f5fbffb@gmail.com/
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230430195952.862527-4-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
