All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev <netdev@vger.kernel.org>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Simon Horman <simon.horman@corigine.com>,
	Christian Marangi <ansuelsmth@gmail.com>
Subject: Re: [PATCH v2 net-next 1/3] led: trig: netdev: Fix requesting offload device
Date: Tue, 18 Jul 2023 20:34:37 +0100	[thread overview]
Message-ID: <ZLbpTWT0StW0AnqX@makrotopia.org> (raw)
In-Reply-To: <20230624205629.4158216-2-andrew@lunn.ch>

On Sat, Jun 24, 2023 at 10:56:27PM +0200, Andrew Lunn wrote:
> 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>
> ---
>  drivers/leds/trigger/ledtrig-netdev.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
> index 32b66703068a..247b100ee1d3 100644
> --- a/drivers/leds/trigger/ledtrig-netdev.c
> +++ b/drivers/leds/trigger/ledtrig-netdev.c
> @@ -565,15 +565,17 @@ static int netdev_trig_activate(struct led_classdev *led_cdev)
>  	/* Check if hw control is active by default on the LED.
>  	 * Init already enabled mode in hw control.
>  	 */
> -	if (supports_hw_control(led_cdev) &&
> -	    !led_cdev->hw_control_get(led_cdev, &mode)) {
> +	if (supports_hw_control(led_cdev)) {
>  		dev = led_cdev->hw_control_get_device(led_cdev);
>  		if (dev) {
>  			const char *name = dev_name(dev);
>  
>  			set_device_name(trigger_data, name, strlen(name));
>  			trigger_data->hw_control = true;
> -			trigger_data->mode = mode;
> +
> +			rc = led_cdev->hw_control_get(led_cdev, &mode);

Shouldn't there also be something like
led_cdev->hw_control_get(led_cdev, 0);
in netdev_trig_deactivate then?
Because somehow we need to tell the hardware to no longer perform an
offloading operation.

> +			if (!rc)
> +				trigger_data->mode = mode;
>  		}
>  	}
>  
> -- 
> 2.40.1
> 
> 

  reply	other threads:[~2023-07-18 19:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-24 20:56 [PATCH v2 net-next 0/3] Support offload LED blinking to PHY Andrew Lunn
2023-06-24 20:56 ` [PATCH v2 net-next 1/3] led: trig: netdev: Fix requesting offload device Andrew Lunn
2023-07-18 19:34   ` Daniel Golle [this message]
2023-08-07 22:27     ` Andrew Lunn
2023-08-07 22:49       ` Daniel Golle
2023-08-07 23:48         ` Andrew Lunn
2023-06-24 20:56 ` [PATCH v2 net-next 2/3] net: phy: phy_device: Call into the PHY driver to set LED offload Andrew Lunn
2023-06-24 20:56 ` [PATCH v2 net-next 3/3] net: phy: marvell: Add support for offloading LED blinking Andrew Lunn
2023-06-26  3:33   ` Kalesh Anakkur Purayil
2023-07-29 12:38 ` [PATCH v2 net-next 0/3] Support offload LED blinking to PHY Daniel Golle
2023-07-29 17:19   ` Andrew Lunn

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=ZLbpTWT0StW0AnqX@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=andrew@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=simon.horman@corigine.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.