Commit graph

11 commits

Author SHA1 Message Date
Fabio Baltieri
39e56e9a71 led: drop a bunch of now redundant brightness validations
This check is now part of the API, individual drivers don't need to do
it.

Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2025-05-14 16:27:18 +02:00
Fabio Baltieri
6f47466899 led: drop a bunch of on/off wrappers
These are now handled at API level, drop them from the drivers.

Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2025-05-14 16:27:18 +02:00
Fabio Baltieri
551c1363dd led: add and use a LED_BRIGTHNESS_MAX definition
The led_set_brightness API says that brightness is defined as
percentage, add a macro from the max and use it everywhere.

Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2025-05-14 16:27:18 +02:00
Yishai Jaffe
c09930ed30 drivers: led: Place API into iterable section
Add wrapper DEVICE_API macro to all led_driver_api instances.

Signed-off-by: Yishai Jaffe <yishai1999@gmail.com>
2024-12-02 22:07:36 +00:00
Gerard Marull-Paretas
79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.

The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.

NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-09-05 16:31:47 +02:00
Gerard Marull-Paretas
40542638fd drivers: led: gpio: use DT_INST_FOREACH_CHILD_SEP_VARGS
Avoid auxiliary macros by using DT_INST_FOREACH_CHILD_SEP_VARGS

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-08-30 16:19:57 +02:00
Gerard Marull-Paretas
fb60aab245 drivers: migrate includes to <zephyr/...>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-06 19:58:21 +02:00
Jordan Yates
7eb48adb52 drivers: led_gpio: use gpio_pin_set_dt
Use the simpler version of `gpio_pin_set` to demonstrate usage.

Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
2021-06-24 06:40:00 -05:00
Martí Bolívar
5cb95c4ce6 drivers: led_gpio: minor tweaks
Two minor tweaks and a semantics change:

- fix a whitespace nit
- use gpio_pin_configure_dt()
- turn the LED on in case the percentage is nonzero

The last change patterns this driver after behavior in the Android
lights HAL, which recommends analogous behavior when the user requests
a color change in a non-RGB LED:

    Do your best here. [...] If you can only do on or off, 0 is off,
    anything else is on.

    https://source.android.com/reference/hal/structlight__state__t

I think this behavior makes more sense.

Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2021-05-04 16:01:30 +02:00
Gerard Marull-Paretas
40e9cb675c drivers: led: remove usage of device_pm_control_nop
device_pm_control_nop is now deprecated in favour of NULL.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2021-04-28 11:25:42 -04:00
Marek Pieta
a712c3622d drivers: led: Add LED GPIO driver
Change introduces LED GPIO driver.

Signed-off-by: Marek Pieta <Marek.Pieta@nordicsemi.no>
2021-04-27 16:21:48 +02:00