ACPICA: Rename some function and variable names

PATCH Superseded Lin Ming 3 participants 9 messages Dec 6, 2010 – Dec 10, 2010 1 message not in the archive

Subsystems (3)

ACPI ACPI component architecture (acpica) IPMI

lore

Share & tools

lore

Lin Ming

author

2010-12-06 15:58 UTC #0 lore raw

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

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 <[email protected]>

---
 drivers/acpi/acpica/acevents.h   |    9 +++---
 drivers/acpi/acpica/acglobal.h   |    2 +-
 drivers/acpi/acpica/aclocal.h    |   12 ++++----
 drivers/acpi/acpica/evgpe.c      |   28 +++++++++++++------
 drivers/acpi/acpica/evgpeblk.c   |    4 +-
 drivers/acpi/acpica/evxface.c    |   26 +++++++++---------
 drivers/acpi/acpica/evxfgpe.c    |   53 +++++++++++++++++++++++--------------
 drivers/acpi/acpica/hwgpe.c      |    2 +-
 drivers/acpi/acpica/utglobal.c   |    2 +-
 drivers/acpi/dock.c              |    2 +-
 drivers/acpi/ec.c                |    3 +-
 drivers/acpi/scan.c              |    6 ++--
 drivers/acpi/wakeup.c            |    4 +-
 drivers/char/ipmi/ipmi_si_intf.c |    3 +-
 include/acpi/acpixf.h            |   10 +++---
 include/acpi/actypes.h           |    7 +++-
 16 files changed, 101 insertions(+), 72 deletions(-)

drivers/acpi/acpica/acevents.h +5 -4

index 43f15c8..ebb467f 100644
@@ -82,9 +82,9 @@ acpi_ev_update_gpe_enable_mask(struct acpi_gpe_event_info *gpe_event_info);
 
 acpi_status acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info);
 
-acpi_status acpi_raw_enable_gpe(struct acpi_gpe_event_info *gpe_event_info);
+acpi_status acpi_ev_add_gpe_reference(struct acpi_gpe_event_info *gpe_event_info);
 
-acpi_status acpi_raw_disable_gpe(struct acpi_gpe_event_info *gpe_event_info);
+acpi_status acpi_ev_remove_gpe_reference(struct acpi_gpe_event_info *gpe_event_info);
 
 struct acpi_gpe_event_info *acpi_ev_get_gpe_event_info(acpi_handle gpe_device,
 						       u32 gpe_number);

@@ -107,12 +107,13 @@ acpi_ev_create_gpe_block(struct acpi_namespace_node *gpe_device,
 acpi_status
 acpi_ev_initialize_gpe_block(struct acpi_gpe_xrupt_info *gpe_xrupt_info,
 			     struct acpi_gpe_block_info *gpe_block,
-			     void *ignored);
+			     void *context);
 
 acpi_status acpi_ev_delete_gpe_block(struct acpi_gpe_block_info *gpe_block);
 
 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);
 
 /*

drivers/acpi/acpica/acglobal.h +1 -1

index ad88fca..fc69464 100644
@@ -370,7 +370,7 @@ ACPI_EXTERN struct acpi_fixed_event_handler
 ACPI_EXTERN struct acpi_gpe_xrupt_info *acpi_gbl_gpe_xrupt_list_head;
 ACPI_EXTERN struct acpi_gpe_block_info
 *acpi_gbl_gpe_fadt_blocks[ACPI_MAX_GPE_BLOCKS];
-ACPI_EXTERN u8 acpi_all_gpes_initialized;
+ACPI_EXTERN u8 acpi_gbl_all_gpes_initialized;
 
 /*****************************************************************************
  *

drivers/acpi/acpica/aclocal.h +6 -6

index 2ceb0c0..6a71f8e 100644
@@ -408,17 +408,17 @@ struct acpi_predefined_data {
 
 /* Dispatch info for each GPE -- either a method or handler, cannot be both */
 
