lkml.org 
[lkml]   [2006]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    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    [W:0.031 / U:239.908 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site