From: Andrew Lunn <andrew@lunn.ch>
To: Ansuel Smith <ansuelsmth@gmail.com>
Cc: "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>,
"Paolo Abeni" <pabeni@redhat.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>, "Pavel Machek" <pavel@ucw.cz>,
"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: Re: [RFC PATCH v6 01/11] leds: add support for hardware driven LEDs
Date: Thu, 5 May 2022 00:19:11 +0200 [thread overview]
Message-ID: <YnL73yOfh+wHQObm@lunn.ch> (raw)
In-Reply-To: <20220503151633.18760-2-ansuelsmth@gmail.com>
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 6a8ea94834fa..3516ae3c4c3c 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -164,6 +164,27 @@ static void led_remove_brightness_hw_changed(struct led_classdev *led_cdev)
> }
> #endif
>
> +#ifdef CONFIG_LEDS_HARDWARE_CONTROL
> +static int led_classdev_check_blink_mode_functions(struct led_classdev *led_cdev)
> +{
> + int mode = led_cdev->blink_mode;
> +
We try to avoid #ifdef in code. I suggest you use
if (IS_ENABLED(CONFIG_LEDS_HARDWARE_CONTROL)) {
}
You then get compiler coverage independent of if the option is on or
off.
> + if (mode == SOFTWARE_HARDWARE_CONTROLLED &&
> + (!led_cdev->hw_control_status ||
> + !led_cdev->hw_control_start ||
> + !led_cdev->hw_control_stop))
> + return -EINVAL;
> +
> + if (mode == SOFTWARE_CONTROLLED &&
> + (led_cdev->hw_control_status ||
> + led_cdev->hw_control_start ||
> + led_cdev->hw_control_stop))
> + return -EINVAL;
> +
> + return 0;
> +}
> +#endif
> +
> /**
> * led_classdev_suspend - suspend an led_classdev.
> * @led_cdev: the led_classdev to suspend.
> @@ -367,6 +388,12 @@ int led_classdev_register_ext(struct device *parent,
> if (ret < 0)
> return ret;
>
> +#ifdef CONFIG_LEDS_HARDWARE_CONTROL
> + ret = led_classdev_check_blink_mode_functions(led_cdev);
> + if (ret < 0)
> + return ret;
> +#endif
You can then drop this #ifdef, since it will return 0 by default when
disabled, and the compiler should optimize it all out.
> @@ -154,6 +160,32 @@ struct led_classdev {
>
> /* LEDs that have private triggers have this set */
> struct led_hw_trigger_type *trigger_type;
> +
> + /* This report the supported blink_mode. The driver should report the
> + * correct LED capabilities.
> + * With this set to HARDWARE_CONTROLLED, LED is always in offload mode
> + * and triggers can't be simulated by software.
> + * If the led is HARDWARE_CONTROLLED, status/start/stop function
> + * are optional.
> + * By default SOFTWARE_CONTROLLED is set as blink_mode.
> + */
> + enum led_blink_modes blink_mode;
> +#ifdef CONFIG_LEDS_HARDWARE_CONTROL
> + /* Ask the LED driver if hardware mode is enabled or not.
> + * If the option is not declared by the LED driver, SOFTWARE_CONTROLLED
> + * is assumed.
> + * Triggers will check if the hardware mode is supported and will be
> + * activated accordingly. If the trigger can't run in hardware mode,
> + * return -EOPNOTSUPP as the blinking can't be simulated by software.
> + */
> + bool (*hw_control_status)(struct led_classdev *led_cdev);
> + /* Set LED in hardware mode */
> + int (*hw_control_start)(struct led_classdev *led_cdev);
> + /* Disable hardware mode for LED. It's advised to the LED driver to put it to
> + * the old status but that is not mandatory and also putting it off is accepted.
> + */
> + int (*hw_control_stop)(struct led_classdev *led_cdev);
> +#endif
I'm surprised this builds. It looked like you accessed these two
members even when the option was disabled. I would keep them even when
the option is disabled. Two pointers don't add much overhead, and it
makes the drivers simpler.
> #ifdef CONFIG_LEDS_BRIGHTNESS_HW_CHANGED
> @@ -215,7 +247,6 @@ extern struct led_classdev *of_led_get(struct device_node *np, int index);
> extern void led_put(struct led_classdev *led_cdev);
> struct led_classdev *__must_check devm_of_led_get(struct device *dev,
> int index);
> -
Unrelated white space change.
Andrew
next prev parent reply other threads:[~2022-05-04 22:19 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-03 15:16 [RFC PATCH v6 00/11] Adds support for PHY LEDs with offload triggers Ansuel Smith
2022-05-03 15:16 ` [RFC PATCH v6 01/11] leds: add support for hardware driven LEDs Ansuel Smith
2022-05-04 22:19 ` Andrew Lunn [this message]
2022-05-05 13:01 ` Ansuel Smith
2022-05-03 15:16 ` [RFC PATCH v6 02/11] leds: add function to configure hardware controlled LED Ansuel Smith
2022-05-04 23:23 ` Andrew Lunn
2022-05-05 13:02 ` Ansuel Smith
2022-05-03 15:16 ` [RFC PATCH v6 03/11] leds: trigger: netdev: drop NETDEV_LED_MODE_LINKUP from mode Ansuel Smith
2022-05-04 23:25 ` Andrew Lunn
2022-05-05 13:05 ` Ansuel Smith
2022-05-03 15:16 ` [RFC PATCH v6 04/11] leds: trigger: netdev: rename and expose NETDEV trigger enum modes Ansuel Smith
2022-05-05 0:29 ` Andrew Lunn
2022-05-03 15:16 ` [RFC PATCH v6 05/11] leds: trigger: netdev: convert device attr to macro Ansuel Smith
2022-05-03 15:16 ` [RFC PATCH v6 06/11] leds: trigger: netdev: add hardware control support Ansuel Smith
2022-05-05 1:00 ` Andrew Lunn
2022-05-05 13:27 ` Ansuel Smith
2022-05-03 15:16 ` [RFC PATCH v6 07/11] leds: trigger: netdev: use mutex instead of spinlocks Ansuel Smith
2022-05-05 1:10 ` Andrew Lunn
2022-05-05 13:29 ` Ansuel Smith
2022-05-05 14:21 ` Andrew Lunn
2022-05-05 14:43 ` Ansuel Smith
2022-05-03 15:16 ` [RFC PATCH v6 08/11] leds: trigger: netdev: add available mode sysfs attr Ansuel Smith
2022-05-03 15:16 ` [RFC PATCH v6 09/11] leds: trigger: netdev: add additional hardware only triggers Ansuel Smith
2022-05-05 1:29 ` Andrew Lunn
2022-05-05 13:30 ` Ansuel Smith
2022-05-03 15:16 ` [RFC PATCH v6 10/11] net: dsa: qca8k: add LEDs support Ansuel Smith
2022-05-05 1:46 ` Andrew Lunn
2022-05-05 1:55 ` Andrew Lunn
2022-05-05 13:33 ` Ansuel Smith
2022-05-05 14:24 ` Andrew Lunn
2022-05-03 15:16 ` [RFC PATCH v6 11/11] dt-bindings: net: dsa: qca8k: add LEDs definition example Ansuel Smith
2022-05-03 22:21 ` Rob Herring
2022-05-04 17:15 ` Rob Herring
2022-05-05 13:34 ` 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=YnL73yOfh+wHQObm@lunn.ch \
--to=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--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=krzk+dt@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=pabeni@redhat.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
all inboxes | Powered by JetHome®