-struct acpi_handler_info {
-	acpi_event_handler address;	/* Address of handler, if any */
+struct acpi_gpe_handler_info {
+	acpi_gpe_handler address;	/* Address of handler, if any */
 	void *context;		/* Context to be passed to handler */
 	struct acpi_namespace_node *method_node;	/* Method node for this GPE level (saved) */
-	u8 orig_flags;		/* Original misc info about this GPE */
-	u8 orig_enabled;	/* Set if the GPE was originally enabled */
+	u8 original_flags;      /* Original (pre-handler) GPE info */
+	u8 originally_enabled;  /* True if GPE was originally enabled */
 };
 
 union acpi_gpe_dispatch_info {
 	struct acpi_namespace_node *method_node;	/* Method node for this GPE level */
-	struct acpi_handler_info *handler;
+	struct acpi_gpe_handler_info *handler;  /* Installed GPE handler */
 };
 
 /*

@@ -458,7 +458,7 @@ struct acpi_gpe_block_info {
 	u32 register_count;	/* Number of register pairs in block */
 	u16 gpe_count;		/* Number of individual GPEs in block */
 	u8 block_base_number;	/* Base GPE number for this block */
-	u8 initialized;         /* If set, the GPE block has been initialized */
+	u8 initialized;         /* TRUE if this block is initialized */
 };
 
 /* Information about GPE interrupt handlers, one per each interrupt level used for GPEs */

drivers/acpi/acpica/evgpe.c +19 -9

index f226eac..3fb621e 100644
@@ -137,7 +137,7 @@ acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info)
 
 /*******************************************************************************
  *
- * FUNCTION:    acpi_raw_enable_gpe
+ * FUNCTION:    acpi_ev_add_gpe_reference
  *
  * PARAMETERS:  gpe_event_info  - GPE to enable
  *

@@ -148,10 +148,12 @@ acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info)
  *
  ******************************************************************************/
 
-acpi_status acpi_raw_enable_gpe(struct acpi_gpe_event_info *gpe_event_info)
+acpi_status acpi_ev_add_gpe_reference(struct acpi_gpe_event_info *gpe_event_info)
 {
 	acpi_status status = AE_OK;
 
+	ACPI_FUNCTION_TRACE(ev_add_gpe_reference);
+
 	if (gpe_event_info->runtime_count == ACPI_UINT8_MAX) {
 		return_ACPI_STATUS(AE_LIMIT);
 	}

@@ -173,7 +175,7 @@ acpi_status acpi_raw_enable_gpe(struct acpi_gpe_event_info *gpe_event_info)
 
 /*******************************************************************************
  *
- * FUNCTION:    acpi_raw_disable_gpe
+ * FUNCTION:    acpi_ev_remove_gpe_reference
  *
  * PARAMETERS:  gpe_event_info  - GPE to disable
  *

@@ -184,10 +186,12 @@ acpi_status acpi_raw_enable_gpe(struct acpi_gpe_event_info *gpe_event_info)
  *
  ******************************************************************************/
 
-acpi_status acpi_raw_disable_gpe(struct acpi_gpe_event_info *gpe_event_info)
+acpi_status acpi_ev_remove_gpe_reference(struct acpi_gpe_event_info *gpe_event_info)
 {
 	acpi_status status = AE_OK;
 
+	ACPI_FUNCTION_TRACE(ev_remove_gpe_reference);
+
 	if (!gpe_event_info->runtime_count) {
 		return_ACPI_STATUS(AE_LIMIT);
 	}

@@ -405,7 +409,9 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info * gpe_xrupt_list)
 					 * or method.
 					 */
 					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);
 				}
 			}

@@ -529,7 +535,7 @@ static void acpi_ev_asynch_enable_gpe(void *context)
 	 * Enable this GPE, conditionally. This means that the GPE will only be
 	 * physically enabled if the enable_for_run bit is set in the event_info
 	 */
-	(void)acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_COND_ENABLE);
+	(void)acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_CONDITIONAL_ENABLE);
 
 	return_VOID;
 }

@@ -538,7 +544,8 @@ static void acpi_ev_asynch_enable_gpe(void *context)
  *
  * FUNCTION:    acpi_ev_gpe_dispatch
  *
