kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/drivers/leds/trigger/ledtrig-netdev.c

765 lines
21 KiB
Raw Normal View History

leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-06-19 22:46:58 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2024-01-11 17:04:54 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Use mutex instead of spinlocks Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-6-ansuelsmth@gmail.com
2023-04-19 23:07:43 +02:00
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>
2024-01-11 17:04:54 +01:00
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>
2023-06-19 22:46:58 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-05-29 18:32:38 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Add support for tx_err and rx_err notification with LEDs 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>
2024-07-10 12:06:51 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-12-17 19:46:42 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Use mutex instead of spinlocks Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-6-ansuelsmth@gmail.com
2023-04-19 23:07:43 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-06-19 22:46:58 +02:00
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>
2024-01-11 17:04:54 +01:00
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>
2023-06-19 22:46:59 +02:00
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>
2023-06-19 22:46:58 +02:00
leds: trigger: netdev: Drop NETDEV_LED_MODE_LINKUP from mode Putting NETDEV_LED_MODE_LINKUP in the same list of the netdev trigger modes is wrong as it's used to set the link state of the device and not to set a blink mode as it's done by NETDEV_LED_LINK, NETDEV_LED_TX and NETDEV_LED_RX. It's also wrong to put this state in the same bitmap of the netdev trigger mode and should be external to it. Drop NETDEV_LED_MODE_LINKUP from mode list and convert to a simple bool that will be true or false based on the carrier link. No functional change intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-3-ansuelsmth@gmail.com
2023-04-19 23:07:40 +02:00
leds: trigger: netdev: introduce check for possible hw control Introduce function to check if the requested mode can use hw control in preparation for hw control support. Currently everything is handled in software so can_hw_control will always return false. Add knob with the new value hw_control in trigger_data struct to set hw control possible. Useful for future implementation to implement in set_baseline_state() the required function to set the requested mode using LEDs hw control ops and in other function to reject set if hw control is currently active. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-29 18:32:35 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2024-01-11 17:04:54 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-05-29 18:32:38 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Drop NETDEV_LED_MODE_LINKUP from mode Putting NETDEV_LED_MODE_LINKUP in the same list of the netdev trigger modes is wrong as it's used to set the link state of the device and not to set a blink mode as it's done by NETDEV_LED_LINK, NETDEV_LED_TX and NETDEV_LED_RX. It's also wrong to put this state in the same bitmap of the netdev trigger mode and should be external to it. Drop NETDEV_LED_MODE_LINKUP from mode list and convert to a simple bool that will be true or false based on the carrier link. No functional change intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-3-ansuelsmth@gmail.com
2023-04-19 23:07:40 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Drop NETDEV_LED_MODE_LINKUP from mode Putting NETDEV_LED_MODE_LINKUP in the same list of the netdev trigger modes is wrong as it's used to set the link state of the device and not to set a blink mode as it's done by NETDEV_LED_LINK, NETDEV_LED_TX and NETDEV_LED_RX. It's also wrong to put this state in the same bitmap of the netdev trigger mode and should be external to it. Drop NETDEV_LED_MODE_LINKUP from mode list and convert to a simple bool that will be true or false based on the carrier link. No functional change intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-3-ansuelsmth@gmail.com
2023-04-19 23:07:40 +02:00
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>
2023-06-19 22:46:58 +02:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
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>
2023-06-19 22:46:58 +02:00
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>
2023-11-28 04:00:10 +00:00
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>
2023-06-19 22:46:59 +02:00
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>
2023-06-19 22:46:58 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
leds: trigger: netdev: Add support for tx_err and rx_err notification with LEDs 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>
2024-07-10 12:06:51 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: add basic check for hw control support Add basic check for hw control support. Check if the required API are defined and check if the defined trigger supported in hw control for the LED driver match netdev. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-29 18:32:36 +02:00
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>
2023-05-29 18:32:39 +02:00
leds: trigger: netdev: introduce check for possible hw control Introduce function to check if the requested mode can use hw control in preparation for hw control support. Currently everything is handled in software so can_hw_control will always return false. Add knob with the new value hw_control in trigger_data struct to set hw control possible. Useful for future implementation to implement in set_baseline_state() the required function to set the requested mode using LEDs hw control ops and in other function to reject set if hw control is currently active. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-29 18:32:35 +02:00
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>
2023-05-29 18:32:38 +02:00
leds: trigger: netdev: add basic check for hw control support Add basic check for hw control support. Check if the required API are defined and check if the defined trigger supported in hw control for the LED driver match netdev. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-29 18:32:36 +02:00
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>
2023-05-29 18:32:38 +02:00
leds: trigger: netdev: add basic check for hw control support Add basic check for hw control support. Check if the required API are defined and check if the defined trigger supported in hw control for the LED driver match netdev. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-29 18:32:36 +02:00
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>
2023-05-29 18:32:38 +02:00
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>
2023-05-29 18:32:39 +02:00
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>
2023-05-29 18:32:38 +02:00
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>
2023-05-29 18:32:39 +02:00
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>
2023-05-29 18:32:38 +02:00
leds: trigger: netdev: introduce check for possible hw control Introduce function to check if the requested mode can use hw control in preparation for hw control support. Currently everything is handled in software so can_hw_control will always return false. Add knob with the new value hw_control in trigger_data struct to set hw control possible. Useful for future implementation to implement in set_baseline_state() the required function to set the requested mode using LEDs hw control ops and in other function to reject set if hw control is currently active. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-29 18:32:35 +02:00
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>
2023-06-19 22:46:58 +02:00
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>
2024-01-11 17:04:54 +01:00
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>
2023-06-19 22:46:58 +02:00
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>
2024-01-11 17:04:54 +01:00
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>
2023-06-19 22:46:58 +02:00
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>
2023-06-19 22:46:59 +02:00
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>
2024-01-11 17:04:54 +01:00
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>
2023-06-19 22:46:58 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Use mutex instead of spinlocks Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-6-ansuelsmth@gmail.com
2023-04-19 23:07:43 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Use mutex instead of spinlocks Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-6-ansuelsmth@gmail.com
2023-04-19 23:07:43 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: refactor code setting device name Move the code into a helper, ready for it to be called at other times. No intended behaviour change. 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>
2023-05-29 18:32:34 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-10-07 15:10:42 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: fix RTNL handling to prevent potential deadlock When working on LED support for r8169 I got the following lockdep warning. Easiest way to prevent this scenario seems to be to take the RTNL lock before the trigger_data lock in set_device_name(). ====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc2-next-20231124+ #2 Not tainted ------------------------------------------------------ bash/383 is trying to acquire lock: ffff888103aa1c68 (&trigger_data->lock){+.+.}-{3:3}, at: netdev_trig_notify+0xec/0x190 [ledtrig_netdev] but task is already holding lock: ffffffff8cddf808 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x12/0x20 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (rtnl_mutex){+.+.}-{3:3}: __mutex_lock+0x9b/0xb50 mutex_lock_nested+0x16/0x20 rtnl_lock+0x12/0x20 set_device_name+0xa9/0x120 [ledtrig_netdev] netdev_trig_activate+0x1a1/0x230 [ledtrig_netdev] led_trigger_set+0x172/0x2c0 led_trigger_write+0xf1/0x140 sysfs_kf_bin_write+0x5d/0x80 kernfs_fop_write_iter+0x15d/0x210 vfs_write+0x1f0/0x510 ksys_write+0x6c/0xf0 __x64_sys_write+0x14/0x20 do_syscall_64+0x3f/0xf0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 -> #0 (&trigger_data->lock){+.+.}-{3:3}: __lock_acquire+0x1459/0x25a0 lock_acquire+0xc8/0x2d0 __mutex_lock+0x9b/0xb50 mutex_lock_nested+0x16/0x20 netdev_trig_notify+0xec/0x190 [ledtrig_netdev] call_netdevice_register_net_notifiers+0x5a/0x100 register_netdevice_notifier+0x85/0x120 netdev_trig_activate+0x1d4/0x230 [ledtrig_netdev] led_trigger_set+0x172/0x2c0 led_trigger_write+0xf1/0x140 sysfs_kf_bin_write+0x5d/0x80 kernfs_fop_write_iter+0x15d/0x210 vfs_write+0x1f0/0x510 ksys_write+0x6c/0xf0 __x64_sys_write+0x14/0x20 do_syscall_64+0x3f/0xf0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(&trigger_data->lock); lock(rtnl_mutex); lock(&trigger_data->lock); *** DEADLOCK *** 8 locks held by bash/383: #0: ffff888103ff33f0 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x6c/0xf0 #1: ffff888103aa1e88 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x114/0x210 #2: ffff8881036f1890 (kn->active#82){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x11d/0x210 #3: ffff888108e2c358 (&led_cdev->led_access){+.+.}-{3:3}, at: led_trigger_write+0x30/0x140 #4: ffffffff8cdd9e10 (triggers_list_lock){++++}-{3:3}, at: led_trigger_write+0x75/0x140 #5: ffff888108e2c270 (&led_cdev->trigger_lock){++++}-{3:3}, at: led_trigger_write+0xe3/0x140 #6: ffffffff8cdde3d0 (pernet_ops_rwsem){++++}-{3:3}, at: register_netdevice_notifier+0x1c/0x120 #7: ffffffff8cddf808 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x12/0x20 stack backtrace: CPU: 0 PID: 383 Comm: bash Not tainted 6.7.0-rc2-next-20231124+ #2 Hardware name: Default string Default string/Default string, BIOS ADLN.M6.SODIMM.ZB.CY.015 08/08/2023 Call Trace: <TASK> dump_stack_lvl+0x5c/0xd0 dump_stack+0x10/0x20 print_circular_bug+0x2dd/0x410 check_noncircular+0x131/0x150 __lock_acquire+0x1459/0x25a0 lock_acquire+0xc8/0x2d0 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev] __mutex_lock+0x9b/0xb50 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev] ? __this_cpu_preempt_check+0x13/0x20 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev] ? __cancel_work_timer+0x11c/0x1b0 ? __mutex_lock+0x123/0xb50 mutex_lock_nested+0x16/0x20 ? mutex_lock_nested+0x16/0x20 netdev_trig_notify+0xec/0x190 [ledtrig_netdev] call_netdevice_register_net_notifiers+0x5a/0x100 register_netdevice_notifier+0x85/0x120 netdev_trig_activate+0x1d4/0x230 [ledtrig_netdev] led_trigger_set+0x172/0x2c0 ? preempt_count_add+0x49/0xc0 led_trigger_write+0xf1/0x140 sysfs_kf_bin_write+0x5d/0x80 kernfs_fop_write_iter+0x15d/0x210 vfs_write+0x1f0/0x510 ksys_write+0x6c/0xf0 __x64_sys_write+0x14/0x20 do_syscall_64+0x3f/0xf0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f269055d034 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d 35 c3 0d 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48 RSP: 002b:00007ffddb7ef748 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000007 RCX: 00007f269055d034 RDX: 0000000000000007 RSI: 000055bf5f4af3c0 RDI: 0000000000000001 RBP: 000055bf5f4af3c0 R08: 0000000000000073 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000007 R13: 00007f26906325c0 R14: 00007f269062ff20 R15: 0000000000000000 </TASK> Fixes: d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode") Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/fb5c8294-2a10-4bf5-8f10-3d2b77d2757e@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-01 11:23:22 +01:00
leds: trigger: netdev: Use mutex instead of spinlocks Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-6-ansuelsmth@gmail.com
2023-04-19 23:07:43 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: refactor code setting device name Move the code into a helper, ready for it to be called at other times. No intended behaviour change. 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>
2023-05-29 18:32:34 +02:00
leds: trigger: netdev: use memcpy in device_name_store If userspace doesn't end the input with a newline (which can easily happen if the write happens from a C program that does write(fd, iface, strlen(iface))), we may end up including garbage from a previous, longer value in the device_name. For example # cat device_name # printf 'eth12' > device_name # cat device_name eth12 # printf 'eth3' > device_name # cat device_name eth32 I highly doubt anybody is relying on this behaviour, so switch to simply copying the bytes (we've already checked that size is < IFNAMSIZ) and unconditionally zero-terminate it; of course, we also still have to strip a trailing newline. This is also preparation for future patches. Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-03-14 15:06:14 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Drop NETDEV_LED_MODE_LINKUP from mode Putting NETDEV_LED_MODE_LINKUP in the same list of the netdev trigger modes is wrong as it's used to set the link state of the device and not to set a blink mode as it's done by NETDEV_LED_LINK, NETDEV_LED_TX and NETDEV_LED_RX. It's also wrong to put this state in the same bitmap of the netdev trigger mode and should be external to it. Drop NETDEV_LED_MODE_LINKUP from mode list and convert to a simple bool that will be true or false based on the carrier link. No functional change intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-3-ansuelsmth@gmail.com
2023-04-19 23:07:40 +02:00
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>
2023-06-19 22:46:58 +02:00
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>
2023-06-19 22:46:59 +02:00
leds: trigger: netdev: fix RTNL handling to prevent potential deadlock When working on LED support for r8169 I got the following lockdep warning. Easiest way to prevent this scenario seems to be to take the RTNL lock before the trigger_data lock in set_device_name(). ====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc2-next-20231124+ #2 Not tainted ------------------------------------------------------ bash/383 is trying to acquire lock: ffff888103aa1c68 (&trigger_data->lock){+.+.}-{3:3}, at: netdev_trig_notify+0xec/0x190 [ledtrig_netdev] but task is already holding lock: ffffffff8cddf808 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x12/0x20 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (rtnl_mutex){+.+.}-{3:3}: __mutex_lock+0x9b/0xb50 mutex_lock_nested+0x16/0x20 rtnl_lock+0x12/0x20 set_device_name+0xa9/0x120 [ledtrig_netdev] netdev_trig_activate+0x1a1/0x230 [ledtrig_netdev] led_trigger_set+0x172/0x2c0 led_trigger_write+0xf1/0x140 sysfs_kf_bin_write+0x5d/0x80 kernfs_fop_write_iter+0x15d/0x210 vfs_write+0x1f0/0x510 ksys_write+0x6c/0xf0 __x64_sys_write+0x14/0x20 do_syscall_64+0x3f/0xf0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 -> #0 (&trigger_data->lock){+.+.}-{3:3}: __lock_acquire+0x1459/0x25a0 lock_acquire+0xc8/0x2d0 __mutex_lock+0x9b/0xb50 mutex_lock_nested+0x16/0x20 netdev_trig_notify+0xec/0x190 [ledtrig_netdev] call_netdevice_register_net_notifiers+0x5a/0x100 register_netdevice_notifier+0x85/0x120 netdev_trig_activate+0x1d4/0x230 [ledtrig_netdev] led_trigger_set+0x172/0x2c0 led_trigger_write+0xf1/0x140 sysfs_kf_bin_write+0x5d/0x80 kernfs_fop_write_iter+0x15d/0x210 vfs_write+0x1f0/0x510 ksys_write+0x6c/0xf0 __x64_sys_write+0x14/0x20 do_syscall_64+0x3f/0xf0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(&trigger_data->lock); lock(rtnl_mutex); lock(&trigger_data->lock); *** DEADLOCK *** 8 locks held by bash/383: #0: ffff888103ff33f0 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x6c/0xf0 #1: ffff888103aa1e88 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x114/0x210 #2: ffff8881036f1890 (kn->active#82){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x11d/0x210 #3: ffff888108e2c358 (&led_cdev->led_access){+.+.}-{3:3}, at: led_trigger_write+0x30/0x140 #4: ffffffff8cdd9e10 (triggers_list_lock){++++}-{3:3}, at: led_trigger_write+0x75/0x140 #5: ffff888108e2c270 (&led_cdev->trigger_lock){++++}-{3:3}, at: led_trigger_write+0xe3/0x140 #6: ffffffff8cdde3d0 (pernet_ops_rwsem){++++}-{3:3}, at: register_netdevice_notifier+0x1c/0x120 #7: ffffffff8cddf808 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x12/0x20 stack backtrace: CPU: 0 PID: 383 Comm: bash Not tainted 6.7.0-rc2-next-20231124+ #2 Hardware name: Default string Default string/Default string, BIOS ADLN.M6.SODIMM.ZB.CY.015 08/08/2023 Call Trace: <TASK> dump_stack_lvl+0x5c/0xd0 dump_stack+0x10/0x20 print_circular_bug+0x2dd/0x410 check_noncircular+0x131/0x150 __lock_acquire+0x1459/0x25a0 lock_acquire+0xc8/0x2d0 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev] __mutex_lock+0x9b/0xb50 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev] ? __this_cpu_preempt_check+0x13/0x20 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev] ? __cancel_work_timer+0x11c/0x1b0 ? __mutex_lock+0x123/0xb50 mutex_lock_nested+0x16/0x20 ? mutex_lock_nested+0x16/0x20 netdev_trig_notify+0xec/0x190 [ledtrig_netdev] call_netdevice_register_net_notifiers+0x5a/0x100 register_netdevice_notifier+0x85/0x120 netdev_trig_activate+0x1d4/0x230 [ledtrig_netdev] led_trigger_set+0x172/0x2c0 ? preempt_count_add+0x49/0xc0 led_trigger_write+0xf1/0x140 sysfs_kf_bin_write+0x5d/0x80 kernfs_fop_write_iter+0x15d/0x210 vfs_write+0x1f0/0x510 ksys_write+0x6c/0xf0 __x64_sys_write+0x14/0x20 do_syscall_64+0x3f/0xf0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f269055d034 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d 35 c3 0d 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48 RSP: 002b:00007ffddb7ef748 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000007 RCX: 00007f269055d034 RDX: 0000000000000007 RSI: 000055bf5f4af3c0 RDI: 0000000000000001 RBP: 000055bf5f4af3c0 R08: 0000000000000073 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000007 R13: 00007f26906325c0 R14: 00007f269062ff20 R15: 0000000000000000 </TASK> Fixes: d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode") Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/fb5c8294-2a10-4bf5-8f10-3d2b77d2757e@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-01 11:23:22 +01:00
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>
2023-06-19 22:46:58 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-12-21 18:31:48 +01:00
leds: trigger: netdev: Use mutex instead of spinlocks Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-6-ansuelsmth@gmail.com
2023-04-19 23:07:43 +02:00
leds: trigger: netdev: fix RTNL handling to prevent potential deadlock When working on LED support for r8169 I got the following lockdep warning. Easiest way to prevent this scenario seems to be to take the RTNL lock before the trigger_data lock in set_device_name(). ====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc2-next-20231124+ #2 Not tainted ------------------------------------------------------ bash/383 is trying to acquire lock: ffff888103aa1c68 (&trigger_data->lock){+.+.}-{3:3}, at: netdev_trig_notify+0xec/0x190 [ledtrig_netdev] but task is already holding lock: ffffffff8cddf808 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x12/0x20 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (rtnl_mutex){+.+.}-{3:3}: __mutex_lock+0x9b/0xb50 mutex_lock_nested+0x16/0x20 rtnl_lock+0x12/0x20 set_device_name+0xa9/0x120 [ledtrig_netdev] netdev_trig_activate+0x1a1/0x230 [ledtrig_netdev] led_trigger_set+0x172/0x2c0 led_trigger_write+0xf1/0x140 sysfs_kf_bin_write+0x5d/0x80 kernfs_fop_write_iter+0x15d/0x210 vfs_write+0x1f0/0x510 ksys_write+0x6c/0xf0 __x64_sys_write+0x14/0x20 do_syscall_64+0x3f/0xf0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 -> #0 (&trigger_data->lock){+.+.}-{3:3}: __lock_acquire+0x1459/0x25a0 lock_acquire+0xc8/0x2d0 __mutex_lock+0x9b/0xb50 mutex_lock_nested+0x16/0x20 netdev_trig_notify+0xec/0x190 [ledtrig_netdev] call_netdevice_register_net_notifiers+0x5a/0x100 register_netdevice_notifier+0x85/0x120 netdev_trig_activate+0x1d4/0x230 [ledtrig_netdev] led_trigger_set+0x172/0x2c0 led_trigger_write+0xf1/0x140 sysfs_kf_bin_write+0x5d/0x80 kernfs_fop_write_iter+0x15d/0x210 vfs_write+0x1f0/0x510 ksys_write+0x6c/0xf0 __x64_sys_write+0x14/0x20 do_syscall_64+0x3f/0xf0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(&trigger_data->lock); lock(rtnl_mutex); lock(&trigger_data->lock); *** DEADLOCK *** 8 locks held by bash/383: #0: ffff888103ff33f0 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x6c/0xf0 #1: ffff888103aa1e88 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x114/0x210 #2: ffff8881036f1890 (kn->active#82){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x11d/0x210 #3: ffff888108e2c358 (&led_cdev->led_access){+.+.}-{3:3}, at: led_trigger_write+0x30/0x140 #4: ffffffff8cdd9e10 (triggers_list_lock){++++}-{3:3}, at: led_trigger_write+0x75/0x140 #5: ffff888108e2c270 (&led_cdev->trigger_lock){++++}-{3:3}, at: led_trigger_write+0xe3/0x140 #6: ffffffff8cdde3d0 (pernet_ops_rwsem){++++}-{3:3}, at: register_netdevice_notifier+0x1c/0x120 #7: ffffffff8cddf808 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x12/0x20 stack backtrace: CPU: 0 PID: 383 Comm: bash Not tainted 6.7.0-rc2-next-20231124+ #2 Hardware name: Default string Default string/Default string, BIOS ADLN.M6.SODIMM.ZB.CY.015 08/08/2023 Call Trace: <TASK> dump_stack_lvl+0x5c/0xd0 dump_stack+0x10/0x20 print_circular_bug+0x2dd/0x410 check_noncircular+0x131/0x150 __lock_acquire+0x1459/0x25a0 lock_acquire+0xc8/0x2d0 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev] __mutex_lock+0x9b/0xb50 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev] ? __this_cpu_preempt_check+0x13/0x20 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev] ? __cancel_work_timer+0x11c/0x1b0 ? __mutex_lock+0x123/0xb50 mutex_lock_nested+0x16/0x20 ? mutex_lock_nested+0x16/0x20 netdev_trig_notify+0xec/0x190 [ledtrig_netdev] call_netdevice_register_net_notifiers+0x5a/0x100 register_netdevice_notifier+0x85/0x120 netdev_trig_activate+0x1d4/0x230 [ledtrig_netdev] led_trigger_set+0x172/0x2c0 ? preempt_count_add+0x49/0xc0 led_trigger_write+0xf1/0x140 sysfs_kf_bin_write+0x5d/0x80 kernfs_fop_write_iter+0x15d/0x210 vfs_write+0x1f0/0x510 ksys_write+0x6c/0xf0 __x64_sys_write+0x14/0x20 do_syscall_64+0x3f/0xf0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f269055d034 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d 35 c3 0d 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48 RSP: 002b:00007ffddb7ef748 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000007 RCX: 00007f269055d034 RDX: 0000000000000007 RSI: 000055bf5f4af3c0 RDI: 0000000000000001 RBP: 000055bf5f4af3c0 R08: 0000000000000073 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000007 R13: 00007f26906325c0 R14: 00007f269062ff20 R15: 0000000000000000 </TASK> Fixes: d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode") Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/fb5c8294-2a10-4bf5-8f10-3d2b77d2757e@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-01 11:23:22 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: refactor code setting device name Move the code into a helper, ready for it to be called at other times. No intended behaviour change. 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>
2023-05-29 18:32:34 +02:00
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>
2024-01-11 17:04:54 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
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>
2023-06-19 22:46:58 +02:00
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>
2023-11-28 04:00:10 +00:00
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>
2023-06-19 22:46:59 +02:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
leds: trigger: netdev: Add support for tx_err and rx_err notification with LEDs 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>
2024-07-10 12:06:51 +02:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
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>
2023-12-17 19:46:42 +01:00
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>
2023-06-19 22:46:58 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
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>
2023-06-19 22:46:58 +02:00
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>
2023-11-28 04:00:10 +00:00
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>
2023-06-19 22:46:59 +02:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
leds: trigger: netdev: Add support for tx_err and rx_err notification with LEDs 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>
2024-07-10 12:06:51 +02:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-06-19 22:46:58 +02:00
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>
2023-11-28 04:00:10 +00:00
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>
2023-06-19 22:46:58 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-06-19 22:46:58 +02:00
leds: trigger: netdev: introduce check for possible hw control Introduce function to check if the requested mode can use hw control in preparation for hw control support. Currently everything is handled in software so can_hw_control will always return false. Add knob with the new value hw_control in trigger_data struct to set hw control possible. Useful for future implementation to implement in set_baseline_state() the required function to set the requested mode using LEDs hw control ops and in other function to reject set if hw control is currently active. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-29 18:32:35 +02:00
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>
2023-12-17 19:46:42 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Convert device attr to macro Convert link tx and rx device attr to a common macro to reduce common code and in preparation for additional attr. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-5-ansuelsmth@gmail.com
2023-04-19 23:07:42 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Convert device attr to macro Convert link tx and rx device attr to a common macro to reduce common code and in preparation for additional attr. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-5-ansuelsmth@gmail.com
2023-04-19 23:07:42 +02:00
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>
2023-06-19 22:46:58 +02:00
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>
2023-11-28 04:00:10 +00:00
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>
2023-06-19 22:46:59 +02:00
leds: trigger: netdev: Convert device attr to macro Convert link tx and rx device attr to a common macro to reduce common code and in preparation for additional attr. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-5-ansuelsmth@gmail.com
2023-04-19 23:07:42 +02:00
leds: trigger: netdev: Add support for tx_err and rx_err notification with LEDs 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>
2024-07-10 12:06:51 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
Revert "leds: trigger: netdev: Configure LED blink interval for HW offload" This reverts commit c629c972b310af41e9e072febb6dae9a299edde6. While .led_blink_set() would previously put an LED into an unconditional permanently blinking state, the offending commit now uses same operation to (also?) set the blink timing of the netdev trigger when offloading. This breaks many if not all of the existing PHY drivers which offer offloading LED operations, as those drivers would just put the LED into blinking state after .led_blink_set() has been called. Unfortunately the change even made it into stable kernels for unknown reasons, so it should be reverted there as well. Fixes: c629c972b310a ("leds: trigger: netdev: Configure LED blink interval for HW offload") Link: https://lore.kernel.org/linux-leds/c6134e26-2e45-4121-aa15-58aaef327201@lunn.ch/T/#m9d6fe81bbcb273e59f12bbedbd633edd32118387 Suggested-by: Andrew Lunn <andrew@lunn.ch> Cc: stable@vger.kernel.org Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/6dcc77ee1c9676891d6250d8994850f521426a0f.1752334655.git.daniel@makrotopia.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-12 16:39:21 +01:00
leds: trigger: netdev: reject interval store for hw_control Reject interval store with hw_control enabled. It's are currently not supported and MUST be set to the default value with hw control enabled. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-29 18:32:37 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
Revert "leds: trigger: netdev: Configure LED blink interval for HW offload" This reverts commit c629c972b310af41e9e072febb6dae9a299edde6. While .led_blink_set() would previously put an LED into an unconditional permanently blinking state, the offending commit now uses same operation to (also?) set the blink timing of the netdev trigger when offloading. This breaks many if not all of the existing PHY drivers which offer offloading LED operations, as those drivers would just put the LED into blinking state after .led_blink_set() has been called. Unfortunately the change even made it into stable kernels for unknown reasons, so it should be reverted there as well. Fixes: c629c972b310a ("leds: trigger: netdev: Configure LED blink interval for HW offload") Link: https://lore.kernel.org/linux-leds/c6134e26-2e45-4121-aa15-58aaef327201@lunn.ch/T/#m9d6fe81bbcb273e59f12bbedbd633edd32118387 Suggested-by: Andrew Lunn <andrew@lunn.ch> Cc: stable@vger.kernel.org Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/6dcc77ee1c9676891d6250d8994850f521426a0f.1752334655.git.daniel@makrotopia.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-12 16:39:21 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
Revert "leds: trigger: netdev: Configure LED blink interval for HW offload" This reverts commit c629c972b310af41e9e072febb6dae9a299edde6. While .led_blink_set() would previously put an LED into an unconditional permanently blinking state, the offending commit now uses same operation to (also?) set the blink timing of the netdev trigger when offloading. This breaks many if not all of the existing PHY drivers which offer offloading LED operations, as those drivers would just put the LED into blinking state after .led_blink_set() has been called. Unfortunately the change even made it into stable kernels for unknown reasons, so it should be reverted there as well. Fixes: c629c972b310a ("leds: trigger: netdev: Configure LED blink interval for HW offload") Link: https://lore.kernel.org/linux-leds/c6134e26-2e45-4121-aa15-58aaef327201@lunn.ch/T/#m9d6fe81bbcb273e59f12bbedbd633edd32118387 Suggested-by: Andrew Lunn <andrew@lunn.ch> Cc: stable@vger.kernel.org Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/6dcc77ee1c9676891d6250d8994850f521426a0f.1752334655.git.daniel@makrotopia.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-12 16:39:21 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-08-21 14:14:53 +02:00
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>
2023-06-19 22:47:00 +02:00
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>
2023-08-21 14:14:53 +02:00
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>
2023-06-19 22:47:00 +02:00
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>
2024-01-11 17:04:54 +01:00
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>
2023-06-19 22:46:58 +02:00
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>
2023-11-28 04:00:10 +00:00
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>
2024-01-11 17:04:54 +01:00
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>
2023-06-19 22:46:59 +02:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: netdev: Add support for tx_err and rx_err notification with LEDs 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>
2024-07-10 12:06:51 +02:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
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>
2023-08-21 14:14:53 +02:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
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>
2024-01-11 17:04:54 +01:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
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>
2024-01-11 17:04:54 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: fix handling on interface rename The NETDEV_CHANGENAME code is not "unneeded" like it is stated in commit 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename"). The event was accidentally misinterpreted equivalent to NETDEV_UNREGISTER, but should be equivalent to NETDEV_REGISTER. This was the case in the original code from the openwrt project. Otherwise, you are unable to set netdev led triggers for (non-existent) netdevices, which has to be renamed. This is the case, for example, for ppp interfaces in openwrt. Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Fixes: 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename") Signed-off-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2019-10-25 09:01:42 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: fix refcnt leak on interface rename Renaming a netdev-trigger-tracked interface was resulting in an unbalanced dev_hold(). Example: > iw phy phy0 interface add foo type __ap > echo netdev > trigger > echo foo > device_name > ip link set foo name bar > iw dev bar del [ 237.355366] unregister_netdevice: waiting for bar to become free. Usage count = 1 [ 247.435362] unregister_netdevice: waiting for bar to become free. Usage count = 1 [ 257.545366] unregister_netdevice: waiting for bar to become free. Usage count = 1 Above problem was caused by trigger checking a dev->name which obviously changes after renaming an interface. It meant missing all further events including the NETDEV_UNREGISTER which is required for calling dev_put(). This change fixes that by: 1) Comparing device struct *address* for notification-filtering purposes 2) Dropping unneeded NETDEV_CHANGENAME code (no behavior change) Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-02-28 22:57:33 +01:00
leds: trigger: netdev: fix handling on interface rename The NETDEV_CHANGENAME code is not "unneeded" like it is stated in commit 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename"). The event was accidentally misinterpreted equivalent to NETDEV_UNREGISTER, but should be equivalent to NETDEV_REGISTER. This was the case in the original code from the openwrt project. Otherwise, you are unable to set netdev led triggers for (non-existent) netdevices, which has to be renamed. This is the case, for example, for ppp interfaces in openwrt. Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Fixes: 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename") Signed-off-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2019-10-25 09:01:42 +02:00
leds: trigger: netdev: fix refcnt leak on interface rename Renaming a netdev-trigger-tracked interface was resulting in an unbalanced dev_hold(). Example: > iw phy phy0 interface add foo type __ap > echo netdev > trigger > echo foo > device_name > ip link set foo name bar > iw dev bar del [ 237.355366] unregister_netdevice: waiting for bar to become free. Usage count = 1 [ 247.435362] unregister_netdevice: waiting for bar to become free. Usage count = 1 [ 257.545366] unregister_netdevice: waiting for bar to become free. Usage count = 1 Above problem was caused by trigger checking a dev->name which obviously changes after renaming an interface. It meant missing all further events including the NETDEV_UNREGISTER which is required for calling dev_put(). This change fixes that by: 1) Comparing device struct *address* for notification-filtering purposes 2) Dropping unneeded NETDEV_CHANGENAME code (no behavior change) Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-02-28 22:57:33 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Use mutex instead of spinlocks Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-6-ansuelsmth@gmail.com
2023-04-19 23:07:43 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Drop NETDEV_LED_MODE_LINKUP from mode Putting NETDEV_LED_MODE_LINKUP in the same list of the netdev trigger modes is wrong as it's used to set the link state of the device and not to set a blink mode as it's done by NETDEV_LED_LINK, NETDEV_LED_TX and NETDEV_LED_RX. It's also wrong to put this state in the same bitmap of the netdev trigger mode and should be external to it. Drop NETDEV_LED_MODE_LINKUP from mode list and convert to a simple bool that will be true or false based on the carrier link. No functional change intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-3-ansuelsmth@gmail.com
2023-04-19 23:07:40 +02:00
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>
2023-06-19 22:46:58 +02:00
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>
2023-06-19 22:46:59 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: fix handling on interface rename The NETDEV_CHANGENAME code is not "unneeded" like it is stated in commit 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename"). The event was accidentally misinterpreted equivalent to NETDEV_UNREGISTER, but should be equivalent to NETDEV_REGISTER. This was the case in the original code from the openwrt project. Otherwise, you are unable to set netdev led triggers for (non-existent) netdevices, which has to be renamed. This is the case, for example, for ppp interfaces in openwrt. Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Fixes: 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename") Signed-off-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2019-10-25 09:01:42 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Remove NULL check before dev_{put, hold} The call netdev_{put, hold} of dev_{put, hold} will check NULL, so there is no need to check before using dev_{put, hold}, remove it to silence the warnings: ./drivers/leds/trigger/ledtrig-netdev.c:291:3-10: WARNING: NULL check before dev_{put, hold} functions is not needed. ./drivers/leds/trigger/ledtrig-netdev.c:401:2-9: WARNING: NULL check before dev_{put, hold} functions is not needed. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=4929 Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20230511070820.52731-1-yang.lee@linux.alibaba.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-11 15:08:20 +08:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2024-02-04 00:54:01 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: fix refcnt leak on interface rename Renaming a netdev-trigger-tracked interface was resulting in an unbalanced dev_hold(). Example: > iw phy phy0 interface add foo type __ap > echo netdev > trigger > echo foo > device_name > ip link set foo name bar > iw dev bar del [ 237.355366] unregister_netdevice: waiting for bar to become free. Usage count = 1 [ 247.435362] unregister_netdevice: waiting for bar to become free. Usage count = 1 [ 257.545366] unregister_netdevice: waiting for bar to become free. Usage count = 1 Above problem was caused by trigger checking a dev->name which obviously changes after renaming an interface. It meant missing all further events including the NETDEV_UNREGISTER which is required for calling dev_put(). This change fixes that by: 1) Comparing device struct *address* for notification-filtering purposes 2) Dropping unneeded NETDEV_CHANGENAME code (no behavior change) Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-02-28 22:57:33 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Check offload ability on interface up 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>
2024-12-16 11:48:22 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-06-19 22:46:58 +02:00
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>
2024-01-11 17:04:54 +01:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Use mutex instead of spinlocks Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-6-ansuelsmth@gmail.com
2023-04-19 23:07:43 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
leds: trigger: netdev: Add support for tx_err and rx_err notification with LEDs 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>
2024-07-10 12:06:51 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Rename add namespace to netdev trigger enum modes Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
2023-04-19 23:07:41 +02:00
leds: trigger: netdev: Add support for tx_err and rx_err notification with LEDs 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>
2024-07-10 12:06:51 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-06-19 22:46:58 +02:00
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>
2023-06-19 22:46:59 +02:00
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>
2023-11-28 04:00:10 +00:00
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>
2023-06-19 22:46:59 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: triggers: let struct led_trigger::activate() return an error code Given that activating a trigger can fail, let the callback return an indication. This prevents to have a trigger active according to the "trigger" sysfs attribute but not functional. All users are changed accordingly to return 0 for now. There is no intended change in behaviour. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:21 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-06-14 10:03:59 +03:00
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>
2023-05-29 18:32:40 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
Convert 'alloc_obj' family to use the new default GFP_KERNEL argument This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21 16:37:42 -08:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Use mutex instead of spinlocks Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-6-ansuelsmth@gmail.com
2023-04-19 23:07:43 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-05-29 18:32:38 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-05-29 18:32:40 +02:00
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>
2023-08-08 23:04:33 +02:00
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>
2023-05-29 18:32:40 +02:00
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>
2023-12-21 18:31:48 +01:00
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>
2023-08-08 23:04:33 +02:00
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>
2023-05-29 18:32:40 +02:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Remove NULL check before dev_{put, hold} The call netdev_{put, hold} of dev_{put, hold} will check NULL, so there is no need to check before using dev_{put, hold}, remove it to silence the warnings: ./drivers/leds/trigger/ledtrig-netdev.c:291:3-10: WARNING: NULL check before dev_{put, hold} functions is not needed. ./drivers/leds/trigger/ledtrig-netdev.c:401:2-9: WARNING: NULL check before dev_{put, hold} functions is not needed. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=4929 Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20230511070820.52731-1-yang.lee@linux.alibaba.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-11 15:08:20 +08:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: netdev trigger: simplifications from core changes The trigger core learned error handling for the activate callback and can handle device attributes now. This allows simplifying the driver considerably. Note that .deactivate() is only called when .activate() succeeded, so the check for trigger_data being non-NULL can go away. (It was broken before because the core didn't clear .trigger_data, so it might have been non-NULL even if .activate() failed before.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-02 22:05:26 +02:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
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>
2023-08-15 15:59:43 +08:00
leds: trigger: Introduce a NETDEV trigger This commit introduces a NETDEV trigger for named device activity. Available triggers are link, rx, and tx. Signed-off-by: Ben Whitten <ben.whitten@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-10 21:17:55 +00:00
leds: trigger: netdev: Add module alias ledtrig:netdev Add module alias ledtrig:netdev to enable auto-loading of the module. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/84a1bbd3-1ac7-4f37-849a-7f4d31698f76@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-12-21 23:20:26 +01:00