linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Pilcher <arequipeno@gmail.com>
To: "Marek Behún" <kabel@kernel.org>
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 00/15] Introduce block device LED trigger
Date: Fri, 10 Sep 2021 09:04:19 -0500	[thread overview]
Message-ID: <06581fe9-f9b2-5bee-07d6-e5b276a5e7f8@gmail.com> (raw)
In-Reply-To: <20210910040959.5ae4a6a1@thinkpad>

On 9/9/21 9:09 PM, Marek Behún wrote:
> I have tried to look into this and replied to some of your patches.
> 
> There are still many things to do, and I think the reviewing would be
> much easier to review if you sent all the code changes as one patch
> (since the changes are doing an atomic change: adding support for blkdev
> LED trigger). Keep only the sysfs doc change in a separate patch.

Marek -

I'll try to get a simplified version out as soon as I can.  It will
probably be 3 patches, because I do think that the block subsystem
changes should be in a separate patch.

(I agree that it will be simpler to review - not to mention easier for
me to create.  Past experience does tell me that there are likely some
folks who will object to that format, however.)

> You are unnecessary using the const keyword in places where it is not
> needed and not customary for Linux kernel codebase. See in another of
> my replies.

I did see that.  I'm a believer in declaring anything that should not
change as const (to the extent that C allows).  It documents the
fact that the value is expected to remain unchanged throughout the
function call, and it enlists the compiler to enforce it.

So while it's true that they aren't necessary, they do result in code
that is at least slightly less likely to be broken by future changes.

> You are using a weird comment style, i.e.
>    /*
>     *
>     *	Disassociate an LED from the trigger
>     *
>     */
> 
>    static void blkdev_deactivate(struct led_classdev *const led_dev)
> 
> Please look at how functions are documented in led-class.c, for example.

Well ... that comment isn't documenting that function.  It's intended to
identify a section of the file whose contents are related.  If there's a
different comment style that I should be using for that purpose, please
let me know.

I'll respond to your other feedback separately.

Thanks for taking your time on this.  I really do appreciate it!

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================

      reply	other threads:[~2021-09-10 14:04 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
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 [this message]

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=06581fe9-f9b2-5bee-07d6-e5b276a5e7f8@gmail.com \
    --to=arequipeno@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=gregkh@linuxfoundation.org \
    --cc=kabel@kernel.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).