linux-kernel - Re: [PATCH 3/3] iio: Add driver for Nicera D3-323-AA PIR sensor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <pndr0026uyg.fsf@axis.com>
Date: Mon, 2 Jun 2025 17:09:59 +0200
From: Waqar Hameed <waqar.hameed@...s.com>
To: Jonathan Cameron <jic23@...nel.org>
CC: Lars-Peter Clausen <lars@...afoo.de>, <kernel@...s.com>,
	<linux-kernel@...r.kernel.org>, <linux-iio@...r.kernel.org>
Subject: Re: [PATCH 3/3] iio: Add driver for Nicera D3-323-AA PIR sensor

On Sat, May 31, 2025 at 16:10 +0100 Jonathan Cameron <jic23@...nel.org> wrote:

[...]

>> 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).
>
> I would disagree slightly.  If it is used in multiple places because there
> is some inherent reason they should have same string then I absolutely agree.
> If it's just because it's a convenient string that is used twice in places
> that could have had different string then not so much.

Absolutely! If two places can end up with different strings, then they
shouldn't share the same variable in the first place. I was not as clear
as you with my one-sentence :)

>> 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?
>
> I'd prefer that for new code, but it is a less clear cut case than the ones
> you have tidied up, so not worth the churn of tidying up unless people
> are otherwise working on the relevant drivers.

Sure, let's use string literals in this driver then.