1. 09 3月, 2012 1 次提交
    • G
      drivercore: Add driver probe deferral mechanism · d1c3414c
      Grant Likely 提交于
      Allow drivers to report at probe time that they cannot get all the resources
      required by the device, and should be retried at a later time.
      
      This should completely solve the problem of getting devices
      initialized in the right order.  Right now this is mostly handled by
      mucking about with initcall ordering which is a complete hack, and
      doesn't even remotely handle the case where device drivers are in
      modules.  This approach completely sidesteps the issues by allowing
      driver registration to occur in any order, and any driver can request
      to be retried after a few more other drivers get probed.
      
      v4: - Integrate Manjunath's addition of a separate workqueue
          - Change -EAGAIN to -EPROBE_DEFER for drivers to trigger deferral
          - Update comment blocks to reflect how the code really works
      v3: - Hold off workqueue scheduling until late_initcall so that the bulk
            of driver probes are complete before we start retrying deferred devices.
          - Tested with simple use cases.  Still needs more testing though.
            Using it to get rid of the gpio early_initcall madness, or to replace
            the ASoC internal probe deferral code would be ideal.
      v2: - added locking so it should no longer be utterly broken in that regard
          - remove device from deferred list at device_del time.
          - Still completely untested with any real use case, but has been
            boot tested.
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Dilan Lee <dilee@nvidia.com>
      Cc: Manjunath GKondaiah <manjunath.gkondaiah@linaro.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1c3414c
  2. 12 1月, 2012 1 次提交
  3. 15 12月, 2011 1 次提交
    • K
      driver-core: implement 'sysdev' functionality for regular devices and buses · ca22e56d
      Kay Sievers 提交于
      All sysdev classes and sysdev devices will converted to regular devices
      and buses to properly hook userspace into the event processing.
      
      There is no interesting difference between a 'sysdev' and 'device' which
      would justify to roll an entire own subsystem with different userspace
      export semantics. Userspace relies on events and generic sysfs subsystem
      infrastructure from sysdev devices, which are currently not properly
      available.
      
      Every converted sysdev class will create a regular device with the class
      name in /sys/devices/system and all registered devices will becom a children
      of theses devices.
      
      For compatibility reasons, the sysdev class-wide attributes are created
      at this parent device. (Do not copy that logic for anything new, subsystem-
      wide properties belong to the subsystem, not to some fake parent device
      created in /sys/devices.)
      
      Every sysdev driver is implemented as a simple subsystem interface now,
      and no longer called a driver.
      
      After all sysdev classes are ported to regular driver core entities, the
      sysdev implementation will be entirely removed from the kernel.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ca22e56d
  4. 01 11月, 2011 1 次提交
  5. 12 5月, 2011 1 次提交
  6. 18 11月, 2010 1 次提交
  7. 16 9月, 2009 3 次提交
    • K
      Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev · 2b2af54a
      Kay Sievers 提交于
      Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
      very early at kernel initialization, before any driver-core device
      is registered. Every device with a major/minor will provide a
      device node in devtmpfs.
      
      Devtmpfs can be changed and altered by userspace at any time,
      and in any way needed - just like today's udev-mounted tmpfs.
      Unmodified udev versions will run just fine on top of it, and will
      recognize an already existing kernel-created device node and use it.
      The default node permissions are root:root 0600. Proper permissions
      and user/group ownership, meaningful symlinks, all other policy still
      needs to be applied by userspace.
      
      If a node is created by devtmps, devtmpfs will remove the device node
      when the device goes away. If the device node was created by
      userspace, or the devtmpfs created node was replaced by userspace, it
      will no longer be removed by devtmpfs.
      
      If it is requested to auto-mount it, it makes init=/bin/sh work
      without any further userspace support. /dev will be fully populated
      and dynamic, and always reflect the current device state of the kernel.
      With the commonly used dynamic device numbers, it solves the problem
      where static devices nodes may point to the wrong devices.
      
      It is intended to make the initial bootup logic simpler and more robust,
      by de-coupling the creation of the inital environment, to reliably run
      userspace processes, from a complex userspace bootstrap logic to provide
      a working /dev.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NJan Blunck <jblunck@suse.de>
      Tested-By: NHarald Hoyer <harald@redhat.com>
      Tested-By: NScott James Remnant <scott@ubuntu.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2b2af54a
    • G
      Driver core: move dev_get/set_drvdata to drivers/base/dd.c · b4028437
      Greg Kroah-Hartman 提交于
      No one should directly access the driver_data field, so remove the field
      and make it private.  We dynamically create the private field now if it
      is needed, to handle drivers that call get/set before they are
      registered with the driver core.
      
      Also update the copyright notices on these files while we are there.
      
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b4028437
    • A
      Driver core: add new device to bus's list before probing · 2023c610
      Alan Stern 提交于
      This patch (as1271) affects when new devices get linked into their
      bus's list of devices.  Currently this happens after probing, and it
      doesn't happen at all if probing fails.  Clearly this is wrong,
      because at that point quite a few symbolic links have already been
      created in sysfs.  We are committed to adding the device, so it should
      be linked into the bus's list regardless.
      
      In addition, this needs to happen before the uevent announcing the new
      device gets issued.  Otherwise user programs might try to access the
      device before it has been added to the bus.
      
      To fix both these problems, the patch moves the call to
      klist_add_tail() forward from bus_attach_device() to bus_add_device().
      Since bus_attach_device() now does nothing but probe for drivers, it
      has been renamed to bus_probe_device().  And lastly, the kerneldoc is
      updated.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      
      
      2023c610
  8. 17 4月, 2009 1 次提交
  9. 25 3月, 2009 5 次提交
  10. 23 2月, 2009 1 次提交
  11. 10 1月, 2009 4 次提交
  12. 07 1月, 2009 4 次提交
  13. 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
  14. 22 7月, 2008 7 次提交
  15. 01 5月, 2008 1 次提交
  16. 25 1月, 2008 7 次提交