Anyway, we just released the code in ACPICA today. I want to thank you and everyone involved for all the good work. I'm confident that we have made a major improvement in the GPE support. Bob >-----Original Message----- >From: Moore, Robert >Sent: Thursday, December 09, 2010 3:14 PM >To: Rafael J. Wysocki >Cc: Lin, Ming M; Len Brown; linux-acpi@xxxxxxxxxxxxxxx; Matthew Garrett >Subject: RE: [PATCH 2/6] ACPICA: Rename some function and variable names > >Yes, I think this has been a problem in the past, where changes have been >made that cannot be backported, thus increasing the acpica<->linux >divergence. > >Next year, we are making the reduction of this divergence a high priority, >so we will be very close to the issues. > > > >-----Original Message----- >From: Rafael J. Wysocki [mailto:rjw@xxxxxxx] >Sent: Thursday, December 09, 2010 3:04 PM >To: Moore, Robert >Cc: Lin, Ming M; Len Brown; linux-acpi@xxxxxxxxxxxxxxx; Matthew Garrett >Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names > >On Thursday, December 09, 2010, Moore, Robert wrote: >> I'm not talking about a single patch, but the entire process that has >been cumbersome. > >The reason it has been so was that some ACPICA-related changes in Linux >were >not backported. I don't know why that happened, but that's something we >need >to be much more careful about in the future. > >Unfortunately, we sometimes need to make ACPICA changes in Linux urgently >as bug fixes, so the workflow in which all changes would go through the >ACPICA >code base wouldn't be very practical. > >I think we need someone from your side to review proposed changes in Linux >related to ACPICA and tell us which of them can be backported. If a Linux >patch is ACKed by this person, it should be backported to the ACPICA code >base timely, ideally as soon as it appears in the Linus' tree or after a >major >kernel release is made. > >Thanks, >Rafael > > >> -----Original Message----- >> From: Rafael J. Wysocki [mailto:rjw@xxxxxxx] >> Sent: Thursday, December 09, 2010 2:51 PM >> To: Moore, Robert >> Cc: Lin, Ming M; Len Brown; linux-acpi@xxxxxxxxxxxxxxx >> Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names >> >> On Thursday, December 09, 2010, Moore, Robert wrote: >> > 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. >> >> Well, I'm talking about a simple thing like splitting a patch into two >pieces. >> That's not going to take a lot of time IMO and the benefit is that more >people >> may actually understand what's being done. >> >> Moreover, if anyone hits a problem related to one of your patches, it's >vital >> to be able to figure out which change caused it to happen. >> >> Thanks, >> Rafael >> >> >> > -----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 >> > >> >> -- 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
