1. 28 4月, 2007 2 次提交
    • K
      Driver core: udev triggered device-<>driver binding · b8c5cec2
      Kay Sievers 提交于
      We get two per-bus sysfs files:
        ls-l /sys/subsystem/usb
        drwxr-xr-x 2 root root    0 2007-02-16 16:42 devices
        drwxr-xr-x 7 root root    0 2007-02-16 14:55 drivers
        -rw-r--r-- 1 root root 4096 2007-02-16 16:42 drivers_autoprobe
        --w------- 1 root root 4096 2007-02-16 16:42 drivers_probe
      
      The flag "drivers_autoprobe" controls the behavior of the bus to bind
      devices by default, or just initialize the device and leave it alone.
      
      The command "drivers_probe" accepts a bus_id and the bus tries to bind a
      driver to this device.
      
      Systems who want to control the driver binding with udev, switch off the
      bus initiated probing:
        echo 0 > /sys/subsystem/usb/drivers_autoprobe
        echo 0 > /sys/subsystem/pcmcia/drivers_autoprobe
        ...
      
      and initiate the probing with udev rules like:
        ACTION=="add", SUBSYSTEM=="usb", ATTR{subsystem/drivers_probe}="$kernel"
        ACTION=="add", SUBSYSTEM=="pcmcia", ATTR{subsystem/drivers_probe}="$kernel"
        ...
      
      Custom driver binding can happen in earlier rules by something like:
        ACTION=="add", SUBSYSTEM=="usb", \
        ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678" \
        ATTR{subsystem/drivers/<custom-driver>/bind}="$kernel"
      
      This is intended to solve the modprobe.conf mess with "install-rules", custom
      bind/unbind-scripts and all the weird things people invented over the years.
      It should also provide the functionality "libusual" was supposed to do.
      
      With udev, one can just write a udev rule to drive all USB-disks at the
      third port of USB-hub by the "ub" driver, and everything else by
      usb-storage. One can also instruct udev to bind different wireless
      drivers to identical cards - just selected by the pcmcia slot-number, and
      whatever ...
      
      To use the mentioned rules, it needs udev version 106, to be able to
      write ATTR{}="$kernel" to sysfs files.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b8c5cec2
    • K
      driver core: fix namespace issue with devices assigned to classes · 86406245
      Kay Sievers 提交于
        - uses a kset in "struct class" to keep track of all directories
          belonging to this class
        - merges with the /sys/devices/virtual logic.
        - removes the namespace-dir if the last member of that class
          leaves the directory.
      
      There may be locking or refcounting fixes left, I stopped when it seemed
      to work with network and sound modules. :)
      
      From: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      86406245
  2. 03 4月, 2007 1 次提交
  3. 16 3月, 2007 1 次提交
    • A
      [PATCH] sysfs and driver core: add callback helper, used by SCSI and S390 · d9a9cdfb
      Alan Stern 提交于
      This patch (as868) adds a helper routine for device drivers that need
      to set up a callback to perform some action in a different process's
      context.  This is intended for use by attribute methods that want to
      unregister themselves or their parent device.  Attribute method calls
      are mutually exclusive with unregistration, so such actions cannot be
      taken directly.
      
      Two attribute methods are converted to use the new helper routine: one
      for SCSI device deletion and one for System/390 ccwgroup devices.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Cc: Oliver Neukum <oneukum@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d9a9cdfb
  4. 24 2月, 2007 1 次提交
  5. 18 2月, 2007 1 次提交
  6. 17 2月, 2007 1 次提交
  7. 10 2月, 2007 1 次提交
    • T
      devres: device resource management · 9ac7849e
      Tejun Heo 提交于
      Implement device resource management, in short, devres.  A device
      driver can allocate arbirary size of devres data which is associated
      with a release function.  On driver detach, release function is
      invoked on the devres data, then, devres data is freed.
      
      devreses are typed by associated release functions.  Some devreses are
      better represented by single instance of the type while others need
      multiple instances sharing the same release function.  Both usages are
      supported.
      
      devreses can be grouped using devres group such that a device driver
      can easily release acquired resources halfway through initialization
      or selectively release resources (e.g. resources for port 1 out of 4
      ports).
      
      This patch adds devres core including documentation and the following
      managed interfaces.
      
      * alloc/free	: devm_kzalloc(), devm_kzfree()
      * IO region	: devm_request_region(), devm_release_region()
      * IRQ		: devm_request_irq(), devm_free_irq()
      * DMA		: dmam_alloc_coherent(), dmam_free_coherent(),
      		  dmam_declare_coherent_memory(), dmam_pool_create(),
      		  dmam_pool_destroy()
      * PCI		: pcim_enable_device(), pcim_pin_device(), pci_is_managed()
      * iomap		: devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
      		  devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
      		  pcim_iomap(), pcim_iounmap()
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      9ac7849e
  8. 08 2月, 2007 3 次提交
  9. 21 12月, 2006 1 次提交
  10. 08 12月, 2006 1 次提交
    • C
      [PATCH] add numa node information to struct device · 87348136
      Christoph Hellwig 提交于
      For node-aware skb allocations we need information about the node in struct
      net_device or struct device.  Davem suggested to put it into struct device
      which this patch does.
      
      In particular:
      
       - struct device gets a new int numa_node member if CONFIG_NUMA is set
       - there are two new helpers, dev_to_node and set_dev_node to
         transparently deal with the non-numa case
       - for pci devices the node-info is set to the value we get from
         pcibus_to_node.
      
      Note that for some architectures pcibus_to_node doesn't work yet at the time
      we call it currently.  This is harmless and will just mean skb allocations
      aren't node-local on this architectures until the implementation of
      pcibus_to_node on these architectures have been updated (There are patches for
      x86 and x86_64 floating around)
      
      [akpm@osdl.org: cleanup]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      87348136
  11. 02 12月, 2006 6 次提交
    • C
      driver core: Introduce device_move(): move a device to a new parent. · 8a82472f
      Cornelia Huck 提交于
      Provide a function device_move() to move a device to a new parent device. Add
      auxilliary functions kobject_move() and sysfs_move_dir().
      kobject_move() generates a new uevent of type KOBJ_MOVE, containing the
      previous path (DEVPATH_OLD) in addition to the usual values. For this, a new
      interface kobject_uevent_env() is created that allows to add further
      environmental data to the uevent at the kobject layer.
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Acked-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      8a82472f
    • C
      driver core: Introduce device_find_child(). · 5ab69981
      Cornelia Huck 提交于
      Introduce device_find_child() to match device_for_each_child().
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5ab69981
    • B
      ACPI: Change ACPI to use dev_archdata instead of firmware_data · 465ae641
      Benjamin Herrenschmidt 提交于
      Change ACPI to use dev_archdata instead of firmware_data
      
      This patch changes ACPI to use the new dev_archdata on i386, x86_64
      and ia64 (is there any other arch using ACPI ?) to store it's
      acpi_handle.
      
      It also removes the firmware_data field from struct device as this
      was the only user.
      
      Only build-tested on x86
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      465ae641
    • B
      Driver core: add dev_archdata to struct device · c6dbaef2
      Benjamin Herrenschmidt 提交于
      Add arch specific dev_archdata to struct device
      
      Adds an arch specific struct dev_arch to struct device. This enables
      architecture to add specific fields to every device in the system, like
      DMA operation pointers, NUMA node ID, firmware specific data, etc...
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NAndi Kleen <ak@suse.de>
      Acked-By: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c6dbaef2
    • G
      Driver Core: Move virtual_device_parent() to core.c · f0ee61a6
      Greg Kroah-Hartman 提交于
      It doesn't need to be global or in device.h
      
      
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f0ee61a6
    • 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
  12. 24 10月, 2006 1 次提交
  13. 26 9月, 2006 15 次提交
  14. 22 6月, 2006 3 次提交
  15. 07 5月, 2006 1 次提交
  16. 26 4月, 2006 1 次提交