- 18 Aug, 2023 3 commits
-
-
Marek Behún authored
Do not lock driver mutex in the global LED panel brightness sysfs accessors brightness_show() and brightness_store(). The mutex locking is unnecessary here. The I2C transfers are guarded by I2C core locking mechanism, and the LED commands itself do not interfere with other commands. Fixes: 089381b2 ("leds: initial support for Turris Omnia LEDs") Signed-off-by:
Marek Behún <kabel@kernel.org> Reviewed-by:
Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230802160748.11208-2-kabel@kernel.orgSigned-off-by:
-
Marek Behún authored
Use the dedicated sysfs_emit() function instead of sprintf() in sysfs attribute accessor brightness_show(). Signed-off-by:
-
Ivan Orlov authored
Now that the driver core allows for struct class to be in read-only memory, move the leds_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ivan Orlov <ivan.orlov0322@gmail.com> Link: https://lore.kernel.org/r/20230810174905.7997-1-ivan.orlov0322@gmail.comSigned-off-by:
-
- 17 Aug, 2023 10 commits
-
-
Zhu Wang authored
The driver depends on CONFIG_OF, so it is not necessary to use of_match_ptr() here. We remove both CONFIG_OF and of_match_ptr() here. Signed-off-by:
Zhu Wang <wangzhu9@huawei.com> Link: https://lore.kernel.org/r/20230808111108.24262-1-wangzhu9@huawei.comSigned-off-by:
-
Alexander Stein authored
This is a gpio-controller, so gpio-line-names should be allowed as well. pca9532 supports up to 16 GPIOs. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230724063520.182888-2-alexander.stein@ew.tq-group.comSigned-off-by:
-
Marek Behún authored
The tty LED trigger uses the obsolete LED_ON & LED_OFF constants when setting LED brightness. This is bad because the LED_ON constant is equal to 1, and so when activating the tty LED trigger on a LED class device with max_brightness greater than 1, the LED is dimmer than it can be (when max_brightness is 255, the LED is very dimm indeed; some devices translate 1/255 to 0, so the LED is OFF all the time). Instead of directly setting brightness to a specific value, use the led_blink_set_oneshot() function from LED core to configure the blink. This function takes the current configured brightness as blink brightness if not zero, and max brightness otherwise. This also changes the behavior of the TTY LED trigger. Previously if rx/tx stats kept changing, the LED was ON all the time they kept changing. With this patch the LED will blink on TTY activity. Fixes: fd4a641a ("leds: trigger: implement a tty trigger") Signed-off-by:
-
Krzysztof Kozlowski authored
select:false makes the schema basically ignored (not selected for given compatible), unless some other binding references it. It's not really useful nor needed for device bindings, even if they are part of other binding (like MFD). Signed-off-by:
Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230728171123.110489-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Marek Behún authored
At the time we call BUG_ON(props.color == LED_COLOR_ID_MULTI); the props variable is still initialized to zero. Call the BUG_ON only after we parse fwnode into props. Fixes: 77dce3a2 ("leds: disallow /sys/class/leds/*:multi:* for now") Signed-off-by: -
Marek Behún authored
Given channel intensity, LED brightness and max LED brightness, the multicolor LED framework helper led_mc_calc_color_components() computes the color channel brightness as chan_brightness = brightness * chan_intensity / max_brightness Consider the situation when (brightness, intensity, max_brightness) is for example (16, 15, 255), then chan_brightness is computed to 0 although the fractional divison would give 0.94, which should be rounded to 1. Use DIV_ROUND_CLOSEST here for the division to give more realistic component computation: chan_brightness = DIV_ROUND_CLOSEST(brightness * chan_intensity, max_brightness) Fixes: 55d5d3b4 ("leds: multicolor: Introduce a multicolor class definition") Signed-off-by: -
Jean-Jacques Hiblot authored
Grouping multiple monochrome LEDs into a multicolor LED device has a few benefits over handling the group in user-space: - The state of the LEDs relative to each other is consistent. In other words, if 2 threads competes to set the LED to green and red, the end-result cannot be black or yellow. - The multicolor LED as a whole can be driven through the sysfs LED interface. Signed-off-by:
Jean-Jacques Hiblot <jjhiblot@traphandler.com> Reviewed-by:
-
Jean-Jacques Hiblot authored
This allows to group multiple monochromatic LEDs into a multicolor LED, e.g. RGB LEDs. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230728153731.3742339-4-jjhiblot@traphandler.comSigned-off-by:
-
Jean-Jacques Hiblot authored
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 authored
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:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230728153731.3742339-2-jjhiblot@traphandler.comSigned-off-by:
-
- 15 Aug, 2023 1 commit
-
-
Marek Vasut authored
Fix copy-paste error in MODULE_DEVICE_TABLE() for the OF table, use the 'of' first parameter instead of duplicate 'i2c'. Fixes: ee4e80b2 ("leds: pca995x: Add support for PCA995X chips") Signed-off-by:
Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230809125314.531806-1-marex@denx.deSigned-off-by:
-
- 28 Jul, 2023 20 commits
-
-
Uwe Kleine-König authored
Since commit f9a8ee8c ("pwm: Always allocate PWM chip base ID dynamically") there is no effect any more for assigning this variable. See pwmchip_add() which unconditionally overwrites this member. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230728065739.580281-1-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Fenglin Wu authored
Put the child node if register flash LED device failed. Signed-off-by:
Fenglin Wu <quic_fenglinw@quicinc.com> Link: https://lore.kernel.org/r/20230725-leds-qcom-flash-driver-tiny-fixes-v2-3-0f5cbce5fed0@quicinc.comSigned-off-by:
-
Fenglin Wu authored
Strobe off the LED before setting flash current to avoid it's being enabled with an incorrect current if it has been working in torch mode. Signed-off-by:
-
Fenglin Wu authored
Explain in Kconfig that the driver can be compiled as a module. Signed-off-by:
-
Rob Herring authored
Convert the Panasonic AN30259A 3-channel LED controller binding to DT schema format. Signed-off-by:
-
Christophe JAILLET authored
Use devm_kcalloc() instead of devm_kzalloc()+array_size(). Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/560b8f140c19a7da40f5e9540c3ef312969b0dc4.1690057595.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Rob Herring authored
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by:
-
Rafał Miłecki authored
Symbol ARCH_BCM4908 has been merged/removed without updating leds Kconfig. Fixes: dd5c672d ("arm64: bcmbca: Merge ARCH_BCM4908 to ARCH_BCMBCA") Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Reviewed-by:
William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20230714063214.3791-1-zajec5@gmail.comSigned-off-by:
-
Henning Schild authored
This is used for the Siemens Simatic IPC BX-21A, which has its LEDs connected to GPIOs provided by the Intel Elkhart Lake pinctrl driver. Signed-off-by:
Henning Schild <henning.schild@siemens.com> Link: https://lore.kernel.org/r/20230713115639.16419-3-henning.schild@siemens.comSigned-off-by:
-
Isai Gaspar authored
The PCA995x chips are I2C controlled LED drivers. Each chip has up to 16 outputs, each one with an individual 8-bit resolution PWM for brightness control. Signed-off-by:
Isai Gaspar <isaiezequiel.gaspar@nxp.com> Signed-off-by: Marek Vasut <marex@denx.de> # Basically rewrite the driver Link: https://lore.kernel.org/r/20230713163516.21644-2-marex@denx.deSigned-off-by:
-
Marek Vasut authored
The PCA995x chips are I2C controlled LED drivers. Each chip has up to 16 outputs, each one with an individual 8-bit resolution PWM for brightness control. Add binding document. Signed-off-by:
-
Henning Schild authored
This was found with giving the file to checkpatch. Signed-off-by:
-
Dan Carpenter authored
Negative -EINVAL was intended, not positive EINVAL. Fix it. Fixes: 95138e01 ("leds: pwm: Make error handling more robust") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
-
Marek Vasut authored
Since the chip can drive up to 6 lines, the maximum register number should be only 5, not 6. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Link: https://lore.kernel.org/r/20230704202929.91962-1-marex@denx.deSigned-off-by:
-
Astrid Rost authored
Normally, the maximum brightness is determined by the hardware, and this property is not required. This property is used to set a software limit. It could happen that an LED is made so bright that it gets damaged or causes damage due to restrictions in a specific system, such as mounting conditions. Note that this flag is mainly used for PWM-LEDs, where it is not possible to map brightness to current. Drivers for other controllers should use led-max-microamp. Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Astrid Rost <astrid.rost@axis.com> Acked-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Link: https://lore.kernel.org/r/20230703130313.548519-3-astrid.rost@axis.comSigned-off-by:
-
Astrid Rost authored
Normally, the maximum brightness is determined by the hardware, and this property is not required. This property is used to set a software limit. It could happen that an LED is made so bright that it gets damaged or causes damage due to restrictions in a specific system, such as mounting conditions. Note that this flag is mainly used for PWM-LEDs, where it is not possible to map brightness to current. Drivers for other controllers should use led-max-microamp. Signed-off-by:
-
Yangtao Li authored
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by:
Yangtao Li <frank.li@vivo.com> Link: https://lore.kernel.org/r/20230704094745.25665-1-frank.li@vivo.comSigned-off-by:
-
Uwe Kleine-König authored
struct i2c_driver::probe_new is about to go away. Switch the driver to use the probe callback with the same prototype. Signed-off-by:
-
Arnd Bergmann authored
A recent rework accidentally lost the dependency on LEDS_CLASS, which leads to a link error when LED support is disbled: x86_64-linux-ld: drivers/leds/simple/simatic-ipc-leds.o: in function `simatic_ipc_leds_probe': simatic-ipc-leds.c:(.text+0x10c): undefined reference to `devm_led_classdev_register_ext' Add back the dependency that was there originally. Fixes: a6c80bec ("leds: simatic-ipc-leds-gpio: Add GPIO version of Siemens driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230623152233.2246285-1-arnd@kernel.orgSigned-off-by:
-
Dan Carpenter authored
The "ret" variable is zero/success here. Don't return that, return -EINVAL instead. Fixes: 36a87f37 ("leds: Add AW20xx driver") Signed-off-by:
-
- 14 Jul, 2023 6 commits
-
-
Henning Schild authored
We recently introduced a way to name additional modules to load for each device. Use that instead of wdtmode to load the watchdog module. This patch does not change behaviour, it is just style. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Henning Schild authored
In order to know which hwmon modules to load one would have to usually first probe from user-land i.e. with sensors-detect and create a config for each machine. But here we know exactly what machines we are dealing with, so we can request those howmon modules without user-mode detection and config files. Signed-off-by:
-
Henning Schild authored
This is the panel variant of a device we already did have. All the same, just no LEDs. Signed-off-by:
-
Henning Schild authored
We do not use PCI any longer since commit 446f0cf9 ("platform/x86: simatic-ipc: drop custom P2SB bar code")' Signed-off-by:
-
Henning Schild authored
Siemens Simatic Industrial PCs can monitor the voltage of the CMOS battery with two bits that indicate low or empty state. This can be GPIO or PortIO based. Here we model that as a hwmon voltage. The core driver does the PortIO and provides boilerplate for the GPIO versions. Which are split out to model runtime dependencies while allowing fine-grained kernel configuration. Signed-off-by:
-
Henning Schild authored
The IO region used for the watchdog also hold CMOS battery monitoring information. Make the access muxed so that a hwmon driver can use the region as well. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230706154831.19100-2-henning.schild@siemens.comReviewed-by:
-