- * PARAMETERS:  gpe_event_info  - Info for this GPE
+ * PARAMETERS:  gpe_device      - Device node. NULL for GPE0/GPE1
+ *              gpe_event_info  - Info for this GPE
  *              gpe_number      - Number relative to the parent GPE block
  *
  * RETURN:      INTERRUPT_HANDLED or INTERRUPT_NOT_HANDLED

@@ -551,7 +558,8 @@ static void acpi_ev_asynch_enable_gpe(void *context)
  ******************************************************************************/
 
 u32
-acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number)
+acpi_ev_gpe_dispatch(struct acpi_namespace_node *gpe_device,
+		    struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number)
 {
 	acpi_status status;

@@ -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);

drivers/acpi/acpica/evgpeblk.c +2 -2

index 020add3..2a445df 100644
@@ -386,7 +386,7 @@ acpi_ev_create_gpe_block(struct acpi_namespace_node *gpe_device,
 		return_ACPI_STATUS(status);
 	}
 
-	acpi_all_gpes_initialized = FALSE;
+	acpi_gbl_all_gpes_initialized = FALSE;
 
 	/* Find all GPE methods (_Lxx or_Exx) for this block */

@@ -479,7 +479,7 @@ acpi_ev_initialize_gpe_block(struct acpi_gpe_xrupt_info *gpe_xrupt_info,
 				continue;
 			}
 
