linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ansuel Smith <ansuelsmth@gmail.com>
To: "Andrew Lunn" <andrew@lunn.ch>,
	"Vivien Didelot" <vivien.didelot@gmail.com>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Vladimir Oltean" <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Jonathan Corbet" <corbet@lwn.net>, "Pavel Machek" <pavel@ucw.cz>,
	"Ansuel Smith" <ansuelsmth@gmail.com>,
	"John Crispin" <john@phrozen.org>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-leds@vger.kernel.org, "Marek Behún" <kabel@kernel.org>
Subject: [RFC PATCH v3 2/8] leds: add function to configure hardware controlled LED
Date: Tue,  9 Nov 2021 03:26:02 +0100	[thread overview]
Message-ID: <20211109022608.11109-3-ansuelsmth@gmail.com> (raw)
In-Reply-To: <20211109022608.11109-1-ansuelsmth@gmail.com>

Add hw_control_configure helper to configure how the LED should work in
hardware mode. The function require to support the particular trigger and
will use the passed flag to elaborate the data and apply the
correct configuration. This function will then be used by the trigger to
request and update hardware configuration.

Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
---
 Documentation/leds/leds-class.rst | 25 ++++++++++++++++++++
 include/linux/leds.h              | 39 +++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)

diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst
index 645940b78d81..efd2f68c46a7 100644
--- a/Documentation/leds/leds-class.rst
+++ b/Documentation/leds/leds-class.rst
@@ -198,6 +198,31 @@ With HARDWARE_CONTROLLED blink_mode hw_control_status/start/stop is optional
 and any software only trigger will reject activation as the LED supports only
 hardware mode.
 
+A trigger once he declared support for hardware controlled blinks, will use the function
+hw_control_configure() provided by the driver to check support for a particular blink mode.
+This function passes as the first argument (flag) a u32 flag.
+The second argument (cmd) of hw_control_configure() method can be used to do various
+operations for the specific blink mode. We currently support ENABLE, DISABLE, READ, ZERO
+and SUPPORTED to enable, disable, read the state of the blink mode, ask the LED
+driver if it does supports the specific blink mode and to reset any blink mode active.
+
+In ENABLE/DISABLE hw_control_configure() should configure the LED to enable/disable the
+requested blink mode (flag).
+In READ hw_control_configure() should return 0 or 1 based on the status of the requested
+blink mode (flag).
+In SUPPORTED hw_control_configure() should return 0 or 1 if the LED driver supports the
+requested blink mode (flags) or not.
+In ZERO hw_control_configure() should return 0 with success operation or error.
+
+The unsigned long flag is specific to the trigger and change across them. It's in the LED
+driver interest know how to elaborate this flag and to declare support for a
+particular trigger. For this exact reason explicit support for the specific
+trigger is mandatory or the driver returns -EOPNOTSUPP if asked to enter offload mode
+with a not supported trigger.
+If the driver returns -EOPNOTSUPP on hw_control_configure(), the trigger activation will
+fail as the driver doesn't support that specific offload trigger or doesn't know
+how to handle the provided flags.
+
 Known Issues
 ============
 
diff --git a/include/linux/leds.h b/include/linux/leds.h
index cf0c6005c297..00bc4d6ed7ca 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -73,6 +73,16 @@ enum led_blink_modes {
 	SOFTWARE_HARDWARE_CONTROLLED,
 };
 
