LED driver based on lp55xx have all a very similar implementation for
load_engine function. Move the function to lp55xx-common and rework the
define to be more dynamic instead of having to declare a temp array for
them.
Engine mask are the same for every LED based on lp55xx.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-6-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Now that stop_all_engine is generalized, probe and remove function are
the same across every lp55xx based LED driver and can be generalized.
To permit to use a common probe, make use of the OF match_data and i2c
driver_data value to store the device_config struct specific for the
LED.
Also drop the now unused exported symbol in lp55xx-common and make them
static.
Update any lp55xx based LED driver to use the new generic probe/remove.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-5-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
In all the lp55xx based driver, we have a similar implementation of the
stop_all_engine function with the only difference of the required sleep
for the OP MODE change.
The main difference is legacy LEDs require a min of 152 us while new one
use a generic 1-2ms. The new one use a 1-2ms sleep as suggested in the
datasheet IN ALTERNATIVE to a much more robust approach by using the
newly introduced ENGINE_BUSY bit in the STATUS reg.
To better handle sleep after OP MODE change, add support for polling the
ENGINE_BUSY bit and use the legacy sleep for old LEDs.
With this change, stop_all_engine can be generalized and moved to
lp55xx-common.
To make more clear the double usage of lp55xx_reg, define a union for
additional scope of mask and shift.
Update all lp55xx based driver to use the new generalized function and
define the required bits in the device_config struct.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-4-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The SY7802 is a current-regulated charge pump which can regulate two
current levels for Flash and Torch modes.
It is a high-current synchronous boost converter with 2-channel high
side current sources. Each channel is able to deliver 900mA current.
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: André Apitzsch <git@apitzsch.eu>
Link: https://lore.kernel.org/r/20240624-sy7802-v5-2-7abc9d96bfa6@apitzsch.eu
Signed-off-by: Lee Jones <lee@kernel.org>
Default blinking period is set to 2s. This is too long to be handled by
the hardware (maximum is 1.69s).
Set the default blinking period to 1s to match what is done in the
other LED drivers.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-5-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
When a LED is used to drive a beeper, it uses PWM1. This can cause
conflicts if an other LED want to use PWM1 for blinking.
Disable use of hardware for blinking when one or more LEDs are used to
drive beepers.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-4-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
PSC0/PWM0 are used by all LEDs for brightness and blinking. This causes
conflicts when you set a brightness of a new LED while an other one is
already using PWM0 for blinking.
Use PSC1/PWM1 for blinking.
Check that no other LED is already blinking with a different PSC1/PWM1
configuration to avoid conflict.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-3-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
Two tables are used to configure the PWM and PSC registers of the two
PWM available in the pca9532. Magic numbers are used to access this table
instead of defines.
Add defines PCA9532_PWM_ID_0 and PCA9532_PWM_ID_1 and use them in place of
these magic numbers.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-2-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
Use __free for device_node values, and thus drop calls to
of_node_put.
The variable attribute __free adds a scope based cleanup to
the device node. The goal is to reduce memory management issues
in the kernel code.
The of_node_put calls were removed, and the
for_each_available_child_of_node was replaced to the equivalent
for_each_available_child_of_node_scoped which use the __free.
Suggested-by: Julia Lawall <julia.lawall@inria.fr>
Signed-off-by: MarileneGarcia <marilene.agarcia@gmail.com>
Link: https://lore.kernel.org/r/20240601031713.1307859-1-marilene.agarcia@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The fwnode_for_each_child_node() loop requires manual intervention to
decrement the child refcount in case of an early return.
Add the missing calls to fwnode_handle_put(child) to avoid memory leaks
in the error paths.
Cc: stable@vger.kernel.org
Fixes: 679f865206 ("leds: Add mt6360 driver")
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Link: https://lore.kernel.org/r/20240611-leds-mt6360-memleak-v1-1-93642eb5011e@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Use __free() for device_node values, and thus drop calls to
of_node_put().
The variable attribute __free() adds a scope based cleanup to
the device node. The goal is to reduce memory management issues
in the kernel code.
The for_each_available_child_of_node() was replaced to the equivalent
for_each_available_child_of_node_scoped() which uses the __free().
Suggested-by: Julia Lawall <julia.lawall@inria.fr>
Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com>
Link: https://lore.kernel.org/r/20240611001740.10490-1-marilene.agarcia@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Currently, all LED LPG devices will call lpg_{set,clear}_pbs_trigger()
when setting brightness regardless of if they support PPG and have PBS
triggers. Check if device supports PPG before setting/clearing PBS
triggers.
Fixes: 6ab1f766a8 ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM")
Fixes: 5e9ff62686 ("leds: rgb: leds-qcom-lpg: Include support for PPG with dedicated LUT SDAM")
Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20240607005250.4047135-1-quic_amelende@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
The race fixed in timer_trig_activate() between a blocking
set_brightness() call and trigger->activate() can affect any trigger.
So move the call to flush_work() into led_trigger_set() where it can
avoid the race for all triggers.
Fixes: 0db37915d9 ("leds: avoid races with workqueue")
Fixes: 8c0f693c6e ("leds: avoid flush_work in atomic context")
Cc: stable@vger.kernel.org
Tested-by: Dustin L. Howett <dustin@howett.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-led-trigger-flush-v2-1-f4f970799d77@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
There is no code that uses ID table directly, except the
struct device_driver at the end of the file. Hence, move
table closer to its user. It's always possible to access
them via a pointer.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240606173037.3091598-7-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remove() so use devm API instead.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240606173037.3091598-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add a label so that a bit of exception handling can be better reused
at the end of this function implementation.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Link: https://lore.kernel.org/r/5faec5de-fc36-4b38-abcb-c61954a824cd@web.de
Signed-off-by: Lee Jones <lee@kernel.org>
If both set_brightness functions return -ENOTSUPP, then the LED doesn't
support setting a fixed brightness value, and the error message isn't
helpful. This can be the case e.g. for LEDs supporting a specific hw
trigger only.
Pinched the subject line and commit message from Heiner:
Link: https://lore.kernel.org/all/44177e37-9512-4044-8991-bb23b184bf37@gmail.com/
Reworked the function to provide Heiner's required semantics whilst
simultaneously increasing readability and flow.
Cc: Pavel Machek <pavel@ucw.cz>
Cc: linux-leds@vger.kernel.org
Suggested-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Add a new trigger which turns LEDs on when there is input
(/dev/input/event*) activity and turns them back off again after there has
been no activity for 5 seconds.
This is primarily intended to control LED devices which are a backlight for
capacitive touch-buttons, such as e.g. the menu / home / back buttons found
on the bottom bezel of many somewhat older smartphones and tablets.
This can also be used to turn on the keyboard backlight LED on input
events and turn the keyboard backlight off again when idle.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531135910.168965-2-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
ich7_lpc_probe() uses pci_read_config_dword() that returns PCIBIOS_*
codes. The error handling code assumes incorrectly it's a normal errno
and checks for < 0. The return code is returned from the probe function
as is but probe functions should return normal errnos.
Remove < 0 from the check and convert PCIBIOS_* returns code using
pcibios_err_to_errno() into normal errno before returning it.
Fixes: a328e95b82 ("leds: LED driver for Intel NAS SS4200 series (v5)")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240527132700.14260-1-ilpo.jarvinen@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Fix the 'make W=1" issue:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/blink/leds-bcm63138.o
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20240517-md-leds-bcm63138-v1-1-247b7302edb6@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
Fix the 'make W=1' issues:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-apollolake.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-core.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-elkhartlake.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-f7188x.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds.o
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20240517-md-simatic-ipc-v1-1-bbbd199262b8@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
While add it, also remove commas after the sentinel entries.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240522165358.62238-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
Some triggers call led_trigger_event() from their activate() callback
to initialize the brightness of the LED for which the trigger is being
activated.
In order for the LED's initial state to be set correctly this requires that
the led_trigger_event() call uses the new version of trigger->led_cdevs,
which has the new LED.
AFAICT led_trigger_event() will always use the new version when it is
running on the same CPU as where the list_add_tail_rcu() call was made,
which is why the missing synchronize_rcu() has not lead to bug reports.
But if activate() is pre-empted, sleeps or uses a worker then
the led_trigger_event() call may run on another CPU which may still use
the old trigger->led_cdevs list.
Add a synchronize_rcu() call to ensure that any led_trigger_event() calls
done from activate() always use the new list.
Triggers using led_trigger_event() from their activate() callback are:
net/bluetooth/leds.c, net/rfkill/core.c and drivers/tty/vt/keyboard.c.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531120124.75662-1-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
Triggers which have trigger specific sysfs attributes typically store
related data in trigger-data allocated by the activate() callback and
freed by the deactivate() callback.
Calling device_remove_groups() after calling deactivate() leaves a window
where the sysfs attributes show/store functions could be called after
deactivation and then operate on the just freed trigger-data.
Move the device_remove_groups() call to before deactivate() to close
this race window.
This also makes the deactivation path properly do things in reverse order
of the activation path which calls the activate() callback before calling
device_add_groups().
Fixes: a7e7a31563 ("leds: triggers: add device attribute support")
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240504162533.76780-1-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
'is31fl3190_regmap_config' and 'is31fl3196_regmap_config' are not modified
in this diver and are only used as a const struct regmap_config.
Constifying these structures moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
text data bss dec hex filename
13827 2002 32 15861 3df5 drivers/leds/leds-is31fl319x.o
After:
text data bss dec hex filename
14467 1370 32 15869 3dfd drivers/leds/leds-is31fl319x.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/82a5cb26ff8af1865a790286bdbc3c4a2bd149f1.1714892598.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones <lee@kernel.org>
The ChromeOS Embedded Controller exposes an LED control command.
Expose its functionality through the leds subsystem.
The LEDs are exposed as multicolor devices.
A hardware trigger, which is active by default, is provided to let the
EC itself take over control over the LED.
The driver is designed to be probed via the cros_ec mfd device.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-4-500b50f41e0f@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
led_get_color_name() is a safer alternative to led_colors.
led-class-multicolor.c is the only external user of led_colors and its
removal allows unexporting the array.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-2-500b50f41e0f@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
This is similar to the existing led_colors[] array but is safer to use and
usable by everyone.
Getting string representations of color ids is useful for drivers
which are handling color IDs anyways, for example for the multicolor API.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-1-500b50f41e0f@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
Commit 66601a29bb ("leds: class: If no default trigger is given, make
hw_control trigger the default trigger") causes ledtrig-netdev to get
set as default trigger on various network LEDs.
This causes users to hit a pre-existing AB-BA deadlock issue in
ledtrig-netdev between the LED-trigger locks and the rtnl mutex,
resulting in hung tasks in kernels >= 6.9.
Solving the deadlock is non trivial, so for now revert the change to
set the hw_control trigger as default trigger, so that ledtrig-netdev
no longer gets activated automatically for various network LEDs.
The netdev trigger is not needed because the network LEDs are usually under
hw-control and the netdev trigger tries to leave things that way so setting
it as the active trigger for the LED class device is a no-op.
Fixes: 66601a29bb ("leds: class: If no default trigger is given, make hw_control trigger the default trigger")
Reported-by: Genes Lists <lists@sapience.com>
Closes: https://lore.kernel.org/all/9d189ec329cfe68ed68699f314e191a10d4b5eda.camel@sapience.com/
Reported-by: Johannes Wüller <johanneswueller@gmail.com>
Closes: https://lore.kernel.org/lkml/e441605c-eaf2-4c2d-872b-d8e541f4cf60@gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Other warnings refer to the name after renaming, which is clearer when
that name is mentioned first.
It is also clearer where "ret" comes from.
While at it, also add the necessary newline to the message and fix the
parameter alignment.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240526-cros_ec-kbd-led-framework-v3-1-ee577415a521@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
Add a new led_mc_trigger_event() function for triggers which want to
change the color of a multi-color LED based on their trigger conditions.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531114124.45346-6-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add a new led_mc_set_brightness() function for in kernel color/brightness
changing of multi-color LEDs.
led-class-multicolor can be build as a module and led_mc_set_brightness()
will have the builtin callers, so put led_mc_set_brightness() inside
led-core instead, just like how led_set_brightness() is part of the core
and not of the led-class object.
This also adds a new LED_MULTI_COLOR led_classdev flag to allow
led_mc_set_brightness() to verify that it is operating on a multi-color
LED classdev, avoiding casting the passed in LED classdev to a multi-color
LED classdev, when it actually is not a multi-color LED.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531114124.45346-5-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
The mutex must be initialized before the LED class device is registered
otherwise there is a race where it may get used before it is initialized:
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 2 PID: 2045 at kernel/locking/mutex.c:587 __mutex_lock
...
RIP: 0010:__mutex_lock+0x7db/0xc10
...
set_brightness_delayed_set_brightness.part.0+0x17/0x60
set_brightness_delayed+0xf1/0x100
process_one_work+0x222/0x5a0
Move the mutex_init() call earlier to avoid this race condition and
switch to devm_mutex_init() to avoid the need to add error-exit
cleanup to probe() if probe() fails later on.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531114124.45346-4-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add an i2c_device_id id_table to match manually instantiated
(non device-tree / ACPI instantiated) KTD202x controllers as
found on some x86 boards.
This table shows the maximum support LED channel for KTD2026
(three LEDs) and KTD-2027 (4 LEDs).
Link: https://www.kinet-ic.com/uploads/KTD2026-7-04h.pdf
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531114124.45346-3-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
This LED controller is installed on a Xiaomi pad2 and it is an x86
platform. The original driver is based on the device tree and can't be
used for this ACPI based system. This patch migrated the driver to use
fwnode to access the properties. Moreover, the fwnode API supports the
device tree so this work won't affect the original implementations.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Tested-by: André Apitzsch <git@apitzsch.eu> # on BQ Aquaris M5
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531114124.45346-2-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
In 'struct mt6370_priv', the 'reg_cfgs' field is unused. Moreover
'struct reg_cfg' isn't defined anywhere, so remove it.
Found with cppcheck, unusedStructMember.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/e389be5e1012dc05fc2641123883ca3b0747525a.1714328839.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones <lee@kernel.org>
match_string() returns the array index of a matching string.
Use it instead of the open-coded implementation.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20240426152515.872917-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Currently, led pattern trigger uses timer_list to schedule brightness
changing. As we know from timer_list API [1], it's not accurate to
milliseconds and depends on HZ granularity.
Example:
"0 10 0 0 50 10 50 0 100 10 100 0 150 10 150 0 200 10 200 0 250 10 250 0",
we expect it to be 60ms long, but it can actually be up to ~120ms
(add ~10ms for each pattern when HZ == 100).
But sometimes, userspace needs time accurate led patterns to make sure
that pattern will be executed during expected time slot.
To achieve this goal the patch introduces optional hrtimer usage for
led trigger pattern, because hrtimer is microseconds accurate timer.
[1]: kernel/time/timer.c#L104
Signed-off-by: Martin Kurbanov <mmkurbanov@salutedevices.com>
Link: https://lore.kernel.org/r/20240416201847.357099-1-mmkurbanov@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
V4L2 will disable strobe mode of the LED device when enable torch mode,
but this logic will conflict with the "priv->fled_torch_used"
in "mt6360_strobe_set()". So after enabling torch mode of the first
LED, the second LED will not be able to enable torch mode correctly.
Therefore, at the beginning of "mt6360_strobe_set()", check whether the
state of the upcoming change and the current LED device state are the
same, so as to avoid the above problem.
Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com>
Link: https://lore.kernel.org/r/28FE6F1712799128000.chiaen_wu@richtek.com
Signed-off-by: Lee Jones <lee@kernel.org>
Building with W=1 shows a warning about an unused dmi_system_id table:
drivers/leds/leds-apu.c:85:35: error: 'apu_led_dmi_table' defined but not used [-Werror=unused-const-variable=]
85 | static const struct dmi_system_id apu_led_dmi_table[] __initconst = {
Since the current version doesn't even do anything about the different
implementations but only checks the type of system, just drop the
custom lookup logic and call dmi_check_system() using the table itself.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20240403080702.3509288-16-arnd@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
led_trigger_set() is the only caller of the deactivate() callback,
and it calls led_set_brightness(LED_OFF) anyway after deactivate().
So we can remove the call here.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/8dc929e7-8e14-4c85-aa28-9c5fe2620f52@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
This is used for the Siemens Simatic IPC BX-59A, which has its LEDs
connected to GPIOs provided by the Nuvoton NCT6126D.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Xing Tong Wu <xingtong.wu@siemens.com>
Link: https://lore.kernel.org/r/20240314070506.2384-1-xingtong_wu@163.com
Signed-off-by: Lee Jones <lee@kernel.org>
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remove() so use devm API instead.
Signed-off-by: George Stark <gnstark@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20240411161032.609544-9-gnstark@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remove() so use devm API instead.
Signed-off-by: George Stark <gnstark@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20240411161032.609544-8-gnstark@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's remove() so use devm API instead of remove().
Signed-off-by: George Stark <gnstark@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20240411161032.609544-7-gnstark@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's remove() so use devm API instead of remove().
Signed-off-by: George Stark <gnstark@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20240411161032.609544-6-gnstark@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's remove() so use devm API instead of remove().
Also drop explicit turning LEDs off from remove() due to they will be off
anyway by led_classdev_unregister().
Signed-off-by: George Stark <gnstark@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20240411161032.609544-5-gnstark@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's remove() so use devm API instead of remove().
Signed-off-by: George Stark <gnstark@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20240411161032.609544-4-gnstark@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's remove() so use devm API instead of remove().
Signed-off-by: George Stark <gnstark@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20240411161032.609544-3-gnstark@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
Now that the audio trigger is fully integrated in
sound/core/control_led.c, we can remove it here.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/1e339779-6d04-4392-8ea2-5592c0fd1aa2@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
This driver is the only one calling ledtrig_audio_set(), therefore
the LED audio trigger isn't usable standalone. So it makes sense
to fully integrate LED audio triger handling here.
The module aliases ensure that the driver is auto-loaded (if built
as module) if a LED device has one of the two audio triggers as
default trigger.
In addition disable building the old audio mute LED trigger.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/107634e6-d9ad-4a9f-881d-1eb72ea1a5a7@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
If a simple trigger is assigned to a LED, then the LED may be off until
the next led_trigger_event() call. This may be an issue for simple
triggers with rare led_trigger_event() calls, e.g. power supply
charging indicators (drivers/power/supply/power_supply_leds.c).
Therefore persist the brightness value of the last led_trigger_event()
call and use this value if the trigger is assigned to a LED.
In addition add a getter for the trigger brightness value.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/b1358b25-3f30-458d-8240-5705ae007a8a@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
heap optimizations".
- Kuan-Wei Chiu has also sped up the library sorting code in the series
"lib/sort: Optimize the number of swaps and comparisons".
- Alexey Gladkov has added the ability for code running within an IPC
namespace to alter its IPC and MQ limits. The series is "Allow to
change ipc/mq sysctls inside ipc namespace".
- Geert Uytterhoeven has contributed some dhrystone maintenance work in
the series "lib: dhry: miscellaneous cleanups".
- Ryusuke Konishi continues nilfs2 maintenance work in the series
"nilfs2: eliminate kmap and kmap_atomic calls"
"nilfs2: fix kernel bug at submit_bh_wbc()"
- Nathan Chancellor has updated our build tools requirements in the
series "Bump the minimum supported version of LLVM to 13.0.1".
- Muhammad Usama Anjum continues with the selftests maintenance work in
the series "selftests/mm: Improve run_vmtests.sh".
- Oleg Nesterov has done some maintenance work against the signal code
in the series "get_signal: minor cleanups and fix".
Plus the usual shower of singleton patches in various parts of the tree.
Please see the individual changelogs for details.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTTMBEPP41GrTpTJgfdBJ7gKXxAjgUCZfMnvgAKCRDdBJ7gKXxA
jjKMAP4/Upq07D4wjkMVPb+QrkipbbLpdcgJ++q3z6rba4zhPQD+M3SFriIJk/Xh
tKVmvihFxfAhdDthseXcIf1nBjMALwY=
=8rVc
-----END PGP SIGNATURE-----
Merge tag 'mm-nonmm-stable-2024-03-14-09-36' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Pull non-MM updates from Andrew Morton:
- Kuan-Wei Chiu has developed the well-named series "lib min_heap: Min
heap optimizations".
- Kuan-Wei Chiu has also sped up the library sorting code in the series
"lib/sort: Optimize the number of swaps and comparisons".
- Alexey Gladkov has added the ability for code running within an IPC
namespace to alter its IPC and MQ limits. The series is "Allow to
change ipc/mq sysctls inside ipc namespace".
- Geert Uytterhoeven has contributed some dhrystone maintenance work in
the series "lib: dhry: miscellaneous cleanups".
- Ryusuke Konishi continues nilfs2 maintenance work in the series
"nilfs2: eliminate kmap and kmap_atomic calls"
"nilfs2: fix kernel bug at submit_bh_wbc()"
- Nathan Chancellor has updated our build tools requirements in the
series "Bump the minimum supported version of LLVM to 13.0.1".
- Muhammad Usama Anjum continues with the selftests maintenance work in
the series "selftests/mm: Improve run_vmtests.sh".
- Oleg Nesterov has done some maintenance work against the signal code
in the series "get_signal: minor cleanups and fix".
Plus the usual shower of singleton patches in various parts of the tree.
Please see the individual changelogs for details.
* tag 'mm-nonmm-stable-2024-03-14-09-36' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (77 commits)
nilfs2: prevent kernel bug at submit_bh_wbc()
nilfs2: fix failure to detect DAT corruption in btree and direct mappings
ocfs2: enable ocfs2_listxattr for special files
ocfs2: remove SLAB_MEM_SPREAD flag usage
assoc_array: fix the return value in assoc_array_insert_mid_shortcut()
buildid: use kmap_local_page()
watchdog/core: remove sysctl handlers from public header
nilfs2: use div64_ul() instead of do_div()
mul_u64_u64_div_u64: increase precision by conditionally swapping a and b
kexec: copy only happens before uchunk goes to zero
get_signal: don't initialize ksig->info if SIGNAL_GROUP_EXIT/group_exec_task
get_signal: hide_si_addr_tag_bits: fix the usage of uninitialized ksig
get_signal: don't abuse ksig->info.si_signo and ksig->sig
const_structs.checkpatch: add device_type
Normalise "name (ad@dr)" MODULE_AUTHORs to "name <ad@dr>"
dyndbg: replace kstrdup() + strchr() with kstrdup_and_replace()
list: leverage list_is_head() for list_entry_is_head()
nilfs2: MAINTAINERS: drop unreachable project mirror site
smp: make __smp_processor_id() 0-argument macro
fat: fix uninitialized field in nostale filehandles
...
- Introduce ExpressWire library
- New Drivers
- Add support for ON Semiconductor NCP5623 RGB LED Driver
- New Device Support
- Add support for PM660L to Qualcomm's LPG driver
- New Functionality
- Dynamically load modules required for the default-trigger
- Add some support for suspend and resume
- Allow LEDs to remain lit during suspend
- Fix-ups
- Device Tree binding adaptions/conversions/creation
- Fix include lists; alphabetise, remove unused, explicitly add used
- Add new led_match_default_trigger to avoid duplication
- Add module alias' to aid auto-loading
- Default to hw_control if no others are specified
- De-bloat the supported link speed attribute lists
- Remove superfluous code and simplify overall
- Constify some variables
- Bug Fixes
- Prevent kernel panic when renaming the net interface
- Fix Kconfig related build errors
- Ensure mutexes are unlocked prior to destroying them
- Provide clean-up between state changes to avoid invalid state
- Fix some broken kernel-doc headers
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmXzCvUACgkQUa+KL4f8
d2Fh0A/+KQiuzluglEsnyG7gfb2771x9dQ9pIwaR68UkCwThNH8ico+NqUDs8Jur
6jtfYfKcWIz3i5kbnWBDGJfEEiVuDGu8Zv9UFxzQViyWQqawkJWNMsYqL3KtfI4i
Ujj2Ja1MsoqO7COngry9I+3sT6rEwdQJMrVfNAdvOYjlXwr3O8Z2NipPACEqutUr
0gxKAEEbGOj3+s3UGInrGi9RGuOVBe9UNA2etmtie1kxkdowTxCNY94ukUf9tnvC
WVXF8iOByUgVAxMh1ugSc27CTCV+VcDMYKKr9ABVhskI/pT3zMFoUCYY1EqhaOTF
Q40+yFX8ERomNTgy1tbNf06PkzaN+NJ4P/SHFU79madfy4OM6QobpTSt7bBpaSEP
gm3zuI1a353NPfAUZiIsTgv8jCh18w/adphTNsXY/4PnmkKF0+Pm57PJf8BDhlY3
KiScK7WXhGS9G3wNpLH+7QBdWiON3oWYJhVK4ijEfgRpEDofv+W16GzcETkUsyQ1
5DLu/W8wHN9zxHj1YXaitmnRjX3IMoltcIix8FI3YUKrx3m3twm2Vj5ZLziaPm83
7rBBPyePXwIamLokiTPCfXOxygO7Qv6VAp1aCR6400R/rtjykziboqvT2o6OMpkS
W/88631VIuL9jAaP/zdUHrle1NpKDiHs2MF0Rtj+0OOoMJyOC7k=
=m2vY
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"Core Framework:
- Introduce ExpressWire library
New Drivers:
- Add support for ON Semiconductor NCP5623 RGB LED Driver
New Device Support:
- Add support for PM660L to Qualcomm's LPG driver
New Functionality:
- Dynamically load modules required for the default-trigger
- Add some support for suspend and resume
- Allow LEDs to remain lit during suspend
Fix-ups:
- Device Tree binding adaptions/conversions/creation
- Fix include lists; alphabetise, remove unused, explicitly add used
- Add new led_match_default_trigger to avoid duplication
- Add module alias' to aid auto-loading
- Default to hw_control if no others are specified
- De-bloat the supported link speed attribute lists
- Remove superfluous code and simplify overall
- Constify some variables
Bug Fixes:
- Prevent kernel panic when renaming the net interface
- Fix Kconfig related build errors
- Ensure mutexes are unlocked prior to destroying them
- Provide clean-up between state changes to avoid invalid state
- Fix some broken kernel-doc headers"
* tag 'leds-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (41 commits)
leds: ncp5623: Add MS suffix to time defines
leds: Add NCP5623 multi-led driver
dt-bindings: leds: Add NCP5623 multi-LED Controller
leds: mlxreg: Drop an excess struct mlxreg_led_data member
leds: leds-mlxcpld: Fix struct mlxcpld_led_priv member name
leds: lm3601x: Fix struct lm3601_led kernel-doc warnings
leds: Fix ifdef check for gpio_led_register_device()
dt-bindings: leds: qcom-lpg: Narrow nvmem for other variants
dt-bindings: leds: qcom-lpg: Drop redundant qcom,pm8550-pwm in if:then:
dt-bindings: leds: Add LED_FUNCTION_WAN_ONLINE for Internet access
leds: sgm3140: Add missing timer cleanup and flash gpio control
leds: expresswire: Don't depend on NEW_LEDS
Revert "leds: Only descend into leds directory when CONFIG_NEW_LEDS is set"
leds: aw2013: Unlock mutex before destroying it
leds: qcom-lpg: Add QCOM_PBS dependency
leds: rgb: leds-group-multicolor: Allow LEDs to stay on in suspend
leds: trigger: netdev: Fix kernel panic on interface rename trig notify
leds: qcom-lpg: Add PM660L configuration and compatible
leds: spi-byte: Use devm_led_classdev_register_ext()
leds: pca963x: Add support for suspend and resume
...
NCP5623 is DC-DC multi-LEDs driver which has three PWMs that can be
programmed up to 32 steps giving 32768 colors hue.
NCP5623 driver supports gradual dimming upward/downward with programmable
delays. Also, the driver supports driving a single LED or multi-LED
like RGB.
Signed-off-by: Abdel Alkuor <alkuor@gmail.com>
Link: https://lore.kernel.org/r/20240305042049.1533279-2-alkuor@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Drop one struct member description to fix a kernel-doc warning:
drivers/leds/leds-mlxreg.c:42: warning: Excess struct member 'led_data' description in 'mlxreg_led_data'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20240229071931.7870-4-rdunlap@infradead.org
Signed-off-by: Lee Jones <lee@kernel.org>
Change "cled" to "cdev" to quieten kernel-doc warnings:
leds-mlxcpld.c:86: warning: Function parameter or struct member 'cdev' not described in 'mlxcpld_led_priv'
leds-mlxcpld.c:86: warning: Excess struct member 'cled' description in 'mlxcpld_led_priv'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20240229071931.7870-3-rdunlap@infradead.org
Signed-off-by: Lee Jones <lee@kernel.org>
Add a short struct description and remove one extraneous struct field
description to quieten these warnings:
leds-lm3601x.c:73: warning: missing initial short description on line:
* struct lm3601x_led -
leds-lm3601x.c💯 warning: Excess struct member 'led_name' description in 'lm3601x_led'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20240229071931.7870-2-rdunlap@infradead.org
Signed-off-by: Lee Jones <lee@kernel.org>
Enabling strobe and then setting brightness to 0 causes the driver to enter
invalid state after strobe end timer fires. We should cancel strobe mode
resources when changing brightness (aka torch mode).
Fixes: cef8ec8cbd ("leds: add sgm3140 driver")
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Link: https://lore.kernel.org/r/20240217191133.1757553-1-megi@xff.cz
Signed-off-by: Lee Jones <lee@kernel.org>
The ExpressWire library does not depend on NEW_LEDS and selecting it
from a subsystem other than LEDs may cause Kconfig warnings:
WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=y]
Selected by [y]:
- BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y]
Move it out of the "if NEW_LEDS" block to allow selection from other
subsystems (in particular backlight) without raising this warning.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/20240212111819.936815-1-arnd@kernel.org
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202402161410.IG9I4odj-lkp@intel.com/
Suggested-by: Daniel Thompson <daniel.thompson@linaro.org>
Fixes: 25ae5f5f4168 ("leds: Introduce ExpressWire library")
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20240216-expresswire-deps-v2-2-8be59c4a75f5@skole.hr
Signed-off-by: Lee Jones <lee@kernel.org>
In the probe() callback in case of error mutex is destroyed being locked
which is not allowed so unlock the mutex before destroying.
Fixes: 59ea3c9faf ("leds: add aw2013 driver")
Signed-off-by: George Stark <gnstark@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20231214173614.2820929-2-gnstark@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
The lpg driver fails to link now when the pbs driver is in a loadable module:
x86_64-linux-ld: drivers/leds/rgb/leds-qcom-lpg.o: in function `lpg_brightness_set':
leds-qcom-lpg.c:(.text+0xe7f): undefined reference to `qcom_pbs_trigger_event'
x86_64-linux-ld: drivers/leds/rgb/leds-qcom-lpg.o: in function `lpg_probe':
leds-qcom-lpg.c:(.text+0x16a5): undefined reference to `get_pbs_client_device'
Add a dependency to avoid the broken configuration. Apparently there is still
a use for lpg with pbs disabled entirely for certain chips, so allow both
but not LEDS_QCOM_LPG=y with QCOM_PBS=m.
Fixes: 214110175679 ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Link: https://lore.kernel.org/r/20240212111526.829122-1-arnd@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
If none of the managed LEDs enable LED_CORE_SUSPENDRESUME, then we
shouldn't need to set it here. This makes it possible to use multicolor
groups with GPIO LEDs that enable retain-state-suspended in the device
tree.
Signed-off-by: Aren Moynihan <aren@peacevolution.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Link: https://lore.kernel.org/r/20240206185400.596979-1-aren@peacevolution.org
[Lee: Changed the comment to respect proper grammar]
Signed-off-by: Lee Jones <lee@kernel.org>
Commit d5e01266e7 ("leds: trigger: netdev: add additional specific link
speed mode") in the various changes, reworked the way to set the LINKUP
mode in commit cee4bd16c3 ("leds: trigger: netdev: Recheck
NETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function.
This changed the logic where, in the previous implementation the dev
from the trigger event was used to check if the carrier was ok, but in
the new implementation with the generic function, the dev in
trigger_data is used instead.
This is problematic and cause a possible kernel panic due to the fact
that the dev in the trigger_data still reference the old one as the
new one (passed from the trigger event) still has to be hold and saved
in the trigger_data struct (done in the NETDEV_REGISTER case).
On calling of get_device_state(), an invalid net_dev is used and this
cause a kernel panic.
To handle this correctly, move the call to get_device_state() after the
new net_dev is correctly set in trigger_data (in the NETDEV_REGISTER
case) and correctly parse the new dev.
Fixes: d5e01266e7 ("leds: trigger: netdev: add additional specific link speed mode")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20240203235413.1146-1-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Inherit PM660L PMIC LPG/triled block configuration from downstream
drivers and DT sources, consisting of a triled block with automatic
trickle charge control and source selection, three colored led channels
belonging to the synchronized triled block and one loose PWM channel.
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20240204-pm660l-lpg-v5-1-2f54d1a0894b@somainline.org
Signed-off-by: Lee Jones <lee@kernel.org>
Use extended classdev registration to generate generic device names from
color and function enums instead of reading only the label from the
device tree.
Signed-off-by: Stefan Kalscheuer <stefan@stklcode.de>
Link: https://lore.kernel.org/r/20240204150726.29783-1-stefan@stklcode.de
Signed-off-by: Lee Jones <lee@kernel.org>
This implements power management for pca9633 which enables
device sleep and resume on system-wide sleep/hibernation
Signed-off-by: Amitesh Singh <singh.amitesh@gmail.com>
Link: https://lore.kernel.org/r/20240203162524.343936-1-singh.amitesh@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Commit 682e98564ffb ("leds: trigger: panic: Simplify
led_trigger_set_panic") removed the last external user of variable
trigger_list. So stop exporting it. If in future a need should arise
again to access this variable, I think we better add some accessor
instead of exporting the variable directly.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/ca185fb1-3a66-46b9-920e-bfecbe39c6bf@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Along the same lines as making devm_led_classdev_register() declared
extern unconditional, do the same thing for the two sub-classes
that have similar stubs.
The users of these interfaces go to great lengths to allow building
with both the generic leds API and the extended version, but realistically
there is not much use in this, so just simplify it to always rely
on it and remove the confusing fallback logic.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20240109090715.982332-2-arnd@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
I don't see why we iterate over all triggers to find the panic trigger.
We *are* the panic trigger. Therefore we also know that the panic
trigger doesn't have an activate() hook. So we can simplify the code
significantly.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Link: https://lore.kernel.org/r/84c0fa67-2f03-4474-aa75-914d65d88dd0@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
A bigger number of board device tree files, plus few drivers, set
default-on as default trigger for LED's. Therefore add an alias for
module auto-loading.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/7e94d26b-d772-4a07-b0f6-bb3111b9ff75@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
This a follow-up to 5edf7f11313d ("leds: trigger: Load trigger modules
on-demand if used as default trigger") and sets an alias for the audio
triggers.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/4663d2d8-660d-4af2-9f65-d95e95263923@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
With the addition of more link speed mode to the netdev trigger, it was
pointed out that there may be a problem with bloating the attribute list
with modes that won't ever be supported by the trigger as the attached
device name doesn't support them.
To clear and address this problem, change the logic where these
additional trigger modes are listed.
Since the netdev trigger REQUIRE a device name to be set, attach to the
device name change function additional logic to parse the supported link
speed modes using ethtool APIs and show only the supported link speed
modes attribute.
Link speed attribute are refreshed on device_name set and on
NETDEV_CHANGE events.
This only apply to the link speed modes and every other mode is still
provided by default.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20240111160501.1774-1-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
If a hw_control_trigger is defined, it's usually desirable to make it
the default trigger. Therefore make it the default trigger, except
the driver explicitly set a default trigger.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/f33543de-3800-488f-a779-1fa282614462@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Even if a trigger is set as default trigger for a LED device,
the respective trigger module (if built as module) isn't automatically
loaded by the kernel if the LED device is registered. I think we can
do better. Try to load the module asynchronously by alias
ledtrig:<trigger name>. This requires that such an alias is added to
relevant triggers.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/79adb260-06ad-443a-a68e-abe4498c3298@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Update the pm8350c lpg_data struct so that pm8350c devices are treated as
PWM devices that support two-nvmem PPG scheme.
Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
Link: https://lore.kernel.org/r/20231221185838.28440-8-quic_amelende@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
On PMICs such as PM8350C, the pattern lookup table (LUT) is stored in a
separate SDAM from the one where the lpg per-channel data is stored.
Add support for PPG with a dedicated LUT SDAM while maintaining backward
compatibility for those targets that use only a single SDAM.
Co-developed-by: Guru Das Srinagesh <quic_gurus@quicinc.com>
Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com>
Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
Link: https://lore.kernel.org/r/20231221185838.28440-7-quic_amelende@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
Update the pmi632 lpg_data struct so that pmi632 devices use PPG
for LUT pattern.
Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
Tested-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20231221185838.28440-6-quic_amelende@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
In some PMICs like pmi632, the pattern look up table (LUT) and LPG
configuration is stored in a single SDAM module instead of LUT
peripheral. This feature is called PPG. PPG uses Qualcomm Programmable
Boot Sequencer (PBS) inorder to trigger pattern sequences for PMICs.
Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
Tested-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20231221185838.28440-5-quic_amelende@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
The current codes uses the sw_control path in set_baseline_state() when
called from netdev_trig_activate() even if we're hw-controlled. This
may result in errors when led_set_brightness() is called because we may
not have set_brightness led ops (if hw doesn't support setting a "LED"
to ON). In addition this path may schedule trigger_data->work which
doesn't make sense when being hw-controlled.
Therefore set trigger_data->hw_control = true before calling
set_device_name() from netdev_trig_activate(). In this call chain we
have to prevent set_baseline_state() from being called, because this
would call hw_control_set(). Use led_cdev->trigger_data == NULL as
indicator for being called from netdev_trig_activate().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/d3f2859c-2673-401c-a4f7-fcaef2167991@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The expresswire module requires gpiolib, so anything selecting it
also needs this dependency:
WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=y] && GPIOLIB [=n]
Selected by [y]:
- LEDS_KTD2692 [=y] && NEW_LEDS [=y] && LEDS_CLASS_FLASH [=y] && OF [=y]
Fixes: e59a15af7aa6 ("leds: ktd2692: Convert to use ExpressWire library")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Link: https://lore.kernel.org/r/20240213165602.2230970-1-arnd@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
The KTD2692 uses the ExpressWire protocol implemented in the newly
introduced ExpressWire library. Convert the driver to use the library.
Suggested-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20240125-ktd2801-v5-2-e22da232a825@skole.hr
Signed-off-by: Lee Jones <lee@kernel.org>
The ExpressWire protocol is shared between at least KTD2692 and KTD2801
with slight differences such as timings and the former not having a
defined set of pulses for enabling the protocol (possibly because it
does not support PWM unlike KTD2801). Despite these differences the
ExpressWire handling code can be shared between the two, so in
preparation for adding KTD2801 support introduce a library implementing
this protocol.
Suggested-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20240125-ktd2801-v5-1-e22da232a825@skole.hr
Signed-off-by: Lee Jones <lee@kernel.org>
Found with git grep 'MODULE_AUTHOR(".*([^)]*@'
Fixed with
sed -i '/MODULE_AUTHOR(".*([^)]*@/{s/ (/ </g;s/)"/>"/;s/)and/> and/}' \
$(git grep -l 'MODULE_AUTHOR(".*([^)]*@')
Also:
in drivers/media/usb/siano/smsusb.c normalise ", INC" to ", Inc";
this is what every other MODULE_AUTHOR for this company says,
and it's what the header says
in drivers/sbus/char/openprom.c normalise a double-spaced separator;
this is clearly copied from the copyright header,
where the names are aligned on consecutive lines thusly:
* Linux/SPARC PROM Configuration Driver
* Copyright (C) 1996 Thomas K. Dyas (tdyas@noc.rutgers.edu)
* Copyright (C) 1996 Eddie C. Dost (ecd@skynet.be)
but the authorship branding is single-line
Link: https://lkml.kernel.org/r/mk3geln4azm5binjjlfsgjepow4o73domjv6ajybws3tz22vb3@tarta.nabijaczleweli.xyz
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
- Add support for Allwinner A100 RGB LED controller
- Add support for Maxim 5970 Dual Hot-swap controller
- New Device Support
- Add support for AW20108 to Awinic LED driver
- New Functionality
- Extend support for Net speeds to include; 2.5G, 5G and 10G
- Allow tx/rx and cts/dsr/dcd/rng TTY LEDS to be turned on and off via sysfs if required
- Add support for hardware control in AW200xx
- Fix-ups
- Use safer methods for string handling
- Improve error handling; return proper error values, simplify, avoid duplicates, etc
- Replace Mutex use with the Completion mechanism
- Fix include lists; alphabetise, remove unused, explicitly add used
- Use generic platform device properties
- Use/convert to new/better APIs/helpers/MACROs instead of hand-rolling implementations
- Device Tree binding adaptions/conversions/creation
- Continue work to remove superfluous platform .remove() call-backs
- Remove superfluous/defunct code
- Trivial; whitespace, unused variables, spelling, clean-ups, etc
- Avoid unnecessary duplicate locks
- Bug Fixes
- Repair Kconfig based dependency lists
- Ensure unused dynamically allocated data is freed after use
- Fix support for brightness control
- Add missing sufficient delays during reset to ensure correct operation
- Avoid division-by-zero issues
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmWmsRkACgkQUa+KL4f8
d2HjTQ/8DKBBDEJQLX1R9GN3W+F1RwenAyeuLcaBzIR1eAcw2CV6bb686CO+WxIn
pgZE33PiB1VR2Y571dUmj1oAJ8QMRsGed0bDzjNHO592ANHbGX/kxRlLsvcYqxE5
zAe0W93qn5ZEHRek6bJ55fsCuwRt1S/sPK/UDRb1MtJNQ51mh1ErhKk9rO0GkaDz
OtOeOwIqwNIDBqmYs8IAgfFolzBgnCMBnAW7EGA6hJjc2lWHHr+T8flT7rEPPcxD
s3ZT/m2jg0bAwWzFYWYxweyJ50NnP1xe7ABSqLi2jTcFkOKyYa/wvuL8GINXOSvM
9OVXPQ4MwiPTCPOhWex0WJ2/s0g2L5rL8gz+GBNVRppn53rYY0GwyXuEjmznYSrp
X4T8C1wRUMXQeBTNyoDxDid3oGoObGfyzIfI/aPOpqRHmeGWsbBITztCXgBEQcbs
k5WuiLzqYpLdTcjE0TJ4WTsR98zoY0yVwF5PFtTBcFTWz1QGmXujAa5gAIGJPhx6
fVovV0aih8hoZOq2xmCYRuR47rwH/QjfHcYZbhGC4YOPPA6Hh6j+eS9+1IpaWdLs
gUtXpU/pIWKUn0FVmtvK83MJ6VbJy5QHpQi7nf06ADNlDt0IoMTJAoMYsiKzqgeG
3L+sAd/DYcuS7Eyf5DP9SY/rqSsamsdSJpaSynP1Rm8Cyqka/Qg=
=/f98
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"New Drivers:
- Add support for Allwinner A100 RGB LED controller
- Add support for Maxim 5970 Dual Hot-swap controller
New Device Support:
- Add support for AW20108 to Awinic LED driver
New Functionality:
- Extend support for Net speeds to include; 2.5G, 5G and 10G
- Allow tx/rx and cts/dsr/dcd/rng TTY LEDS to be turned on and off
via sysfs if required
- Add support for hardware control in AW200xx
Fix-ups:
- Use safer methods for string handling
- Improve error handling; return proper error values, simplify,
avoid duplicates, etc
- Replace Mutex use with the Completion mechanism
- Fix include lists; alphabetise, remove unused, explicitly add used
- Use generic platform device properties
- Use/convert to new/better APIs/helpers/MACROs instead of
hand-rolling implementations
- Device Tree binding adaptions/conversions/creation
- Continue work to remove superfluous platform .remove() call-backs
- Remove superfluous/defunct code
- Trivial; whitespace, unused variables, spelling, clean-ups, etc
- Avoid unnecessary duplicate locks
Bug Fixes:
- Repair Kconfig based dependency lists
- Ensure unused dynamically allocated data is freed after use
- Fix support for brightness control
- Add missing sufficient delays during reset to ensure correct
operation
- Avoid division-by-zero issues"
* tag 'leds-next-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (45 commits)
leds: trigger: netdev: Add core support for hw not supporting fallback to LED sw control
leds: trigger: panic: Don't register panic notifier if creating the trigger failed
leds: sun50i-a100: Convert to be agnostic to property provider
leds: max5970: Add missing headers
leds: max5970: Make use of dev_err_probe()
leds: max5970: Make use of device properties
leds: max5970: Remove unused variable
leds: rgb: Drop obsolete dependency on COMPILE_TEST
leds: sun50i-a100: Avoid division-by-zero warning
leds: trigger: Remove unused function led_trigger_rename_static()
leds: qcom-lpg: Introduce a wrapper for getting driver data from a pwm chip
leds: gpio: Add kernel log if devm_fwnode_gpiod_get() fails
dt-bindings: leds: qcom,spmi-flash-led: Fix example node name
dt-bindings: leds: aw200xx: Fix led pattern and add reg constraints
dt-bindings: leds: awinic,aw200xx: Add AW20108 device
leds: aw200xx: Add support for aw20108 device
leds: aw200xx: Improve autodim calculation method
leds: aw200xx: Enable disable_locking flag in regmap config
leds: aw200xx: Add delay after software reset
dt-bindings: leds: aw200xx: Remove property "awinic,display-rows"
...
This contains a bunch of cleanups and simplifications across the board,
as well as a number of small fixes.
Perhaps the most notable change here is the addition of an API that
allows PWMs to be used in atomic contexts, which is useful when time-
critical operations are involved, such as using a PWM to generate IR
signals.
Finally, I have decided to step down as PWM subsystem maintainer. Due to
other responsibilities I have lately not been able to find the time that
the subsystem deserves and Uwe, who has been helping out a lot for the
past few years and has many things planned for the future, has kindly
volunteered to take over. I have no doubt that he will be a suitable
replacement.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmWhYQAZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zobK8EACtzJX+AeoTkN2S671A7QoG
IGl9mrFhvrqN/6syigAIU8ZGOgb5uScZDH58PeTXH/oGEMn+bhQ9MK7JyWF5BUzF
I8p6CqaVjG66LsfWz1m8AEAl/0N2Sc2032fWQSJB0o8qgYH0ZRBKc1j371Zm2DgD
HT78pZJDSnyCnltPKjbDLShRfBwGINspmbihZKFa6yxrPbvADixCTo19b9Pk8XGa
S9k2R/9S/QKPxvB+3DiZAHFstwoTn2p+1IBsg+hp/jLniw8XidZp2Rq0RJuwTjqO
jVQDnOFOqNBa3VQccvNe23rDaKUkrmYwk+zzuFF27URam2Gp9wHZ8Y86WPSO5TA9
ftNsoeW++R25PBsOVZFGMU9r9aI9XI1tNyVuv2blNc0yr1fNSRzwjcELzLzG2myp
gHgdayJofnvlKM7JV5ZDY6BDPwTP9jfDRdZOqKKNUeB8e9IiQD9JtAV9P+EL/5Hl
C+7mh5Xb17bVlczWHqNkTd89Omp+Eu2z5BMfJyiQWQ2lzZpxOkBwB0nrlPshZpPi
hz5IhsGjREkEfNV2qz/YDEyaj+CAYO8toitFGt5HeAYTftuG4WD49rHE5VQ8nhwg
P9XpWNFHK2EtpU3/BRuupWHZRVd7MU4kMx4WQvWZGOFEqc9DYaC29ynk6sK0ryaC
ba8U4gpBS66d3wNvVpkN3A==
=pIh8
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This contains a bunch of cleanups and simplifications across the
board, as well as a number of small fixes.
Perhaps the most notable change here is the addition of an API that
allows PWMs to be used in atomic contexts, which is useful when time-
critical operations are involved, such as using a PWM to generate IR
signals.
Finally, I have decided to step down as PWM subsystem maintainer. Due
to other responsibilities I have lately not been able to find the time
that the subsystem deserves and Uwe, who has been helping out a lot
for the past few years and has many things planned for the future, has
kindly volunteered to take over. I have no doubt that he will be a
suitable replacement"
* tag 'pwm/for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (44 commits)
MAINTAINERS: pwm: Thierry steps down, Uwe takes over
pwm: linux/pwm.h: fix Excess kernel-doc description warning
pwm: Add pwm_apply_state() compatibility stub
pwm: cros-ec: Drop documentation for dropped struct member
pwm: Drop two unused API functions
pwm: lpc18xx-sct: Don't modify the cached period of other PWM outputs
pwm: meson: Simplify using dev_err_probe()
pwm: stmpe: Silence duplicate error messages
pwm: Reduce number of pointer dereferences in pwm_device_request()
pwm: crc: Use consistent variable naming for driver data
pwm: omap-dmtimer: Drop locking
dt-bindings: pwm: ti,pwm-omap-dmtimer: Update binding for yaml
media: pwm-ir-tx: Trigger edges from hrtimer interrupt context
pwm: bcm2835: Allow PWM driver to be used in atomic context
pwm: Make it possible to apply PWM changes in atomic context
pwm: renesas: Remove unused include
pwm: Replace ENOTSUPP with EOPNOTSUPP
pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()
pwm: Stop referencing pwm->chip
pwm: Update kernel doc for struct pwm_chip
...
If hw doesn't support sw control of the LED and we switch to a mode
not supported by hw, currently we get lots of errors because neither
brigthness_set() nor brithness_set_blocking() is set.
Deal with this by not falling back to sw control, and return
-EOPNOTSUPP to the user. Note that we still store the new mode.
This is needed in case an intermediate unsupported mode is necessary
to switch from one supported mode to another.
Add a comment explaining how a driver for such hw is supposed to behave.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/3fd5184c-3641-4b0b-b59a-f489ec69a6cd@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Convert the driver to be agnostic to the property provider.
LEDS subsytem is not dependent on OF, so no need to make drivers
be a such.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20231214192131.1309912-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
leds-max5970.c:50:21: warning: variable 'num_leds' set but not used [-Wunused-but-set-variable]
Remove unused variable.
Fixes: 736214b4b0 ("leds: max5970: Add support for max5970")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231214184050.1272848-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Since commit 0166dc11be ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Link: https://lore.kernel.org/r/20231202214353.7c02f23c@endymion.delvare
Signed-off-by: Lee Jones <lee@kernel.org>
In order to introduce a pwm api which can be used from atomic context,
we will need two functions for applying pwm changes:
int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
int pwm_apply_atomic(struct pwm *, struct pwm_state *);
This commit just deals with renaming pwm_apply_state(), a following
commit will introduce the pwm_apply_atomic() function.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When CONFIG_COMMON_CLK is disabled, e.g. on an x86 randconfig compile test,
clang reports a field overflow from propagating the result of a division by
zero:
drivers/leds/leds-sun50i-a100.c:309:12: error: call to '__compiletime_assert_265' declared with 'error' attribute: FIELD_PREP: value too large for the field
control = FIELD_PREP(LEDC_T01_TIMING_CTRL_REG_T1H, timing->t1h_ns / cycle_ns) |
Avoid the problem by adding an explicit check for the zero value here. Alternatively
the assertion could be avoided with a Kconfig dependency on COMMON_CLK.
Fixes: 090a25ad9798 ("leds: sun50i-a100: New driver for the A100 LED controller")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Guo Ren <guoren@kernel.org>
Link: https://lore.kernel.org/r/20231212214536.175327-1-arnd@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
In case leds-gpio fails to get at least one of possibly many GPIOs
from the DT (e.g. the GPIO is already requested) neither gpiolib nor
the driver does provide any helpful error log:
leds-gpio: probe of leds failed with error -16
As the driver knows better how to handle errors with such mandatory
GPIOs, let's implement an error log which points to the affected
GPIO.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20231202183636.7055-1-wahrenst@gmx.net
Signed-off-by: Lee Jones <lee@kernel.org>
Add support for the Awinic aw20108 device, which belongs to the same LED
drivers family. The new device supports 108 LEDs using a matrix of 12x9
outputs."
Signed-off-by: George Stark <gnstark@salutedevices.com>
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Link: https://lore.kernel.org/r/20231125200519.1750-10-ddrokosov@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
It is highly recommended to leverage the DIV_ROUND_UP() function as a
more refined and mathematically precise alternative to employing a
coarse division method.
Signed-off-by: George Stark <gnstark@salutedevices.com>
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20231125200519.1750-9-ddrokosov@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
In the driver regmap is always used under mutex so regmap's inner lock
can be disabled.
Signed-off-by: George Stark <gnstark@salutedevices.com>
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20231125200519.1750-8-ddrokosov@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
According to the datasheets of AW200xx devices, the software reset takes
at least 1ms. Therefore, it is required to add a delay after the
reset before issuing commands to the device.
Signed-off-by: George Stark <gnstark@salutedevices.com>
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Link: https://lore.kernel.org/r/20231125200519.1750-7-ddrokosov@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
Get rid of device tree property "awinic,display-rows". The property
value actually means number of current switches and depends on how LEDs
are connected to the device. It should be calculated manually by max
used LED number. In the same way it is computed automatically now.
Max used LED is taken from LED definition subnodes.
Signed-off-by: George Stark <gnstark@salutedevices.com>
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20231125200519.1750-5-ddrokosov@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
HWEN is hardware control, which is used for enable/disable aw200xx chip.
It's high active, internally pulled down to GND.
After HWEN pin set high the chip begins to load the OTP information,
which takes 200us to complete. About 200us wait time is needed for
internal oscillator startup and display SRAM initialization. After
display SRAM initialization, the registers in page 1 to page 5 can be
configured via i2c interface.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Link: https://lore.kernel.org/r/20231125200519.1750-3-ddrokosov@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
If write only DIM value to the page 4, LED brightness will not be
updated, as both DIM and FADE need to be written to the page 4.
Therefore, write DIM to the page 1.
Fixes: 36a87f371b ("leds: Add AW20xx driver")
Signed-off-by: Martin Kurbanov <mmkurbanov@salutedevices.com>
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20231125200519.1750-2-ddrokosov@salutedevices.com
Signed-off-by: Lee Jones <lee@kernel.org>
The serial tty interface also supports additional input signals, that
can also be evaluated within this trigger. This change is adding the
following additional input sources, which could be controlled
via the '/sys/class/<leds>/' sysfs interface.
Explanation:
DCE = Data Communication Equipment (Modem)
DTE = Data Terminal Equipment (Computer)
- cts:
DCE is ready to accept data from the DTE (CTS = Clear To Send). If
the line state is detected, the LED is switched on.
If set to 0 (default), the LED will not evaluate CTS.
If set to 1, the LED will evaluate CTS.
- dsr:
DCE is ready to receive and send data (DSR = Data Set Ready). If the
line state is detected, the LED is switched on.
If set to 0 (default), the LED will not evaluate DSR.
If set to 1, the LED will evaluate DSR.
- dcd:
DTE is receiving a carrier from the DCE (DCD = Data Carrier Detect).
If the line state is detected, the LED is switched on.
If set to 0 (default), the LED will not evaluate DCD.
If set to 1, the LED will evaluate DCD.
- rng:
DCE has detected an incoming ring signal on the telephone line
(RNG = Ring Indicator). If the line state is detected, the LED is
switched on.
If set to 0 (default), the LED will not evaluate RNG.
If set to 1, the LED will evaluate RNG.
Also add an invert flag on LED blink, so that the LED blinks in the
correct order.
* If one off the new enabled input signals are evaluatet as 'enabled',
and data are transmitted, then the LED should first blink 'off' and
then 'on' (invert).
* If all the new enabled input signals are evaluatet as 'disabled',
and data are transmitted, then the LED should first blink 'on' and
then 'off'.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Reviewed-by: Maarten Brock <m.brock@vanmierlo.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20231127110311.3583957-5-fe@dev.tdt.de
Signed-off-by: Lee Jones <lee@kernel.org>
Until now, the LED blinks when data is sent via the tty (rx/tx).
This is not configurable.
This change adds the possibility to make the indication for the direction
of the transmitted data independently controllable via the new rx and
tx sysfs entries.
- rx:
Signal reception (rx) of data on the named tty device.
If set to 0, the LED will not blink on reception.
If set to 1 (default), the LED will blink on reception.
- tx:
Signal transmission (tx) of data on the named tty device.
If set to 0, the LED will not blink on transmission.
If set to 1 (default), the LED will blink on transmission.
This new sysfs entry are on by default. Thus the trigger behaves as
before this change.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20231127110311.3583957-4-fe@dev.tdt.de
Signed-off-by: Lee Jones <lee@kernel.org>
With this commit, the mutex handling is replaced by the completion
handling. When handling mutex, it must always be ensured that the held
mutex is also released again. This is more error-prone should the number
of code paths increase.
This is a preparatory commit to make the trigger more configurable via
additional sysfs parameters. With this change, the worker always runs and
is no longer stopped if no ttyname is set.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20231127110311.3583957-3-fe@dev.tdt.de
Signed-off-by: Lee Jones <lee@kernel.org>
One error path already used dev_err_probe(). Adapt the other error paths
that emit an error message to also use this function for consistency and
slightly simplified code.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231126095230.683204-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
With pwmchip_remove() being automatically called after switching to
devm_pwmchip_add() the remove function can be dropped completely. Yay!
With lpg_remove() gone there is no user of the platform device's drvdata
left, so platform_set_drvdata() can be dropped from .probe(), too.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231126095230.683204-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
The ttyname buffer for the ledtrig_tty_data struct is allocated in the
sysfs ttyname_store() function. This buffer must be released on trigger
deactivation. This was missing and is thus a memory leak.
While we are at it, the TTY handler in the ledtrig_tty_data struct should
also be returned in case of the trigger deactivation call.
Cc: stable@vger.kernel.org
Fixes: fd4a641ac8 ("leds: trigger: implement a tty trigger")
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20231127081621.774866-1-fe@dev.tdt.de
Signed-off-by: Lee Jones <lee@kernel.org>
Follow the advice of the Documentation/filesystems/sysfs.rst and show()
should only use sysfs_emit() or sysfs_emit_at() when formatting the
value to be returned to user space.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20231103195310.948327-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
sscanf() is a heavy one and moreover requires additional boundary checks.
Convert driver to use kstrtou8() in gpio_trig_inverted_store().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20231103195310.948327-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
gpiod_get_optional() and currently used fwnode_gpiod_get_index()
are both wrappers against the same engine internally. Since we
have a pointer to struct device there is no reason to use fwnode
type of GPIO call. So, replace the current fwnode call by respective
gpiod ones.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20231103195310.948327-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
The AW2013 driver uses devm_regmap_init_i2c, so REGMAP_I2C needs to
be selected.
Otherwise build process may fail with:
ld: drivers/leds/leds-aw2013.o: in function `aw2013_probe':
leds-aw2013.c:345: undefined reference to `__devm_regmap_init_i2c'
Signed-off-by: Dang Huynh <danct12@riseup.net>
Acked-by: Nikita Travkin <nikita@trvn.ru>
Fixes: 59ea3c9faf ("leds: add aw2013 driver")
Link: https://lore.kernel.org/r/20231103114203.1108922-1-danct12@riseup.net
Signed-off-by: Lee Jones <lee@kernel.org>
Some Allwinner sunxi SoCs, starting with the A100, contain an LED
controller designed to drive RGB LED pixels. Add a driver for it using
the multicolor LED framework, and with LEDs defined in the device tree.
Acked-by: Guo Ren <guoren@kernel.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20231029212738.7871-3-samuel@sholland.org
Signed-off-by: Lee Jones <lee@kernel.org>
The register-bit-led binding now also supports 'reg' in addition to
'offset' for the register address. Add support to the driver to get the
address from 'reg'.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20231025190619.881090-2-robh@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
The commit c7d80059b0 ("leds: class: Store the color index in struct
led_classdev") introduced a new sysfs entry "color" that is commonly
created for the led classdev. Unfortunately, this conflicts with the
"color" sysfs entry of already existing drivers such as Logitech HID
or System76 ACPI drivers. The driver probe fails due to the conflict,
hence it leads to a severe regression with the missing keyboard, for
example.
This patch reverts partially the change in the commit above for
removing the led class color sysfs entries again for addressing the
regressions. The newly introduced led_classdev.color field is kept as
it's already used by other driver.
Fixes: c7d80059b0 ("leds: class: Store the color index in struct led_classdev")
Reported-by: Johannes Penßel <johannes.penssel@gmail.com>
Closes: https://lore.kernel.org/r/b5646db3-acff-45aa-baef-df3f660486fb@gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218045
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218155
Link: https://bugzilla.suse.com/show_bug.cgi?id=1217172
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20231121162359.9332-1-tiwai@suse.de
Signed-off-by: Lee Jones <lee@kernel.org>
This contains a few fixes and a bunch of cleanups, a lot of which is in
preparation for Uwe's character device support that may be ready in time
for the next merge window.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmVLhGsZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoazOD/oDjIcP4lSkAdcRLuEPsHor
47INsdzm84g7CcUhFVY8a1ODjXNtVWcoXeLsJ69lJ3CJW9cjHlUaeFcP5KW5YhMN
nE3Kk8MsAyeaN6QgSVeqsMj8t64WvUve3/M0M/bmaPt3mO8hxYTuSQlK5v+JfEyO
Px8JH/U2f7W2zdVbdK3YtpcRtMiqYlYw2mu/ILumlZhZvxXEPWPs6lH8J3VHW9nU
L8Up1dQB7TQcZiw4M2cdP/oSieQ+2PhWKbyWxdutArNxdMlE6xDurzIDzvwXL5kt
cMWZtU0/kPu9cuH+19wqvRyFgGHSCjvP/smuu87/JvHc3Nbjxt//H3bQuDFLyiGc
ZPfyNJOQ4vGSQ9gHQbedEsBnnX9qeZZecrd9PteUAqbAuRh/53bij0buXvzIwWzr
36/nHyjO9oEDcXgxGI75ATd7yd51ipyIEmYmzDGWoUGF8TK61wUYVaI0+x6I8JFO
vQu1/pxcwjnQ/4r87opmx7E1UK/v5hYugpZIA39d5yM2djikZTTcNEhQchnN0RHN
ih8ZyQ/A0XGHr2ICRFsgTPVFzKM0JyjCCVGvuEdkEN2dtk4dJlJTPz0xpNRIaALU
dhsqziUT0FqqeLprwKBWjXZLbzWwwXWrOzAbbsXkoPny8BRYE60Pp5qqjPrLgj5Z
2z8rCDBaoILeFl5utV0rzw==
=S2DI
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This contains a few fixes and a bunch of cleanups, a lot of which is
in preparation for Uwe's character device support that may be ready in
time for the next merge window"
* tag 'pwm/for-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (37 commits)
pwm: samsung: Document new member .channel in struct samsung_pwm_chip
pwm: bcm2835: Add support for suspend/resume
pwm: brcmstb: Checked clk_prepare_enable() return value
pwm: brcmstb: Utilize appropriate clock APIs in suspend/resume
pwm: pxa: Explicitly include correct DT includes
pwm: cros-ec: Simplify using devm_pwmchip_add() and dev_err_probe()
pwm: samsung: Consistently use the same name for driver data
pwm: vt8500: Simplify using devm functions
pwm: sprd: Simplify using devm_pwmchip_add() and dev_err_probe()
pwm: sprd: Provide a helper to cast a chip to driver data
pwm: spear: Simplify using devm functions
pwm: mtk-disp: Simplify using devm_pwmchip_add()
pwm: imx-tpm: Simplify using devm functions
pwm: brcmstb: Simplify using devm functions
pwm: bcm2835: Simplify using devm functions
pwm: bcm-iproc: Simplify using devm functions
pwm: Adapt sysfs API documentation to reality
pwm: dwc: add PWM bit unset in get_state call
pwm: dwc: make timer clock configurable
pwm: dwc: split pci out of core driver
...
- Add support for a bunch more colours
- New Drivers
- Add support for Kinetic KTD2026/7 RGB/White LEDs
- New Functionality
- Add support for device to enter HW Controlled Mode to Turris Omnia LEDs
- Add support for HW Gamma Correction to Turris Omnia LEDs
- Fix-ups
- Apply new __counted_by() annotation to several data structures containing flexible arrays
- Rid the return value from Platform's .remove() operation
- Use *_cansleep() variants for instances were threads can sleep
- Improve the semantics when setting the brightness
- Generic clean-ups; code reduction, coding style, standard patterns
- Replace strncpy() with strscpy()
- Fix-up / add various documentation
- Re-author the GPIO associated Trigger to use trigger-sources
- Move to using standard APIs and helpers
- Improve error checking
- Stop using static GPIO bases
- Bug Fixes
- Fix Pointer to Enum casing warnings
- Do not pretend that I2C backed device supports SMBUS
- Ensure PWM LEDs are extinguished when disabled, rather than held in a state
- Fix 'output may be truncated' warnings
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmVDsTgACgkQUa+KL4f8
d2EQsg/+Jy2zYIpFXaj/sSZCB9gDToIpHNer2XUEgKMXCAF0Ar8SCHvdmIeb9exG
rCLb86AxvE2trIcZBRITtRgU4YCAr6yiyNZHCYyLxN+WZLind3lL7mKB1x9gVFbw
MKFmQjl9cWmJjI1Mk10NFzhgYJkMotKWZrQqAeggD5gYinieSVXE2RkrcV/zfQxh
NqtijzDL0C9pWIXQtqpjic7PSgyC8mIGmD0Q9gyEOWOVbWzmR/vklwEsbirT4nEp
7QIz/b5nwXVEEJ69WCTNeDBmXYeEKw4DMLJxJ6aTYHf62gramtfTH+d6izY3Hnrs
EszgWmqmwSqXrwadtg7Zn6xrgec+yDuwj3rwQEQcveOsUJMENtVN6i2ZYO90Hpor
XP6jzz+KBT/qLF4syfkO7Z9vV7em1zm/AuoiDieFVBy6vMQJmmCvIb+GE1l5CXUv
myEYVu0P9Ir9/2W+z9rqzor2wtZ9OVXT1XCnV6UPU7mNhJIH8PXr9/cjJgsY5vYC
H8kZcfaCRlwqPiVA0yucvfEeveptObVojZdkhCH/BnhRtIAWf1jlj5PglfSaOQaU
jGy6s/8auS5ua0vX2UYFv0cXxSTZpX+7jDzpQcaIKqOPe/xqUSAeL/N4btY+TlfR
zkQxWxksOtVdD2xaIZvGutcAMXRBEIjgDS61SZBLf/jh7N/iXlc=
=XYXV
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"Core Frameworks:
- Add support for a bunch more colours
New Drivers:
- Add support for Kinetic KTD2026/7 RGB/White LEDs
New Functionality:
- Add support for device to enter HW Controlled Mode to Turris Omnia
LEDs
- Add support for HW Gamma Correction to Turris Omnia LEDs
Fix-ups:
- Apply new __counted_by() annotation to several data structures
containing flexible arrays
- Rid the return value from Platform's .remove() operation
- Use *_cansleep() variants for instances were threads can sleep
- Improve the semantics when setting the brightness
- Generic clean-ups; code reduction, coding style, standard patterns
- Replace strncpy() with strscpy()
- Fix-up / add various documentation
- Re-author the GPIO associated Trigger to use trigger-sources
- Move to using standard APIs and helpers
- Improve error checking
- Stop using static GPIO bases
Bug Fixes:
- Fix Pointer to Enum casing warnings
- Do not pretend that I2C backed device supports SMBUS
- Ensure PWM LEDs are extinguished when disabled, rather than held in
a state
- Fix 'output may be truncated' warnings"
* tag 'leds-next-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (43 commits)
leds: lp5521: Add an error check in lp5521_post_init_device
leds: gpio: Update headers
leds: gpio: Remove unneeded assignment
leds: gpio: Move temporary variable for struct device to gpio_led_probe()
leds: gpio: Refactor code to use devm_gpiod_get_index_optional()
leds: gpio: Utilise PTR_ERR_OR_ZERO()
leds: gpio: Keep driver firmware interface agnostic
leds: core: Refactor led_update_brightness() to use standard pattern
leds: turris-omnia: Fix brightness setting and trigger activating
leds: sc27xx: Move mutex_init() down
leds: trigger: netdev: Move size check in set_device_name
leds: Add ktd202x driver
dt-bindings: leds: Add Kinetic KTD2026/2027 LED
leds: core: Add more colors from DT bindings to led_colors
dt-bindings: leds: Last color ID is now 14 (LED_COLOR_ID_LIME)
leds: tca6507: Don't use fixed GPIO base
leds: lp3952: Convert to use maple tree register cache
leds: lm392x: Convert to use maple tree register cache
leds: aw200xx: Convert to use maple tree register cache
leds: lm3601x: Convert to use maple tree register cache
...
Instead of checking for the specific error codes, replace
devm_gpiod_get_index() with devm_gpiod_get_index_optional().
In this case we just return all errors to the caller and
simply check for NULL in case if legacy GPIO is being used.
As the result the code is easier to read and maintain.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231016161005.1471768-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
The of.h is used as a proxy to mod_devicetable, replace former by
latter.
The commit 2d6180147e ("leds: gpio: Configure per-LED pin control")
added yet another unneeded OF APIs. Replace with direct use of fwnode.
Altogether this makes driver agnostic to the firmware interface in use.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231016161005.1471768-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
The standard conditional pattern is to check for errors first and
bail out if any. Refactor led_update_brightness() accordingly.
While at it, drop unneeded assignment and return 0 unconditionally
on success.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Denis Osterland-Heim <denis.osterland@diehl.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20231016153051.1409074-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
I have improperly refactored commits
4d5ed2621c24 ("leds: turris-omnia: Make set_brightness() more efficient")
and
aaf38273cf76 ("leds: turris-omnia: Support HW controlled mode via private trigger")
after Lee requested a change in API semantics of the new functions I
introduced in commit
28350bc0ac77 ("leds: turris-omnia: Do not use SMBUS calls").
Before the change, the function omnia_cmd_write_u8() returned 0 on
success, and afterwards it returned a positive value (number of bytes
written). The latter version was applied, but the following commits did
not properly account for this change.
This results in non-functional LED's .brightness_set_blocking() and
trigger's .activate() methods.
The main reasoning behind the semantics change was that read/write
methods should return the number of read/written bytes on success.
It was pointed to me [1] that this is not always true (for example the
regmap API does not do so), and since the driver never uses this number
of read/written bytes information, I decided to fix this issue by
changing the functions to the original semantics (return 0 on success).
[1] https://lore.kernel.org/linux-gpio/ZQnn+Gi0xVlsGCYA@smile.fi.intel.com/
Fixes: 28350bc0ac77 ("leds: turris-omnia: Do not use SMBUS calls")
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20231016141538.30037-1-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Move the mutex_init() to avoid redundant mutex_destroy() calls after
that for each time the probe fails.
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Link: https://lore.kernel.org/r/20231013022010.854367-1-chunyan.zhang@unisoc.com
Signed-off-by: Lee Jones <lee@kernel.org>
GCC 13.2 complains about array subscript 17 is above array bounds of
'char[16]' with IFNAMSIZ set to 16.
The warning is correct but this scenario is impossible.
set_device_name is called by device_name_store (store sysfs entry) and
netdev_trig_activate.
device_name_store already check if size is >= of IFNAMSIZ and return
-EINVAL. (making the warning scenario impossible)
netdev_trig_activate works on already defined interface, where the name
has already been checked and should already follow the condition of
strlen() < IFNAMSIZ.
Aside from the scenario being impossible, set_device_name can be
improved to both mute the warning and make the function safer.
To make it safer, move size check from device_name_store directly to
set_device_name and prevent any out of bounds scenario.
Cc: stable@vger.kernel.org
Fixes: 28a6a2ef18 ("leds: trigger: netdev: refactor code setting device name")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202309192035.GTJEEbem-lkp@intel.com/
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20231007131042.15032-1-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The colors are already part of DT bindings. Make sure the kernel is
able to convert them to strings.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Link: https://lore.kernel.org/r/20231008144014.1180334-1-megi@xff.cz
Signed-off-by: Lee Jones <lee@kernel.org>
First of all, the fixed GPIO base is source of troubles and
it doesn't scale. Second, there is no in-kernel user of this
base, so drop it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231002135629.2605462-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230929-leds-maple-v1-4-ba5f9dcb1e75@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230929-leds-maple-v1-3-ba5f9dcb1e75@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230929-leds-maple-v1-2-ba5f9dcb1e75@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230929-leds-maple-v1-1-ba5f9dcb1e75@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
By providing a GPIO line as "trigger-sources" in the FWNODE
(such as from the device tree) and combining with the
GPIO trigger, we can support a GPIO LED trigger in a natural
way from the hardware description instead of using the
custom sysfs and deprecated global GPIO numberspace.
Example:
gpio: gpio@0 {
compatible "my-gpio";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
#trigger-source-cells = <2>;
};
leds {
compatible = "gpio-leds";
led-my-gpio {
label = "device:blue:myled";
gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
linux,default-trigger = "gpio";
trigger-sources = <&gpio 1 GPIO_ACTIVE_HIGH>;
};
};
Make this the norm, unmark the driver as broken.
Delete the sysfs handling of GPIOs.
Since GPIO descriptors inherently can describe inversion,
the inversion handling can just be deleted.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230926-gpio-led-trigger-dt-v2-3-e06e458b788e@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Some cleanups:
* Remove the trailing comma in the terminator entry for the OF
table making code robust against (theoretical) misrebases or other
similar things where the new entry goes _after_ the termination without
the compiler noticing.
* Drop a space from terminator entry for ID table.
While at it, move OF/ID table near to the user.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230923171921.53503-3-biju.das.jz@bp.renesas.com
Signed-off-by: Lee Jones <lee@kernel.org>
Convert enum->pointer for data in the match tables, so that
device_get_match_data() can do match against OF/ACPI/I2C tables, once i2c
bus type match support added to it.
Replace enum->struct *pca955x_chipdefs for data in the match table.
Simplify the probe() by replacing device_get_match_data() and ID lookup
for retrieving data by i2c_get_match_data().
While at it, add const definition to pca955x_chipdefs[].
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230923171921.53503-2-biju.das.jz@bp.renesas.com
Signed-off-by: Lee Jones <lee@kernel.org>
`strncpy` is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect `dest` to be NUL-terminated due to its use with dev_err.
lp3952_get_label()'s dest argument is priv->leds[i].name:
| acpi_ret = lp3952_get_label(&priv->client->dev, led_name_hdl[i],
| priv->leds[i].name);
... which is then assigned to:
| priv->leds[i].cdev.name = priv->leds[i].name;
... which is used with a format string
| dev_err(&priv->client->dev,
| "couldn't register LED %s\n",
| priv->leds[i].cdev.name);
There is no indication that NUL-padding is required but if it is let's
opt for strscpy_pad.
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230922-strncpy-drivers-leds-leds-lp3952-c-v1-1-4941d6f60ca4@google.com
Signed-off-by: Lee Jones <lee@kernel.org>
In order to teach the compiler that 'trig->name' will never be truncated,
we need to tell it that 'cpu' is not negative.
When building with W=1, this fixes the following warnings:
drivers/leds/trigger/ledtrig-cpu.c: In function ‘ledtrig_cpu_init’:
drivers/leds/trigger/ledtrig-cpu.c:155:56: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 5 [-Werror=format-truncation=]
155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
| ^~
drivers/leds/trigger/ledtrig-cpu.c:155:52: note: directive argument in the range [-2147483648, 7]
155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
| ^~~~~~~
drivers/leds/trigger/ledtrig-cpu.c:155:17: note: ‘snprintf’ output between 5 and 15 bytes into a destination of size 8
155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 8f88731d05 ("led-triggers: create a trigger for CPU activity")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/3f4be7a99933cf8566e630da54f6ab913caac432.1695453322.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones <lee@kernel.org>
Disabling a PWM (i.e. calling pwm_apply_state with .enabled = false)
gives no guarantees what the PWM output does. It might freeze where it
currently is, or go in a High-Z state or drive the active or inactive
state, it might even continue to toggle.
To ensure that the LED gets really disabled, don't disable the PWM even
when .duty_cycle is zero.
This fixes disabling a leds-pwm LED on i.MX28. The PWM on this SoC is
one of those that freezes its output on disable, so if you disable an
LED that is full on, it stays on. If you disable a LED with half
brightness it goes off in 50% of the cases and full on in the other 50%.
Fixes: 41c42ff5db ("leds: simple driver for pwm driven LEDs")
Reported-by: Rogan Dawes <rogan@dawes.za.net>
Reported-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20230922192834.1695727-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
If the MCU on Turris Omnia is running newer firmware versions, the LED
controller supports RGB gamma correction (and enables it by default for
newer boards).
Determine whether the gamma correction setting feature is supported and
add the ability to set it via sysfs attribute file.
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230918161104.20860-5-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Add support for enabling MCU controlled mode of the Turris Omnia LEDs
via a LED private trigger called "omnia-mcu". Recall that private LED
triggers will only be listed in the sysfs trigger file for LEDs that
support them (currently there is no user of this mechanism).
When in MCU controlled mode, the user can still set LED color, but the
blinking is done by MCU, which does different things for different LEDs:
- WAN LED is blinked according to the LED[0] pin of the WAN PHY
- LAN LEDs are blinked according to the LED[0] output of the
corresponding port of the LAN switch
- PCIe LEDs are blinked according to the logical OR of the MiniPCIe port
LED pins
In the future I want to make the netdev trigger to transparently offload
the blinking to the HW if user sets compatible settings for the netdev
trigger (for LEDs associated with network devices).
There was some work on this already, and hopefully we will be able to
complete it sometime, but for now there are still multiple blockers for
this, and even if there weren't, we still would not be able to configure
HW controlled mode for the LEDs associated with MiniPCIe ports.
In the meantime let's support HW controlled mode via the private LED
trigger mechanism. If, in the future, we manage to complete the netdev
trigger offloading, we can still keep this private trigger for backwards
compatibility, if needed.
We also set "omnia-mcu" to cdev->default_trigger, so that the MCU keeps
control until the user first wants to take over it. If a different
default trigger is specified in device-tree via the
'linux,default-trigger' property, LED class will overwrite
cdev->default_trigger, and so the DT property will be respected.
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230918161104.20860-4-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Implement caching of the LED color and state values that are sent to MCU
in order to make the set_brightness() operation more efficient by
avoiding I2C transactions which are not needed.
On Turris Omnia's MCU, which acts as the RGB LED controller, each LED
has a RGB color, and a ON/OFF state, which are configurable via I2C
commands CMD_LED_COLOR and CMD_LED_STATE.
The CMD_LED_COLOR command sends 5 bytes and the CMD_LED_STATE command 2
bytes over the I2C bus, which operates at 100 kHz. With I2C overhead
this allows ~1670 color changing commands and ~3200 state changing
commands per second (or around 1000 color + state changes per second).
This may seem more than enough, but the issue is that the I2C bus is
shared with another peripheral, the MCU. The MCU exposes an interrupt
interface, and it can trigger hundreds of interrupts per second. Each
time, we need to read the interrupt state register over this I2C bus.
Whenever we are sending a LED color/state changing command, the
interrupt reading is waiting.
Currently, every time LED brightness or LED multi intensity is changed,
we send a CMD_LED_STATE command, and if the computed color (brightness
adjusted multi_intensity) is non-zero, we also send a CMD_LED_COLOR
command.
Consider for example the situation when we have a netdev trigger enabled
for a LED. The netdev trigger does not change the LED color, only the
brightness (either to 0 or to currently configured brightness), and so
there is no need to send the CMD_LED_COLOR command. But each change of
brightness to 0 sends one CMD_LED_STATE command, and each change of
brightness to max_brightness sends one CMD_LED_STATE command and one
CMD_LED_COLOR command:
set_brightness(0) -> CMD_LED_STATE
set_brightness(255) -> CMD_LED_STATE + CMD_LED_COLOR
(unnecessary)
We can avoid the unnecessary I2C transactions if we cache the values of
state and color that are sent to the controller. If the color does not
change from the one previously sent, there is no need to do the
CMD_LED_COLOR I2C transaction, and if the state does not change, there
is no need to do the CMD_LED_STATE transaction.
Because we need to make sure that our cached values are consistent with
the controller state, add explicit setting of the LED color to white at
probe time (this is the default setting when MCU resets, but does not
necessarily need to be the case, for example if U-Boot played with the
LED colors).
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230918161104.20860-3-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
The leds-turris-omnia driver uses three function for I2C access:
- i2c_smbus_write_byte_data() and i2c_smbus_read_byte_data(), which
cause an emulated SMBUS transfer,
- i2c_master_send(), which causes an ordinary I2C transfer.
The Turris Omnia MCU LED controller is not semantically SMBUS, it
operates as a simple I2C bus. It does not implement any of the SMBUS
specific features, like PEC, or procedure calls, or anything. Moreover
the I2C controller driver also does not implement SMBUS, and so the
emulated SMBUS procedure from drivers/i2c/i2c-core-smbus.c is used for
the SMBUS calls, which gives an unnecessary overhead.
When I first wrote the driver, I was unaware of these facts, and I
simply used the first function that worked.
Drop the I2C SMBUS calls and instead use simple I2C transfers.
Fixes: 089381b27a ("leds: initial support for Turris Omnia LEDs")
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230918161104.20860-2-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Use gpiod_set_value_cansleep in the init_device function. Without this
change, the driver may print a warning if the LP55xx enable pin is
connected to a GPIO chip which can sleep (e.g. a GPIO expander):
WARNING: CPU: 0 PID: 2719 at drivers/gpio/gpiolib.c:3051 gpiod_set_value+0x64/0xbc
Signed-off-by: Stefan Eichenberger <eichest@gmail.com>
Link: https://lore.kernel.org/r/20230918143238.75600-1-eichest@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct mt6370_priv.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230915201051.never.429-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct mt6360_priv.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230915201020.never.433-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() is renamed to .remove().
All platform drivers below drivers/leds/ unconditionally return zero in
their remove callback and so can be converted trivially to the variant
returning void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230917130947.1122198-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Make simatic_ipc_leds_gpio_remove() return void instead of returning
zero unconditionally. After that the three remove callbacks that use
this function were trivial to convert to return void, too.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230916164516.1063380-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct lpg_led.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915201059.never.086-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct lm3697.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915201010.never.399-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct gpio_leds_priv.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915201003.never.148-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct el15203000.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915200955.never.871-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct cr0014114.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915200948.never.728-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct aw200xx.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915200938.never.767-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
When building with clang 18 I see the following warning:
| drivers/leds/leds-pca955x.c:487:15: warning: cast to smaller integer
| type 'enum pca955x_type' from 'const void *' [-Wvoid-pointer-to-enum-cast]
| 487 | chip_type = (enum pca955x_type)md;
This is due to the fact that `md` is a void* while `enum pca995x_type` has the
size of an int.
Add uintptr_t cast to silence clang warning while also keeping enum cast
for readability and consistency with other `chip_type` assignment just a
few lines below:
| chip_type = (enum pca955x_type)id->driver_data;
Reported-by: Nathan Chancellor <nathan@kernel.org>
Closes: https://github.com/ClangBuiltLinux/linux/issues/1910
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20230816-void-drivers-leds-leds-pca955x-v1-1-2967e4c1bdcc@google.com
Signed-off-by: Lee Jones <lee@kernel.org>
Instead of requiring each driver to care for assigning the owner member
of struct pwm_ops, handle that implicitly using a macro. Note that the
owner member has to be moved to struct pwm_chip, as the ops structure
usually lives in read-only memory and so cannot be modified.
The upside is that new low level drivers cannot forget the assignment and
save one line each. The pwm-crc driver didn't assign .owner, that's not
a problem in practice though as the driver cannot be compiled as a
module.
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # Intel LPSS
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> # pwm-{bcm,brcm}*.c
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> # sun4i
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> # pwm-visconti
Acked-by: Heiko Stuebner <heiko@sntech.de> # pwm-rockchip
Acked-by: Michael Walle <michael@walle.cc> # pwm-sl28cpld
Acked-by: Neil Armstrong <neil.armstrong@linaro.org> # pwm-meson
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230804142707.412137-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Commit c3f853184b ("leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that
is always false") fixed a no-op BUG_ON. This turned out to cause a
regression, since some in-tree device-tree files already use
LED_COLOR_ID_MULTI.
Drop the BUG_ON altogether.
Fixes: c3f853184b ("leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false")
Reported-by: Da Xue <da@libre.computer>
Closes: https://lore.kernel.org/linux-leds/ZQLelWcNjjp2xndY@duo.ucw.cz/T/
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230918140724.18634-1-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
- Add new framework to support Group Multi-Color (GMC) LEDs
- Offer an 'optional' API for non-essential LEDs
- Support obtaining 'max brightness' values from Device Tree
- Provide new led_classdev member 'color' (settable via DT and SYFS)
- Stop TTY Trigger from using the old LED_ON constraints
- Statically allocate leds_class
- New Drivers
- Add support for NXP PCA995x I2C Constant Current LED Driver
- New Device Support
- Add support for Siemens Simatic IPC BX-21 to Simatic IPC
- Fix-ups
- Some dependency / Kconfig tweaking
- Move final probe() functions back over from .probe_new()
- Simplify obtaining resources (memory, device data) using unified API helpers
- Bunch of Device Tree additions, conversions and adaptions
- Fix trivial styling issues; comments
- Ensure correct includes are present and remove some that are not required
- Omit the use of redundant casts and if relevant replace with better ones
- Use purpose-built APIs for various actions; sysfs_emit(), module_led_trigger()
- Remove a bunch of superfluous locking
- Bug Fixes
- Ensure error codes are correctly propagated back up the call chain
- Fix incorrect error values from being returned (missing '-')
- Ensure get'ed resources are put'ed to prevent leaks
- Use correct class when exporting module resources
- Fixing rounding (or lack there of) issues
- Fix 'always false' LED_COLOR_ID_MULTI BUG() check
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmT15DUACgkQUa+KL4f8
d2ER0BAAoejCCnb24JOrYQy7Pq3/ZaaT6PWOB+/U+6s5jyj9ikwHqqH+g/E+FqkE
AHvhkBalgw1l+QRCvrZMEcsiQmjK5ZR010Ju3lCbvUDa1tsm2Fn/K2IZZxI1j9O8
mGnPjYrX3FRfejscw0a+MA75o3DuN97V9mHNk6lyRnm/d0ronu+vv/fRYFON04iY
v2e166/9wfJWvDwOLo+phDS2aCkjLkxzj2lcTtcvuzYqQjOPDqiFTJsft9gOpC9r
hKOqUkexKebShbi08A+x0fmiB9LNs5kZ3xWWLaxVDT58Plkqv905oLVrWARTGhIG
BDAhW2/TLV30bhSiTb/bX0eNEMCU6q6WIPwc3otUYpkDeLgbxLD7Rlhp49oud7j9
5vWX8bxSczIYRir42TKZ+s/d6pKKSvMrsNRDplFb1ahZTv3ssDxuxAA/FY2UPqTt
C83j0hJOwVfj6ric01R+yedPSW8Po8xqEIzjoxzYtsu3IYGiz6ddjd2ZnhNF5YfP
AN7GDuja9r7+Fa8JcTFssHe6HtuzkfpJvrpjV3BxL79q6s1z+lT9szTw5Z65zGmO
k/z4xz95RHUTbpR4rVT+A1pdbQ8OsbVthdy1XnJoYK3NJYJrPldj3Ur3W4wRecP6
32RWF8ZF6WARsSyyACLo/MP6qxwAE2xk5TjmpLqCeK0ObVmlwDM=
=wNmv
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"Core Frameworks:
- Add new framework to support Group Multi-Color (GMC) LEDs
- Offer an 'optional' API for non-essential LEDs
- Support obtaining 'max brightness' values from Device Tree
- Provide new led_classdev member 'color' (settable via DT and SYFS)
- Stop TTY Trigger from using the old LED_ON constraints
- Statically allocate leds_class
New Drivers:
- Add support for NXP PCA995x I2C Constant Current LED Driver
New Device Support:
- Add support for Siemens Simatic IPC BX-21 to Simatic IPC
Fix-ups:
- Some dependency / Kconfig tweaking
- Move final probe() functions back over from .probe_new()
- Simplify obtaining resources (memory, device data) using unified
API helpers
- Bunch of Device Tree additions, conversions and adaptions
- Fix trivial styling issues; comments
- Ensure correct includes are present and remove some that are not
required
- Omit the use of redundant casts and if relevant replace with better
ones
- Use purpose-built APIs for various actions; sysfs_emit(),
module_led_trigger()
- Remove a bunch of superfluous locking
Bug Fixes:
- Ensure error codes are correctly propagated back up the call chain
- Fix incorrect error values from being returned (missing '-')
- Ensure get'ed resources are put'ed to prevent leaks
- Use correct class when exporting module resources
- Fixing rounding (or lack there of) issues
- Fix 'always false' LED_COLOR_ID_MULTI BUG() check"
* tag 'leds-next-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (40 commits)
leds: aw2013: Enable pull-up supply for interrupt and I2C
dt-bindings: leds: Document pull-up supply for interrupt and I2C
dt-bindings: leds: aw2013: Document interrupt
leds: uleds: Use module_misc_device macro to simplify the code
leds: trigger: netdev: Use module_led_trigger macro to simplify the code
dt-bindings: leds: Fix reference to definition of default-state
leds: turris-omnia: Drop unnecessary mutex locking
leds: turris-omnia: Use sysfs_emit() instead of sprintf()
leds: Make leds_class a static const structure
leds: Remove redundant of_match_ptr()
dt-bindings: leds: Add gpio-line-names to PCA9532 GPIO
leds: trigger: tty: Do not use LED_ON/OFF constants, use led_blink_set_oneshot instead
dt-bindings: leds: rohm,bd71828: Drop select:false
leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false
leds: multicolor: Use rounded division when calculating color components
leds: rgb: Add a multicolor LED driver to group monochromatic LEDs
dt-bindings: leds: Add binding for a multicolor group of LEDs
leds: class: Store the color index in struct led_classdev
leds: Provide devm_of_led_get_optional()
leds: pca995x: Fix MODULE_DEVICE_TABLE for OF
...
Highlights:
- hp-bioscfg: New firmware-attributes driver for changing BIOS settings
from within Linux
- asus-wmi: Add charger mode, middle fan and eGPU settings support
- ideapad: Support keyboard backlight control on more models
- mellanox: Support for new models
- sel-3350: New LED and power-supply driver for this industrial mainboard
- simatic-ipc: Add RTC battery monitor and various new models support
- Miscellaneous other cleanups / fixes
The following is an automated git shortlog grouped by driver:
Add SEL-3350 platform driver:
- Add SEL-3350 platform driver
Documentation/ABI:
- Add new attribute for mlxreg-io sysfs interfaces
MAINTAINERS:
- Add entries for Siemens IPC modules
Merge remote-tracking branch 'intel-speed-select/intel-sst' into review-hans:
- Merge remote-tracking branch 'intel-speed-select/intel-sst' into review-hans
Merge remote-tracking branch 'pdx86/fixes' into pdx86/for-next:
- Merge remote-tracking branch 'pdx86/fixes' into pdx86/for-next
Merge remote-tracking branch 'pdx86/platform-drivers-x86-simatic-ipc' into review-hans:
- Merge remote-tracking branch 'pdx86/platform-drivers-x86-simatic-ipc' into review-hans
Merge tag 'ib-pdx86-simatic-v6.6' into review-hans:
- Merge tag 'ib-pdx86-simatic-v6.6' into review-hans
Merge tag 'ib-pdx86-simatic-v6.6-2' into review-hans:
- Merge tag 'ib-pdx86-simatic-v6.6-2' into review-hans
Move all simatic ipc drivers to the subdirectory siemens:
- Move all simatic ipc drivers to the subdirectory siemens
asus-wmi:
- corrections to egpu safety check
- Fix support for showing middle fan RPM
- expose dGPU and CPU tunables for ROG
- support setting mini-LED mode
- add safety checks to gpu switching
- don't allow eGPU switching if eGPU not connected
- add WMI method to show if egpu connected
- support middle fan custom curves
- add support for showing middle fan RPM
- add support for showing charger mode
dell-sysman:
- Fix reference leak
doc:
- TPMI: Add debugfs documentation
hp-bioscfg:
- Update steps order list elements are evaluated
- Use kmemdup() to replace kmalloc + memcpy
- Remove duplicate use of variable in inner loop
- Change how password encoding size is evaluated
- Change how enum possible values size is evaluated
- Change how order list size is evaluated
- Change how prerequisites size is evaluated
- Replace the word HACK from source code
- Fix uninitialized variable errors
- Fix memory leaks in attribute packages
- fix error reporting in hp_add_other_attributes()
- prevent a small buffer overflow
- fix a signedness bug in hp_wmi_perform_query()
- MAINTAINERS
- Makefile
- surestart-attributes
- string-attributes
- spmobj-attributes
- passwdobj-attributes
- order-list-attributes
- int-attributes
- enum-attributes
- biosattr-interface
- bioscfg
- bioscfg-h
- Documentation
ideapad-laptop:
- Add support for keyboard backlights using KBLC ACPI symbol
leds:
- simatic-ipc-leds: default config switch to platform switch
mlx-platform:
- Add dependency on PCI to Kconfig
mlxbf-bootctl:
- Support sysfs entries for MFG fields
- Support setting the ARM boot state to "OS up"
- Support the large icmc write/read
p2sb:
- Make the Kconfig symbol hidden
platform:
- mellanox: nvsw-sn2201: change fans i2c busses.
- mellanox: mlxreg-hotplug: Extend condition for notification callback processing
- mellanox: Add initial support for PCIe based programming logic device
- mellanox: mlx-platform: Get interrupt line through ACPI
- mellanox: mlx-platform: Introduce ACPI init flow
- mellanox: mlx-platform: Prepare driver to allow probing through ACPI infrastructure
- mellanox: mlx-platform: Add reset callback
- mellanox: Cosmetic changes
- mellanox: mlx-platform: Modify power off callback
- mellanox: mlx-platform: add support for additional CPLD
- mellanox: mlx-platform: Add reset cause attribute
- mellanox: mlx-platform: Modify health and power hotplug action
- mellanox: Modify reset causes description
- mellanox: Add field upgrade capability register
- mellanox: Add new attributes
- Explicitly include correct DT includes
platform/x86/amd/pmc:
- Fix build error with randconfig
- Move PMC driver to separate directory
platform/x86/amd/pmf:
- Fix a missing cleanup path
- Use str_on_off() helper
platform/x86/intel/tpmi:
- Add debugfs interface
- Read feature control status
platform/x86/siemens:
- simatic-ipc-batt: fix logical error for BX-59A
- simatic-ipc: fix logical error for BX-59A
- simatic-ipc-batt: fix wrong pointer pass to PTR_ERR()
- simatic-ipc-batt: add support for module BX-59A
- simatic-ipc: add new models BX-56A/BX-59A
- Kconfig: adjust help text
- simatic-ipc-batt: fix bat reading in BX_21A
simatic-ipc:
- use extra module loading for watchdog
- add auto-loading of hwmon modules
- add another model
- drop PCI runtime depends and header
- add CMOS battery monitoring
- add another model BX-21A
system76:
- Handle new KBLED ACPI methods
thinkpad_acpi:
- Switch to memdup_user_nul() helper
- use lockdep annotations
- take mutex for hotkey_mask_{set,get}
tools/power/x86/intel-speed-select:
- v1.17 release
- Change mem-frequency display name
- Prevent CPU 0 offline
- Error on CPU count exceed in request
- Support more than 8 sockets.
- Fix CPU count display
watchdog:
- simatic: Use idiomatic selection of P2SB
- simatic: add PCI dependency
- make Siemens Simatic watchdog driver default on platform
- simatic-ipc-wdt: make IO region access of one model muxed
wmi-bmof:
- Update MAINTAINERS entry
- Simplify read_bmof()
- Use device_create_bin_file()
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEEuvA7XScYQRpenhd+kuxHeUQDJ9wFAmTx720UHGhkZWdvZWRl
QHJlZGhhdC5jb20ACgkQkuxHeUQDJ9wHYggAgPpl4tcbqUK7S/fwVP2SzBKI+eF3
5PjO7PlMEVzyKyjHdkqoV8miMffWAGVPE+LV33Uifs5WTFjHRq2fq/Esvj9mAstG
1fCoHJ442xYkwNCUT1CCP7VsmcvV5eFXBjBantvwmIs8TyknGHwtq1h+d95evp4n
2uyQlRMmrWh/+8fjD8x5V35T0tky+4a4EX2WNLul13LlHCybGT/F2Kq456WdthjJ
zTQSL+qAMWmAiQKSEmhI3bRnFYPdpTetjiNSTlQczch8Y4qV3mJQlnkyDPX7SM9w
M2uZ4W39Ptxihx0ks/MIcuA4yrTfUX8BnhMTD29ZYCKHS7xBqW8YC5HQug==
=GaQL
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver updates from Hans de Goede:
- hp-bioscfg: New firmware-attributes driver for changing BIOS settings
from within Linux
- asus-wmi: Add charger mode, middle fan and eGPU settings support
- ideapad: Support keyboard backlight control on more models
- mellanox: Support for new models
- sel-3350: New LED and power-supply driver for this industrial
mainboard
- simatic-ipc: Add RTC battery monitor and various new models support
- miscellaneous other cleanups / fixes
* tag 'platform-drivers-x86-v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (101 commits)
platform/x86: asus-wmi: corrections to egpu safety check
platform/x86: mlx-platform: Add dependency on PCI to Kconfig
platform/x86: ideapad-laptop: Add support for keyboard backlights using KBLC ACPI symbol
platform/x86/amd/pmc: Fix build error with randconfig
platform/x86/amd/pmf: Fix a missing cleanup path
watchdog: simatic: Use idiomatic selection of P2SB
platform/x86: p2sb: Make the Kconfig symbol hidden
Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces
platform: mellanox: nvsw-sn2201: change fans i2c busses.
platform: mellanox: mlxreg-hotplug: Extend condition for notification callback processing
platform: mellanox: Add initial support for PCIe based programming logic device
platform: mellanox: mlx-platform: Get interrupt line through ACPI
platform: mellanox: mlx-platform: Introduce ACPI init flow
platform: mellanox: mlx-platform: Prepare driver to allow probing through ACPI infrastructure
platform: mellanox: mlx-platform: Add reset callback
platform: mellanox: Cosmetic changes
platform: mellanox: mlx-platform: Modify power off callback
platform: mellanox: mlx-platform: add support for additional CPLD
platform: mellanox: mlx-platform: Add reset cause attribute
platform: mellanox: mlx-platform: Modify health and power hotplug action
...
Commit b655892ffd ("leds: trigger: netdev: expose hw_control status
via sysfs") exposed to sysfs the flag that tells whether the LED trigger
is offloaded to hardware, under the name "hw_control", since that is the
name under which this setting is called in the code.
Everywhere else in kernel when some work that is normally done in
software can be made to be done by hardware instead, we use the word
"offloading" to describe this, e.g. "LED blinking is offloaded to
hardware".
Normally renaming sysfs entries is a no-go because of backwards
compatibility. But since this patch was not yet released in a stable
kernel, I think it is still possible to rename it, if there is
consensus.
Fixes: b655892ffd ("leds: trigger: netdev: expose hw_control status via sysfs")
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20230821121453.30203-1-kabel@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Request and enable the "vio" regulator that represents the power supply
that is needed for the pull-up resistors of the interrupt and I2C lines
of AW2013. While this regulator is not wired directly to the AW2013
chip it is best managed as part of the AW2013 driver since it decides
when AW2013 is powered on and when the interrupt is enabled or
disabled.
This regulator should always be enabled in conjunction with the main
VCC power supply, so use the bulk regulator functions to enable both
at the same time.
Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com>
[rewrite commit message based on discussion]
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20230815-aw2013-vio-v3-3-2505296b0856@gerhold.net
Signed-off-by: Lee Jones <lee@kernel.org>
Use the module_misc_device macro to simplify the code, which is the
same as declaring with module_init() and module_exit().
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20230815075944.1089298-3-lizetao1@huawei.com
Signed-off-by: Lee Jones <lee@kernel.org>
Use the module_led_trigger macro to simplify the code, which is the
same as declaring with module_init() and module_exit().
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20230815075944.1089298-2-lizetao1@huawei.com
Signed-off-by: Lee Jones <lee@kernel.org>
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: 089381b27a ("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.org
Signed-off-by: Lee Jones <lee@kernel.org>
Use the dedicated sysfs_emit() function instead of sprintf() in sysfs
attribute accessor brightness_show().
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230802160748.11208-4-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
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.com
Signed-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.com
Signed-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: fd4a641ac8 ("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.org
Signed-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: 77dce3a22e ("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.org
Signed-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: 55d5d3b46b ("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.org
Signed-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.com
Signed-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.com
Signed-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.com
Signed-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: ee4e80b296 ("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.de
Signed-off-by: Lee Jones <lee@kernel.org>
Ensure that the offloading of blinking is stopped when the trigger is
deactivated. Calling led_set_brightness() is documented as stopping
offload and setting the LED to a constant brightness.
Suggested-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/20230808210436.838995-5-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When the netdev trigger is activates, it tries to determine what
device the LED blinks for, and what the current blink mode is.
The documentation for hw_control_get() says:
* Return 0 on success, a negative error number on failing parsing the
* initial mode. Error from this function is NOT FATAL as the device
* may be in a not supported initial state by the attached LED trigger.
*/
For the Marvell PHY and the Armada 370-rd board, the initial LED blink
mode is not supported by the trigger, so it returns an error. This
resulted in not getting the device the LED is blinking for. As a
result, the device is unknown and offloaded is never performed.
Change to condition to always get the device if offloading is
supported, and reduce the scope of testing for an error from
hw_control_get() to skip setting trigger internal state if there is an
error.
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/20230808210436.838995-2-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If a user did choose to enable Siemens Simatic platform support they
likely want the LED drivers to be enabled without having to flip more
config switches. So we make the LED drivers config switch default to
the platform driver switches value.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230719153518.13073-3-henning.schild@siemens.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Since commit f9a8ee8c8b ("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.de
Signed-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.org
Signed-off-by: Lee Jones <lee@kernel.org>
Symbol ARCH_BCM4908 has been merged/removed without updating leds
Kconfig.
Fixes: dd5c672d7c ("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.com
Signed-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.com
Signed-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.de
Signed-off-by: Lee Jones <lee@kernel.org>
Negative -EINVAL was intended, not positive EINVAL. Fix it.
Fixes: 95138e0127 ("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.mountain
Signed-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.com
Signed-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: a6c80bec3c ("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.org
Signed-off-by: Lee Jones <lee@kernel.org>
- Add support for Intel Cherry Trail Whiskey Cove PMIC LEDs
- Add support for Awinic AW20036/AW20054/AW20072 LEDs
- New Device Support
- Add support for PMI632 LPG to QCom LPG
- Add support for PMI8998 to QCom Flash
- Add support for MT6331, WLEDs and MT6332 to Mediatek MT6323 PMIC
- New Functionality
- Implement the LP55xx Charge Pump
- Add support for suspend / resume to Intel Cherry Trail Whiskey Cove PMIC
- Add support for breathing mode to Intel Cherry Trail Whiskey Cove PMIC
- Enable per-pin resolution Pinctrl in LEDs GPIO
- Fix-ups
- Allow thread to sleep by switching from spinlock to mutex
- Add lots of Device Tree bindings / support
- Adapt relationships / dependencies driven by Kconfig
- Switch I2C drivers from .probe_new() to .probe()
- Remove superfluous / duplicate code
- Replace strlcpy() with strscpy() for efficiency and overflow prevention
- Staticify various functions
- Trivial: Fixing coding style
- Simplify / reduce code
- Bug Fixes
- Prevent NETDEV_LED_MODE_LINKUP from being cleared on rename
- Repair race between led_set_brightness(LED_{OFF,FULL})
- Fix Oops relating to sleeping in critical sections
- Clear LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger
- Do not leak resources in error handling paths
- Fix unsigned comparison which can never be negative
- Provide missing NULL terminating entries in tables
- Fix misnaming issues
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmSinb0ACgkQUa+KL4f8
d2FYfg//WWLVfXRuRpY9ueOxvWj65WVPQSQ+wzF/vRTweogR+lN0qxNPH6yT943z
ap2EBxpWf84zCifYG4yhTEYDHQT+nH1fIz6xaK29DK8sCQi4WdRpHuE2pE30R/tf
Q7SyZi9DlWyoqNiqgNNCl7vkTaHpO3trxoxfEfN2YIB0npLf8yyWRz4feVXXsYtg
41S4Mo7oTxphd7OLvw9PKogdTbT29vBMXen8jzv5g8FObj1Gheg0frq2t2W+bfAl
27cJJJS7he4/WLCDzXVQfB46Nva5NpqHiANbgOAApDGx3hFCzZFTCg6K7+VucpjY
bNz3pqmslT5uJxMjqNz8fCSzwWTjyKLHBeGsIT/4HBXD4DnfFbWz9HYkorfNgsu2
lKEp0SYhSmmuS8IVzJvqDqXg6k21hGpuR9P+dI7teoClh0qLTMCz2L2c9p2zNfth
0W+WeLYQ67QTRH9EcHo3dlZH/mP/J1jGmUDbF+DFI6bHsg2iahZUA6ixD18E7sWE
RwtCnb3xyn7eoDe3LwJdKtJMyrX59MbFWqozij2NNhvduXc+m1kH/DX5CSaBUVwf
RtfDZwWHf4qK4CipuuqOLd5fiUArJ3TSHBxXkoo0Wz7NYXK9k86eIZgWrgdEbvuA
oHmSousS19Eiscjtzxl7OjvDJMRc0rTJfD7LzYoHQBL4Vpnd8VI=
=9kd5
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"New Drivers:
- Add support for Intel Cherry Trail Whiskey Cove PMIC LEDs
- Add support for Awinic AW20036/AW20054/AW20072 LEDs
New Device Support:
- Add support for PMI632 LPG to QCom LPG
- Add support for PMI8998 to QCom Flash
- Add support for MT6331, WLEDs and MT6332 to Mediatek MT6323 PMIC
New Functionality:
- Implement the LP55xx Charge Pump
- Add support for suspend / resume to Intel Cherry Trail Whiskey Cove PMIC
- Add support for breathing mode to Intel Cherry Trail Whiskey Cove PMIC
- Enable per-pin resolution Pinctrl in LEDs GPIO
Fix-ups:
- Allow thread to sleep by switching from spinlock to mutex
- Add lots of Device Tree bindings / support
- Adapt relationships / dependencies driven by Kconfig
- Switch I2C drivers from .probe_new() to .probe()
- Remove superfluous / duplicate code
- Replace strlcpy() with strscpy() for efficiency and overflow prevention
- Staticify various functions
- Trivial: Fixing coding style
- Simplify / reduce code
Bug Fixes:
- Prevent NETDEV_LED_MODE_LINKUP from being cleared on rename
- Repair race between led_set_brightness(LED_{OFF,FULL})
- Fix Oops relating to sleeping in critical sections
- Clear LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger
- Do not leak resources in error handling paths
- Fix unsigned comparison which can never be negative
- Provide missing NULL terminating entries in tables
- Fix misnaming issues"
* tag 'leds-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (53 commits)
leds: leds-mt6323: Adjust return/parameter types in wled get/set callbacks
leds: sgm3140: Add richtek,rt5033-led compatible
dt-bindings: leds: sgm3140: Document richtek,rt5033 compatible
dt-bindings: backlight: kinetic,ktz8866: Add missing type for "current-num-sinks"
dt-bindings: leds: Drop unneeded quotes
leds: Fix config reference for AW200xx driver
leds: leds-mt6323: Add support for WLEDs and MT6332
leds: leds-mt6323: Add support for MT6331 leds
leds: leds-mt6323: Open code and drop MT6323_CAL_HW_DUTY macro
leds: leds-mt6323: Drop MT6323_ prefix from macros and defines
leds: leds-mt6323: Specify registers and specs in platform data
dt-bindings: leds: leds-mt6323: Document mt6332 compatible
dt-bindings: leds: leds-mt6323: Document mt6331 compatible
leds: simatic-ipc-leds-gpio: Introduce more Kconfig switches
leds: simatic-ipc-leds-gpio: Split up into multiple drivers
leds: simatic-ipc-leds-gpio: Move two extra gpio pins into another table
leds: simatic-ipc-leds-gpio: Add terminating entries to gpio tables
leds: flash: leds-qcom-flash: Fix an unsigned comparison which can never be negative
leds: cht-wcove: Remove unneeded semicolon
leds: cht-wcove: Fix an unsigned comparison which can never be negative
...
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: 9bb0a9e062 ("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>
Expose hw_control status via sysfs for the netdev trigger to give
userspace better understanding of the current state of the trigger and
the LED.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add additional modes for specific link duplex. Use ethtool APIs to get the
current link duplex and enable the LED accordingly. Under netdev event
handler the rtnl lock is already held and is not needed to be set to
access ethtool APIs.
This is especially useful for PHY and Switch that supports LEDs hw
control for specific link duplex.
Add additional modes:
- half_duplex: Turn on LED when link is half duplex
- full_duplex: Turn on LED when link is full duplex
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add additional modes for specific link speed. Use ethtool APIs to get the
current link speed and enable the LED accordingly. Under netdev event
handler the rtnl lock is already held and is not needed to be set to
access ethtool APIs.
This is especially useful for PHY and Switch that supports LEDs hw
control for specific link speed. (example scenario a PHY that have 2 LED
connected one green and one orange where the green is turned on with
1000mbps speed and orange is turned on with 10mpbs speed)
On mode set from sysfs we check if we have enabled split link speed mode
and reject enabling generic link mode to prevent wrong and redundant
configuration.
Rework logic on the set baseline state to support these new modes to
select if we need to turn on or off the LED.
Add additional modes:
- link_10: Turn on LED when link speed is 10mbps
- link_100: Turn on LED when link speed is 100mbps
- link_1000: Turn on LED when link speed is 1000mbps
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 36a87f371b ("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: 36a87f371b ("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.com
Signed-off-by: Lee Jones <lee@kernel.org>
The qca8k_cled_hw_control_get() function which implements ->hw_control_get
sets the appropriate bits but does not clear them. This leads to an
uninitialized variable bug. Fix this by setting mode to zero at the
start.
Fixes: e0256648c8 ("net: dsa: qca8k: implement hw_control ops")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
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
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
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
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
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
Cross-merge networking fixes after downstream PR.
Conflicts:
net/sched/sch_taprio.c
d636fc5dd6 ("net: sched: add rcu annotations around qdisc->qdisc_sleeping")
dced11ef84 ("net/sched: taprio: don't overwrite "sch" variable in taprio_dump_class_stats()")
net/ipv4/sysctl_net_ipv4.c
e209fee411 ("net/ipv4: ping_group_range: allow GID from 2147483648 to 4294967294")
ccce324dab ("tcp: make the first N SYN RTO backoffs linear")
https://lore.kernel.org/all/20230605100816.08d41a7b@canb.auug.org.au/
No adjacent changes.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230524124628.32295-5-henning.schild@siemens.com
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 <henning.schild@siemens.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230524124628.32295-4-henning.schild@siemens.com
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 <henning.schild@siemens.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230524124628.32295-3-henning.schild@siemens.com
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: Henning Schild <henning.schild@siemens.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230524124628.32295-2-henning.schild@siemens.com
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=5344
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230531053559.5702-1-jiapeng.chong@linux.alibaba.com
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: Abaci Robot <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5341
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230531020238.102684-1-yang.lee@linux.alibaba.com