-			status = acpi_raw_enable_gpe(gpe_event_info);
+			status = acpi_ev_add_gpe_reference(gpe_event_info);
 			if (ACPI_FAILURE(status)) {
 				ACPI_EXCEPTION((AE_INFO, status,
 					"Could not enable GPE 0x%02X",

drivers/acpi/acpica/evxface.c +13 ~~-13~~

index 36af222..d193b90 100644
@@ -671,10 +671,10 @@ ACPI_EXPORT_SYMBOL(acpi_remove_notify_handler)
 acpi_status
 acpi_install_gpe_handler(acpi_handle gpe_device,
 			 u32 gpe_number,
-			 u32 type, acpi_event_handler address, void *context)
+			 u32 type, acpi_gpe_handler address, void *context)
 {
 	struct acpi_gpe_event_info *gpe_event_info;
-	struct acpi_handler_info *handler;
+	struct acpi_gpe_handler_info *handler;
 	acpi_status status;
 	acpi_cpu_flags flags;

@@ -693,7 +693,7 @@ acpi_install_gpe_handler(acpi_handle gpe_device,
 
 	/* Allocate memory for the handler object */
 
-	handler = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_handler_info));
+	handler = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_gpe_handler_info));
 	if (!handler) {
 		status = AE_NO_MEMORY;
 		goto unlock_and_exit;

@@ -722,7 +722,7 @@ acpi_install_gpe_handler(acpi_handle gpe_device,
 	handler->address = address;
 	handler->context = context;
 	handler->method_node = gpe_event_info->dispatch.method_node;
-	handler->orig_flags = gpe_event_info->flags &
+	handler->original_flags = gpe_event_info->flags &
 			(ACPI_GPE_XRUPT_TYPE_MASK | ACPI_GPE_DISPATCH_MASK);
 
 	/*

@@ -731,10 +731,10 @@ acpi_install_gpe_handler(acpi_handle gpe_device,
 	 * disabled now to avoid spurious execution of the handler.
 	 */
 
-	if ((handler->orig_flags & ACPI_GPE_DISPATCH_METHOD)
+	if ((handler->original_flags & ACPI_GPE_DISPATCH_METHOD)
 	    && gpe_event_info->runtime_count) {
-		handler->orig_enabled = 1;
-		(void)acpi_raw_disable_gpe(gpe_event_info);
+		handler->originally_enabled = 1;
+		(void)acpi_ev_remove_gpe_reference(gpe_event_info);
 	}
 
 	/* Install the handler */

@@ -777,10 +777,10 @@ ACPI_EXPORT_SYMBOL(acpi_install_gpe_handler)
  ******************************************************************************/
 acpi_status
 acpi_remove_gpe_handler(acpi_handle gpe_device,
-			u32 gpe_number, acpi_event_handler address)
+			u32 gpe_number, acpi_gpe_handler address)
 {
 	struct acpi_gpe_event_info *gpe_event_info;
-	struct acpi_handler_info *handler;
+	struct acpi_gpe_handler_info *handler;
 	acpi_status status;
 	acpi_cpu_flags flags;

@@ -835,7 +835,7 @@ acpi_remove_gpe_handler(acpi_handle gpe_device,
 	gpe_event_info->dispatch.method_node = handler->method_node;
 	gpe_event_info->flags &=
 		~(ACPI_GPE_XRUPT_TYPE_MASK | ACPI_GPE_DISPATCH_MASK);
-	gpe_event_info->flags |= handler->orig_flags;
+	gpe_event_info->flags |= handler->original_flags;
 
 	/*
 	 * If the GPE was previously associated with a method and it was

@@ -843,9 +843,9 @@ acpi_remove_gpe_handler(acpi_handle gpe_device,
 	 * post-initialization configuration.
 	 */
 
-	if ((handler->orig_flags & ACPI_GPE_DISPATCH_METHOD)
-	    && handler->orig_enabled)
-		(void)acpi_raw_enable_gpe(gpe_event_info);
+	if ((handler->original_flags & ACPI_GPE_DISPATCH_METHOD)
+	    && handler->originally_enabled)
+		(void)acpi_ev_add_gpe_reference(gpe_event_info);
 
 	/* Now we can free the handler object */

drivers/acpi/acpica/evxfgpe.c +33 ~~-20~~

173 lines not on this page · raw message

drivers/acpi/acpica/hwgpe.c +1 -1

index 14750db..7c6d485 100644
@@ -118,7 +118,7 @@ acpi_hw_low_set_gpe(struct acpi_gpe_event_info *gpe_event_info, u8 action)
 	register_bit = acpi_hw_get_gpe_register_bit(gpe_event_info,
 						gpe_register_info);
 	switch (action) {
-	case ACPI_GPE_COND_ENABLE:
+	case ACPI_GPE_CONDITIONAL_ENABLE:
 		if (!(register_bit & gpe_register_info->enable_for_run))
 			return (AE_BAD_PARAMETER);

drivers/acpi/acpica/utglobal.c +1 -1

index e87bc67..a99c32a 100644
@@ -768,7 +768,7 @@ acpi_status acpi_ut_init_globals(void)
 	acpi_gbl_gpe_fadt_blocks[0] = NULL;
 	acpi_gbl_gpe_fadt_blocks[1] = NULL;
 	acpi_current_gpe_count = 0;
-	acpi_all_gpes_initialized = FALSE;
+	acpi_gbl_all_gpes_initialized = FALSE;
 
 	/* Global handlers */

drivers/acpi/dock.c +1 -1

index 81514a4..1864ad3 100644
@@ -725,7 +725,7 @@ static void dock_notify(acpi_handle handle, u32 event, void *data)
 			complete_dock(ds);
 			dock_event(ds, event, DOCK_EVENT);
 			dock_lock(ds, 1);
-			acpi_update_gpes();
+			acpi_update_all_gpes();
 			break;
 		}
 		if (dock_present(ds) || dock_in_progress(ds))

drivers/acpi/ec.c +2 -1

index 372ff80..e15439a 100644
@@ -606,7 +606,8 @@ static int ec_check_sci(struct acpi_ec *ec, u8 state)
 	return 0;
 }
 
-static u32 acpi_ec_gpe_handler(void *data)
+static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
+	u32 gpe_number, void *data)
 {
 	struct acpi_ec *ec = data;

drivers/acpi/scan.c +3 -3

index 2b6c21d..afdbd6e 100644
@@ -750,7 +750,7 @@ acpi_bus_extract_wakeup_device_power_package(struct acpi_device *device,
 		device->wakeup.resources.handles[i] = element->reference.handle;
 	}
 
-	acpi_gpe_can_wake(device->wakeup.gpe_device, device->wakeup.gpe_number);
+	acpi_setup_gpe_for_wake(device->wakeup.gpe_device, device->wakeup.gpe_number);
 
 	return AE_OK;
 }

@@ -1444,7 +1444,7 @@ int acpi_bus_start(struct acpi_device *device)
 
 	result = acpi_bus_scan(device->handle, &ops, NULL);
 
-	acpi_update_gpes();
+	acpi_update_all_gpes();
 
 	return result;
 }

@@ -1561,7 +1561,7 @@ int __init acpi_scan_init(void)
 	if (result)
 		acpi_device_unregister(acpi_root, ACPI_BUS_REMOVAL_NORMAL);
 	else
-		acpi_update_gpes();
+		acpi_update_all_gpes();
 
 	return result;
 }

