linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Ian Pilcher <arequipeno@gmail.com>
Cc: axboe@kernel.dk, pavel@ucw.cz, linux-leds@vger.kernel.org,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	gregkh@linuxfoundation.org
Subject: Re: [PATCH v2 09/15] leds: trigger: blkdev: Check devices for activity and blink LEDs
Date: Fri, 10 Sep 2021 03:48:38 +0200	[thread overview]
Message-ID: <20210910034838.4331512d@thinkpad> (raw)
In-Reply-To: <20210909222513.2184795-10-arequipeno@gmail.com>

On Thu,  9 Sep 2021 17:25:07 -0500
Ian Pilcher <arequipeno@gmail.com> wrote:

> +static void blkdev_blink(const struct ledtrig_blkdev_led *const led)
> +{

Why are you declaring the led variable as const? This is not needed.
Sure, you do not change it, but I have never seen this being used in
this way in kernel.

> +	unsigned long delay_on = READ_ONCE(led->blink_msec);
> +	unsigned long delay_off = 1;	/* 0 leaves LED turned on */
> +
> +	led_blink_set_oneshot(led->led_dev, &delay_on, &delay_off, 0);
> +}
> +
> +static void blkdev_update_disk(struct ledtrig_blkdev_disk *const disk,
> +			       const unsigned int generation)
> +{
> +	const struct block_device *const part0 = disk->gd->part0;
> +	const unsigned long read_ios = part_stat_read(part0, ios[STAT_READ]);
> +	const unsigned long write_ios = part_stat_read(part0, ios[STAT_WRITE])
> +				+ part_stat_read(part0, ios[STAT_DISCARD])
> +				+ part_stat_read(part0, ios[STAT_FLUSH]);

Again, yes, you do not change part0, read_ios or write_ios in this
function, but this does not mean you need to declare them const.

Const is good when you want to declare that a place where a pointer
points to should be constant. You don't need to do it for the pointer
itself, I don't see any benefit from this.

> +
> +	if (disk->read_ios != read_ios) {
> +		disk->read_act = true;
> +		disk->read_ios = read_ios;
> +	} else {
> +		disk->read_act = false;
> +	}
> +
> +	if (disk->write_ios != write_ios) {
> +		disk->write_act = true;
> +		disk->write_ios = write_ios;
> +	} else {
> +		disk->write_act = false;
> +	}
> +
> +	disk->generation = generation;
> +}
> +
> +static bool blkdev_read_mode(const enum ledtrig_blkdev_mode mode)
> +{
> +	return mode != LEDTRIG_BLKDEV_MODE_WO;
> +}
> +
> +static bool blkdev_write_mode(const enum ledtrig_blkdev_mode mode)
> +{
> +	return mode != LEDTRIG_BLKDEV_MODE_RO;
> +}

It would be better to simply do the comparison where it is needed,
since it is so short. These functions aren't needed, they do not
shorten code in any significant way, nor do they make it more readable
(in fact, they make it a little less readable).

> +
> +static void blkdev_process(struct work_struct *const work)

You are again using const where it is not needed.
In fact the work_func_t type does not have it:
  typedef void (*work_func_t)(struct work_struct *work);

> +{
> +	static unsigned int generation;
> +
> +	struct ledtrig_blkdev_led *led;
> +	struct ledtrig_blkdev_link *link;
> +	unsigned long delay;
> +
> +	if (!mutex_trylock(&ledtrig_blkdev_mutex))
> +		goto exit_reschedule;
> +
> +	hlist_for_each_entry(led, &ledtrig_blkdev_leds, leds_node) {
> +
> +		hlist_for_each_entry(link, &led->disks, led_disks_node) {
> +
> +			struct ledtrig_blkdev_disk *const disk = link->disk;
> +
> +			if (disk->generation != generation)
> +				blkdev_update_disk(disk, generation);
> +
> +			if (disk->read_act && blkdev_read_mode(led->mode)) {
> +				blkdev_blink(led);
> +				break;
> +			}
> +
> +			if (disk->write_act && blkdev_write_mode(led->mode)) {
> +				blkdev_blink(led);
> +				break;
> +			}

These two blinks should be one blink, i.e.
  if ((read_act && read_mode) || (write_act && write_mode))
    blink();

> +		}
> +	}
> +
> +	++generation;
> +
> +	mutex_unlock(&ledtrig_blkdev_mutex);
> +
> +exit_reschedule:
> +	delay = READ_ONCE(ledtrig_blkdev_interval);
> +	WARN_ON_ONCE(!schedule_delayed_work(&ledtrig_blkdev_work, delay));
> +}
> +
>  
>  /*
>   *


  reply	other threads:[~2021-09-10  1:48 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 22:24 [PATCH v2 00/15] Introduce block device LED trigger Ian Pilcher
2021-09-09 22:24 ` [PATCH v2 01/15] docs: Add block device (blkdev) LED trigger documentation Ian Pilcher
2021-09-09 22:25 ` [PATCH v2 02/15] leds: trigger: blkdev: Add build infrastructure Ian Pilcher
2021-09-10  1:32   ` Marek Behún
2021-09-09 22:25 ` [PATCH v2 03/15] leds: trigger: blkdev: Add functions needed by block changes Ian Pilcher
2021-09-09 22:25 ` [PATCH v2 04/15] block: Add block device LED trigger integrations Ian Pilcher
2021-09-09 23:27   ` Chaitanya Kulkarni
2021-09-10  1:23   ` Marek Behún
2021-09-10 15:00     ` Ian Pilcher
2021-09-10  1:38   ` Marek Behún
2021-09-09 22:25 ` [PATCH v2 05/15] leds: trigger: blkdev: Complete functions called by block subsys Ian Pilcher
2021-09-09 22:25 ` [PATCH v2 06/15] leds: trigger: blkdev: Add function to get gendisk by name Ian Pilcher
2021-09-10  6:45   ` Greg KH
2021-09-10 15:17     ` Ian Pilcher
2021-09-10 15:23       ` Greg KH
2021-09-10 16:28     ` Ian Pilcher
2021-09-09 22:25 ` [PATCH v2 07/15] leds: trigger: blkdev: Add constants and types Ian Pilcher
2021-09-09 22:25 ` [PATCH v2 08/15] leds: trigger: blkdev: Add stub LED trigger structure Ian Pilcher
2021-09-09 22:25 ` [PATCH v2 09/15] leds: trigger: blkdev: Check devices for activity and blink LEDs Ian Pilcher
2021-09-10  1:48   ` Marek Behún [this message]
2021-09-10  2:17   ` Marek Behún
2021-09-10 15:09     ` Ian Pilcher
2021-09-10 15:12       ` Marek Behún
2021-09-10 21:23         ` Ian Pilcher
2021-09-09 22:25 ` [PATCH v2 10/15] leds: trigger: blkdev: Add LED trigger activate function Ian Pilcher
2021-09-10  6:47   ` Greg KH
2021-09-10 16:10     ` Ian Pilcher
2021-09-09 22:25 ` [PATCH v2 11/15] leds: trigger: blkdev: Enable linking block devices to LEDs Ian Pilcher
2021-09-10  6:48   ` Greg KH
2021-09-10 16:25     ` Ian Pilcher
2021-09-09 22:25 ` [PATCH v2 12/15] leds: trigger: blkdev: Enable unlinking block devices from LEDs Ian Pilcher
2021-09-14  9:58   ` Dan Carpenter
2021-09-09 22:25 ` [PATCH v2 13/15] leds: trigger: blkdev: Add LED trigger deactivate function Ian Pilcher
2021-09-09 22:25 ` [PATCH v2 14/15] leds: trigger: blkdev: Add remaining sysfs attributes Ian Pilcher
2021-09-09 22:25 ` [PATCH v2 15/15] leds: trigger: blkdev: Add disk cleanup and init/exit functions Ian Pilcher
2021-09-10  2:09 ` [PATCH v2 00/15] Introduce block device LED trigger Marek Behún
2021-09-10 14:04   ` Ian Pilcher

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=20210910034838.4331512d@thinkpad \
    --to=kabel@kernel.org \
    --cc=arequipeno@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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).