lkml.org 
[lkml]   [2006]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] pci hotplug: add common acpi functions to core
On Tue, 28 Feb 2006 16:46:57 -0800 Kristen Accardi wrote:

> shpchprm_acpi.c and pciehprm_acpi.c are nearly identical.
> In addition, there are functions in both these files that
> are also in acpiphp_glue.c. This patch will remove duplicate
> functions from shpchp, pciehp, and acpiphp and move this
> functionality to pci_hotplug, as it is not hardware specific.
> Get rid of shpchprm* and pciehprm* files since they are no longer needed.
> shpchprm_nonacpi.c and pciehprm_nonacpi.c are identical, as well
> as shpchprm_legacy.c and can be replaced with a macro.
>
> Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
> ---
> 13 files changed, 331 insertions(+), 663 deletions(-)

> --- /dev/null
> +++ 2.6-git-gregkh/drivers/pci/hotplug/acpi_pcihp.c
> @@ -0,0 +1,201 @@
> +/*
> + * ACPI related functions for PCI hotplug drivers
> + *
> + * Copyright (C) 2006 Intel Corporation
> + *
> + * All rights reserved.
> + *
> + * Send feedback to <kristen.c.accardi@intel.com>
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/types.h>
> +#include <linux/pci.h>
> +#include <acpi/acpi.h>
> +#include <acpi/acpi_bus.h>
> +#include <acpi/actypes.h>
> +#include "pci_hotplug.h"
> +
> +#define METHOD_NAME__SUN "_SUN"
> +#define METHOD_NAME__HPP "_HPP"
> +#define METHOD_NAME_OSHP "OSHP"
> +
> +u8 * acpi_path_name( acpi_handle handle)

odd spacing.

> +{
> + acpi_status status;
> + static u8 path_name[ACPI_PATHNAME_MAX];
> + struct acpi_buffer ret_buf = { ACPI_PATHNAME_MAX, path_name };
> +
> + memset(path_name, 0, sizeof (path_name));
> + status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &ret_buf);
> +
> + if (ACPI_FAILURE(status))
> + return NULL;
> + else
> + return path_name;
> +}
> +EXPORT_SYMBOL_GPL(acpi_path_name);

Can acpi_path_name() be used safely by more than 1 caller?
Previously it was duplicated, so the return <path_name> was duplicated,
which made it multiple-caller safe. Now it seems that in a worst-case
scenario, one caller's path could be clobbered by another. ?
or maybe (probably) caller 1 is finished with it before caller 2
can ever run. ?

> +acpi_status acpi_run_oshp(acpi_handle handle)
> +{
> + acpi_status status;
> + u8 *path_name = acpi_path_name(handle);
> +
> + /* run OSHP */
> + status = acpi_evaluate_object(handle, METHOD_NAME_OSHP, NULL, NULL);
> + if (ACPI_FAILURE(status)) {
> + printk(KERN_ERR "%s:%s OSHP fails=0x%x\n", __FUNCTION__,
> + path_name, status);
> + } else {
> + pr_debug("%s:%s OSHP passes\n", __FUNCTION__, path_name);

{} braces not needed here (on the if nor the else).
> + }
> + return status;
> +}
> +EXPORT_SYMBOL_GPL(acpi_run_oshp);


A little kernel-doc for non-static (non-private) functions would
be a good thing.

> +int is_root_bridge(acpi_handle handle)
> +{
> + acpi_status status;
> + struct acpi_device_info *info;
> + struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
> + int i;
> +
> + status = acpi_get_object_info(handle, &buffer);
> + if (ACPI_SUCCESS(status)) {
> + info = buffer.pointer;
> + if ((info->valid & ACPI_VALID_HID) &&
> + !strcmp(PCI_ROOT_HID_STRING,
> + info->hardware_id.value)) {
> + acpi_os_free(buffer.pointer);
> + return 1;
> + }
> + if (info->valid & ACPI_VALID_CID) {
> + for (i=0; i < info->compatibility_id.count; i++) {
> + if (!strcmp(PCI_ROOT_HID_STRING,
> + info->compatibility_id.id[i].value)) {
> + acpi_os_free(buffer.pointer);
> + return 1;
> + }
> + }
> + }
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(is_root_bridge);
> --- 2.6-git-gregkh.orig/drivers/pci/hotplug/pci_hotplug.h
> +++ 2.6-git-gregkh/drivers/pci/hotplug/pci_hotplug.h
> @@ -176,5 +176,22 @@ extern int pci_hp_change_slot_info (stru
> +
> +#ifdef CONFIG_ACPI
> +#include <acpi/acpi.h>
> +#include <acpi/acpi_bus.h>
> +#include <acpi/actypes.h>
> +extern acpi_status acpi_run_oshp(acpi_handle handle);
> +extern void acpi_get_hp_params_from_firmware(struct pci_dev *dev,
> + struct hotplug_params *hpp);
> +extern u8 * acpi_path_name( acpi_handle handle);

odd spacing (again).

> +int is_root_bridge(acpi_handle handle);
> +#endif
> #endif
>
> --- 2.6-git-gregkh.orig/drivers/pci/hotplug/pciehp_hpc.c
> +++ 2.6-git-gregkh/drivers/pci/hotplug/pciehp_hpc.c
> @@ -38,6 +38,9 @@
>
> #include "../pci.h"
> #include "pciehp.h"
> +#ifdef CONFIG_ACPI
> +#include <linux/pci-acpi.h>
> +#endif

Does this driver work with or without ACPI, depending on CONFIG_ACPI?

We don't usually bracket #includes in .c files with ifdef/endif.

> --- 2.6-git-gregkh.orig/drivers/pci/hotplug/shpchp.h
> +++ 2.6-git-gregkh/drivers/pci/hotplug/shpchp.h
> @@ -193,15 +187,24 @@ extern u8 shpchp_handle_power_fault(u8 h
>
> +
> +#ifdef CONFIG_ACPI
> +#define get_hp_params_from_firmware(dev, hpp) \
> + acpi_get_hp_params_from_firmware(dev, hpp)
> +#define get_hp_hw_control_from_firmware(pdev) \
> + do { \
> + if (DEVICE_ACPI_HANDLE(&(pdev->dev))) \
> + acpi_run_oshp(DEVICE_ACPI_HANDLE(&(pdev->dev))); \
> + } while (0)
> +#else
> +#define get_hp_params_from_firmware(dev, hpp)
> +#define get_hp_hw_control_from_firmware(dev)

usually empty macros are like so in Linux:
#define foo(bar) do { } while(0)
> +#endif
> +

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
\
 
 \ /
  Last update: 2006-03-01 03:02    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean