Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933186Ab2KEVFv (ORCPT ); Mon, 5 Nov 2012 16:05:51 -0500 Received: from mail-wi0-f172.google.com ([209.85.212.172]:61201 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932245Ab2KEVFt (ORCPT ); Mon, 5 Nov 2012 16:05:49 -0500 MIME-Version: 1.0 In-Reply-To: <1351958865-24394-2-git-send-email-jiang.liu@huawei.com> References: <1351958865-24394-1-git-send-email-jiang.liu@huawei.com> <1351958865-24394-2-git-send-email-jiang.liu@huawei.com> From: Bjorn Helgaas Date: Mon, 5 Nov 2012 14:05:24 -0700 Message-ID: Subject: Re: [ACPIHP PATCH part1 1/4] ACPIHP: introduce a framework for ACPI based system device hotplug To: Jiang Liu Cc: "Rafael J . Wysocki" , Yinghai Lu , Tony Luck , Yasuaki Ishimatsu , Wen Congyang , Tang Chen , Taku Izumi , Jiang Liu , Kenji Kaneshige , Huang Ying , Bob Moore , Len Brown , "Srivatsa S . Bhat" , Yijing Wang , Hanjun Guo , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, Gaohuai Han Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4506 Lines: 94 On Sat, Nov 3, 2012 at 10:07 AM, Jiang Liu wrote: > Modern high-end servers may support advanced RAS features, such as > system device dynamic reconfiguration. On x86 and IA64 platforms, > system device means processor(CPU), memory device, PCI host bridge > and even computer node. > > The ACPI specifications have provided standard interfaces between > firmware and OS to support device dynamic reconfiguraiton at runtime. > This patch series introduces a new framework for system device > dynamic reconfiguration based on ACPI specification, which will > replace current existing system device hotplug logic embedded in > ACPI processor/memory/container device drivers. > > The new ACPI based hotplug framework is modelled after the PCI hotplug > architecture and target to achieve following goals: > 1) Optimize device configuration order to achieve best performance for > hot-added system devices. For best perforamnce, system device should > be configured in order of memory -> CPU -> IOAPIC/IOMMU -> PCI HB. > 2) Resolve dependencies among hotplug slots. You need first to remove > the memory device before removing a physical processor if a > hotpluggable memory device is connected to a hotpluggable physical > processor. Doesn't the namespace already have a way to communicate these dependencies? > 3) Provide interface to cancel ongoing hotplug operations. It may take > a very long time to remove a memory device, so provide interface to > cancel the inprogress hotplug operations. > 4) Support new advanced RAS features, such as socket/memory migration. > 5) Provide better user interfaces to access the hotplug functionalities. > 6) Provide a mechanism to detect hotplug slots by checking existence > of ACPI _EJ0 method or by other hardware platform specific methods. I don't know what "hotplug slot" means for ACPI. ACPI allows hotplug of arbitrary devices in the namespace, whether they have EJ0 or not. > 7) Unify the way to enumerate ACPI based hotplug slots. All hotplug > slots will be enumerated by the enumeration driver (acpihp_slot), > instead of by individual ACPI device drivers. Why do we need to enumerate these "slots" specifically? I think this patch adds things in /sys. It might help if you described what they are. > 8) Unify the way to handle ACPI hotplug events. All ACPI hotplug events > for system devices will be handled by a generic ACPI hotplug driver > (acpihp_drv) instead of by individual ACPI device drivers. > 9) Provide better error handling and error recovery. > 10) Trigger hotplug events/operations by software. This feature is useful > for hardware fault management and/or power saving. > > The new framework is composed up of three major components: > 1) A system device hotplug slot enumerator driver, which enumerates > hotplug slots in the system and provides platform specific methods > to control those slots. > 2) A system device hotplug driver, which is a platform independent > driver to manage all hotplug slots created by the slot enumerator. > The hotplug driver implements a state machine for hotplug slots and > provides user interfaces to manage hotplug slots. > 3) Several ACPI device drivers to configure/unconfigure system devices > at runtime. > > To get rid of inter dependengcy between the slot enumerator and hotplug > driver, common code shared by them will be built into the kernel. The > shared code provides some helper routines and a device class named > acpihp_slot_class with following default sysfs properties: > capabilities: RAS capabilities of the hotplug slot > state: current state of the hotplug slot state machine > status: current health status of the hotplug slot > object: ACPI object corresponding to the hotplug slot > > Signed-off-by: Jiang Liu > Signed-off-by: Gaohuai Han ... > +static char *acpihp_dev_mem_ids[] = { > + "PNP0C80", > + NULL > +}; > + > +static char *acpihp_dev_pcihb_ids[] = { > + "PNP0A03", > + NULL > +}; Why should this driver need to know about these PNP IDs? We ought to be able to support hotplug of any device in the namespace, no matter what its ID. -- 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/