1. 02 12月, 2006 1 次提交
    • B
      Driver core: add notification of bus events · 116af378
      Benjamin Herrenschmidt 提交于
      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
      notifiers.
      
      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
      unbound.
      
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      116af378
  2. 24 10月, 2006 1 次提交
  3. 26 9月, 2006 15 次提交
  4. 22 6月, 2006 3 次提交
  5. 07 5月, 2006 1 次提交
  6. 26 4月, 2006 1 次提交
  7. 22 3月, 2006 1 次提交
  8. 21 3月, 2006 1 次提交
    • T
      [PATCH] Driver core: add macros notice(), dev_notice() · 4f2928d0
      Tilman Schmidt 提交于
      Both usb.h and device.h have collections of convenience macros for
      printk() with the KERN_ERR, KERN_WARNING, and KERN_NOTICE severity
      levels. This patch adds macros for the KERN_NOTICE level which was
      so far uncatered for.
      
      These macros already exist privately in drivers/isdn/gigaset/gigaset.h
      (currently in the process of being submitted for the kernel tree)
      but they really belong with their brothers and sisters in
      include/linux/{device,usb}.h.
      Signed-off-by: NTilman Schmidt <tilman@imap.cc>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4f2928d0
  9. 15 3月, 2006 1 次提交
  10. 14 1月, 2006 1 次提交
  11. 05 1月, 2006 1 次提交
  12. 30 10月, 2005 1 次提交
  13. 29 10月, 2005 5 次提交
  14. 22 9月, 2005 1 次提交
  15. 12 7月, 2005 1 次提交
  16. 30 6月, 2005 2 次提交
  17. 21 6月, 2005 3 次提交
    • Y
      [PATCH] Driver core: change device_attribute callbacks · 54b6f35c
      Yani Ioannou 提交于
      This patch adds the device_attribute paramerter to the
      device_attribute store and show sysfs callback functions, and passes a
      reference to the attribute when the callbacks are called.
      Signed-off-by: NYani Ioannou <yani.ioannou@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      54b6f35c
    • P
      [PATCH] Driver Core: fix bk-driver-core kills ppc64 · 0d3e5a2e
      Patrick Mochel 提交于
      There's no check to see if the device is already bound to a driver, which
      could do bad things.  The first thing to go wrong is that it will try to match
      a driver with a device already bound to one.  In some cases (it appears with
      USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
      device based on the class type, so it would be common (especially for HID
      devices) to match a device that is already bound.
      
      The fun comes when ->probe() is called, it fails, then
      driver_probe_device() does this:
      
      	dev->driver = NULL;
      
      Later on, that pointer could be be dereferenced without checking and cause
      hell to break loose.
      
      This problem could be nasty. It's very hardware dependent, since some
      devices could have a different set of matching qualifiers than others.
      
      Now, I don't quite see exactly where/how you were getting that crash.
      You're dereferencing bad memory, but I'm not sure which pointer was bad
      and where it came from, but it could have come from a couple of different
      places.
      
      The patch below will hopefully fix it all up for you. It's against
      2.6.12-rc2-mm1, and does the following:
      
      - Move logic to driver_probe_device() and comments uncommon returns:
        1 - If device is bound
        0 - If device not bound, and no error
        error - If there was an error.
      
      - Move locking to caller of that function, since we want to lock a
        device for the entire time we're trying to bind it to a driver (to
        prevent against a driver being loaded at the same time).
      
      - Update __device_attach() and __driver_attach() to do that locking.
      
      - Check if device is already bound in __driver_attach()
      
      - Update the converse device_release_driver() so it locks the device
        around all of the operations.
      
      - Mark driver_probe_device() as static and remove export. It's an
        internal function, it should stay that way, and there are no other
        callers. If there is ever a need to export it, we can audit it as
        necessary.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      0d3e5a2e
    • M
      [PATCH] Use a klist for device child lists. · 36239577
      mochel@digitalimplant.org 提交于
      - Use klist iterator in device_for_each_child(), making it safe to use for
        removing devices.
      - Remove unused list_to_dev() function.
      - Kills all usage of devices_subsys.rwsem.
      Signed-off-by: NPatrick Mochel <mochel@digitalimplant.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      36239577