| Message ID | 20230527112854.2366-4-ansuelsmth@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | leds: introduce new LED hw control APIs | expand |
| Context | Check | Description |
|---|---|---|
| netdev/series_format | success | Posting correctly formatted |
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/fixes_present | success | Fixes tag not required for -next series |
| netdev/header_inline | success | No static functions without inline keyword in header files |
| netdev/build_32bit | success | Errors and warnings before: 8 this patch: 8 |
| netdev/cc_maintainers | success | CCed 5 of 5 maintainers |
| netdev/build_clang | success | Errors and warnings before: 8 this patch: 8 |
| netdev/verify_signedoff | success | Signed-off-by tag matches author and committer |
| netdev/deprecated_api | success | None detected |
| netdev/check_selftest | success | No net selftest shell script |
| netdev/verify_fixes | success | No Fixes tag |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 8 this patch: 8 |
| netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 86 lines checked |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/source_inline | success | Was 0 now: 0 |
On Sat, May 27, 2023 at 01:28:44PM +0200, Christian Marangi wrote: > + - hw_control_set: > + activate hw control. LED driver will use the provided > + flags passed from the supported trigger, parse them to > + a set of mode and setup the LED to be driven by hardware > + following the requested modes. > + > + Set LED_OFF via the brightness_set to deactivate hw control. > + > + Return 0 on success, a negative error number on flags apply > + fail. "... on failing to apply flags." > + - hw_control_get_device: > + return the device associated with the LED driver in > + hw control. A trigger might use this to match the > + returned device from this function with a configured > + device for the trigger as the source for blinking > + events and correctly enable hw control. > + (example a netdev trigger configured to blink for a > + particular dev match the returned dev from get_device > + to set hw control) > + > + Return a device or NULL if nothing is currently attached. Returns a device name? > + > +LED driver can activate additional modes by default to workaround the > +impossibility of supporting each different mode on the supported trigger. > +Example are hardcoding the blink speed to a set interval, enable special "Examples are hardcoding ..." Thanks.
On Mon, May 29, 2023 at 08:12:42AM -0600, Jonathan Corbet wrote: > Bagas Sanjaya <bagasdotme@gmail.com> writes: > > >> + - hw_control_get_device: > >> + return the device associated with the LED driver in > >> + hw control. A trigger might use this to match the > >> + returned device from this function with a configured > >> + device for the trigger as the source for blinking > >> + events and correctly enable hw control. > >> + (example a netdev trigger configured to blink for a > >> + particular dev match the returned dev from get_device > >> + to set hw control) > >> + > >> + Return a device or NULL if nothing is currently attached. > > Returns a device name? > > The return type of this function is struct device * - how would you > expect it to return a name? > Just to clarify, a device name can't be returned. Not every device have a name and such name can be changed. An example is network device where you can change the name of the interface. Using the device prevents all of this problem.
Bagas Sanjaya <bagasdotme@gmail.com> writes: >> + - hw_control_get_device: >> + return the device associated with the LED driver in >> + hw control. A trigger might use this to match the >> + returned device from this function with a configured >> + device for the trigger as the source for blinking >> + events and correctly enable hw control. >> + (example a netdev trigger configured to blink for a >> + particular dev match the returned dev from get_device >> + to set hw control) >> + >> + Return a device or NULL if nothing is currently attached. > Returns a device name? The return type of this function is struct device * - how would you expect it to return a name? jon
On Mon, May 29, 2023 at 03:10:15PM +0700, Bagas Sanjaya wrote: > On Sat, May 27, 2023 at 01:28:44PM +0200, Christian Marangi wrote: > > + - hw_control_set: > > + activate hw control. LED driver will use the provided > > + flags passed from the supported trigger, parse them to > > + a set of mode and setup the LED to be driven by hardware > > + following the requested modes. > > + > > + Set LED_OFF via the brightness_set to deactivate hw control. > > + > > + Return 0 on success, a negative error number on flags apply > > + fail. > "... on failing to apply flags." > > > + - hw_control_get_device: > > + return the device associated with the LED driver in > > + hw control. A trigger might use this to match the > > + returned device from this function with a configured > > + device for the trigger as the source for blinking > > + events and correctly enable hw control. > > + (example a netdev trigger configured to blink for a > > + particular dev match the returned dev from get_device > > + to set hw control) > > + > > + Return a device or NULL if nothing is currently attached. > Returns a device name? How about "Returns a pointer to a struct device ..." Andrew
On 5/29/23 21:09, Christian Marangi wrote: > Just to clarify, a device name can't be returned. Not every device have > a name and such name can be changed. An example is network device where > you can change the name of the interface. > > Using the device prevents all of this problem. > Oh, I guess it was /dev/something.
On Tue, May 30, 2023 at 10:09:28AM +0700, Bagas Sanjaya wrote: > On 5/29/23 21:09, Christian Marangi wrote: > > Just to clarify, a device name can't be returned. Not every device have > > a name and such name can be changed. An example is network device where > > you can change the name of the interface. > > > > Using the device prevents all of this problem. > > > > Oh, I guess it was /dev/something. Network devices don't appear in /dev. At least not in Linux. Some other Unix implementations do, i think SunOS used to have an entry in /dev, but i could be remembering wrongly. But within the kernel, you generally don't refer to a device by its /dev/foo name. That is a user space abstraction. In the kernel, each device in the system has a struct device representing it. Andrew
diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst index cd155ead8703..3d7874c18982 100644 --- a/Documentation/leds/leds-class.rst +++ b/Documentation/leds/leds-class.rst @@ -169,6 +169,86 @@ Setting the brightness to zero with brightness_set() callback function should completely turn off the LED and cancel the previously programmed hardware blinking function, if any. +Hardware driven LEDs +==================== + +Some LEDs can be programmed to be driven by hardware. This is not +limited to blink but also to turn off or on autonomously. +To support this feature, a LED needs to implement various additional +ops and needs to declare specific support for the supported triggers. + +With hw control we refer to the LED driven by hardware. + +LED driver must define the following value to support hw control: + + - hw_control_trigger: + unique trigger name supported by the LED in hw control + mode. + +LED driver must implement the following API to support hw control: + - hw_control_is_supported: + check if the flags passed by the supported trigger can + be parsed and activate hw control on the LED. + + Return 0 if the passed flags mask is supported and + can be set with hw_control_set(). + + If the passed flags mask is not supported -EOPNOTSUPP + must be returned, the LED trigger will use software + fallback in this case. + + Return a negative error in case of any other error like + device not ready or timeouts. + + - hw_control_set: + activate hw control. LED driver will use the provided + flags passed from the supported trigger, parse them to + a set of mode and setup the LED to be driven by hardware + following the requested modes. + + Set LED_OFF via the brightness_set to deactivate hw control. + + Return 0 on success, a negative error number on flags apply + fail. + + - hw_control_get: + get active modes from a LED already in hw control, parse + them and set in flags the current active flags for the + supported trigger. + + 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. + + - hw_control_get_device: + return the device associated with the LED driver in + hw control. A trigger might use this to match the + returned device from this function with a configured + device for the trigger as the source for blinking + events and correctly enable hw control. + (example a netdev trigger configured to blink for a + particular dev match the returned dev from get_device + to set hw control) + + Return a device or NULL if nothing is currently attached. + +LED driver can activate additional modes by default to workaround the +impossibility of supporting each different mode on the supported trigger. +Example are hardcoding the blink speed to a set interval, enable special +feature like bypassing blink if some requirements are not met. + +A trigger should first check if the hw control API are supported by the LED +driver and check if the trigger is supported to verify if hw control is possible, +use hw_control_is_supported to check if the flags are supported and only at +the end use hw_control_set to activate hw control. + +A trigger can use hw_control_get to check if a LED is already in hw control +and init their flags. + +When the LED is in hw control, no software blink is possible and doing so +will effectively disable hw control. Known Issues ============
Document new Hardware driven LEDs APIs. Some LEDs can be programmed to be driven by hardware. This is not limited to blink but also to turn off or on autonomously. To support this feature, a LED needs to implement various additional ops and needs to declare specific support for the supported triggers. Add documentation for each required value and API to make hw control possible and implementable by both LEDs and triggers. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> --- Documentation/leds/leds-class.rst | 80 +++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+)