drivers/acpi/wakeup.c +2 -2

index f62a50c..c6cb68e 100644
@@ -45,7 +45,7 @@ void acpi_enable_wakeup_devices(u8 sleep_state)
 			acpi_enable_wakeup_device_power(dev, sleep_state);
 
 		/* The wake-up power should have been enabled already. */
-		acpi_gpe_wakeup(dev->wakeup.gpe_device, dev->wakeup.gpe_number,
+		acpi_set_gpe_wake_mask(dev->wakeup.gpe_device, dev->wakeup.gpe_number,
 				ACPI_GPE_ENABLE);
 	}
 }

@@ -67,7 +67,7 @@ void acpi_disable_wakeup_devices(u8 sleep_state)
 		    || (sleep_state > (u32) dev->wakeup.sleep_state))
 			continue;
 
-		acpi_gpe_wakeup(dev->wakeup.gpe_device, dev->wakeup.gpe_number,
+		acpi_set_gpe_wake_mask(dev->wakeup.gpe_device, dev->wakeup.gpe_number,
 				ACPI_GPE_DISABLE);
 
 		if (dev->wakeup.state.enabled)

drivers/char/ipmi/ipmi_si_intf.c +2 -1

index 035da9e..c4bacc6 100644
@@ -1928,7 +1928,8 @@ static void __devinit hardcode_find_bmc(void)
 static int acpi_failure;
 
 /* For GPE-type interrupts. */
-static u32 ipmi_acpi_gpe(void *context)
+static u32 ipmi_acpi_gpe(acpi_handle gpe_device,
+	u32 gpe_number, void *context)
 {
 	struct smi_info *smi_info = context;
 	unsigned long   flags;

include/acpi/acpixf.h +5 -5

index 53b7cfd..b806e56 100644
@@ -258,11 +258,11 @@ acpi_remove_address_space_handler(acpi_handle device,
 acpi_status
 acpi_install_gpe_handler(acpi_handle gpe_device,
 			 u32 gpe_number,
-			 u32 type, acpi_event_handler address, void *context);
+			 u32 type, acpi_gpe_handler address, void *context);
 
 acpi_status
 acpi_remove_gpe_handler(acpi_handle gpe_device,
-			u32 gpe_number, acpi_event_handler address);
+			u32 gpe_number, acpi_gpe_handler address);
 
 #ifdef ACPI_FUTURE_USAGE
 acpi_status acpi_install_exception_handler(acpi_exception_handler handler);

@@ -292,11 +292,11 @@ acpi_status acpi_enable_gpe(acpi_handle gpe_device, u32 gpe_number);
 
 acpi_status acpi_disable_gpe(acpi_handle gpe_device, u32 gpe_number);
 
-acpi_status acpi_gpe_can_wake(acpi_handle gpe_device, u32 gpe_number);
+acpi_status acpi_setup_gpe_for_wake(acpi_handle gpe_device, u32 gpe_number);
 
 acpi_status acpi_clear_gpe(acpi_handle gpe_device, u32 gpe_number);
 
-acpi_status acpi_gpe_wakeup(acpi_handle gpe_device, u32 gpe_number, u8 action);
+acpi_status acpi_set_gpe_wake_mask(acpi_handle gpe_device, u32 gpe_number, u8 action);
 
 acpi_status
 acpi_get_gpe_status(acpi_handle gpe_device,

@@ -315,7 +315,7 @@ acpi_install_gpe_block(acpi_handle gpe_device,
 
 acpi_status acpi_remove_gpe_block(acpi_handle gpe_device);
 
-acpi_status acpi_update_gpes(void);
+acpi_status acpi_update_all_gpes(void);
 
 /*
  * Resource interfaces

include/acpi/actypes.h +5 -2

index 2b134b6..b9575ad 100644
@@ -656,11 +656,11 @@ typedef u32 acpi_event_status;
 #define ACPI_GPE_MAX                    0xFF
 #define ACPI_NUM_GPE                    256
 
-/* Actions for acpi_gpe_wakeup, acpi_hw_low_set_gpe */
+/* Actions for acpi_set_gpe_wake_mask, acpi_hw_low_set_gpe */
 
 #define ACPI_GPE_ENABLE                 0
 #define ACPI_GPE_DISABLE                1
-#define ACPI_GPE_COND_ENABLE            2
+#define ACPI_GPE_CONDITIONAL_ENABLE     2
 
 /*
  * GPE info flags - Per GPE

@@ -897,6 +897,9 @@ typedef void
 typedef u32(*acpi_event_handler) (void *context);
 
 typedef
+u32 (*acpi_gpe_handler) (acpi_handle gpe_device, u32 gpe_number, void *context);
+
+typedef
 void (*acpi_notify_handler) (acpi_handle device, u32 value, void *context);
 
 typedef

Signature · 1 line

1.5.3

Rafael J. Wysocki

2010-12-09 22:00 UTC #1 lore raw

Quoted 12 lines · Lin Ming

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
...

Quoted 1 line

Signed-off-by Lin Ming <[email protected]>

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.

...

Quoted 6 lines

u32

drivers/acpi/acpica/acevents.h +2 -1

-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);

...

Quoted 8 lines

drivers/acpi/acpica/evgpe.c +3 -1

 					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);
 				}
 			}

...

drivers/acpi/acpica/evgpe.c acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number) · line 605

Quoted 11 lines

drivers/acpi/acpica/evgpe.c +3 -1

@@ -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

Moore, Robert

2010-12-09 22:33 UTC #2 lore raw

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:[email protected]]
Sent: Thursday, December 09, 2010 2:00 PM
To: Lin, Ming M
Cc: Len Brown; Moore, Robert; [email protected]
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names

Quoted 12 lines · Lin Ming

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
...

Quoted 1 line

Signed-off-by Lin Ming <[email protected]>

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.

...

Quoted 6 lines

u32

drivers/acpi/acpica/acevents.h +2 -1

-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);

...

Quoted 8 lines

drivers/acpi/acpica/evgpe.c +3 -1

 					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);
 				}
 			}

...

drivers/acpi/acpica/evgpe.c acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number) · line 605

Quoted 11 lines

drivers/acpi/acpica/evgpe.c +3 -1

@@ -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

Rafael J. Wysocki

2010-12-09 22:52 UTC #3 lore raw

Quoted 9 lines · Robert

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

Quoted 59 lines

-----Original Message-----
From: Rafael J. Wysocki [mailto:[email protected]]
Sent: Thursday, December 09, 2010 2:00 PM
To: Lin, Ming M
Cc: Len Brown; Moore, Robert; [email protected]
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names
Quoted 12 lines · Lin Ming
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
...
Quoted 1 line
Signed-off-by Lin Ming <[email protected]>
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.
...
Quoted 6 lines
u32
drivers/acpi/acpica/acevents.h +2 -1
-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);
...
Quoted 8 lines
drivers/acpi/acpica/evgpe.c +3 -1
 					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);
 				}
 			}
...
drivers/acpi/acpica/evgpe.c acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number) · line 605
Quoted 11 lines
drivers/acpi/acpica/evgpe.c +3 -1
@@ -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

Moore, Robert

2010-12-09 22:53 UTC #4 lore raw

I'm not talking about a single patch, but the entire process that has been cumbersome.

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

Quoted 9 lines · Robert

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.

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

Quoted 59 lines

-----Original Message-----
From: Rafael J. Wysocki [mailto:[email protected]]
Sent: Thursday, December 09, 2010 2:00 PM
To: Lin, Ming M
Cc: Len Brown; Moore, Robert; [email protected]
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names
Quoted 12 lines · Lin Ming
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
...
Quoted 1 line
Signed-off-by Lin Ming <[email protected]>
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.
...
Quoted 6 lines
u32
drivers/acpi/acpica/acevents.h +2 -1
-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);
...
Quoted 8 lines
drivers/acpi/acpica/evgpe.c +3 -1
 					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);
 				}
 			}
...
drivers/acpi/acpica/evgpe.c acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number) · line 605
Quoted 11 lines
drivers/acpi/acpica/evgpe.c +3 -1
@@ -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

Rafael J. Wysocki

2010-12-09 23:05 UTC #5 lore raw

Quoted 1 line · Robert

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

Quoted 90 lines

-----Original Message-----
From: Rafael J. Wysocki [mailto:[email protected]]
Sent: Thursday, December 09, 2010 2:51 PM
To: Moore, Robert
Cc: Lin, Ming M; Len Brown; [email protected]
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names
Quoted 9 lines · Robert
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
Quoted 59 lines
-----Original Message-----
From: Rafael J. Wysocki [mailto:[email protected]]
Sent: Thursday, December 09, 2010 2:00 PM
To: Lin, Ming M
Cc: Len Brown; Moore, Robert; [email protected]
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names
Quoted 12 lines · Lin Ming
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
...
Quoted 1 line
Signed-off-by Lin Ming <[email protected]>
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.
...
Quoted 6 lines
u32
drivers/acpi/acpica/acevents.h +2 -1
-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);
...
Quoted 8 lines
drivers/acpi/acpica/evgpe.c +3 -1
 					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);
 				}
 			}
...
drivers/acpi/acpica/evgpe.c acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number) · line 605
Quoted 11 lines
drivers/acpi/acpica/evgpe.c +3 -1
@@ -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

Moore, Robert

2010-12-09 23:14 UTC #6 lore raw

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:[email protected]]
Sent: Thursday, December 09, 2010 3:04 PM
To: Moore, Robert
Cc: Lin, Ming M; Len Brown; [email protected]; Matthew Garrett
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names

Quoted 1 line · Robert

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.

Thanks,
Rafael

Quoted 90 lines

-----Original Message-----
From: Rafael J. Wysocki [mailto:[email protected]]
Sent: Thursday, December 09, 2010 2:51 PM
To: Moore, Robert
Cc: Lin, Ming M; Len Brown; [email protected]
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names
Quoted 9 lines · Robert
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
Quoted 59 lines
-----Original Message-----
From: Rafael J. Wysocki [mailto:[email protected]]
Sent: Thursday, December 09, 2010 2:00 PM
To: Lin, Ming M
Cc: Len Brown; Moore, Robert; [email protected]
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names
Quoted 12 lines · Lin Ming
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
...
Quoted 1 line
Signed-off-by Lin Ming <[email protected]>
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.
...
Quoted 6 lines
u32
drivers/acpi/acpica/acevents.h +2 -1
-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);
...
Quoted 8 lines
drivers/acpi/acpica/evgpe.c +3 -1
 					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);
 				}
 			}
...
drivers/acpi/acpica/evgpe.c acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number) · line 605
Quoted 11 lines
drivers/acpi/acpica/evgpe.c +3 -1
@@ -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

A message that is not in the archive (sent off-list or not yet received): 2B60D52015C3A84D9B0C6DFBF46A9C9F01B7892217@orsmsx503.amr.corp.intel.com

Moore, Robert

2010-12-10 01:09 UTC #8 lore raw

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

Quoted 154 lines

-----Original Message-----
From: Moore, Robert
Sent: Thursday, December 09, 2010 3:14 PM
To: Rafael J. Wysocki
Cc: Lin, Ming M; Len Brown; [email protected]; 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:[email protected]]
Sent: Thursday, December 09, 2010 3:04 PM
To: Moore, Robert
Cc: Lin, Ming M; Len Brown; [email protected]; Matthew Garrett
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names
Quoted 1 line · Robert
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
Quoted 9 lines
-----Original Message-----
From: Rafael J. Wysocki [mailto:[email protected]]
Sent: Thursday, December 09, 2010 2:51 PM
To: Moore, Robert
Cc: Lin, Ming M; Len Brown; [email protected]
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names
Quoted 1 line · Robert
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.
Quoted 4 lines
Quoted 4 lines
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.
Quoted 4 lines
Quoted 4 lines
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.
Quoted 2 lines
Well, I'm talking about a simple thing like splitting a patch into two
pieces.
Quoted 1 line
That's not going to take a lot of time IMO and the benefit is that more
people
Quoted 3 lines
may actually understand what's being done.
Moreover, if anyone hits a problem related to one of your patches, it's
vital
Quoted 12 lines
to be able to figure out which change caused it to happen.
Thanks,
Rafael
Quoted 6 lines
-----Original Message-----
From: Rafael J. Wysocki [mailto:[email protected]]
Sent: Thursday, December 09, 2010 2:00 PM
To: Lin, Ming M
Cc: Len Brown; Moore, Robert; [email protected]
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable
names
Quoted 14 lines
Quoted 14 lines · Lin Ming
Quoted 12 lines
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
...
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Lin Ming <[email protected]>
Well, tha changes related to acpi_ev_gpe_dispatch() do not really match
the
Quoted 11 lines
Quoted 11 lines
changelog. I'd prefer them to go into a separate patch with the right description.
...
Quoted 6 lines
u32
(quoted diff) +2 -1
-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);
...
Quoted 6 lines
Quoted 6 lines
Review
Quoted 6 lines
(quoted diff) +3 -1
 					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);
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
(quoted diff) +0 -0
 				}
 			}
...
Review acpi_ev_gpe_dispatch(struct acpi_gpe_event_info
Quoted 1 line
(quoted diff) +0 -0
@@ -589,7 +597,9 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_event_info
*gpe_event_info, u32 gpe_number)
Quoted 19 lines
Quoted 4 lines
Review acpi_ev_gpe_dispatch(struct acpi_gpe_event_info · line 592
Quoted 4 lines
(quoted diff) +0 -1
 		 * Ignore return status for now.
 		 * TBD: leave GPE disabled on error?
 		 */
-		(void)gpe_event_info->dispatch.handler-
address(gpe_event_info->
Quoted 1 line
Review acpi_ev_gpe_dispatch(struct acpi_gpe_event_info · line 600
Quoted 1 line
(quoted diff) +1 -0
+		(void)gpe_event_info->dispatch.handler-
address(gpe_device,
Quoted 10 lines
Review acpi_ev_gpe_dispatch(struct acpi_gpe_event_info · line 605
Quoted 5 lines
(quoted diff) +2 -0
+								gpe_number,
+								gpe_event_info->
 								dispatch.
 								handler->
 								context);
...
Thanks,
Rafael

Lin Ming

author

2010-12-10 00:22 UTC #9 lore raw

In reply to Rafael J. Wysocki

Quoted 13 lines · Rafael J. Wysocki

Quoted 12 lines · Lin Ming
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
...

Quoted 5 lines

Quoted 1 line
Signed-off-by Lin Ming <[email protected]>
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.

OK, will split it.

Thanks.

Quoted 33 lines

...

Quoted 6 lines

u32

drivers/acpi/acpica/acevents.h +2 -1

-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);

...

Quoted 8 lines

drivers/acpi/acpica/evgpe.c +3 -1

 					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);
 				}
 			}

...

drivers/acpi/acpica/evgpe.c acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number) · line 605

Quoted 11 lines

drivers/acpi/acpica/evgpe.c +3 -1

@@ -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