An error occurred fetching the project authors.
  1. 12 Oct, 2007 2 commits
  2. 11 Jul, 2007 1 commit
  3. 03 May, 2007 1 commit
  4. 27 Apr, 2007 1 commit
  5. 09 Feb, 2007 1 commit
    • Tejun Heo's avatar
      devres: device resource management · 9ac7849e
      Tejun Heo authored
      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: default avatarTejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      9ac7849e
  6. 26 Sep, 2006 1 commit
  7. 21 Jun, 2006 4 commits
  8. 06 Feb, 2006 1 commit
  9. 28 Oct, 2005 1 commit
    • Ben Dooks's avatar
      [PATCH] drivers/base - fix sparse warnings · a1bdc7aa
      Ben Dooks authored
      There are a number of sparse warnings from the latest sparse
      snapshot being generated from the drivers/base build. The
      main culprits are due to the initialisation functions not
      being declared in a header file.
      
      Also, the firmware.c file should include <linux/device.h>
      to get the prototype of  firmware_register() and
      firmware_unregister().
      
      This patch moves the init function declerations from the
      init.c file to the base.h, and ensures it is included in
      all the relevant c sources. It also adds <linux/device.h>
      to the included headers for firmware.c.
      
      The patch does not solve all the sparse errors generated,
      but reduces the count significantly.
      
      drivers/base/core.c:161:1: warning: symbol 'devices_subsys' was not declared. Should it be static?
      drivers/base/core.c:417:12: warning: symbol 'devices_init' was not declared. Should it be static?
      drivers/base/sys.c:253:6: warning: symbol 'sysdev_shutdown' was not declared. Should it be static?
      drivers/base/sys.c:326:5: warning: symbol 'sysdev_suspend' was not declared. Should it be static?
      drivers/base/sys.c:428:5: warning: symbol 'sysdev_resume' was not declared. Should it be static?
      drivers/base/sys.c:450:12: warning: symbol 'system_bus_init' was not declared. Should it be static?
      drivers/base/bus.c:133:1: warning: symbol 'bus_subsys' was not declared. Should it be static?
      drivers/base/bus.c:667:12: warning: symbol 'buses_init' was not declared. Should it be static?
      drivers/base/class.c:759:12: warning: symbol 'classes_init' was not declared. Should it be static?
      drivers/base/platform.c:313:12: warning: symbol 'platform_bus_init' was not declared. Should it be static?
      drivers/base/cpu.c:110:12: warning: symbol 'cpu_dev_init' was not declared. Should it be static?
      drivers/base/firmware.c:17:5: warning: symbol 'firmware_register' was not declared. Should it be static?
      drivers/base/firmware.c:23:6: warning: symbol 'firmware_unregister' was not declared. Should it be static?
      drivers/base/firmware.c:28:12: warning: symbol 'firmware_init' was not declared. Should it be static?
      drivers/base/init.c:28:13: warning: symbol 'driver_init' was not declared. Should it be static?
      drivers/base/dmapool.c:174:10: warning: implicit cast from nocast type
      drivers/base/attribute_container.c:439:1: warning: symbol 'attribute_container_init' was not declared. Should it be static?
      drivers/base/power/runtime.c:76:6: warning: symbol 'dpm_set_power_state' was not declared. Should it be static?
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      a1bdc7aa
  10. 30 Jun, 2005 1 commit
    • Greg Kroah-Hartman's avatar
      [PATCH] driver core: Add the ability to bind drivers to devices from userspace · afdce75f
      Greg Kroah-Hartman authored
      This adds a single file, "bind", to the sysfs directory of every driver
      registered with the driver core.  To bind a device to a driver, write
      the bus id of the device you wish to bind to that specific driver to the
      "bind" file (remember to not add a trailing \n).  If that bus id matches
      a device on that bus, and it does not currently have a driver bound to
      it, the probe sequence will be initiated with that driver and device.
      
      Note, this requires that the driver itself be willing and able to accept
      that device (usually through a device id type table).  This patch does
      not make it possible to override the driver's id table.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      afdce75f
  11. 20 Jun, 2005 1 commit
  12. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4