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: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

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: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230802090753.13611-1-kabel@kernel.orgSigned-off-by: Lee Jones <lee@kernel.org>

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: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-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: Lee Jones <lee@kernel.org>

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 <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230801151623.30387-1-kabel@kernel.orgSigned-off-by: Lee Jones <lee@kernel.org>

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: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230801124931.8661-1-kabel@kernel.orgSigned-off-by: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230728153731.3742339-5-jjhiblot@traphandler.comSigned-off-by: Lee Jones <lee@kernel.org>

This allows to group multiple monochromatic LEDs into a multicolor
LED, e.g. RGB LEDs.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230728153731.3742339-4-jjhiblot@traphandler.comSigned-off-by: Lee Jones <lee@kernel.org>

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 <jjhiblot@traphandler.com>
Link: https://lore.kernel.org/r/20230728153731.3742339-3-jjhiblot@traphandler.comSigned-off-by: Lee Jones <lee@kernel.org>

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: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20230728153731.3742339-2-jjhiblot@traphandler.comSigned-off-by: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

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 <quic_fenglinw@quicinc.com>
Link: https://lore.kernel.org/r/20230725-leds-qcom-flash-driver-tiny-fixes-v2-2-0f5cbce5fed0@quicinc.comSigned-off-by: Lee Jones <lee@kernel.org>

Explain in Kconfig that the driver can be compiled as a module.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
Link: https://lore.kernel.org/r/20230725-leds-qcom-flash-driver-tiny-fixes-v2-1-0f5cbce5fed0@quicinc.comSigned-off-by: Lee Jones <lee@kernel.org>

Convert the Panasonic AN30259A 3-channel LED controller binding to DT
schema format.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230724230258.1017258-1-robh@kernel.orgSigned-off-by: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

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: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230714174651.4058753-1-robh@kernel.orgSigned-off-by: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

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: Marek Vasut <marex@denx.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230713163516.21644-1-marex@denx.deSigned-off-by: Lee Jones <lee@kernel.org>

This was found with giving the file to checkpatch.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20230706161040.21152-3-henning.schild@siemens.comSigned-off-by: Lee Jones <lee@kernel.org>

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: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/a33b981a-b2c4-4dc2-b00a-626a090d2f11@moroto.mountainSigned-off-by: Lee Jones <lee@kernel.org>

Since the chip can drive up to 6 lines, the maximum
register number should be only 5, not 6.
Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://lore.kernel.org/r/20230704202929.91962-1-marex@denx.deSigned-off-by: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

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: Astrid Rost <astrid.rost@axis.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Link: https://lore.kernel.org/r/20230703130313.548519-2-astrid.rost@axis.comSigned-off-by: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230626090254.556206-1-u.kleine-koenig@pengutronix.deSigned-off-by: Lee Jones <lee@kernel.org>

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: Lee Jones <lee@kernel.org>

The "ret" variable is zero/success here.  Don't return that, return
-EINVAL instead.

Fixes: 36a87f37 ("leds: Add AW20xx driver")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/4d791b69-01c7-4532-818c-63712d3f63e1@moroto.mountainSigned-off-by: Lee Jones <lee@kernel.org>

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: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20230713144832.26473-4-henning.schild@siemens.comReviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

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 <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20230713144832.26473-3-henning.schild@siemens.comReviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

This is the panel variant of a device we already did have. All the same,
just no LEDs.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20230713144832.26473-2-henning.schild@siemens.comReviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

We do not use PCI any longer since
commit 446f0cf9 ("platform/x86: simatic-ipc: drop custom P2SB bar code")'
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20230706161040.21152-2-henning.schild@siemens.comReviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

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 <henning.schild@siemens.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230706154831.19100-3-henning.schild@siemens.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>

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: Henning Schild <henning.schild@siemens.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20230706154831.19100-2-henning.schild@siemens.comReviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

This adds support for the Siemens Simatic IPC model BX-21A. Actual
drivers for that model will be sent in separate patches.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230713115639.16419-2-henning.schild@siemens.comReviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>