From: Greg KH <gregkh@linuxfoundation.org>
To: Toshi Kani <toshi.kani@hp.com>
Cc: "linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"jiang.liu@huawei.com" <jiang.liu@huawei.com>,
"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"yinghai@kernel.org" <yinghai@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"isimatu.yasuaki@jp.fujitsu.com" <isimatu.yasuaki@jp.fujitsu.com>,
"srivatsa.bhat@linux.vnet.ibm.com"
<srivatsa.bhat@linux.vnet.ibm.com>,
"guohanjun@huawei.com" <guohanjun@huawei.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
Date: Mon, 4 Feb 2013 04:46:12 -0800 [thread overview]
Message-ID: <20130204124612.GA22096@kroah.com> (raw)
In-Reply-To: <1359937689.23410.82.camel@misato.fc.hp.com>
On Sun, Feb 03, 2013 at 05:28:09PM -0700, Toshi Kani wrote:
> On Sat, 2013-02-02 at 16:01 +0100, Greg KH wrote:
> > On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote:
> > > On Fri, 2013-02-01 at 07:30 +0000, Greg KH wrote:
> > > > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > > > > This is already done for PCI host bridges and platform devices and I don't
> > > > > > see why we can't do that for the other types of devices too.
> > > > > >
> > > > > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > > > > when we try do eject a device at the top of a subtree and need to tear down
> > > > > > the entire subtree below it, but if that's going to lead to a system crash,
> > > > > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > > > > help from the driver core here.
> > > > >
> > > > > There are three different approaches suggested for system device
> > > > > hot-plug:
> > > > > A. Proceed within system device bus scan.
> > > > > B. Proceed within ACPI bus scan.
> > > > > C. Proceed with a sequence (as a mini-boot).
> > > > >
> > > > > Option A uses system devices as tokens, option B uses acpi devices as
> > > > > tokens, and option C uses resource tables as tokens, for their handlers.
> > > > >
> > > > > Here is summary of key questions & answers so far. I hope this
> > > > > clarifies why I am suggesting option 3.
> > > > >
> > > > > 1. What are the system devices?
> > > > > System devices provide system-wide core computing resources, which are
> > > > > essential to compose a computer system. System devices are not
> > > > > connected to any particular standard buses.
> > > >
> > > > Not a problem, lots of devices are not connected to any "particular
> > > > standard busses". All this means is that system devices are connected
> > > > to the "system" bus, nothing more.
> > >
> > > Can you give me a few examples of other devices that support hotplug and
> > > are not connected to any particular buses? I will investigate them to
> > > see how they are managed to support hotplug.
> >
> > Any device that is attached to any bus in the driver model can be
> > hotunplugged from userspace by telling it to be "unbound" from the
> > driver controlling it. Try it for any platform device in your system to
> > see how it happens.
>
> The unbind operation, as I understand from you, is to detach a driver
> from a device. Yes, unbinding can be done for any devices. It is
> however different from hot-plug operation, which unplugs a device.
Physically, yes, but to the driver involved, and the driver core, there
is no difference. That was one of the primary goals of the driver core
creation so many years ago.
> Today, the unbind operation to an ACPI cpu/memory devices causes
> hot-unplug (offline) operation to them, which is one of the major issues
> for us since unbind cannot fail. This patchset addresses this issue by
> making the unbind operation of ACPI cpu/memory devices to do the
> unbinding only. ACPI drivers no longer control cpu and memory as they
> are supposed to be controlled by their drivers, cpu and memory modules.
I think that's the problem right there, solve that, please.
> > > > > 2. Why are the system devices special?
> > > > > The system devices are initialized during early boot-time, by multiple
> > > > > subsystems, from the boot-up sequence, in pre-defined order. They
> > > > > provide low-level services to enable other subsystems to come up.
> > > >
> > > > Sorry, no, that doesn't mean they are special, nothing here is unique
> > > > for the point of view of the driver model from any other device or bus.
> > >
> > > I think system devices are unique in a sense that they are initialized
> > > before drivers run.
> >
> > No, most all devices are "initialized" before a driver runs on it, USB
> > is one such example, PCI another, and I'm pretty sure that there are
> > others.
>
> USB devices can be initialized after the USB bus driver is initialized.
> Similarly, PCI devices can be initialized after the PCI bus driver is
> initialized. However, CPU and memory are initialized without any
> dependency to their bus driver since there is no such thing.
You can create such a thing if you want :)
> In addition, CPU and memory have two drivers -- their actual
> drivers/subsystems and their ACPI drivers.
Again, I feel that is the root of the problem. Rafael seems to be
working on solving this, which I think is essencial to your work as
well.
thanks,
greg k-h
next prev parent reply other threads:[~2013-02-04 12:44 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-10 23:40 [RFC PATCH v2 00/12] System device hot-plug framework Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework Toshi Kani
2013-01-11 21:23 ` Rafael J. Wysocki
2013-01-14 15:33 ` Toshi Kani
2013-01-14 18:48 ` Rafael J. Wysocki
2013-01-14 19:02 ` Toshi Kani
2013-01-30 4:48 ` Greg KH
2013-01-31 1:15 ` Toshi Kani
2013-01-31 5:24 ` Greg KH
2013-01-31 14:42 ` Toshi Kani
2013-01-30 4:53 ` Greg KH
2013-01-31 1:46 ` Toshi Kani
2013-01-30 4:58 ` Greg KH
2013-01-31 2:57 ` Toshi Kani
2013-01-31 20:54 ` Rafael J. Wysocki
2013-02-01 1:32 ` Toshi Kani
2013-02-01 7:30 ` Greg KH
2013-02-01 20:40 ` Toshi Kani
2013-02-01 22:21 ` Rafael J. Wysocki
2013-02-01 23:12 ` Toshi Kani
2013-02-02 15:01 ` Greg KH
2013-02-04 0:28 ` Toshi Kani
2013-02-04 12:46 ` Greg KH [this message]
2013-02-04 16:46 ` Toshi Kani
2013-02-04 19:45 ` Rafael J. Wysocki
2013-02-04 20:59 ` Toshi Kani
2013-02-04 23:23 ` Rafael J. Wysocki
2013-02-04 23:33 ` Toshi Kani
2013-02-01 7:23 ` Greg KH
2013-02-01 22:12 ` Rafael J. Wysocki
2013-02-02 14:58 ` Greg KH
2013-02-02 20:15 ` Rafael J. Wysocki
2013-02-02 22:18 ` [PATCH?] Move ACPI device nodes under /sys/firmware/acpi (was: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework) Rafael J. Wysocki
2013-02-04 1:24 ` Greg KH
2013-02-04 12:34 ` Rafael J. Wysocki
2013-02-03 20:44 ` [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework Rafael J. Wysocki
2013-02-04 12:48 ` Greg KH
2013-02-04 14:21 ` Rafael J. Wysocki
2013-02-04 14:33 ` Greg KH
2013-02-04 20:07 ` Rafael J. Wysocki
2013-02-04 22:13 ` Toshi Kani
2013-02-04 23:52 ` Rafael J. Wysocki
2013-02-05 0:04 ` Greg KH
2013-02-05 1:02 ` Rafael J. Wysocki
2013-02-05 11:11 ` Rafael J. Wysocki
2013-02-05 18:39 ` Greg KH
2013-02-05 21:13 ` Rafael J. Wysocki
2013-02-05 0:55 ` Toshi Kani
2013-02-04 16:19 ` Toshi Kani
2013-02-04 19:43 ` Rafael J. Wysocki
2013-02-04 1:23 ` Greg KH
2013-02-04 13:41 ` Rafael J. Wysocki
2013-02-04 16:02 ` Toshi Kani
2013-02-04 19:48 ` Rafael J. Wysocki
2013-02-04 19:46 ` Toshi Kani
2013-02-04 20:12 ` Rafael J. Wysocki
2013-02-04 20:34 ` Toshi Kani
2013-02-04 23:19 ` Rafael J. Wysocki
2013-01-10 23:40 ` [RFC PATCH v2 02/12] ACPI: " Toshi Kani
2013-01-11 21:25 ` Rafael J. Wysocki
2013-01-14 15:53 ` Toshi Kani
2013-01-14 18:47 ` Rafael J. Wysocki
2013-01-14 18:42 ` Toshi Kani
2013-01-14 19:07 ` Rafael J. Wysocki
2013-01-14 19:21 ` Toshi Kani
2013-01-30 4:51 ` Greg KH
2013-01-31 1:38 ` Toshi Kani
2013-01-14 19:21 ` Greg KH
2013-01-14 19:29 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 03/12] drivers/base: Add " Toshi Kani
2013-01-30 4:54 ` Greg KH
2013-01-31 1:48 ` Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 04/12] cpu: Add cpu hotplug handlers Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 05/12] mm: Add memory " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 06/12] ACPI: Add ACPI bus " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 07/12] ACPI: Add ACPI resource hotplug handler Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 08/12] ACPI: Update processor driver for hotplug framework Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 09/12] ACPI: Update memory " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 10/12] ACPI: Update container " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 11/12] cpu: Update sysfs cpu/online " Toshi Kani
2013-01-10 23:40 ` [RFC PATCH v2 12/12] ACPI: Update sysfs eject " Toshi Kani
2013-01-17 0:50 ` [RFC PATCH v2 00/12] System device hot-plug framework Rafael J. Wysocki
2013-01-17 17:59 ` 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=20130204124612.GA22096@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=bhelgaas@google.com \
--cc=guohanjun@huawei.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=jiang.liu@huawei.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=rjw@sisk.pl \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=toshi.kani@hp.com \
--cc=wency@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).