summaryrefslogtreecommitdiffstats
path: root/drivers/leds/leds-mt6323.c
Commit message (Collapse)AuthorAgeFilesLines
* leds: leds-mt6323: Adjust return/parameter types in wled get/set callbacksNathan Chancellor2023-06-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 9bb0a9e0626c ("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>
* leds: leds-mt6323: Add support for WLEDs and MT6332AngeloGioacchino Del Regno2023-06-091-7/+164
| | | | | | | | | | | | 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 <angelogioacchino.delregno@collabora.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230601110813.2373764-9-angelogioacchino.delregno@collabora.com
* leds: leds-mt6323: Add support for MT6331 ledsAngeloGioacchino Del Regno2023-06-091-0/+17
| | | | | | | | | | Add the register offsets for MT6331. The hwspec is the same as MT6323. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230601110813.2373764-8-angelogioacchino.delregno@collabora.com
* leds: leds-mt6323: Open code and drop MT6323_CAL_HW_DUTY macroAngeloGioacchino Del Regno2023-06-091-3/+1
| | | | | | | | | | | | | | 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 <angelogioacchino.delregno@collabora.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230601110813.2373764-7-angelogioacchino.delregno@collabora.com
* leds: leds-mt6323: Drop MT6323_ prefix from macros and definesAngeloGioacchino Del Regno2023-06-091-63/+60
| | | | | | | | | | | | | | 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 <angelogioacchino.delregno@collabora.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230601110813.2373764-6-angelogioacchino.delregno@collabora.com
* leds: leds-mt6323: Specify registers and specs in platform dataAngeloGioacchino Del Regno2023-06-091-38/+115
| | | | | | | | | | | | | | | 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 <angelogioacchino.delregno@collabora.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230601110813.2373764-5-angelogioacchino.delregno@collabora.com
* leds: mt6323: Get rid of custom led_init_default_state_get()Andy Shevchenko2023-01-301-15/+15
| | | | | | | | | | LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230103131256.33894-7-andriy.shevchenko@linux.intel.com
* leds: parse linux,default-trigger DT property in LED coreMarek Behún2020-09-261-4/+0
| | | | | | | | | | | | | | | | | | | | Do the parsing of `linux,default-trigger` DT property to LED core. Currently it is done in many different drivers and the code is repeated. This patch removes the parsing from 23 drivers: an30259a, aw2013, bcm6328, bcm6358, cr0014114, el15203000, gpio, is31fl32xx, lm3532, lm36274, lm3692x, lm3697, lp50xx, lp8860, lt3593, max77650, mt6323, ns2, pm8058, pwm, syscon, tlc591xx and turris-omnia. There is one driver in drivers/input which parses this property on it's own. I shall send a separate patch there after this is applied. There are still 8 drivers that parse this property on their own because they do not pass the led_init_data structure to the registering function. I will try to refactor those in the future. Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: mt6323: cosmetic change: use helper variableMarek Behún2020-09-261-4/+3
| | | | | | | | | | Use helper variable dev instead of always writing &pdev->dev. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Sean Wang <sean.wang@mediatek.com> Cc: John Crispin <john@phrozen.org> Cc: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: mt6323: use struct led_init_data when registeringMarek Behún2020-09-261-3/+6
| | | | | | | | | | | | | | | | By using struct led_init_data when registering we do not need to parse `label` DT property. Moreover `label` is deprecated and if it is not present but `color` and `function` are, LED core will compose a name from these properties instead. Since init_data is passed with fwnode handle, we do not need to set the of_node member of the newly created LED classdev. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Sean Wang <sean.wang@mediatek.com> Cc: John Crispin <john@phrozen.org> Cc: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: various: use dev_of_node(dev) instead of dev->of_nodeMarek Behún2020-09-261-1/+1
| | | | | | | | | | | | | The dev_of_node function should be preferred. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Baolin Wang <baolin.wang7@gmail.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Cc: Sean Wang <sean.wang@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Riku Voipio <riku.voipio@iki.fi> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: mt6323: move period calculationTom Rix2020-08-171-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | clang static analysis reports this problem leds-mt6323.c:275:12: warning: Division by zero duty_hw = MT6323_CAL_HW_DUTY(*delay_on, period); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is because period can be 0. period = *delay_on + *delay_off; There is a later check that *delay_on/off are valid. if (!*delay_on && !*delay_off) { *delay_on = 500; *delay_off = 500; } Setting the delay_on/off means period needs to be recalculated anyway. So move the period statements after this check. Fixes: 216ec6cc4c19 ("leds: Add LED support for MT6323 PMIC") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157Thomas Gleixner2019-05-301-10/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on 3 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1105 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* leds: mt6323: Fix an off by one bug in probeDan Carpenter2017-03-231-1/+1
| | | | | | | | | | It should be ">= MT6323_MAX_LEDS" instead of ">". Also "reg" is a u32 so it can't be negative and we can remove the test for negative values. Fixes: 216ec6cc4c19 ("leds: Add LED support for MT6323 PMIC") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* leds: Add LED support for MT6323 PMICSean Wang2017-03-211-0/+502
MT6323 PMIC is a multi-function device that includes LED function. It allows attaching up to 4 LEDs which can either be on, off or dimmed and/or blinked with the controller. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>