+#ifdef CONFIG_LEDS_HARDWARE_CONTROL
+enum blink_mode_cmd {
+	BLINK_MODE_ENABLE, /* Enable the hardware blink mode */
+	BLINK_MODE_DISABLE, /* Disable the hardware blink mode */
+	BLINK_MODE_READ, /* Read the status of the hardware blink mode */
+	BLINK_MODE_SUPPORTED, /* Ask the driver if the hardware blink mode is supported */
+	BLINK_MODE_ZERO, /* Disable any hardware blink active */
+};
+#endif
+
 struct led_classdev {
 	const char		*name;
 	unsigned int brightness;
@@ -185,6 +195,17 @@ struct led_classdev {
 	 * the old status but that is not mandatory and also putting it off is accepted.
 	 */
 	int			(*hw_control_stop)(struct led_classdev *led_cdev);
+	/* This will be used to configure the various blink modes LED support in hardware
+	 * mode.
+	 * The LED driver require to support the active trigger and will elaborate the
+	 * unsigned long flag and do the operation based on the provided cmd.
+	 * Current operation are enable,disable,supported and status.
+	 * A trigger will use this to enable or disable the asked blink mode, check the
+	 * status of the blink mode or ask if the blink mode can run in hardware mode.
+	 */
+	int			(*hw_control_configure)(struct led_classdev *led_cdev,
+							unsigned long flag,
+							enum blink_mode_cmd cmd);
 #endif
 #endif
 
@@ -454,6 +475,24 @@ static inline void *led_get_trigger_data(struct led_classdev *led_cdev)
 	return led_cdev->trigger_data;
 }
 
+#ifdef CONFIG_LEDS_HARDWARE_CONTROL
+static inline bool led_trigger_blink_mode_is_supported(struct led_classdev *led_cdev,
+						       unsigned long flag)
+{
+	int ret;
+
+	/* Sanity check: make sure led support hw mode */
+	if (led_cdev->blink_mode == SOFTWARE_CONTROLLED)
+		return false;
+
+	ret = led_cdev->hw_control_configure(led_cdev, flag, BLINK_MODE_SUPPORTED);
+	if (ret > 0)
+		return true;
+
+	return false;
+}
+#endif
+
 /**
  * led_trigger_rename_static - rename a trigger
  * @name: the new trigger name
-- 
2.32.0


  parent reply	other threads:[~2021-11-09  2:26 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-09  2:26 [RFC PATCH v3 0/8] Adds support for PHY LEDs with offload triggers Ansuel Smith
2021-11-09  2:26 ` [RFC PATCH v3 1/8] leds: add support for hardware driven LEDs Ansuel Smith
2021-11-09  6:16   ` Randy Dunlap
2021-11-09 20:34   ` Andrew Lunn
2021-11-09 20:40     ` Ansuel Smith
2021-11-09  2:26 ` Ansuel Smith [this message]
2021-11-09  3:01   ` [RFC PATCH v3 2/8] leds: add function to configure hardware controlled LED Marek Behún
2021-11-09 14:22     ` Ansuel Smith
2021-11-09 20:49       ` Andrew Lunn
2021-11-10 19:51         ` Ansuel Smith
2021-11-10 22:24           ` Andrew Lunn
2021-11-09 22:18       ` Marek Behún
2021-11-09  6:12   ` Randy Dunlap
2021-11-09  2:26 ` [RFC PATCH v3 3/8] leds: trigger: netdev: drop NETDEV_LED_MODE_LINKUP from mode Ansuel Smith
2021-11-09  3:02   ` Marek Behún
2021-11-09 14:24     ` Ansuel Smith
2021-11-09 20:53     ` Andrew Lunn
2021-11-09  2:26 ` [RFC PATCH v3 4/8] leds: trigger: netdev: rename and expose NETDEV trigger enum modes Ansuel Smith
2021-11-09 20:58   ` Andrew Lunn
2021-11-10 19:57     ` Ansuel Smith
2021-11-10 22:29       ` Andrew Lunn
2021-11-09  2:26 ` [RFC PATCH v3 5/8] leds: trigger: netdev: add hardware control support Ansuel Smith
2021-11-09  3:12   ` Marek Behún
2021-11-09 15:02     ` Ansuel Smith
2021-11-09  2:26 ` [RFC PATCH v3 6/8] leds: trigger: add hardware-phy-activity trigger Ansuel Smith
2021-11-09  3:25   ` Marek Behún
2021-11-09 21:09     ` Andrew Lunn
2021-11-10 20:04       ` Ansuel Smith
2021-11-10 22:32         ` Andrew Lunn
2021-11-09  6:02   ` Randy Dunlap
2021-11-09 15:06     ` Ansuel Smith
2021-11-09 21:17   ` Andrew Lunn
2021-11-09 21:28   ` Andrew Lunn
2021-11-09  2:26 ` [RFC PATCH v3 7/8] net: dsa: qca8k: add LEDs support Ansuel Smith
2021-11-09  6:03   ` Randy Dunlap
2021-11-09 21:22   ` Andrew Lunn
2021-11-09  2:26 ` [RFC PATCH v3 8/8] dt-bindings: net: dsa: qca8k: add LEDs definition example Ansuel Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211109022608.11109-3-ansuelsmth@gmail.com \
    --to=ansuelsmth@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=john@phrozen.org \
    --cc=kabel@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).