All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Jiang Liu <liuj97@gmail.com>
Cc: Toshi Kani <toshi.kani@hp.com>, Jiang Liu <jiang.liu@huawei.com>,
	Yinghai Lu <yinghai@kernel.org>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
	Wen Congyang <wency@cn.fujitsu.com>,
	Tang Chen <tangchen@cn.fujitsu.com>,
	Taku Izumi <izumi.taku@jp.fujitsu.com>,
	Tony Luck <tony.luck@intel.com>,
	Huang Ying <ying.huang@intel.com>,
	Bob Moore <robert.moore@intel.com>, Len Brown <lenb@kernel.org>,
	"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [RFC PATCH v2 00/16] ACPI based system device hotplug framework
Date: Wed, 8 Aug 2012 09:27:07 -0700	[thread overview]
Message-ID: <CAErSpo7S0zuU=tSJVzxk8cPjop0B+JKJjkM46sFCirJCX9KQ2g@mail.gmail.com> (raw)
In-Reply-To: <50228968.3070904@gmail.com>

On Wed, Aug 8, 2012 at 8:44 AM, Jiang Liu <liuj97@gmail.com> wrote:
> On 08/08/2012 07:38 AM, Toshi Kani wrote:

>> It is nice to see redundant ACPI namespace walks removed from the ACPI
>> drivers.  But why do you need to add a new enumerator to create the
>> acpihp_slot tree, in addition to the current acpi_device tree?  I'd
>> prefer hotplug features to be generally integrated into the current ACPI
>> core code and data structures, instead of adding a new layer on top of
>> it.
> The idea comes from PCI hotplug framework, which has an concepts of PCI
> hotplug slot and PCI device. For system device hotplug, we could follow
> the same model as PCI by abstracting control points as slots. By introducing
> of hotplug slot, we could:
>
> 1) Report all hotplug slots and slot's capabilities to user, no matter whether
> there are devices connecting to a slot. If we integrate hotplug functionality
> into current ACPI device tree, the slot (or device) is only visible when the
> connected devices are enabled.

In PCI, the idea of a slot is a pretty explicit -- you can look at the
capabilities of a bridge device and see whether it supports hot-add of
a device below it.  Is it the same way in ACPI?  My impression is that
it is not: there will be a parent ACPI device under which a new device
can be added, but you might not be able to tell by looking at the
parent device that hot-add is possible.  I thought the platform could
just give us a Notify event on the parent, asking us to rescan the
namespace below it and potentially discover new devices.

  reply	other threads:[~2012-08-08 16:27 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-04 12:13 [RFC PATCH v2 00/16] ACPI based system device hotplug framework Jiang Liu
2012-08-04 12:13 ` Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 01/16] ACPIHP: introduce a framework for ACPI based system device hotplug Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 02/16] ACPIHP: ACPI system device hotplug slot enumerator Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 03/16] ACPIHP: detect ACPI hotplug slots by checking ACPI _EJ0 method Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 04/16] ACPI: introduce interfaces to manage ACPI device reference count Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 05/16] ACPIHP: scan and walk ACPI devices connecting to an ACPI hotplug slot Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 06/16] ACPIHP: group devices connecting to a hotplug slot according to device types Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 07/16] ACPIHP: add callbacks into acpi_device_ops to support new hotplug framework Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 08/16] ACPIHP: provide interfaces to associate driver specific data to hotplug slots Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 09/16] ACPIHP: implement utility functions to support system device hotplug Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 10/16] ACPIHP: system device hotplug driver skeleton Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-09  7:12   ` Tang Chen
2012-08-09  7:40     ` Jiang Liu
2012-08-09  7:40       ` Jiang Liu
2012-08-09  8:41       ` Tang Chen
2012-08-09  9:36         ` Jiang Liu
2012-08-09  9:36           ` Jiang Liu
2012-08-10  4:39           ` Tang Chen
2012-08-04 12:13 ` [RFC PATCH v2 11/16] ACPIHP: analyse dependences among ACPI system device hotplug slots Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 12/16] ACPIHP: cancel inprogress ACPI system device hotplug operations Jiang Liu
2012-08-04 12:13   ` Jiang Liu
2012-08-04 12:14 ` [RFC PATCH v2 13/16] ACPIHP: configure/unconfigure system devices connecting to a hotplug slot Jiang Liu
2012-08-04 12:14   ` Jiang Liu
2012-08-04 12:14 ` [RFC PATCH v2 14/16] ACPIHP: implement the state machine for ACPI hotplug slots Jiang Liu
2012-08-04 12:14   ` Jiang Liu
2012-08-04 12:14 ` [RFC PATCH v2 15/16] ACPIHP: implement ACPI hotplug sysfs interfaces Jiang Liu
2012-08-04 12:14   ` Jiang Liu
2012-08-04 12:14 ` [RFC PATCH v2 16/16] ACPIHP: enhance ACPI container driver to support new hotplug framework Jiang Liu
2012-08-04 12:14   ` Jiang Liu
2012-08-07 23:38 ` [RFC PATCH v2 00/16] ACPI based system device " Toshi Kani
2012-08-08 15:44   ` Jiang Liu
2012-08-08 16:27     ` Bjorn Helgaas [this message]
2012-08-09 15:24       ` Jiang Liu
2012-08-08 21:05     ` Toshi Kani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAErSpo7S0zuU=tSJVzxk8cPjop0B+JKJjkM46sFCirJCX9KQ2g@mail.gmail.com' \
    --to=bhelgaas@google.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=jiang.liu@huawei.com \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=liuj97@gmail.com \
    --cc=robert.moore@intel.com \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=tangchen@cn.fujitsu.com \
    --cc=tony.luck@intel.com \
    --cc=toshi.kani@hp.com \
    --cc=wency@cn.fujitsu.com \
    --cc=ying.huang@intel.com \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.