>would probably work just as well. Certainly acpi_native_uint was overkill. I disagree. Often more efficient to use machine native word rather than fooling around with a byte load/clear and store >-----Original Message----- >From: Len Brown [mailto:lenb@xxxxxxxxxx] >Sent: Tuesday, April 22, 2008 12:23 PM >To: Alexey Starikovskiy >Cc: linux-acpi@xxxxxxxxxxxxxxx; Moore, Robert; Alexey Starikovskiy >Subject: Re: [PATCH 65/73] ACPICA: Fix for extraneous debug message for >packages > >On Tuesday 15 April 2008, Alexey Starikovskiy wrote: >> Len Brown wrote: >> > From: Len Brown <len.brown@xxxxxxxxx> >> > >> > drivers/acpi/dispatcher/dsobject.c:499: warning: format '%X' expects >type 'unsigned int', but argument 4 has type 'acpi_native_uint' >> > drivers/acpi/dispatcher/dsobject.c:507: warning: format '%X' expects >type 'unsigned int', but argument 7 has type 'acpi_native_uint' >> > >> > Signed-off-by: Len Brown <len.brown@xxxxxxxxx> >> > --- >> > drivers/acpi/dispatcher/dsobject.c | 2 +- >> > 1 files changed, 1 insertions(+), 1 deletions(-) >> > >> > diff --git a/drivers/acpi/dispatcher/dsobject.c >b/drivers/acpi/dispatcher/dsobject.c >> > index 5184278..bdef2f0 100644 >> > --- a/drivers/acpi/dispatcher/dsobject.c >> > +++ b/drivers/acpi/dispatcher/dsobject.c >> > @@ -373,7 +373,7 @@ acpi_ds_build_internal_package_obj(struct >acpi_walk_state *walk_state, >> > union acpi_parse_object *parent; >> > union acpi_operand_object *obj_desc = NULL; >> > acpi_status status = AE_OK; >> > - acpi_native_uint i; >> > + u32 i; >> > >> why not just unsigned ? > >> > u16 index; >> > u16 reference_count; > >No particular reason, u32 and unsigned are synonyms on the architectures we >care about. >Now that you point it out, i prefer unsigned, and will go with that. > >This is used as an index into the arrary of elements in a package, so 8- >bits >would probably work just as well. Certainly acpi_native_uint was overkill. > >-Len -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
