* Re: [KJ] [PATCH] drivers/acpi: sizeof/sizeof array size calculations replaced with ARRAY_SIZE
[not found] ` <200705301525.05905.lenb@kernel.org>
@ 2007-05-31 9:56 ` Christoph Hellwig
2007-06-10 10:57 ` Pavel Machek
0 siblings, 1 reply; 7+ messages in thread
From: Christoph Hellwig @ 2007-05-31 9:56 UTC (permalink / raw)
To: Len Brown; +Cc: Andi Drebes, kernel-janitors, linux-acpi, linux-kernel
On Wed, May 30, 2007 at 03:25:05PM -0400, Len Brown wrote:
>
> > > Any reason to not just replace ACPI_RSD_TABLE_SIZE with ARRAY_SIZE?
>
> Probably because ARRAY_SIZE doesn't exist in ACPICA, which is
> where this code comes from...
>
> When we change syntax in ACPICA files in Linux to make it more "beautiful",
> then it creates more work for me -- as forever on, that syntax difference
> must be manually compared to upstream ACPICA and Linux -- and that syntax
> difference causes upstream patches to no longer apply and require
> hand merging.
Or we could stop that ACPCICA crap ASAP. The acpi code not only looks
like crap because of that but it's buggy as hell now.
Intel is claiming how great linux is and how supportive is to it, but
can't even write proper code for their abomination of a firmware standard.
This is really more than dishonest. Please take patches to get acpi into
shape and stop this complaining.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [KJ] [PATCH] drivers/acpi: sizeof/sizeof array size calculations replaced with ARRAY_SIZE
2007-05-31 9:56 ` [KJ] [PATCH] drivers/acpi: sizeof/sizeof array size calculations replaced with ARRAY_SIZE Christoph Hellwig
@ 2007-06-10 10:57 ` Pavel Machek
2007-06-10 21:44 ` Bjorn Helgaas
0 siblings, 1 reply; 7+ messages in thread
From: Pavel Machek @ 2007-06-10 10:57 UTC (permalink / raw)
To: Christoph Hellwig, Len Brown, Andi Drebes, kernel-janitors,
linux-acpi, linux-kernel
Hi!
> > > > Any reason to not just replace ACPI_RSD_TABLE_SIZE with ARRAY_SIZE?
> >
> > Probably because ARRAY_SIZE doesn't exist in ACPICA, which is
> > where this code comes from...
> >
> > When we change syntax in ACPICA files in Linux to make it more "beautiful",
> > then it creates more work for me -- as forever on, that syntax difference
> > must be manually compared to upstream ACPICA and Linux -- and that syntax
> > difference causes upstream patches to no longer apply and require
> > hand merging.
>
> Or we could stop that ACPCICA crap ASAP. The acpi code not only looks
> like crap because of that but it's buggy as hell now.
+1.
Len, acpi subsystem is old enough to live by kernel standards, and
important enough that it should look&feel like a kernel code. It also
does not seem to change quickly, so merging patches should not be a
big deal.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [KJ] [PATCH] drivers/acpi: sizeof/sizeof array size calculations replaced with ARRAY_SIZE
2007-06-10 10:57 ` Pavel Machek
@ 2007-06-10 21:44 ` Bjorn Helgaas
2007-06-12 18:41 ` Andi Drebes
0 siblings, 1 reply; 7+ messages in thread
From: Bjorn Helgaas @ 2007-06-10 21:44 UTC (permalink / raw)
To: Pavel Machek
Cc: Christoph Hellwig, Len Brown, Andi Drebes, kernel-janitors,
linux-acpi, linux-kernel
On Sunday 10 June 2007 04:57:12 am Pavel Machek wrote:
> > > > > Any reason to not just replace ACPI_RSD_TABLE_SIZE with ARRAY_SIZE?
> > >
> > > Probably because ARRAY_SIZE doesn't exist in ACPICA, which is
> > > where this code comes from...
> > >
> > > When we change syntax in ACPICA files in Linux to make it more "beautiful",
> > > then it creates more work for me -- as forever on, that syntax difference
> > > must be manually compared to upstream ACPICA and Linux -- and that syntax
> > > difference causes upstream patches to no longer apply and require
> > > hand merging.
> >
> > Or we could stop that ACPCICA crap ASAP. The acpi code not only looks
> > like crap because of that but it's buggy as hell now.
>
> +1.
>
> Len, acpi subsystem is old enough to live by kernel standards, and
> important enough that it should look&feel like a kernel code. It also
> does not seem to change quickly, so merging patches should not be a
> big deal.
I agree the ACPI CA is a nuisance. But in this case, we're making
a mountain out of a molehill. I suspect that if somebody spent the
15 minutes to make the ARRAY_SIZE patch work in both the Linux ACPI CA
and the generic Intel one and license it appropriately, Len would
happily apply the patch.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [KJ] [PATCH] drivers/acpi: sizeof/sizeof array size calculations replaced with ARRAY_SIZE
2007-06-10 21:44 ` Bjorn Helgaas
@ 2007-06-12 18:41 ` Andi Drebes
2007-06-12 18:53 ` Bjorn Helgaas
0 siblings, 1 reply; 7+ messages in thread
From: Andi Drebes @ 2007-06-12 18:41 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Pavel Machek, Christoph Hellwig, Len Brown, kernel-janitors,
linux-acpi, linux-kernel
First off: sorry for my late answer.
> I agree the ACPI CA is a nuisance. But in this case, we're making
> a mountain out of a molehill. I suspect that if somebody spent the
> 15 minutes to make the ARRAY_SIZE patch work in both the Linux ACPI CA
> and the generic Intel one and license it appropriately, Len would
> happily apply the patch.
I hope I got everything right. Here's what I understood so far:
The ACPI Subsystem in the kernel is derived from intel sources. I searched
the web for information about that and finally found
http://www.intel.com/technology/iapc/acpi/downloads.htm
Is that the right one? So what I would have to do in order to
"make the ARRAY_SIZE patch work in both the Linux ACPI CA
and the generic Intel one" is to modify those sources aswell,
send a patch to Intel and another one back to the
lkml.
Is that right? Or am I totally wrong?
Cheers,
Andi
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [KJ] [PATCH] drivers/acpi: sizeof/sizeof array size calculations replaced with ARRAY_SIZE
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
0 siblings, 2 replies; 7+ messages in thread
From: Bjorn Helgaas @ 2007-06-12 18:53 UTC (permalink / raw)
To: Andi Drebes
Cc: Pavel Machek, Christoph Hellwig, Len Brown, kernel-janitors,
linux-acpi, linux-kernel
On Tuesday 12 June 2007 12:41:05 pm Andi Drebes wrote:
> First off: sorry for my late answer.
>
> > I agree the ACPI CA is a nuisance. But in this case, we're making
> > a mountain out of a molehill. I suspect that if somebody spent the
> > 15 minutes to make the ARRAY_SIZE patch work in both the Linux ACPI CA
> > and the generic Intel one and license it appropriately, Len would
> > happily apply the patch.
> I hope I got everything right. Here's what I understood so far:
>
> The ACPI Subsystem in the kernel is derived from intel sources. I searched
> the web for information about that and finally found
>
> http://www.intel.com/technology/iapc/acpi/downloads.htm
>
> Is that the right one? So what I would have to do in order to
> "make the ARRAY_SIZE patch work in both the Linux ACPI CA
> and the generic Intel one" is to modify those sources aswell,
> send a patch to Intel and another one back to the
> lkml.
You found the right one. The ACPI CA in Linux is really the same
as the one from Intel. Len integrates the Intel one into Linux
periodically. He uses scripts or something to format it so it looks
more like Linux.
I think Len sometimes takes patches against the "Linux-ized" ACPI CA.
He probably has to apply those by hand to the Intel one, which is
the real "upstream" in this case. So it might be a bit easier for
him if you generated a diff against the Intel version. Then it
would show up in Linux, too, in the fullness of time.
In any event, you want to end up with one patch, not two.
You probably would have to add something like:
#ifndef ARRAY_SIZE
#define ARRAY_SIZE(x) ...
#endif
somewhere in the ACPI CA header files. That way it will work in
non-Linux OSes as well.
Bjorn
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [KJ] [PATCH] drivers/acpi: sizeof/sizeof array size calculations replaced with ARRAY_SIZE
2007-06-12 18:53 ` Bjorn Helgaas
@ 2007-06-13 21:21 ` Andi Drebes
2007-06-15 17:56 ` Andi Drebes
1 sibling, 0 replies; 7+ messages in thread
From: Andi Drebes @ 2007-06-13 21:21 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Pavel Machek, Christoph Hellwig, Len Brown, kernel-janitors,
linux-acpi, linux-kernel
<snip>
> You found the right one. The ACPI CA in Linux is really the same
> as the one from Intel. Len integrates the Intel one into Linux
> periodically. He uses scripts or something to format it so it looks
> more like Linux.
Ok. That's what I thought so far.
> I think Len sometimes takes patches against the "Linux-ized" ACPI CA.
> He probably has to apply those by hand to the Intel one, which is
> the real "upstream" in this case. So it might be a bit easier for
> him if you generated a diff against the Intel version.
OK. I will do this in the next time.
> In any event, you want to end up with one patch, not two.
Ok. I thought of two patches because I didn't know how strong
the sources from the ACPI CA are modified.
> You probably would have to add something like:
>
> #ifndef ARRAY_SIZE
> #define ARRAY_SIZE(x) ...
> #endif
>
> somewhere in the ACPI CA header files. That way it will work in
> non-Linux OSes as well.
Thanks so far,
Andi
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [KJ] [PATCH] drivers/acpi: sizeof/sizeof array size calculations replaced with ARRAY_SIZE
2007-06-12 18:53 ` Bjorn Helgaas
2007-06-13 21:21 ` Andi Drebes
@ 2007-06-15 17:56 ` Andi Drebes
1 sibling, 0 replies; 7+ messages in thread
From: Andi Drebes @ 2007-06-15 17:56 UTC (permalink / raw)
To: Len Brown
Cc: Bjorn Helgaas, Pavel Machek, Christoph Hellwig, kernel-janitors,
linux-acpi, linux-kernel
<snip>
> You found the right one. The ACPI CA in Linux is really the same
> as the one from Intel.
Hmmm. The file that I downloaded recently is acpica-unix-20061109. It seems
to be quite old. There are some differences between the contents
of that archive and the acpi files in the kernel. I hope I really got the right version.
> So it might be a bit easier for
> him if you generated a diff against the Intel version. Then it
> would show up in Linux, too, in the fullness of time.
Ok. The new patch can be found in this message.
I tried to figure out where to put the definition of the ARRAY_SIZE macro.
I searched a little bit in the include directory, but I couldn't find a place
that satisfied me to a hundred percent. I chose acpi.h, because this
seems to be file that is most general. The problem is, that the file
only consists of lines that include other header files and the newly added
definition for ARRAY_SIZE breaks this consistency in some way. Perhaps
Len could give me a hint where to put it.
Ok, here's the new patch:
Diffed against the intel acpica implementation "acpica-unix-20061109".
Tested by compilation.
Signed-off-by: Andi Drebes <lists-receive@programmierforen.de>
---
diff --git a/include/acpi.h b/include/acpi.h
index ddaeec4..9de744c 100644
--- a/include/acpi.h
+++ b/include/acpi.h
@@ -139,5 +139,11 @@
#include "achware.h" /* Hardware defines and interfaces */
#include "acutils.h" /* Utility interfaces */
+#ifndef ARRAY_SIZE
+/*
+ * ARRAY_SIZE calculates the size of a statically initialized array
+ */
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
#endif /* __ACPI_H__ */
diff --git a/resources/rsdump.c b/resources/rsdump.c
index 1f90cf7..4eea301 100644
--- a/resources/rsdump.c
+++ b/resources/rsdump.c
@@ -188,8 +188,6 @@ AcpiRsDumpDescriptor (
#define ACPI_RSD_OFFSET(f) (UINT8) ACPI_OFFSET (ACPI_RESOURCE_DATA,f)
#define ACPI_PRT_OFFSET(f) (UINT8) ACPI_OFFSET (ACPI_PCI_ROUTING_TABLE,f)
-#define ACPI_RSD_TABLE_SIZE(name) (sizeof(name) / sizeof (ACPI_RSDUMP_INFO))
-
/*******************************************************************************
*
@@ -202,7 +200,7 @@ AcpiRsDumpDescriptor (
ACPI_RSDUMP_INFO AcpiRsDumpIrq[6] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpIrq), "IRQ", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpIrq), "IRQ", NULL},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Irq.Triggering), "Triggering", AcpiGbl_HeDecode},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Irq.Polarity), "Polarity", AcpiGbl_LlDecode},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Irq.Sharable), "Sharing", AcpiGbl_ShrDecode},
@@ -212,7 +210,7 @@ ACPI_RSDUMP_INFO AcpiRsDumpIrq[6] =
ACPI_RSDUMP_INFO AcpiRsDumpDma[6] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpDma), "DMA", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpDma), "DMA", NULL},
{ACPI_RSD_2BITFLAG, ACPI_RSD_OFFSET (Dma.Type), "Speed", AcpiGbl_TypDecode},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Dma.BusMaster), "Mastering", AcpiGbl_BmDecode},
{ACPI_RSD_2BITFLAG, ACPI_RSD_OFFSET (Dma.Transfer), "Transfer Type", AcpiGbl_SizDecode},
@@ -222,19 +220,19 @@ ACPI_RSDUMP_INFO AcpiRsDumpDma[6] =
ACPI_RSDUMP_INFO AcpiRsDumpStartDpf[3] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpStartDpf), "Start-Dependent-Functions",NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpStartDpf), "Start-Dependent-Functions",NULL},
{ACPI_RSD_2BITFLAG, ACPI_RSD_OFFSET (StartDpf.CompatibilityPriority), "Compatibility Priority", AcpiGbl_ConfigDecode},
{ACPI_RSD_2BITFLAG, ACPI_RSD_OFFSET (StartDpf.PerformanceRobustness), "Performance/Robustness", AcpiGbl_ConfigDecode}
};
ACPI_RSDUMP_INFO AcpiRsDumpEndDpf[1] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpEndDpf), "End-Dependent-Functions", NULL}
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpEndDpf), "End-Dependent-Functions", NULL}
};
ACPI_RSDUMP_INFO AcpiRsDumpIo[6] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpIo), "I/O", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpIo), "I/O", NULL},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Io.IoDecode), "Address Decoding", AcpiGbl_IoDecode},
{ACPI_RSD_UINT16, ACPI_RSD_OFFSET (Io.Minimum), "Address Minimum", NULL},
{ACPI_RSD_UINT16, ACPI_RSD_OFFSET (Io.Maximum), "Address Maximum", NULL},
@@ -244,26 +242,26 @@ ACPI_RSDUMP_INFO AcpiRsDumpIo[6] =
ACPI_RSDUMP_INFO AcpiRsDumpFixedIo[3] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpFixedIo), "Fixed I/O", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpFixedIo), "Fixed I/O", NULL},
{ACPI_RSD_UINT16, ACPI_RSD_OFFSET (FixedIo.Address), "Address", NULL},
{ACPI_RSD_UINT8, ACPI_RSD_OFFSET (FixedIo.AddressLength), "Address Length", NULL}
};
ACPI_RSDUMP_INFO AcpiRsDumpVendor[3] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpVendor), "Vendor Specific", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpVendor), "Vendor Specific", NULL},
{ACPI_RSD_UINT16, ACPI_RSD_OFFSET (Vendor.ByteLength), "Length", NULL},
{ACPI_RSD_LONGLIST, ACPI_RSD_OFFSET (Vendor.ByteData[0]), "Vendor Data", NULL}
};
ACPI_RSDUMP_INFO AcpiRsDumpEndTag[1] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpEndTag), "EndTag", NULL}
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpEndTag), "EndTag", NULL}
};
ACPI_RSDUMP_INFO AcpiRsDumpMemory24[6] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpMemory24), "24-Bit Memory Range", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpMemory24), "24-Bit Memory Range", NULL},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Memory24.WriteProtect), "Write Protect", AcpiGbl_RwDecode},
{ACPI_RSD_UINT16, ACPI_RSD_OFFSET (Memory24.Minimum), "Address Minimum", NULL},
{ACPI_RSD_UINT16, ACPI_RSD_OFFSET (Memory24.Maximum), "Address Maximum", NULL},
@@ -273,7 +271,7 @@ ACPI_RSDUMP_INFO AcpiRsDumpMemory24[6] =
ACPI_RSDUMP_INFO AcpiRsDumpMemory32[6] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpMemory32), "32-Bit Memory Range", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpMemory32), "32-Bit Memory Range", NULL},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Memory32.WriteProtect), "Write Protect", AcpiGbl_RwDecode},
{ACPI_RSD_UINT32, ACPI_RSD_OFFSET (Memory32.Minimum), "Address Minimum", NULL},
{ACPI_RSD_UINT32, ACPI_RSD_OFFSET (Memory32.Maximum), "Address Maximum", NULL},
@@ -283,7 +281,7 @@ ACPI_RSDUMP_INFO AcpiRsDumpMemory32[6] =
ACPI_RSDUMP_INFO AcpiRsDumpFixedMemory32[4] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpFixedMemory32), "32-Bit Fixed Memory Range",NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpFixedMemory32), "32-Bit Fixed Memory Range",NULL},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (FixedMemory32.WriteProtect), "Write Protect", AcpiGbl_RwDecode},
{ACPI_RSD_UINT32, ACPI_RSD_OFFSET (FixedMemory32.Address), "Address", NULL},
{ACPI_RSD_UINT32, ACPI_RSD_OFFSET (FixedMemory32.AddressLength), "Address Length", NULL}
@@ -291,7 +289,7 @@ ACPI_RSDUMP_INFO AcpiRsDumpFixedMemory32[4] =
ACPI_RSDUMP_INFO AcpiRsDumpAddress16[8] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpAddress16), "16-Bit WORD Address Space",NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpAddress16), "16-Bit WORD Address Space",NULL},
{ACPI_RSD_ADDRESS, 0, NULL, NULL},
{ACPI_RSD_UINT16, ACPI_RSD_OFFSET (Address16.Granularity), "Granularity", NULL},
{ACPI_RSD_UINT16, ACPI_RSD_OFFSET (Address16.Minimum), "Address Minimum", NULL},
@@ -303,7 +301,7 @@ ACPI_RSDUMP_INFO AcpiRsDumpAddress16[8] =
ACPI_RSDUMP_INFO AcpiRsDumpAddress32[8] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpAddress32), "32-Bit DWORD Address Space", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpAddress32), "32-Bit DWORD Address Space", NULL},
{ACPI_RSD_ADDRESS, 0, NULL, NULL},
{ACPI_RSD_UINT32, ACPI_RSD_OFFSET (Address32.Granularity), "Granularity", NULL},
{ACPI_RSD_UINT32, ACPI_RSD_OFFSET (Address32.Minimum), "Address Minimum", NULL},
@@ -315,7 +313,7 @@ ACPI_RSDUMP_INFO AcpiRsDumpAddress32[8] =
ACPI_RSDUMP_INFO AcpiRsDumpAddress64[8] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpAddress64), "64-Bit QWORD Address Space", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpAddress64), "64-Bit QWORD Address Space", NULL},
{ACPI_RSD_ADDRESS, 0, NULL, NULL},
{ACPI_RSD_UINT64, ACPI_RSD_OFFSET (Address64.Granularity), "Granularity", NULL},
{ACPI_RSD_UINT64, ACPI_RSD_OFFSET (Address64.Minimum), "Address Minimum", NULL},
@@ -327,7 +325,7 @@ ACPI_RSDUMP_INFO AcpiRsDumpAddress64[8] =
ACPI_RSDUMP_INFO AcpiRsDumpExtAddress64[8] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpExtAddress64), "64-Bit Extended Address Space", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpExtAddress64), "64-Bit Extended Address Space", NULL},
{ACPI_RSD_ADDRESS, 0, NULL, NULL},
{ACPI_RSD_UINT64, ACPI_RSD_OFFSET (ExtAddress64.Granularity), "Granularity", NULL},
{ACPI_RSD_UINT64, ACPI_RSD_OFFSET (ExtAddress64.Minimum), "Address Minimum", NULL},
@@ -339,7 +337,7 @@ ACPI_RSDUMP_INFO AcpiRsDumpExtAddress64[8] =
ACPI_RSDUMP_INFO AcpiRsDumpExtIrq[8] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpExtIrq), "Extended IRQ", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpExtIrq), "Extended IRQ", NULL},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (ExtendedIrq.ProducerConsumer), "Type", AcpiGbl_ConsumeDecode},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (ExtendedIrq.Triggering), "Triggering", AcpiGbl_HeDecode},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (ExtendedIrq.Polarity), "Polarity", AcpiGbl_LlDecode},
@@ -351,7 +349,7 @@ ACPI_RSDUMP_INFO AcpiRsDumpExtIrq[8] =
ACPI_RSDUMP_INFO AcpiRsDumpGenericReg[6] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpGenericReg), "Generic Register", NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpGenericReg), "Generic Register", NULL},
{ACPI_RSD_UINT8, ACPI_RSD_OFFSET (GenericReg.SpaceId), "Space ID", NULL},
{ACPI_RSD_UINT8, ACPI_RSD_OFFSET (GenericReg.BitWidth), "Bit Width", NULL},
{ACPI_RSD_UINT8, ACPI_RSD_OFFSET (GenericReg.BitOffset), "Bit Offset", NULL},
@@ -365,7 +363,7 @@ ACPI_RSDUMP_INFO AcpiRsDumpGenericReg[6] =
*/
static ACPI_RSDUMP_INFO AcpiRsDumpGeneralFlags[5] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpGeneralFlags), NULL, NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpGeneralFlags), NULL, NULL},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Address.ProducerConsumer), "Consumer/Producer", AcpiGbl_ConsumeDecode},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Address.Decode), "Address Decode", AcpiGbl_DecDecode},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Address.MinAddressFixed), "Min Relocatability", AcpiGbl_MinDecode},
@@ -374,7 +372,7 @@ static ACPI_RSDUMP_INFO AcpiRsDumpGeneralFlags[5] =
static ACPI_RSDUMP_INFO AcpiRsDumpMemoryFlags[5] =
{
- {ACPI_RSD_LITERAL, ACPI_RSD_TABLE_SIZE (AcpiRsDumpMemoryFlags), "Resource Type", (void *) "Memory Range"},
+ {ACPI_RSD_LITERAL, ARRAY_SIZE (AcpiRsDumpMemoryFlags), "Resource Type", (void *) "Memory Range"},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Address.Info.Mem.WriteProtect), "Write Protect", AcpiGbl_RwDecode},
{ACPI_RSD_2BITFLAG, ACPI_RSD_OFFSET (Address.Info.Mem.Caching), "Caching", AcpiGbl_MemDecode},
{ACPI_RSD_2BITFLAG, ACPI_RSD_OFFSET (Address.Info.Mem.RangeType), "Range Type", AcpiGbl_MtpDecode},
@@ -383,7 +381,7 @@ static ACPI_RSDUMP_INFO AcpiRsDumpMemoryFlags[5] =
static ACPI_RSDUMP_INFO AcpiRsDumpIoFlags[4] =
{
- {ACPI_RSD_LITERAL, ACPI_RSD_TABLE_SIZE (AcpiRsDumpIoFlags), "Resource Type", (void *) "I/O Range"},
+ {ACPI_RSD_LITERAL, ARRAY_SIZE (AcpiRsDumpIoFlags), "Resource Type", (void *) "I/O Range"},
{ACPI_RSD_2BITFLAG, ACPI_RSD_OFFSET (Address.Info.Io.RangeType), "Range Type", AcpiGbl_RngDecode},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Address.Info.Io.Translation), "Translation", AcpiGbl_TtpDecode},
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (Address.Info.Io.TranslationType), "Translation Type", AcpiGbl_TrsDecode}
@@ -395,7 +393,7 @@ static ACPI_RSDUMP_INFO AcpiRsDumpIoFlags[4] =
*/
static ACPI_RSDUMP_INFO AcpiRsDumpPrt[5] =
{
- {ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE (AcpiRsDumpPrt), NULL, NULL},
+ {ACPI_RSD_TITLE, ARRAY_SIZE (AcpiRsDumpPrt), NULL, NULL},
{ACPI_RSD_UINT64, ACPI_PRT_OFFSET (Address), "Address", NULL},
{ACPI_RSD_UINT32, ACPI_PRT_OFFSET (Pin), "Pin", NULL},
{ACPI_RSD_STRING, ACPI_PRT_OFFSET (Source[0]), "Source", NULL},
diff --git a/tables/tbfadt.c b/tables/tbfadt.c
index a1afd6d..04f2fac 100644
--- a/tables/tbfadt.c
+++ b/tables/tbfadt.c
@@ -189,9 +189,6 @@ static ACPI_FADT_INFO FadtInfoTable[] =
ACPI_FADT_OFFSET (Gpe1BlockLength), ACPI_FADT_SEPARATE_LENGTH}
};
-#define ACPI_FADT_INFO_ENTRIES (sizeof (FadtInfoTable) / sizeof (ACPI_FADT_INFO))
-
-
/*******************************************************************************
*
* FUNCTION: AcpiTbInitGenericAddress
@@ -398,7 +395,7 @@ AcpiTbConvertFadt (
* 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(FadtInfoTable); i++)
{
Target = ACPI_ADD_PTR (
ACPI_GENERIC_ADDRESS, &AcpiGbl_FADT, FadtInfoTable[i].Target);
@@ -471,7 +468,7 @@ AcpiTbValidateFadt (
/* 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(FadtInfoTable); i++)
{
/* Generate pointers to the 32-bit and 64-bit addresses and get the length */
^ permalink raw reply related [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-06-15 17:57 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200705261239.27485.lists-receive@programmierforen.de>
[not found] ` <46581C06.7000005@student.ltu.se>
[not found] ` <200705261558.24912.lists-receive@programmierforen.de>
[not found] ` <200705301525.05905.lenb@kernel.org>
2007-05-31 9:56 ` [KJ] [PATCH] drivers/acpi: sizeof/sizeof array size calculations replaced with ARRAY_SIZE 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox