1. 25 3月, 2009 8 次提交
  2. 22 2月, 2009 1 次提交
  3. 10 1月, 2009 4 次提交
  4. 07 1月, 2009 8 次提交
  5. 23 10月, 2008 1 次提交
  6. 17 10月, 2008 4 次提交
    • G
      Driver core: add bus_sort_breadthfirst() function · 99178b03
      Greg Kroah-Hartman 提交于
      The PCI core wants to reorder the devices in the bus list.  So move this
      functionality out of the pci core and into the driver core so that
      anyone else can also do this if needed.  This also lets us change how
      struct device is attached to drivers in the future without messing with
      the PCI core.
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      99178b03
    • A
      debug: Introduce a dev_WARN() function · e6139662
      Arjan van de Ven 提交于
      in the line of dev_printk(), this patch introduces a dev_WARN() function,
      that takes a struct device and then a printk format/args set of arguments.
      Unlike dev_printk(), the effect is that of WARN() in that a full warning
      message (including filename/line, module list, versions and a backtrace)
      is printed in addition to the device name and the arguments.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e6139662
    • J
      driver core: basic infrastructure for per-module dynamic debug messages · 346e15be
      Jason Baron 提交于
      Base infrastructure to enable per-module debug messages.
      
      I've introduced CONFIG_DYNAMIC_PRINTK_DEBUG, which when enabled centralizes
      control of debugging statements on a per-module basis in one /proc file,
      currently, <debugfs>/dynamic_printk/modules. When, CONFIG_DYNAMIC_PRINTK_DEBUG,
      is not set, debugging statements can still be enabled as before, often by
      defining 'DEBUG' for the proper compilation unit. Thus, this patch set has no
      affect when CONFIG_DYNAMIC_PRINTK_DEBUG is not set.
      
      The infrastructure currently ties into all pr_debug() and dev_dbg() calls. That
      is, if CONFIG_DYNAMIC_PRINTK_DEBUG is set, all pr_debug() and dev_dbg() calls
      can be dynamically enabled/disabled on a per-module basis.
      
      Future plans include extending this functionality to subsystems, that define 
      their own debug levels and flags.
      
      Usage:
      
      Dynamic debugging is controlled by the debugfs file, 
      <debugfs>/dynamic_printk/modules. This file contains a list of the modules that
      can be enabled. The format of the file is as follows:
      
      	<module_name> <enabled=0/1>
      		.
      		.
      		.
      
      	<module_name> : Name of the module in which the debug call resides
      	<enabled=0/1> : whether the messages are enabled or not
      
      For example:
      
      	snd_hda_intel enabled=0
      	fixup enabled=1
      	driver enabled=0
      
      Enable a module:
      
      	$echo "set enabled=1 <module_name>" > dynamic_printk/modules
      
      Disable a module:
      
      	$echo "set enabled=0 <module_name>" > dynamic_printk/modules
      
      Enable all modules:
      
      	$echo "set enabled=1 all" > dynamic_printk/modules
      
      Disable all modules:
      
      	$echo "set enabled=0 all" > dynamic_printk/modules
      
      Finally, passing "dynamic_printk" at the command line enables
      debugging for all modules. This mode can be turned off via the above
      disable command.
      
      [gkh: minor cleanups and tweaks to make the build work quietly]
      Signed-off-by: NJason Baron <jbaron@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      346e15be
    • G
      device create: remove device_create_drvdata · 7fb6b5d5
      Greg Kroah-Hartman 提交于
      Now that the tree is cleaned up, device_create_drvdata can be safely
      removed.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7fb6b5d5
  7. 09 10月, 2008 1 次提交
    • T
      driver-core: use klist for class device list and implement iterator · 5a3ceb86
      Tejun Heo 提交于
      Iterating over entries using callback usually isn't too fun especially
      when the entry being iterated over can't be manipulated freely.  This
      patch converts class->p->class_devices to klist and implements class
      device iterator so that the users can freely build their own control
      structure.  The users are also free to call back into class code
      without worrying about locking.
      
      class_for_each_device() and class_find_device() are converted to use
      the new iterators, so their users don't have to worry about locking
      anymore either.
      
      Note: This depends on klist-dont-iterate-over-deleted-entries patch
      because class_intf->add/remove_dev() depends on proper synchronization
      with device removal.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      5a3ceb86
  8. 22 8月, 2008 2 次提交
  9. 22 7月, 2008 10 次提交
  10. 11 6月, 2008 1 次提交
    • R
      Introduce new top level suspend and hibernation callbacks · 1eede070
      Rafael J. Wysocki 提交于
      Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
      'extended') representing suspend and hibernation operations for bus
      types, device classes, device types and device drivers.
      
      Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
      objects, if defined, instead of the ->suspend(), ->resume(),
      ->suspend_late(), and ->resume_early() callbacks (the old callbacks
      will be considered as legacy and gradually phased out).
      
      The main purpose of doing this is to separate suspend (aka S2RAM and
      standby) callbacks from hibernation callbacks in such a way that the
      new callbacks won't take arguments and the semantics of each of them
      will be clearly specified.  This has been requested for multiple
      times by many people, including Linus himself, and the reason is that
      within the current scheme if ->resume() is called, for example, it's
      difficult to say why it's been called (ie. is it a resume from RAM or
      from hibernation or a suspend/hibernation failure etc.?).
      
      The second purpose is to make the suspend/hibernation callbacks more
      flexible so that device drivers can handle more than they can within
      the current scheme.  For example, some drivers may need to prevent
      new children of the device from being registered before their
      ->suspend() callbacks are executed or they may want to carry out some
      operations requiring the availability of some other devices, not
      directly bound via the parent-child relationship, in order to prepare
      for the execution of ->suspend(), etc.
      
      Ultimately, we'd like to stop using the freezing of tasks for suspend
      and therefore the drivers' suspend/hibernation code will have to take
      care of the handling of the user space during suspend/hibernation.
      That, in turn, would be difficult within the current scheme, without
      the new ->prepare() and ->complete() callbacks.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      1eede070