RE: [PATCH 2/6] ACPICA: Rename some function and variable names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



For the next time we attempt to make such a large ACPICA change, we need to put a methodology in place to simplify things. It has been very difficult for us to take Linux patches, backport and integrate into ACPICA, make additional changes, then forward port the final ACPICA changes to Linux, and then shoehorn the code into the original Linux patches.

Difficult as in several times the work.

Ming has worked very hard to forward-port the ACPICA code and then shoehorn the changes into the original Linux patches.

But we can't do it this way again. 

We are open to suggestions on a better way to do this, perhaps Len can help.

Bob


-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@xxxxxxx] 
Sent: Thursday, December 09, 2010 2:00 PM
To: Lin, Ming M
Cc: Len Brown; Moore, Robert; linux-acpi@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names

On Monday, December 06, 2010, Lin Ming wrote:
> Some function and variable names are renamed to be consistent with
> ACPICA code base.
> 
> acpi_raw_enable_gpe -> acpi_ev_add_gpe_reference
> acpi_raw_disable_gpe -> acpi_ev_remove_gpe_reference
> acpi_gpe_can_wake -> acpi_setup_gpe_for_wake
> acpi_gpe_wakeup -> acpi_set_gpe_wake_mask
> acpi_update_gpes -> acpi_update_all_gpes
> acpi_all_gpes_initialized -> acpi_gbl_all_gpes_initialized
> acpi_handler_info -> acpi_gpe_handler_info
> ...
> 
> Signed-off-by: Lin Ming <ming.m.lin@xxxxxxxxx>

Well, tha changes related to acpi_ev_gpe_dispatch() do not really match the
changelog.  I'd prefer them to go into a separate patch with the right
description.

...  
>  u32
> -acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info,
> +acpi_ev_gpe_dispatch(struct acpi_namespace_node *gpe_device,
> +		     struct acpi_gpe_event_info *gpe_event_info,
>  		     u32 gpe_number);
>  
...
>  					int_status |=
> -					    acpi_ev_gpe_dispatch(&gpe_block->
> +					    acpi_ev_gpe_dispatch(gpe_block->
> +								 node,
> +								 &gpe_block->
>  						event_info[((acpi_size) i * ACPI_GPE_REGISTER_WIDTH) + j], j + gpe_register_info->base_gpe_number);
>  				}
>  			}
...
> @@ -589,7 +597,9 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number)
>  		 * Ignore return status for now.
>  		 * TBD: leave GPE disabled on error?
>  		 */
> -		(void)gpe_event_info->dispatch.handler->address(gpe_event_info->
> +		(void)gpe_event_info->dispatch.handler->address(gpe_device,
> +								gpe_number,
> +								gpe_event_info->
>  								dispatch.
>  								handler->
>  								context);
...

Thanks,
Rafael
ÿô.nlj·Ÿ®‰­†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶›¡Ü}©ž²ÆzÚj:+v‰¨þø®w¥þŠàÞ¨è&¢)ß«a¶Úÿûz¹ÞúŽŠÝjÿŠwèf



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux