This clarification makes Zephyr's LED brightness API match the
behavior that both the Android lights HAL and Linux's userspace LED
drivers expose.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Return -ENOSYS when implementation is missing and -ENOTSUP if the
feature is not supported. Those are 2 things. Missing implementation
(-ENOSYS) means that the driver is lacking support for the feature,
-ENOTSUP means we have an implementation but some parameters or
conditions makes the request unsupported.
Also, explicitly check for NULL.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Some LED controllers are connected to a large number of LEDs (i.e.
array/strip of LEDs). A user may need to set several LEDs at the same
time. The LED oriented syscalls are not adapted to this task. Indeed a
call per LED is needed to configure a group of LEDs. To that end, this
patch adds the led_set_channel and led_write_channels syscalls to the
LED API. They offer direct access to the raw channels. They respectively
allow to set a single channel and to write several contiguous channels
(and therefore to configure a group of LEDs).
Moreover the addition of the led_write_channels syscall also aims at
closing the gap with the LED strip API.
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
Signed-off-by: Maxime Bittan <maxime.bittan@seagate.com>
For the LED controller without any hardware blinking capability this
doesn't really make sense to make the blink callback mandatory. It is
better to let it undefined. This way this will allow the LED API to
fall back to a common software blink implementation.
In addition some controllers with RGB LEDs don't have the capability
to configure the LED brightness but only the channel/color levels.
Their drivers may only implement the set_color callback.
That's why this patch makes the blink and set_brightness LED API
callbacks optional.
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
The led_set_color syscall adds support for multicolor (i.e.
multi-channel) LEDs to the LED API. It allows a user to set all the
colors/channels of a LED at once by passing a color array. Note that
this array must provide an entry per color/channel and must also be
ordered following the color mapping of the LED. This color mapping can
be either retrieved from the "color-mapping" DT property or from the LED
driver itself (by using the led_get_info syscall).
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
When supported by the driver the led_get_info syscall allows a user
to retrieve the following information about each LED available:
- The LED label.
- The number of colors/channels.
- And for a multicolor LED a pointer to a channel-color mapping.
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
Signed-off-by: Maxime Bittan <maxime.bittan@seagate.com>
Actually the LED API functions are handling channel objects. The "led"
parameter passed to the functions is defined as a channel number. This
patch redefines it as a LED number instead.
Note that this patch doesn't change anything for the drivers handling
mono-color (or single channel) LEDs. For the drivers handling multicolor
(or multi-channel) LEDs, such as the lp5562, then the API is broken.
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
This change removes the hardcoded subsystem list in gen_kobject_list.py
favor of marking the relevant driver API structs with the _subsystem
sentinel.
Signed-off-by: Corey Wharton <coreyw7@fb.com>
The automated process used to remove implicit casts resulted in code
that exceeded the documented line length limits. Break the assignment
into two lines where this happened.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
C++ disallows implicit cast of void pointers to a non-void pointer
type. Presence of implicit casts prevents use of these headers in C++
applications.
Process: Run the following coccinelle script:
@@
identifier V;
identifier TAG =~ "driver_api";
type T;
expression E;
@@
T* V =
+(T *)
E->TAG;
in this command line from $ZEPHYR_BASE:
spatch --sp-file expcast.cocci \
--include-headers --dir include/ --very-quiet \
| sed -e '/^\+/s@\*) @*)@' \
| (cd include/ ; patch -p1)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
move led.h to drivers/led.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
