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

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

 



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


[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