From: Andi Drebes <lists-receive@programmierforen.de>
To: Richard Knutsson <ricknu-0@student.ltu.se>
Cc: kernel-janitors@lists.osdl.org, lenb@kernel.org,
linux-acpi@vger.kernel.org
Subject: Re: [KJ] [PATCH] drivers/acpi: sizeof/sizeof array size calculations replaced with ARRAY_SIZE
Date: Sat, 26 May 2007 13:58:24 +0000 [thread overview]
Message-ID: <200705261558.24912.lists-receive@programmierforen.de> (raw)
In-Reply-To: <46581C06.7000005@student.ltu.se>
<snip>
> > diff --git a/drivers/acpi/resources/rsdump.c b/drivers/acpi/resources/rsdump.c
> > index 46da116..7b8e12d 100644
> > --- a/drivers/acpi/resources/rsdump.c
> > +++ b/drivers/acpi/resources/rsdump.c
> > @@ -76,7 +76,7 @@ acpi_rs_dump_descriptor(void *resource, struct acpi_rsdump_info *table);
> >
> > #define ACPI_RSD_OFFSET(f) (u8) ACPI_OFFSET (union acpi_resource_data,f)
> > #define ACPI_PRT_OFFSET(f) (u8) ACPI_OFFSET (struct acpi_pci_routing_table,f)
> > -#define ACPI_RSD_TABLE_SIZE(name) (sizeof(name) / sizeof (struct acpi_rsdump_info))
> > +#define ACPI_RSD_TABLE_SIZE(name) (ARRAY_SIZE(name))
> >
> Any reason to not just replace ACPI_RSD_TABLE_SIZE with ARRAY_SIZE? Got
> just 21 instances of it in the file (+ the define) and no more in the
> rest of the tree.
I agree with that. Robert P. J. Day pointed out something similiar. For
a more verbose answer to that see the reply to his message.
> > /*******************************************************************************
> > *
> > diff --git a/drivers/acpi/tables/tbfadt.c b/drivers/acpi/tables/tbfadt.c
> > index 1285e91..4d59de2 100644
> > --- a/drivers/acpi/tables/tbfadt.c
> > +++ b/drivers/acpi/tables/tbfadt.c
> > @@ -104,7 +104,7 @@ static struct acpi_fadt_info fadt_info_table[] = {
> > ACPI_FADT_OFFSET(gpe1_block_length), ACPI_FADT_SEPARATE_LENGTH}
> > };
> >
> > -#define ACPI_FADT_INFO_ENTRIES (sizeof (fadt_info_table) / sizeof (struct acpi_fadt_info))
> > +#define ACPI_FADT_INFO_ENTRIES (ARRAY_SIZE(fadt_info_table))
> >
> Normally I think this is ok when it is just a "constant", since the name
> of it may be more descriptive, but it is just used twice and I find
> (imho) ARRAY_SIZE(fadt_info_table) easier to understand.
I totally agree with that. Here's a new patch that totally removes the ACPI_FADT_INFO_ENTRIES
macro. In contrast to the original patch, this one only affects tbfadt.c (I split this, because
there's another issue about rsdump.c pointed out by Robert P. J. Day. The other
changes will be in a reply to his message)
Tested by compilation.
Signed-off-by: Andi Drebes <lists-receive@programmierforen.de>
--
diff --git a/drivers/acpi/tables/tbfadt.c b/drivers/acpi/tables/tbfadt.c
index 1285e91..ba6d4a1 100644
--- a/drivers/acpi/tables/tbfadt.c
+++ b/drivers/acpi/tables/tbfadt.c
@@ -104,8 +104,6 @@ static struct acpi_fadt_info fadt_info_table[] = {
ACPI_FADT_OFFSET(gpe1_block_length), ACPI_FADT_SEPARATE_LENGTH}
};
-#define ACPI_FADT_INFO_ENTRIES (sizeof (fadt_info_table) / sizeof (struct acpi_fadt_info))
-
/*******************************************************************************
*
* FUNCTION: acpi_tb_init_generic_address
@@ -295,7 +293,7 @@ static void acpi_tb_convert_fadt(void)
* Expand the 32-bit V1.0 addresses to the 64-bit "X" generic address
* structures as necessary.
*/
- for (i = 0; i < ACPI_FADT_INFO_ENTRIES; i++) {
+ for (i = 0; i < ARRAY_SIZE(fadt_info_table); i++) {
target =
ACPI_ADD_PTR(struct acpi_generic_address, &acpi_gbl_FADT,
fadt_info_table[i].target);
@@ -392,7 +390,7 @@ static void acpi_tb_validate_fadt(void)
/* Examine all of the 64-bit extended address fields (X fields) */
- for (i = 0; i < ACPI_FADT_INFO_ENTRIES; i++) {
+ for (i = 0; i < ARRAY_SIZE(fadt_info_table); i++) {
/* Generate pointers to the 32-bit and 64-bit addresses and get the length */
next prev parent reply other threads:[~2007-05-26 13:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-26 10:39 [KJ] [PATCH] drivers/acpi: sizeof/sizeof array size calculations replaced with ARRAY_SIZE Andi Drebes
2007-05-26 11:28 ` Robert P. J. Day
2007-05-26 13:53 ` Andi Drebes
2007-05-26 11:37 ` Richard Knutsson
2007-05-26 13:58 ` Andi Drebes [this message]
2007-05-30 19:25 ` Len Brown
2007-05-31 9:56 ` Christoph Hellwig
2007-06-10 10:57 ` Pavel Machek
2007-06-10 21:44 ` Bjorn Helgaas
2007-06-12 18:41 ` Andi Drebes
2007-06-12 18:53 ` Bjorn Helgaas
2007-06-13 21:21 ` Andi Drebes
2007-06-15 17:56 ` Andi Drebes
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=200705261558.24912.lists-receive@programmierforen.de \
--to=lists-receive@programmierforen.de \
--cc=kernel-janitors@lists.osdl.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=ricknu-0@student.ltu.se \
/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