diff mbox series

[v5,08/10] acpi/nfit: Improve terminator line in acpi_nfit_ids

Message ID 20230616165034.3630141-9-michal.wilczynski@intel.com (mailing list archive)
State Superseded
Headers show
Series Remove .notify callback in acpi_device_ops | expand

Commit Message

Wilczynski, Michal June 16, 2023, 4:50 p.m. UTC
Currently terminator line contains redunant characters. Remove them and
also remove a comma at the end.

Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
---
 drivers/acpi/nfit/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Rafael J. Wysocki June 29, 2023, 4:14 p.m. UTC | #1
On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
<michal.wilczynski@intel.com> wrote:
>
> Currently terminator line contains redunant characters.

Well, they are terminating the list properly AFAICS, so they aren't
redundant and the size of it before and after the change is actually
the same, isn't it?

> Remove them and also remove a comma at the end.

I suppose that this change is made for consistency with the other ACPI
code, so this would be the motivation to give in the changelog.

In any case, it doesn't seem to be related to the rest of the series.

> Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
> ---
>  drivers/acpi/nfit/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index aff79cbc2190..95930e9d776c 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -3455,7 +3455,7 @@ EXPORT_SYMBOL_GPL(__acpi_nfit_notify);
>
>  static const struct acpi_device_id acpi_nfit_ids[] = {
>         { "ACPI0012", 0 },
> -       { "", 0 },
> +       {}
>  };
>  MODULE_DEVICE_TABLE(acpi, acpi_nfit_ids);
>
> --
> 2.41.0
>
Dan Williams June 29, 2023, 8:51 p.m. UTC | #2
Michal Wilczynski wrote:
> Currently terminator line contains redunant characters. Remove them and
> also remove a comma at the end.
> 
> Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
> ---
>  drivers/acpi/nfit/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index aff79cbc2190..95930e9d776c 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -3455,7 +3455,7 @@ EXPORT_SYMBOL_GPL(__acpi_nfit_notify);
>  
>  static const struct acpi_device_id acpi_nfit_ids[] = {
>  	{ "ACPI0012", 0 },
> -	{ "", 0 },
> +	{}

Looks like a pointless change to me.
Wilczynski, Michal June 30, 2023, 9:52 a.m. UTC | #3
On 6/29/2023 6:14 PM, Rafael J. Wysocki wrote:
> On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
> <michal.wilczynski@intel.com> wrote:
>> Currently terminator line contains redunant characters.
> Well, they are terminating the list properly AFAICS, so they aren't
> redundant and the size of it before and after the change is actually
> the same, isn't it?

This syntax is correct of course, but we have an internal guidelines specifically
saying that terminator line should NOT contain a comma at the end. Justification:

"Terminator line is established for the data structure arrays which may have unknown,
to the caller, sizes. The purpose of it is to stop iteration over an array and avoid
out-of-boundary access. Nevertheless, we may apply a bit more stricter rule to avoid
potential, but unlike, event of adding the entry after terminator, already at compile time.
This will be achieved by not putting comma at the end of terminator line"

>
>> Remove them and also remove a comma at the end.
> I suppose that this change is made for consistency with the other ACPI
> code, so this would be the motivation to give in the changelog.
>
> In any case, it doesn't seem to be related to the rest of the series.
>
>> Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
>> ---
>>  drivers/acpi/nfit/core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
>> index aff79cbc2190..95930e9d776c 100644
>> --- a/drivers/acpi/nfit/core.c
>> +++ b/drivers/acpi/nfit/core.c
>> @@ -3455,7 +3455,7 @@ EXPORT_SYMBOL_GPL(__acpi_nfit_notify);
>>
>>  static const struct acpi_device_id acpi_nfit_ids[] = {
>>         { "ACPI0012", 0 },
>> -       { "", 0 },
>> +       {}
>>  };
>>  MODULE_DEVICE_TABLE(acpi, acpi_nfit_ids);
>>
>> --
>> 2.41.0
>>
Wilczynski, Michal June 30, 2023, 10:10 a.m. UTC | #4
On 6/29/2023 10:51 PM, Dan Williams wrote:
> Michal Wilczynski wrote:
>> Currently terminator line contains redunant characters. Remove them and
>> also remove a comma at the end.
>>
>> Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
>> ---
>>  drivers/acpi/nfit/core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
>> index aff79cbc2190..95930e9d776c 100644
>> --- a/drivers/acpi/nfit/core.c
>> +++ b/drivers/acpi/nfit/core.c
>> @@ -3455,7 +3455,7 @@ EXPORT_SYMBOL_GPL(__acpi_nfit_notify);
>>  
>>  static const struct acpi_device_id acpi_nfit_ids[] = {
>>  	{ "ACPI0012", 0 },
>> -	{ "", 0 },
>> +	{}
> Looks like a pointless change to me.

It's not very consequential, but isn't totally pointless in my view:

"Terminator line is established for the data structure arrays which may have unknown,
to the caller, sizes. The purpose of it is to stop iteration over an array and avoid
out-of-boundary access. Nevertheless, we may apply a bit more stricter rule to avoid
potential, but unlike, event of adding the entry after terminator, already at compile time.
This will be achieved by not putting comma at the end of terminator line"



Anyway I can drop this change, it's just confusing everyone
Rafael J. Wysocki June 30, 2023, 11:04 a.m. UTC | #5
On Fri, Jun 30, 2023 at 11:52 AM Wilczynski, Michal
<michal.wilczynski@intel.com> wrote:
>
>
>
> On 6/29/2023 6:14 PM, Rafael J. Wysocki wrote:
> > On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
> > <michal.wilczynski@intel.com> wrote:
> >> Currently terminator line contains redunant characters.
> > Well, they are terminating the list properly AFAICS, so they aren't
> > redundant and the size of it before and after the change is actually
> > the same, isn't it?
>
> This syntax is correct of course, but we have an internal guidelines specifically
> saying that terminator line should NOT contain a comma at the end. Justification:
>
> "Terminator line is established for the data structure arrays which may have unknown,
> to the caller, sizes. The purpose of it is to stop iteration over an array and avoid
> out-of-boundary access. Nevertheless, we may apply a bit more stricter rule to avoid
> potential, but unlike, event of adding the entry after terminator, already at compile time.
> This will be achieved by not putting comma at the end of terminator line"

This certainly applies to any new code.

The existing code, however, is what it is and the question is how much
of an improvement the given change makes.

So yes, it may not follow the current rules for new code, but then it
may not be worth changing to follow these rules anyway.
Rafael J. Wysocki June 30, 2023, 11:13 a.m. UTC | #6
On Fri, Jun 30, 2023 at 1:04 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Fri, Jun 30, 2023 at 11:52 AM Wilczynski, Michal
> <michal.wilczynski@intel.com> wrote:
> >
> >
> >
> > On 6/29/2023 6:14 PM, Rafael J. Wysocki wrote:
> > > On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
> > > <michal.wilczynski@intel.com> wrote:
> > >> Currently terminator line contains redunant characters.
> > > Well, they are terminating the list properly AFAICS, so they aren't
> > > redundant and the size of it before and after the change is actually
> > > the same, isn't it?
> >
> > This syntax is correct of course, but we have an internal guidelines specifically
> > saying that terminator line should NOT contain a comma at the end. Justification:
> >
> > "Terminator line is established for the data structure arrays which may have unknown,
> > to the caller, sizes. The purpose of it is to stop iteration over an array and avoid
> > out-of-boundary access. Nevertheless, we may apply a bit more stricter rule to avoid
> > potential, but unlike, event of adding the entry after terminator, already at compile time.
> > This will be achieved by not putting comma at the end of terminator line"
>
> This certainly applies to any new code.
>
> The existing code, however, is what it is and the question is how much
> of an improvement the given change makes.
>
> So yes, it may not follow the current rules for new code, but then it
> may not be worth changing to follow these rules anyway.

This is a bit like housing in a city.

Usually, there are strict requirements that must be followed while
constructing a new building, but existing buildings are not
reconstructed to follow them in the majority of cases.  It may not
even be a good idea to do that.
Wilczynski, Michal June 30, 2023, 12:02 p.m. UTC | #7
On 6/30/2023 1:13 PM, Rafael J. Wysocki wrote:
> On Fri, Jun 30, 2023 at 1:04 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On Fri, Jun 30, 2023 at 11:52 AM Wilczynski, Michal
>> <michal.wilczynski@intel.com> wrote:
>>>
>>>
>>> On 6/29/2023 6:14 PM, Rafael J. Wysocki wrote:
>>>> On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski
>>>> <michal.wilczynski@intel.com> wrote:
>>>>> Currently terminator line contains redunant characters.
>>>> Well, they are terminating the list properly AFAICS, so they aren't
>>>> redundant and the size of it before and after the change is actually
>>>> the same, isn't it?
>>> This syntax is correct of course, but we have an internal guidelines specifically
>>> saying that terminator line should NOT contain a comma at the end. Justification:
>>>
>>> "Terminator line is established for the data structure arrays which may have unknown,
>>> to the caller, sizes. The purpose of it is to stop iteration over an array and avoid
>>> out-of-boundary access. Nevertheless, we may apply a bit more stricter rule to avoid
>>> potential, but unlike, event of adding the entry after terminator, already at compile time.
>>> This will be achieved by not putting comma at the end of terminator line"
>> This certainly applies to any new code.
>>
>> The existing code, however, is what it is and the question is how much
>> of an improvement the given change makes.
>>
>> So yes, it may not follow the current rules for new code, but then it
>> may not be worth changing to follow these rules anyway.
> This is a bit like housing in a city.
>
> Usually, there are strict requirements that must be followed while
> constructing a new building, but existing buildings are not
> reconstructed to follow them in the majority of cases.  It may not
> even be a good idea to do that.

Thanks, great explanation ! I think it's a shared sentiment among maintainers.
I've been watching upstreaming effort of intel new idpf driver, and it got rejected
basically because new drivers are held to a higher standard (they didn't modernize
their code to use new page pool API).

https://lore.kernel.org/netdev/20230621122106.56cb5bf1@kernel.org/#t
diff mbox series

Patch

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index aff79cbc2190..95930e9d776c 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -3455,7 +3455,7 @@  EXPORT_SYMBOL_GPL(__acpi_nfit_notify);
 
 static const struct acpi_device_id acpi_nfit_ids[] = {
 	{ "ACPI0012", 0 },
-	{ "", 0 },
+	{}
 };
 MODULE_DEVICE_TABLE(acpi, acpi_nfit_ids);