public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Waqar Hameed <waqar.hameed@axis.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>, <kernel@axis.com>,
	<linux-kernel@vger.kernel.org>, <linux-iio@vger.kernel.org>
Subject: Re: [PATCH 3/3] iio: Add driver for Nicera D3-323-AA PIR sensor
Date: Tue, 27 May 2025 16:48:30 +0200	[thread overview]
Message-ID: <pndecwa85z5.fsf@axis.com> (raw)
In-Reply-To: <20250525103019.3773be94@jic23-huawei> (Jonathan Cameron's message of "Sun, 25 May 2025 10:30:19 +0100")

On Sun, May 25, 2025 at 10:30 +0100 Jonathan Cameron <jic23@kernel.org> wrote:

> On Tue, 20 May 2025 13:27:54 +0200
> Waqar Hameed <waqar.hameed@axis.com> wrote:
>
>> On Sun, May 18, 2025 at 18:38 +0100 Jonathan Cameron <jic23@kernel.org> wrote:
>> 
>> >> >> +#define D3323AA_DRV_NAME "d3323aa"    
>> >> >
>> >> > Put that inline where used.  A define like this both implies that various values
>> >> > must be the same when they need not be and means that we have to go find the
>> >> > define to fine out what they are set to.  Just setting the strings directly
>> >> > tends to end up more readable.    
>> >> 
>> >> Sure, we can do that. (There are a bunch of IIO-drivers doing this, so I
>> >> just thought that was the "convention".)  
>> >
>> > I'm sometimes in less fussy mood.  One day I might just clean those up
>> > so there is nothing to copy into new drivers!  
>> 
>> A quick search tells that there are (at least) 105 of those:
>> 
>>   rgrep -A 30 "\.driver" drivers/iio/ | grep "\.name" | grep -v '"'
>>   
>> I was just about to write a small Python script to fix those, but just
>> wanted to confirm with you before spending more time on this. So if you
>> don't want to do this yourself, I can help your here :)
>
> It's probably not worth the churn on the ones that have the string repeated
> multiple times.  However, perhaps any that are only using it for .name would
> be good to tidy up?  Those are less a case of it being 'taste' vs it being silly
> to have a define!

I think if you use it in multiple places, it should definitively be a
macro definition. I just sent some patches for those that only used it
once (I didn't include those with `KBUILD_MODNAME`. We can discuss if we
should also address those in that thread).

However, there are a bunch of drivers that _only_ use a macro definition
in `.name` and `indio_dev->name`, including this one. That _is_ more
than one place, so we should actually leave it? Or do you still think we
should have the same string literal in both places, as you originally
commented above?

  reply	other threads:[~2025-05-27 14:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-09 15:03 [PATCH 0/3] Add driver for Nicera D3-323-AA PIR sensor Waqar Hameed
2025-05-09 15:03 ` [PATCH 1/3] dt-bindings: vendor-prefixes: Add Nicera Waqar Hameed
2025-05-09 15:03 ` [PATCH 2/3] dt-bindings: iio: proximity: Add Nicera D3-323-AA PIR sensor Waqar Hameed
2025-05-09 15:06   ` Krzysztof Kozlowski
2025-05-16 17:15     ` Waqar Hameed
2025-05-20  6:36       ` Krzysztof Kozlowski
2025-05-20 12:00         ` Waqar Hameed
2025-05-09 15:03 ` [PATCH 3/3] iio: Add driver for " Waqar Hameed
2025-05-11  7:57   ` Christophe JAILLET
2025-05-16 17:16     ` Waqar Hameed
2025-05-11 12:14   ` Jonathan Cameron
2025-05-16 17:16     ` Waqar Hameed
2025-05-18 17:38       ` Jonathan Cameron
2025-05-20 11:27         ` Waqar Hameed
2025-05-25  9:30           ` Jonathan Cameron
2025-05-27 14:48             ` Waqar Hameed [this message]
2025-05-31 15:10               ` Jonathan Cameron
2025-06-02 15:09                 ` Waqar Hameed
2025-06-14 22:05       ` Waqar Hameed
2025-05-09 15:09 ` [PATCH 0/3] " Krzysztof Kozlowski
2025-05-16 17:14   ` Waqar Hameed
  -- strict thread matches above, loose matches on Subject: below --
2025-06-14 21:56 Waqar Hameed
2025-06-14 21:56 ` [PATCH 3/3] iio: " Waqar Hameed

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=pndecwa85z5.fsf@axis.com \
    --to=waqar.hameed@axis.com \
    --cc=jic23@kernel.org \
    --cc=kernel@axis.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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