This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [PATCH 1/5] take 2: PCIe IO space multiplexing: backport of

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [PATCH 1/5] take 2: PCIe IO space multiplexing: backport of bus event notification patch
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Fri, 17 Apr 2009 17:09:20 +0900
Cc: shimada-yxb@xxxxxxxxxxxxxxx, Ian.Jackson@xxxxxxxxxxxxx, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Delivery-date: Fri, 17 Apr 2009 01:13:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
back port of 116af378201ef793424cd10508ccf18b06d8a021 and

commit 116af378201ef793424cd10508ccf18b06d8a021
Author: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
Date:   Wed Oct 25 13:44:59 2006 +1000

    Driver core: add notification of bus events
    I finally did as you suggested and added the notifier to the struct
    bus_type itself. There are still problems to be expected is something
    attaches to a bus type where the code can hook in different struct
    device sub-classes (which is imho a big bogosity but I won't even try to
    argue that case now) but it will solve nicely a number of issues I've
    had so far.
    That also means that clients interested in registering for such
    notifications have to do it before devices are added and after bus types
    are registered. Fortunately, most bus types that matter for the various
    usage scenarios I have in mind are registerd at postcore_initcall time,
    which means I have a really nice spot at arch_initcall time to add my
    There are 4 notifications provided. Device being added (before hooked to
    the bus) and removed (failure of previous case or after being unhooked
    from the bus), along with driver being bound to a device and about to be
    The usage I have for these are:
     - The 2 first ones are used to maintain a struct device_ext that is
    hooked to struct device.firmware_data. This structure contains for now a
    pointer to the Open Firmware node related to the device (if any), the
    NUMA node ID (for quick access to it) and the DMA operations pointers &
    iommu table instance for DMA to/from this device. For bus types I own
    (like IBM VIO or EBUS), I just maintain that structure directly from the
    bus code when creating the devices. But for bus types managed by generic
    code like PCI or platform (actually, of_platform which is a variation of
    platform linked to Open Firmware device-tree), I need this notifier.
     - The other two ones have a completely different usage scenario. I have
    cases where multiple devices and their drivers depend on each other. For
    example, the IBM EMAC network driver needs to attach to a MAL DMA engine
    which is a separate device, and a PHY interface which is also a separate
    device. They are all of_platform_device's (well, about to be with my
    upcoming patches) but there is no say in what precise order the core
    will "probe" them and instanciate the various modules. The solution I
    found for that is to have the drivers for emac to use multithread_probe,
    and wait for a driver to be bound to the target MAL and PHY control
    devices (the device-tree contains reference to the MAL and PHY interface
    nodes, which I can then match to of_platform_devices). Right now, I've
    been polling, but with that notifier, I can more cleanly wait (with a
    timeout of course).
    Signed-off-by: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>

commit ec0676ee28528dc8dda13a93ee4b1f215a0c2f9d
Author: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
Date:   Fri Dec 5 14:10:31 2008 -0500

    Driver core: move the bus notifier call points
    This patch (as1184) changes the location of the notifications in
    device_add() and device_del().  Now the BUS_NOTIFY_ADD_DEVICE message
    is sent after dpm_sysfs_add(), which is necessary for clients that
    want to add attributes to the power/ subdirectory.  The
    BUS_NOTIFY_DEL_DEVICE message is correspondingly moved before
    Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
    Cc: Kay Sievers <kay.sievers@xxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -683,6 +683,8 @@ int bus_register(struct bus_type * bus)
        int retval;
+       BLOCKING_INIT_NOTIFIER_HEAD(&bus->bus_notifier);
        retval = kobject_set_name(&bus->subsys.kset.kobj, "%s", bus->name);
        if (retval)
                goto out;
