- 23 Jun, 2023 1 commit
-
-
Nathan Chancellor authored
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: 9bb0a9e0 ("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.orgSigned-off-by:
Lee Jones <lee@kernel.org>
-
- 21 Jun, 2023 3 commits
-
-
Raymond Hackley authored
Richtek's rt5033-led has pin configurations similar to sgm3140. Add it to the compatible list. Signed-off-by:
Raymond Hackley <raymondhackley@protonmail.com> Link: https://lore.kernel.org/r/20230602131024.260297-1-raymondhackley@protonmail.comSigned-off-by:
-
Raymond Hackley authored
Add devicetree binding for Richtek RT5033 Flash LED charge pump used for camera flash LEDs. Signed-off-by:
-
Rob Herring authored
"current-num-sinks" is missing a type, add it. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230613201022.2823392-1-robh@kernel.orgSigned-off-by:
-
- 15 Jun, 2023 2 commits
-
-
Krzysztof Kozlowski authored
Cleanup bindings dropping unneeded quotes. Once all these are fixed, checking for this can be enabled in yamllint. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230609140725.64771-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Lukas Bulwahn authored
Commit 36a87f37 ("leds: Add AW20xx driver") adds config LEDS_AW200XX in drivers/leds/Kconfig, but then in drivers/leds/Makefile accidently refers to CONFIG_LEDS_W200XX; note the missing A! This typo makes it impossible to add the driver to a kernel build. Fix this wrong config reference. Fixes: 36a87f37 ("leds: Add AW20xx driver") Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20230609100233.4111-1-lukas.bulwahn@gmail.comSigned-off-by:
-
- 09 Jun, 2023 7 commits
-
-
AngeloGioacchino Del Regno authored
Add basic code to turn on and off WLEDs and wire up MT6332 support to take advantage of it. This is a simple approach due to the aforementioned PMIC supporting only on/off status so, at the time of writing, it is impossible for me to validate more advanced functionality due to lack of hardware. Signed-off-by:
-
AngeloGioacchino Del Regno authored
Add the register offsets for MT6331. The hwspec is the same as MT6323. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Reviewed-by:
Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by:
-
AngeloGioacchino Del Regno authored
There is only one instance of using this macro and it's anyway not simplifying the flow, or increasing the readability of this driver. Drop this macro by open coding it in mt6323_led_set_blink(). No functional changes. Signed-off-by:
-
AngeloGioacchino Del Regno authored
This renames all definitions and macros to drop the MT6323_ prefix, since it is now possible to easily add support to more PMICs in this driver. While at it, also fix related formatting where possible. This commit brings no functional changes. Signed-off-by:
-
AngeloGioacchino Del Regno authored
In order to enhance the flexibility of this driver and let it support more than just one MediaTek LEDs IP for more than just one PMIC, add platform data structure specifying the register offsets and data that commonly varies between different IPs. This commit brings no functional changes. Signed-off-by:
-
AngeloGioacchino Del Regno authored
Add support for MT6332 LEDs/WLEDs with compatible "mediatek,mt6332-led". Signed-off-by:
-
AngeloGioacchino Del Regno authored
Add mediatek,mt6331-led compatible for the LED controller found in the MT6331 PMIC. Signed-off-by:
-
- 08 Jun, 2023 8 commits
-
-
Henning Schild authored
To describe the dependency chain better and allow for potential fine-grained config tuning, introduce Kconfig switch for the individual GPIO based drivers. Signed-off-by:
Henning Schild <henning.schild@siemens.com> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Henning Schild authored
In order to clearly describe the dependencies between the GPIO controller drivers and the users the driver is split up into a core, two drivers and a common header. Signed-off-by:
-
Henning Schild authored
There are two special pins needed to init the LEDs. We used to have them at the end of the gpiod_lookup table to give to "leds-gpio". A cleaner way is to have a dedicated table for the special pins. Signed-off-by:
-
Henning Schild authored
The entries do not seem to be stricly needed when the number of entries is given via the number of LEDs. But adding them is a safeguard should anyone ever iterate over the tables to their end, it also gets us in line with other drivers that register "leds-gpio" tables. Reported-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Jiapeng Chong authored
The variable 'count' is defined as unsigned type, so the following if statement is invalid, we can modify the type of count to int. if (count <= 0) { dev_err(dev, "No led-sources specified\n"); return -ENODEV; } ./drivers/leds/flash/leds-qcom-flash.c:546:5-10: WARNING: Unsigned expression compared with zero: count <= 0. Reported-by:Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5344Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
Jiapeng Chong authored
No functional modification involved. ./drivers/leds/leds-cht-wcove.c:193:2-3: Unneeded semicolon. Reported-by:
-
Yang Li authored
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:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Hans de Goede authored
cht_wc_leds_brightness_get() is only used internally, mark it static. Cc: Yauhen Kharuzhy <jekhor@gmail.com> Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202305260008.QCRrKILf-lkp@intel.com/Signed-off-by:
-
- 01 Jun, 2023 2 commits
-
-
Martin Kurbanov authored
Add YAML devicetree binding for AWINIC AW20036/AW20052/AW20074 led driver. Signed-off-by:
Martin Kurbanov <mmkurbanov@sberdevices.ru> Reviewed-by:
-
Martin Kurbanov authored
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:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230519130403.212479-3-mmkurbanov@sberdevices.ruSigned-off-by:
-
- 25 May, 2023 17 commits
-
-
Lu Hongfei authored
Ensure child node references are decremented properly in the error path. Signed-off-by:
Lu Hongfei <luhongfei@vivo.com> Link: https://lore.kernel.org/r/20230525111705.3055-1-luhongfei@vivo.comSigned-off-by:
-
Neil Armstrong authored
The PM8550 PWM modules are compatible with the PM8350c PWM modules, document the PM8350c PWM compatible as fallback for the PM8550 PWM. Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
-
Dylan Van Assche authored
Document compatible for PMI8998 Torch and Flash LED controller. Signed-off-by:
Dylan Van Assche <me@dylanvanassche.be> Acked-by:
-
Luca Weiss authored
The path /sys/class/leds/rgb:status is already widely used with the qcom-lpg driver and others. Document it. Signed-off-by:
Luca Weiss <luca@z3ntu.xyz> Link: https://lore.kernel.org/r/20230414-pmi632-v3-3-079d2cada699@z3ntu.xyzSigned-off-by:
-
Krzysztof Kozlowski authored
Document compatible for PM8550 Torch and Flash LED controller. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230516150202.188655-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Azeem Shaikh authored
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/89Signed-off-by:
Azeem Shaikh <azeemshaikh38@gmail.com> Link: https://lore.kernel.org/r/20230524144824.2360607-1-azeemshaikh38@gmail.comSigned-off-by:
-
Marek Vasut authored
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 <cniedermaier@dh-electronics.com> Signed-off-by:
Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230523183151.5460-1-marex@denx.deSigned-off-by:
-
Azeem Shaikh authored
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/89Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230523021451.2406362-1-azeemshaikh38@gmail.comSigned-off-by:
-
Azeem Shaikh authored
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/89Signed-off-by:
-
Niklas Schnelle authored
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 <arnd@kernel.org> Signed-off-by:
Niklas Schnelle <schnelle@linux.ibm.com> Acked-by:
-
Yang Li authored
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: -
Hans de Goede authored
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:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Tested-by:
Yauhen Kharuzhy <jekhor@gmail.com> Link: https://lore.kernel.org/r/20230510162234.291439-5-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
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 authored
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 authored
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:
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.comSigned-off-by:
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f4 ("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 <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230517180559.166329-1-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Geert Uytterhoeven authored
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:
-
