The trigger_data->hw_control indicates whether the LED is controlled by HW
offload, i.e. the PHY. The trigger_data->hw_control = can_hw_control() is
currently called only from netdev_led_attr_store(), i.e. when writing any
sysfs attribute of the netdev trigger instance associated with a PHY LED.
The can_hw_control() calls validate_net_dev() which internally calls
led_cdev->hw_control_get_device(), which is phy_led_hw_control_get_device()
for PHY LEDs. The phy_led_hw_control_get_device() returns NULL if the PHY
is not attached.
At least in case of DWMAC (STM32MP, iMX8M, ...), the PHY device is attached
only when the interface is brought up and is detached again when the
interface is brought down. In case e.g. udev rules configure the netdev
LED trigger sysfs attributes before the interface is brought up, then when
the interface is brought up, the LEDs are not blinking.
This is because trigger_data->hw_control = can_hw_control() was called
when udev wrote the sysfs attribute files, before the interface was up,
so can_hw_control() resp. validate_net_dev() returned false, and the
trigger_data->hw_control = can_hw_control() was never called again to
update the trigger_data->hw_control content and let the offload take
over the LED blinking.
Call data->hw_control = can_hw_control() from netdev_trig_notify() to
update the offload capability of the LED when the UP notification arrives.
This makes the LEDs blink after the interface is brought up.
On STM32MP13xx with RTL8211F, it is enough to have the following udev rule
in place, boot the machine with cable plugged in, and the LEDs won't work
without this patch once the interface is brought up, even if they should:
"
ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:green:wan", ATTR{trigger}="netdev", ATTR{link_10}="1", ATTR{link_100}="1", ATTR{link_1000}="1", ATTR{device_name}="end0"
ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:yellow:wan", ATTR{trigger}="netdev", ATTR{rx}="1", ATTR{tx}="1", ATTR{device_name}="end0"
"
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20241216104826.6946-1-marex@denx.de
Signed-off-by: Lee Jones <lee@kernel.org>
This patch provides support for enabling blinking of LEDs when RX or TX
errors are detected.
Approach taken in this patch is similar to one for TX or RX data
transmission indication (i.e. TRIGGER_NETDEV_TX/RX attribute).
One can inspect transmission errors with:
ip -s link show eth0
Example LED configuration:
cd /sys/devices/platform/amba_pl@0/a001a000.leds/leds/
echo netdev > mode:blue/trigger && \
echo eth0 > mode:blue/device_name && \
echo 1 > mode:blue/tx_err
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20240710100651.4059887-1-lukma@denx.de
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>
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>
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>
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>
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>
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>
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"
...
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>
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>