@@ -737,6 +739,18 @@ void bus_unregister(struct bus_type * bu
+int bus_register_notifier(struct bus_type *bus, struct notifier_block *nb)
+       return blocking_notifier_chain_register(&bus->bus_notifier, nb);
+int bus_unregister_notifier(struct bus_type *bus, struct notifier_block *nb)
+       return blocking_notifier_chain_unregister(&bus->bus_notifier, nb);
 int __init buses_init(void)
        return subsystem_register(&bus_subsys);
diff --git a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -15,6 +15,7 @@
 #include <linux/slab.h>
 #include <linux/string.h>
 #include <linux/kdev_t.h>
+#include <linux/notifier.h>
 #include <asm/semaphore.h>
@@ -350,6 +351,14 @@ int device_add(struct device *dev)
                goto PMError;
        if ((error = bus_add_device(dev)))
                goto BusError;
+       /* Notify clients of device addition.  This call must come
+        * after dpm_sysf_add() and before kobject_uevent().
+        */
+       if (dev->bus)
+               blocking_notifier_call_chain(&dev->bus->bus_notifier,
+                                            BUS_NOTIFY_ADD_DEVICE, dev);
        kobject_uevent(&dev->kobj, KOBJ_ADD);
        if (parent)
@@ -450,6 +459,12 @@ void device_del(struct device * dev)
        struct device * parent = dev->parent;
        char *class_name = NULL;
+       /* Notify clients of device removal.  This call must come
+        * before dpm_sysfs_remove().
+        */
+       if (dev->bus)
+               blocking_notifier_call_chain(&dev->bus->bus_notifier,
+                                            BUS_NOTIFY_DEL_DEVICE, dev);
        if (parent)
        if (dev->devt_attr)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -45,6 +45,11 @@ void device_bind_driver(struct device * 
        pr_debug("bound device '%s' to driver '%s'\n",
                 dev->bus_id, dev->driver->name);
+       if (dev->bus)
+               blocking_notifier_call_chain(&dev->bus->bus_notifier,
+                                            BUS_NOTIFY_BOUND_DRIVER, dev);
        klist_add_tail(&dev->knode_driver, &dev->driver->klist_devices);
        sysfs_create_link(&dev->driver->kobj, &dev->kobj,
@@ -209,6 +214,11 @@ static void __device_release_driver(stru
                sysfs_remove_link(&dev->kobj, "driver");
+               if (dev->bus)
+                       blocking_notifier_call_chain(&dev->bus->bus_notifier,
+                                                    BUS_NOTIFY_UNBIND_DRIVER,
+                                                    dev);
                if (dev->bus && dev->bus->remove)
                else if (drv->remove)
diff --git a/include/linux/device.h b/include/linux/device.h
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -41,6 +41,8 @@ struct bus_type {
        struct klist            klist_devices;
        struct klist            klist_drivers;
+       struct blocking_notifier_head bus_notifier;
        struct bus_attribute    * bus_attrs;
        struct device_attribute * dev_attrs;
        struct driver_attribute * drv_attrs;
@@ -71,6 +73,29 @@ int bus_for_each_drv(struct bus_type * b
                     void * data, int (*fn)(struct device_driver *, void *));
+ * Bus notifiers: Get notified of addition/removal of devices
+ * and binding/unbinding of drivers to devices.
+ * In the long run, it should be a replacement for the platform
+ * notify hooks.
+ */
+struct notifier_block;
+extern int bus_register_notifier(struct bus_type *bus,
+                                struct notifier_block *nb);
+extern int bus_unregister_notifier(struct bus_type *bus,
+                                  struct notifier_block *nb);
+/* All 4 notifers below get called with the target struct device *
+ * as an argument. Note that those functions are likely to be called
+ * with the device semaphore held in the core, so be careful.
+ */
+#define BUS_NOTIFY_ADD_DEVICE          0x00000001 /* device added */
+#define BUS_NOTIFY_DEL_DEVICE          0x00000002 /* device removed */
+#define BUS_NOTIFY_BOUND_DRIVER                0x00000003 /* driver bound to 
device */
+#define BUS_NOTIFY_UNBIND_DRIVER       0x00000004 /* driver about to be
+                                                     unbound */
 /* driverfs interface for exporting bus attributes */
 struct bus_attribute {

Attachment: backport-notifier.patch
Description: Text Data

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [PATCH 1/5] take 2: PCIe IO space multiplexing: backport of bus event notification patch, Isaku Yamahata <=