summaryrefslogtreecommitdiffstats
path: root/drivers/leds
Commit message (Collapse)AuthorAgeFilesLines
...
| * leds: flash: mt6370: Add MediaTek MT6370 flashlight supportChiYuan Huang2023-03-233-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 <alice_chen@richtek.com> Signed-off-by: Alice Chen <alice_chen@richtek.com> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/52480420a160e5a4c71715fbbf105e684a16e7c2.1678430444.git.chiaen_wu@richtek.com
| * leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator supportChiYuan Huang2023-03-233-0/+1024
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 MediaTek MT6370 Current Sink Type LED Indicator driver. It can control four channels current-sink RGB LEDs with 3 modes: constant current, PWM, and breath mode. Co-developed-by: Alice Chen <alice_chen@richtek.com> Signed-off-by: Alice Chen <alice_chen@richtek.com> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/1df93a583c3f508a7158b83b95857e9bce235e1b.1678430444.git.chiaen_wu@richtek.com
| * leds: flash: Add driver to support flash LED module in QCOM PMICsFenglin Wu2023-03-163-0/+789
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add initial driver to support flash LED module found in Qualcomm Technologies, Inc. PMICs. The flash module can have 3 or 4 channels and each channel can be controlled indepedently and support full scale current up to 1.5 A. It also supports connecting two channels together to supply one LED component with full scale current up to 2 A. In that case, the current will be split on each channel symmetrically and the channels will be enabled and disabled at the same time. Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # sm7225-fairphone-fp4 + pm6150l Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230303095023.538917-2-quic_fenglinw@quicinc.com
| * leds: Mark GPIO LED trigger brokenLinus Walleij2023-03-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GPIO LED trigger exposes a userspace ABI where a user can echo a GPIO number from the global GPIO numberspace into a file that will trigger a certain LED when active. This is problematic because the global GPIO numberspace is inherently instable. The trigger came about at a time when systems had one GPIO controller that defined hard-wired GPIOs numbered 0..N and this number space was stable. We have since moved to dynamic allocation of GPIO numbers and there is no real guarantee that a GPIO number will stay consistent even across a reboot: consider a USB attached GPIO controller for example. Or two. Or the effect of probe order after adding -EPROBE_DEFER to the kernel. The trigger was added to support keypad LEDs on the Nokia n810 from the GPIO event when a user slides up/down the keypad. This is arch/arm/boot/dts/omap2420-n810.dts. A userspace script is needed to activate the trigger. This will be broken unless the script was updated recently since the OMAP GPIO controller now uses dynamic GPIO number allocations. I want to know that this trigger has active users that cannot live without it if we are to continue to support it. Option if this is really needed: I can develop a new trigger that can associate GPIOs with LEDs as triggers using device tree, which should also remove the use of userspace custom scripts to achieve this and be much more trustworthy, if someone with the Nokia n810 or a device with a similar need is willing to test it. Suggested-by Pavel Machek <pavel@ucw.cz> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230314210059.419159-1-linus.walleij@linaro.org
| * leds: tlc591xx: Mark OF related data as maybe unusedKrzysztof Kozlowski2023-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/leds/leds-tlc591xx.c:138:34: error: ‘of_tlc591xx_leds_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230311111717.252019-1-krzysztof.kozlowski@linaro.org
| * leds: lp8860: Remove duplicate NULL checks for gpio_descAndy Shevchenko2023-03-161-6/+3
| | | | | | | | | | | | | | | | | | gpiod_*() API check already for the NULL, no need to repeat that in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230215170403.84449-2-andriy.shevchenko@linux.intel.com
| * leds: lp8860: Remove unused of_gpio,hAndy Shevchenko2023-03-161-1/+0
| | | | | | | | | | | | | | | | | | of_gpio.h provides a single function, which is not used in this driver. Remove unused header. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230215170403.84449-1-andriy.shevchenko@linux.intel.com
| * leds: TI_LMU_COMMON: select REGMAP instead of depending on itRandy Dunlap2023-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on REGMAP" to "select REGMAP". Fixes: 3fce8e1eb994 ("leds: TI LMU: Add common code for TI LMU devices") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230226053953.4681-5-rdunlap@infradead.org
* | driver core: class: remove module * from class_create()Greg Kroah-Hartman2023-03-171-1/+1
|/ | | | | | | | | | | | The module pointer in class_create() never actually did anything, and it shouldn't have been requred to be set as a parameter even if it did something. So just remove it and fix up all callers of the function in the kernel tree at the same time. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'leds-next-6.3' of ↵Linus Torvalds2023-02-2338-429/+171
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds Pull LED updates from Lee Jones: "Removed Drivers: - HTC ASIC3 LED New Functionality: - Provide generic led_get() which can be used by both DT and !DT platforms Fix-ups: - Convert a bunch of I2C subsystem users to the new probing API - Explicitly provide missing include files - Make use of led_init_default_state_get() and rid the custom variants - Use simplified fwnode_device_is_compatible() API - Provide some Device Tree additions / adaptions - Fix some trivial spelling issues Bug Fixes: - Prevent device refcount leak during led_put() and of_led_get() - Clear previous data from temporary led_pwm structure before processing next child - Fix Clang's warning about incompatible function types when using devm_add_action*()" * tag 'leds-next-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (41 commits) leds: Remove ide-disk trigger dt-bindings: leds: Add disk write/read and usb-host/usb-gadget Documentation: leds: Correct spelling dt-bindings: leds: Document Bluetooth and WLAN triggers leds: Remove asic3 driver leds: simatic-ipc-leds-gpio: Make sure we have the GPIO providing driver leds: tca6507: Convert to use fwnode_device_is_compatible() leds: syscon: Get rid of custom led_init_default_state_get() leds: pm8058: Get rid of custom led_init_default_state_get() leds: pca955x: Get rid of custom led_init_default_state_get() leds: mt6360: Get rid of custom led_init_default_state_get() leds: mt6323: Get rid of custom led_init_default_state_get() leds: bcm6358: Get rid of custom led_init_default_state_get() leds: bcm6328: Get rid of custom led_init_default_state_get() leds: an30259a: Get rid of custom led_init_default_state_get() leds: Move led_init_default_state_get() to the global header leds: Add missing includes and forward declarations in leds.h leds: is31fl319x: Wrap mutex_destroy() for devm_add_action_or_rest() leds: turris-omnia: Convert to i2c's .probe_new() leds: tlc591xx: Convert to i2c's .probe_new() ...
| * leds: Remove ide-disk triggerCorentin Labbe2023-02-041-4/+0
| | | | | | | | | | | | | | | | | | | | | | No user of ide-disk remains, so remove this deprecated trigger. Only a few platforms used this and were fixed in 2016. Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230131140304.626779-2-clabbe@baylibre.com
| * leds: Remove asic3 driverArnd Bergmann2023-01-303-189/+0
| | | | | | | | | | | | | | | | | | Since ASIC3 MFD driver is removed, the LED support is also obsolete. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230105134622.254560-25-arnd@kernel.org
| * leds: simatic-ipc-leds-gpio: Make sure we have the GPIO providing driverHenning Schild2023-01-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we register a "leds-gpio" platform device for GPIO pins that do not exist we get a -EPROBE_DEFER and the probe will be tried again later. If there is no driver to provide that pin we will poll forever and also create a lot of log messages. So check if that GPIO driver is configured, if so it will come up eventually. If not, we exit our probe function early and do not even bother registering the "leds-gpio". This method was chosen over "Kconfig depends" since this way we can add support for more devices and GPIO backends more easily without "depends":ing on all GPIO backends. Fixes: a6c80bec3c93 ("leds: simatic-ipc-leds-gpio: Add GPIO version of Siemens driver") Signed-off-by: Henning Schild <henning.schild@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221007153323.1326-1-henning.schild@siemens.com
| * leds: tca6507: Convert to use fwnode_device_is_compatible()Andy Shevchenko2023-01-301-2/+1
| | | | | | | | | | | | | | | | Replace open coded fwnode_device_is_compatible() in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230119175150.77250-1-andriy.shevchenko@linux.intel.com
| * leds: syscon: Get rid of custom led_init_default_state_get()Andy Shevchenko2023-01-301-26/+23
| | | | | | | | | | | | | | | | | | 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> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230103131256.33894-11-andriy.shevchenko@linux.intel.com
| * leds: pm8058: Get rid of custom led_init_default_state_get()Andy Shevchenko2023-01-301-14/+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> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230103131256.33894-10-andriy.shevchenko@linux.intel.com
| * leds: pca955x: Get rid of custom led_init_default_state_get()Andy Shevchenko2023-01-301-20/+6
| | | | | | | | | | | | | | | | | | 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> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230103131256.33894-9-andriy.shevchenko@linux.intel.com
| * leds: mt6360: Get rid of custom led_init_default_state_get()Andy Shevchenko2023-01-301-32/+6
| | | | | | | | | | | | | | | | | | | | | | 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: Matthias Brugger <matthias.bgg@gmail.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-8-andriy.shevchenko@linux.intel.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: bcm6358: Get rid of custom led_init_default_state_get()Andy Shevchenko2023-01-301-16/+16
| | | | | | | | | | | | | | | | | | | | 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: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230103131256.33894-6-andriy.shevchenko@linux.intel.com
| * leds: bcm6328: Get rid of custom led_init_default_state_get()Andy Shevchenko2023-01-301-25/+24
| | | | | | | | | | | | | | | | | | | | 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: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230103131256.33894-5-andriy.shevchenko@linux.intel.com
| * leds: an30259a: Get rid of custom led_init_default_state_get()Andy Shevchenko2023-01-301-17/+4
| | | | | | | | | | | | | | | | | | 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> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230103131256.33894-4-andriy.shevchenko@linux.intel.com
| * leds: Move led_init_default_state_get() to the global headerAndy Shevchenko2023-01-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | 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
| * leds: is31fl319x: Wrap mutex_destroy() for devm_add_action_or_rest()Andy Shevchenko2023-01-301-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang complains that devm_add_action() takes a parameter with a wrong type: warning: cast from 'void (*)(struct mutex *)' to 'void (*)(void *)' converts to incompatible function type [-Wcast-function-type-strict] err = devm_add_action(dev, (void (*)(void *))mutex_destroy, &is31->lock); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. It appears that the commit e1af5c815586 ("leds: is31fl319x: Fix devm vs. non-devm ordering") missed two things: - whilst the commit mentions devm_add_action_or_reset() the actual change utilised devm_add_action() call by mistake - strictly speaking the parameter is not compatible by type Fix both issues by switching to devm_add_action_or_reset() and adding a wrapper for mutex_destroy() call. Reported-by: kernel test robot <lkp@intel.com> Fixes: e1af5c815586 ("leds: is31fl319x: Fix devm vs. non-devm ordering") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221228093238.82713-1-andriy.shevchenko@linux.intel.com
| * leds: turris-omnia: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-289-uwe@kleine-koenig.org
| * leds: tlc591xx: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-288-uwe@kleine-koenig.org
| * leds: tca6507: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-287-uwe@kleine-koenig.org
| * leds: pca963x: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | | | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-286-uwe@kleine-koenig.org
| * leds: pca9532: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-5/+4
| | | | | | | | | | | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-285-uwe@kleine-koenig.org
| * leds: lp8860: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-284-uwe@kleine-koenig.org
| * leds: lp8501: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | | | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-283-uwe@kleine-koenig.org
| * leds: lp5562: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-282-uwe@kleine-koenig.org
| * leds: lp5523: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | | | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-281-uwe@kleine-koenig.org
| * leds: lp5521: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | | | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-280-uwe@kleine-koenig.org
| * leds: lp3952: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-279-uwe@kleine-koenig.org
| * leds: lp3944: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-278-uwe@kleine-koenig.org
| * leds: lm3697: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-277-uwe@kleine-koenig.org
| * leds: lm3692x: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | | | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-276-uwe@kleine-koenig.org
| * leds: lm3642: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-275-uwe@kleine-koenig.org
| * leds: lm355x: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+3
| | | | | | | | | | | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-274-uwe@kleine-koenig.org
| * leds: lm3532: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-273-uwe@kleine-koenig.org
| * leds: lm3530: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-272-uwe@kleine-koenig.org
| * leds: is31fl32xx: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-271-uwe@kleine-koenig.org
| * leds: blinkm: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-270-uwe@kleine-koenig.org
| * leds: bd2802: Convert to i2c's .probe_new()Uwe Kleine-König2023-01-301-3/+2
| | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-269-uwe@kleine-koenig.org
| * leds: led-core: Fix refcount leak in of_led_get()Miaoqian Lin2023-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | class_find_device_by_of_node() calls class_find_device(), it will take the reference, use the put_device() to drop the reference when not need anymore. Fixes: 699a8c7c4bd3 ("leds: Add of_led_get() and led_put()") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221220121807.1543790-1-linmq006@gmail.com
| * leds: pwm: Clear the led structure before parsing each child nodeHui Wang2023-01-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I defined 2 leds in the device tree, in the 1st led node, the max-brightness is set to 248, while in the 2nd led node, I mis-spelled the max-brightness to max-brighttness, but the driver is still able to get the max-brightness 248 for the 2nd node, that is because the led structure is not cleared before parsing each child node. pwmleds { compatible = "pwm-leds"; pwm-green { ... max-brightness = <248>; }; pwm-red { ... max-brighttness = <128>; }; Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221220073335.393489-1-hui.wang@canonical.com
* | Merge tag 'platform-drivers-x86-v6.3-1' of ↵Linus Torvalds2023-02-211-20/+118
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver updates from Hans de Goede: - AMD PMC: Improvements to aid s2idle debugging - Dell WMI-DDV: hwmon support - INT3472 camera sensor power-management: Improve privacy LED support - Intel VSEC: Base TPMI (Topology Aware Register and PM Capsule Interface) support - Mellanox: SN5600 and Nvidia L1 switch support - Microsoft Surface Support: Various cleanups + code improvements - tools/intel-speed-select: Various improvements - Miscellaneous other cleanups / fixes * tag 'platform-drivers-x86-v6.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (80 commits) platform/x86: nvidia-wmi-ec-backlight: Add force module parameter platform/x86/amd/pmf: Add depends on CONFIG_POWER_SUPPLY platform/x86: dell-ddv: Prefer asynchronous probing platform/x86: dell-ddv: Add hwmon support Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces platform: mellanox: mlx-platform: Move bus shift assignment out of the loop platform: mellanox: mlx-platform: Add mux selection register to regmap platform_data/mlxreg: Add field with mapped resource address platform/mellanox: mlxreg-hotplug: Allow more flexible hotplug events configuration platform: mellanox: Extend all systems with I2C notification callback platform: mellanox: Split logic in init and exit flow platform: mellanox: Split initialization procedure platform: mellanox: Introduce support of new Nvidia L1 switch platform: mellanox: Introduce support for next-generation 800GB/s switch platform: mellanox: Cosmetic changes - rename to more common name platform: mellanox: Change "reset_pwr_converter_fail" attribute platform: mellanox: Introduce support for rack manager switch MAINTAINERS: dell-wmi-sysman: drop Divya Bharathi x86/platform/uv: Make kobj_type structure constant platform/x86: think-lmi: Make kobj_type structure constant ...
| * leds: led-class: Add generic [devm_]led_get()Hans de Goede2023-01-271-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * leds: led-class: Add __devm_led_get() helperHans de Goede2023-01-271-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a __devm_led_get() helper which registers a passed in led_classdev with devm for unregistration. This is a preparation patch for adding a generic (non devicetree specific) devm_led_get() function. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> 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-4-hdegoede@redhat.com