JIRA: https://issues.redhat.com/browse/RHEL-59052
CVE: CVE-2024-42129
Conflicts:
* Avoiding commit <606130209230> ("leds: Convert all platform drivers to
return void")
commit efc347b9efee1c2b081f5281d33be4559fa50a16
Author: George Stark <gnstark@salutedevices.com>
Date: Thu, 11 Apr 2024 19:10:31 +0300
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>
Signed-off-by: Desnes Nunes <desnesn@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-54835
CVE: CVE-2024-43830
commit c0dc9adf9474ecb7106e60e5472577375aedaed3
Author: Hans de Goede <hdegoede@redhat.com>
Date: Sat May 4 18:25:33 2024 +0200
leds: trigger: Unregister sysfs attributes before calling deactivate()
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>
Signed-off-by: CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-43483
commit e7431bd7899c955e126c742fe608512f7e2e111a
Author: Stefan Wahren <wahrenst@gmx.net>
Date: Sat Dec 2 19:36:36 2023 +0100
leds: gpio: Add kernel log if devm_fwnode_gpiod_get() fails
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>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-43483
commit 2038d3fdc7434d522369c58cb7a4acd5315eebec
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon Oct 16 19:10:05 2023 +0300
leds: gpio: Update headers
Include headers which we are direct users of, no need
to have proxies.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231016161005.1471768-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-43483
commit 7b2d8a059c77344eca0f5281f97224d1accfb88a
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon Oct 16 19:10:04 2023 +0300
leds: gpio: Remove unneeded assignment
The initial ret is not used anywhere, drop the unneeded assignment.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231016161005.1471768-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-43483
commit 54e657d604ae27a30ce4f84c243661d9b744bbce
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon Oct 16 19:10:03 2023 +0300
leds: gpio: Move temporary variable for struct device to gpio_led_probe()
Use temporary variable for struct device in gpio_led_probe() in order
to make code neater.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231016161005.1471768-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-43483
commit 5ac50ec712921f6250188732387bf5dac33736ae
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon Oct 16 19:10:02 2023 +0300
leds: gpio: Refactor code to use devm_gpiod_get_index_optional()
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>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-43483
commit f5ad594e389c57dfe19059ce868392809f9b1a71
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon Oct 16 19:10:01 2023 +0300
leds: gpio: Utilise PTR_ERR_OR_ZERO()
Avoid a boilerplate code by using PTR_ERR_OR_ZERO() in create_gpio_led().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231016161005.1471768-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-43483
commit e80fc4bfc820aa44c500cf4c61e08765f36d3c63
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon Oct 16 19:10:00 2023 +0300
leds: gpio: Keep driver firmware interface agnostic
The of.h is used as a proxy to mod_devicetable, replace former by
latter.
The commit 2d6180147e92 ("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>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-43483
commit 52cd75108a426bdd43161d0e73e7bee95d103ed1
Author: Kees Cook <keescook@chromium.org>
Date: Fri Sep 15 13:10:04 2023 -0700
leds: gpio: Annotate struct gpio_leds_priv with __counted_by
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>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-43483
commit 2d6180147e924b76b75b8b1e59bbf0c59c2a29d2
Author: Marek Vasut <marex@denx.de>
Date: Tue May 23 20:31:51 2023 +0200
leds: gpio: Configure per-LED pin control
Each gpio-leds DT node DT subnode can have a pinctrl property assigned
to it, parse the DT subnode pinctrl properties and configure each pin
accordingly.
Tested-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20230523183151.5460-1-marex@denx.de
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-43483
commit a055204b063ade914e6dd6e270d3c2c0453a3cf5
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Fri Sep 2 17:55:25 2022 -0700
leds: gpio: switch to using devm_fwnode_gpiod_get()
devm_fwnode_get_gpiod_from_child() is going away as the name is too
unwieldy, let's switch to using the new devm_fwnode_gpiod_get().
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-43483
commit 791bc41163c51f870972d6c6b82d971ce951096c
Author: Denis Osterland-Heim <Denis.Osterland@diehl.com>
Date: Tue Jun 8 08:35:53 2021 +0200
leds: move default_state read from fwnode to core
This patch introduces a new function to read initial
default_state from fwnode.
Suggested-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 415798bc07dd1c1ae3a656aa026580816e0b9fe8
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Sun Feb 4 00:54:01 2024 +0100
leds: trigger: netdev: Fix kernel panic on interface rename trig notify
Commit d5e01266e7f5 ("leds: trigger: netdev: add additional specific link
speed mode") in the various changes, reworked the way to set the LINKUP
mode in commit cee4bd16c319 ("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: d5e01266e7f5 ("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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 7eef64da0b0ad8e90409fc4aa80eb69c1b4bdd2c
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat Dec 9 23:54:51 2023 +0100
leds: trigger: panic: Simplify led_trigger_set_panic
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 7e1121138cececbdc8827b0b6a5d4a1ea2aed4e7
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon Jan 15 22:46:23 2024 +0100
leds: triggers: default-on: Add module alias for module auto-loading
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit cdac0fd2b7654042a80fa63b50f2b2d8ff2bf48c
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat Jan 13 17:00:11 2024 +0100
leds: trigger: audio: Set module alias for module auto-loading
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 06cdca014eca3449d8c34bf7c2fcb796a114a0b8
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Thu Jan 11 17:04:54 2024 +0100
leds: trigger: netdev: Display only supported link speed attribute
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit f574751cdfac6645a050e64ea3107a57ae13b816
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu Dec 21 18:31:48 2023 +0100
leds: trigger: netdev: Skip setting baseline state in activate if hw-controlled
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 4289e434c46c8cbd32cf8b67fa7689b3d2ca4361
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun Dec 17 19:46:42 2023 +0100
leds: trigger: netdev: Add core support for hw not supporting fallback to LED sw control
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit afacb21834bb02785ddb0c3ec197208803b74faa
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat Dec 16 21:05:33 2023 +0100
leds: trigger: panic: Don't register panic notifier if creating the trigger failed
It doesn't make sense to register the panic notifier if creating the
panic trigger failed.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/8a61e229-5388-46c7-919a-4d18cc7362b2@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit c82a1662d4548c454de5343b88f69b9fc82266b3
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri Dec 8 23:56:41 2023 +0100
leds: trigger: Remove unused function led_trigger_rename_static()
This function was added with a8df7b1ab7 ("leds: add led_trigger_rename
function") 11 yrs ago, but it has no users. So remove it.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/d90f30be-f661-4db7-b0b5-d09d07a78a68@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 6dec659896b4e683beaea223d306e71e174e84cd
Author: Florian Eckert <fe@dev.tdt.de>
Date: Mon Nov 27 12:03:11 2023 +0100
leds: ledtrig-tty: Add additional line state evaluation
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 5b755ca677dba117063c6fd8d7ce21b67376deba
Author: Florian Eckert <fe@dev.tdt.de>
Date: Mon Nov 27 12:03:10 2023 +0100
leds: ledtrig-tty: Make rx tx activitate configurable
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 76675f69bed5f1e8ae44ba72904ff7f97aa95c0a
Author: Florian Eckert <fe@dev.tdt.de>
Date: Mon Nov 27 12:03:09 2023 +0100
leds: ledtrig-tty: Replace mutex with completion
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 25054b232681c286fca9c678854f56494d1352cc
Author: Florian Eckert <fe@dev.tdt.de>
Date: Mon Nov 27 09:16:21 2023 +0100
leds: ledtrig-tty: Free allocated ttyname buffer on deactivate
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 7b9c5500f42e92992fe7b012974e0dddb673b1f5
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri Nov 3 21:53:09 2023 +0200
leds: trigger: gpio: Use sysfs_emit() to instead of s*printf()
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 7d6766f5377686b871ab52c564327718ece233ad
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri Nov 3 21:53:08 2023 +0200
leds: trigger: gpio: Convert to use kstrtox()
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 9bbd6b7209cf1e26390975b7617a29901c8990a1
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri Nov 3 21:53:07 2023 +0200
leds: trigger: gpio: Replace custom code for gpiod_get_optional()
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 59b3e31e73322ec195e45e0a1da712c752ee1b0c
Author: Daniel Golle <daniel@makrotopia.org>
Date: Tue Nov 28 04:00:10 2023 +0000
leds: trigger: netdev: Extend speeds up to 10G
Add 2.5G, 5G and 10G as available speeds to the netdev LED trigger.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/99e7d3304c6bba7f4863a4a80764a869855f2085.1701143925.git.daniel@makrotopia.org
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 259e33cbb1712a7dd844fc9757661cc47cb0e39b
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Sat Oct 7 15:10:42 2023 +0200
leds: trigger: netdev: Move size check in set_device_name
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: 28a6a2ef18ad ("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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 4a11dbf04f31c71eb458c062129e95b7aa308464
Author: Linus Walleij <linus.walleij@linaro.org>
Date: Tue Sep 26 23:48:13 2023 +0200
leds: triggers: gpio: Rewrite to use trigger-sources
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 8f0adae1cb1a3cf83e38dd435831baa38dd84b4c
Author: Linus Walleij <linus.walleij@linaro.org>
Date: Tue Mar 14 22:00:59 2023 +0100
leds: Mark GPIO LED trigger broken
The GPIO LED trigger exposes a userspace ABI where a user
can echo a GPIO number from the global GPIO numberspace into
a file that will trigger a certain LED when active.
This is problematic because the global GPIO numberspace is
inherently instable. The trigger came about at a time when
systems had one GPIO controller that defined hard-wired
GPIOs numbered 0..N and this number space was stable.
We have since moved to dynamic allocation of GPIO numbers
and there is no real guarantee that a GPIO number will stay
consistent even across a reboot: consider a USB attached
GPIO controller for example. Or two. Or the effect of
probe order after adding -EPROBE_DEFER to the kernel.
The trigger was added to support keypad LEDs on the Nokia
n810 from the GPIO event when a user slides up/down the
keypad. This is arch/arm/boot/dts/omap2420-n810.dts.
A userspace script is needed to activate the trigger.
This will be broken unless the script was updated recently
since the OMAP GPIO controller now uses dynamic GPIO
number allocations.
I want to know that this trigger has active users that
cannot live without it if we are to continue to support it.
Option if this is really needed: I can develop a new trigger
that can associate GPIOs with LEDs as triggers using device
tree, which should also remove the use of userspace custom
scripts to achieve this and be much more trustworthy, if
someone with the Nokia n810 or a device with a similar need
is willing to test it.
Suggested-by Pavel Machek <pavel@ucw.cz>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230314210059.419159-1-linus.walleij@linaro.org
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit ff50f53276131a3059e8307d11293af388ed2bcd
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sat Sep 23 09:15:38 2023 +0200
leds: trigger: ledtrig-cpu:: Fix 'output may be truncated' issue for 'cpu'
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 44f0fb8dfe263e27ac95d502a58586fe95fd5958
Author: Marek Behún <kabel@kernel.org>
Date: Mon Aug 21 14:14:53 2023 +0200
leds: trigger: netdev: rename 'hw_control' sysfs entry to 'offloaded'
Commit b655892ffd6d ("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: b655892ffd6d ("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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 74cd23e87d7b5ebd5185d3930a7d95fbd859a256
Author: Li Zetao <lizetao1@huawei.com>
Date: Tue Aug 15 15:59:43 2023 +0800
leds: trigger: netdev: Use module_led_trigger macro to simplify the code
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 730094577e0c37e1bc40be37cbd41f71b0a8a2a4
Author: Marek Behún <kabel@kernel.org>
Date: Wed Aug 2 11:07:53 2023 +0200
leds: trigger: tty: Do not use LED_ON/OFF constants, use led_blink_set_oneshot instead
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit e8fbcc47a8e935f36f044d85f21a99acecbd7bfb
Author: Andrew Lunn <andrew@lunn.ch>
Date: Tue Aug 8 23:04:36 2023 +0200
leds: trig-netdev: Disable offload on deactivation of trigger
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 7df1f14c04cbb1950e79c19793420f87227c3e80
Author: Andrew Lunn <andrew@lunn.ch>
Date: Tue Aug 8 23:04:33 2023 +0200
led: trig: netdev: Fix requesting offload device
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit b655892ffd6d89b0c7407e099c40dbde82ee3f03
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Mon Jun 19 22:47:00 2023 +0200
leds: trigger: netdev: expose hw_control status via sysfs
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit f22f95b9ff1551c9bab13104131929f33d51f23f
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Mon Jun 19 22:46:59 2023 +0200
leds: trigger: netdev: add additional specific link duplex mode
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
Conflicts: Just a context difference due to linearization of the git
history. The backport of commit af7320ecae0c ("leds: trigger: netdev:
Remove NULL check before dev_{put, hold}") precedes this one.
commit d5e01266e7f5fa12400d4c8aa4e86fe89dcc61e9
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Mon Jun 19 22:46:58 2023 +0200
leds: trigger: netdev: add additional specific link speed mode
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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 97c5209b3d374a25ebdb4c2ea9e9c1b121768da0
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date: Wed Jun 14 10:03:59 2023 +0300
leds: trigger: netdev: uninitialized variable in netdev_trig_activate()
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: e0256648c831 ("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>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 947acacab5ea151291b861cdfbde16ff5cf1b08c
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Mon May 29 18:32:41 2023 +0200
leds: trigger: netdev: expose netdev trigger modes in linux include
Expose netdev trigger modes to make them accessible by LED driver that
will support netdev trigger for hw control.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 0316cc5629d15880dd3f097d221c55ca648bcd61
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Mon May 29 18:32:40 2023 +0200
leds: trigger: netdev: init mode if hw control already active
On netdev trigger activation, hw control may be already active by
default. If this is the case and a device is actually provided by
hw_control_get_device(), init the already active mode and set the
bool to hw_control bool to true to reflect the already set mode in the
trigger_data.
Co-developed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 33ec0b53befff2c0a7f3aa19ff08556d60585d6b
Author: Andrew Lunn <andrew@lunn.ch>
Date: Mon May 29 18:32:39 2023 +0200
leds: trigger: netdev: validate configured netdev
The netdev which the LED should blink for is configurable in
/sys/class/led/foo/device_name. Ensure when offloading that the
configured netdev is the same as the netdev the LED is associated
with. If it is not, only perform software blinking.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-32110
commit 7c145a34ba6e380616af93262fcab9fc7261d851
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Mon May 29 18:32:38 2023 +0200
leds: trigger: netdev: add support for LED hw control
Add support for LED hw control for the netdev trigger.
The trigger on calling set_baseline_state to configure a new mode, will
do various check to verify if hw control can be used for the requested
mode in can_hw_control() function.
It will first check if the LED driver supports hw control for the netdev
trigger, then will use hw_control_is_supported() and finally will call
hw_control_set() to apply the requested mode.
To use such mode, interval MUST be set to the default value and net_dev
MUST be set. If one of these 2 value are not valid, hw control will
never be used and normal software fallback is used.
The default interval value is moved to a define to make sure they are
always synced.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Desnes Nunes
CKI Backport Bot
Radu Rendec
Michal Schmidt