linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Subject: Re: [RFC PATCH v6 06/11] leds: trigger: netdev: add hardware control support
Date: Thu, 5 May 2022 03:00:03 +0200	[thread overview]
Message-ID: <YnMhk1F0LrIMK5hp@lunn.ch> (raw)
In-Reply-To: <20220503151633.18760-7-ansuelsmth@gmail.com>

> +struct netdev_led_attr_detail {
> +	char *name;
> +	bool hardware_only;
> +	enum led_trigger_netdev_modes bit;
> +};
> +
> +static struct netdev_led_attr_detail attr_details[] = {
> +	{ .name = "link", .bit = TRIGGER_NETDEV_LINK},
> +	{ .name = "tx", .bit = TRIGGER_NETDEV_TX},
> +	{ .name = "rx", .bit = TRIGGER_NETDEV_RX},

hardware_only is never set. Maybe it is used in a later patch? If so,
please introduce it there.

>  static void set_baseline_state(struct led_netdev_data *trigger_data)
>  {
> +	int i;
>  	int current_brightness;
> +	struct netdev_led_attr_detail *detail;
>  	struct led_classdev *led_cdev = trigger_data->led_cdev;

This file mostly keeps with reverse christmas tree, probably because
it was written by a netdev developer. It is probably not required for
the LED subsystem, but it would be nice to keep the file consistent.

> @@ -100,10 +195,15 @@ static ssize_t device_name_store(struct device *dev,
>  				 size_t size)
>  {
>  	struct led_netdev_data *trigger_data = led_trigger_get_drvdata(dev);
> +	struct net_device *old_net = trigger_data->net_dev;
> +	char old_device_name[IFNAMSIZ];
>  
>  	if (size >= IFNAMSIZ)
>  		return -EINVAL;
>  
> +	/* Backup old device name */
> +	memcpy(old_device_name, trigger_data->device_name, IFNAMSIZ);
> +
>  	cancel_delayed_work_sync(&trigger_data->work);
>  
>  	spin_lock_bh(&trigger_data->lock);
> @@ -122,6 +222,19 @@ static ssize_t device_name_store(struct device *dev,
>  		trigger_data->net_dev =
>  		    dev_get_by_name(&init_net, trigger_data->device_name);
>  
> +	if (!validate_baseline_state(trigger_data)) {

You probably want to validate trigger_data->net_dev is not NULL first. The current code
is a little odd with that, 

> +		/* Restore old net_dev and device_name */
> +		if (trigger_data->net_dev)
> +			dev_put(trigger_data->net_dev);
> +
> +		dev_hold(old_net);

This dev_hold() looks wrong. It is trying to undo a dev_put()
somewhere? You should not actually do a put until you know you really
do not old_net, otherwise there is a danger it disappears and you
cannot undo.

> @@ -228,13 +349,22 @@ static ssize_t interval_store(struct device *dev,
>  		return ret;
>  
>  	/* impose some basic bounds on the timer interval */
> -	if (value >= 5 && value <= 10000) {
> -		cancel_delayed_work_sync(&trigger_data->work);
> +	if (value < 5 || value > 10000)
> +		return -EINVAL;
> +
> +	cancel_delayed_work_sync(&trigger_data->work);
> +
> +	atomic_set(&trigger_data->interval, msecs_to_jiffies(value));
>  
> -		atomic_set(&trigger_data->interval, msecs_to_jiffies(value));
> -		set_baseline_state(trigger_data);	/* resets timer */
> +	if (!validate_baseline_state(trigger_data)) {
> +		/* Restore old interval on validation error */
> +		atomic_set(&trigger_data->interval, old_interval);
> +		trigger_data->mode = old_mode;

I think you need to schedule the work again, since you cancelled
it. It is at the end of the work that the next work is scheduled, and
so it will not self recover.

   Andrew

  reply	other threads:[~2022-05-05  1:00 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
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 [this message]
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=YnMhk1F0LrIMK5hp@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=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;
as well as URLs for NNTP newsgroup(s).