1. 27 Jul, 2013 1 commit
  2. 16 Jul, 2013 2 commits
  3. 03 Jun, 2013 1 commit
  4. 21 May, 2013 2 commits
  5. 12 May, 2013 1 commit
    • Rafael J. Wysocki's avatar
      Driver core: Add offline/online device operations · 4f3549d7
      Rafael J. Wysocki authored
      In some cases, graceful hot-removal of devices is not possible,
      although in principle the devices in question support hotplug.
      For example, that may happen for the last CPU in the system or
      for memory modules holding kernel memory.
      In those cases it is nice to be able to check if the given device
      can be gracefully hot-removed before triggering a removal procedure
      that cannot be aborted or reversed.  Unfortunately, however, the
      kernel currently doesn't provide any support for that.
      To address that deficiency, introduce support for offline and
      online operations that can be performed on devices, respectively,
      before a hot-removal and in case when it is necessary (or convenient)
      to put a device back online after a successful offline (that has not
      been followed by removal).  The idea is that the offline will fail
      whenever the given device cannot be gracefully removed from the
      system and it will not be allowed to use the device after a
      successful offline (until a subsequent online) in analogy with the
      existing CPU offline/online mechanism.
      For now, the offline and online operations are introduced at the
      bus type level, as that should be sufficient for the most urgent use
      cases (CPUs and memory modules).  In the future, however, the
      approach may be extended to cover some more complicated device
      offline/online scenarios involving device drivers etc.
      The lock_device_hotplug() and unlock_device_hotplug() functions are
      introduced because subsequent patches need to put larger pieces of
      code under device_hotplug_lock to prevent race conditions between
      device offline and removal from happening.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: default avatarToshi Kani <toshi.kani@hp.com>
  6. 11 Apr, 2013 1 commit
  7. 08 Apr, 2013 1 commit
    • Kay Sievers's avatar
      driver core: add uid and gid to devtmpfs · 3c2670e6
      Kay Sievers authored
      Some drivers want to tell userspace what uid and gid should be used for
      their device nodes, so allow that information to percolate through the
      driver core to userspace in order to make this happen.  This means that
      some systems (i.e.  Android and friends) will not need to even run a
      udev-like daemon for their device node manager and can just rely in
      devtmpfs fully, reducing their footprint even more.
      Signed-off-by: default avatarKay Sievers <kay@vrfy.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. 15 Mar, 2013 1 commit
  9. 12 Mar, 2013 1 commit
    • Tejun Heo's avatar
      driver/base: implement subsys_virtual_register() · d73ce004
      Tejun Heo authored
      Kay tells me the most appropriate place to expose workqueues to
      userland would be /sys/devices/virtual/workqueues/WQ_NAME which is
      symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking
      a way to do that outside of driver core as virtual_device_parent()
      isn't exported and there's no inteface to conveniently create a
      virtual subsystem.
      This patch implements subsys_virtual_register() by factoring out
      subsys_register() from subsys_system_register() and using it with
      virtual_device_parent() as the origin directory.  It's identical to
      subsys_system_register() other than the origin directory but we aren't
      gonna restrict the device names which should be used under it.
      This will be used to expose workqueue attributes to userland.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
  10. 06 Feb, 2013 1 commit
  11. 17 Jan, 2013 3 commits
  12. 27 Nov, 2012 2 commits
  13. 14 Nov, 2012 1 commit
    • LongX Zhang's avatar
      driver core / PM: move the calling to device_pm_remove behind the calling to bus_remove_device · 4b6d1f12
      LongX Zhang authored
      We hit an hang issue when removing a mmc device on Medfield Android phone by sysfs interface.
      device_pm_remove will call pm_runtime_remove which would disable
      runtime PM of the device. After that pm_runtime_get* or
      pm_runtime_put* will be ignored. So if we disable the runtime PM
      before device really be removed, drivers' _remove callback may
      access HW even pm_runtime_get* fails. That is bad.
      Consider below call sequence when removing a device:
      device_del => device_pm_remove
                   => class_intf->remove_dev(dev, class_intf)  => pm_runtime_get_sync/put_sync
                   => bus_remove_device => device_release_driver => pm_runtime_get_sync/put_sync
      remove_dev might call pm_runtime_get_sync/put_sync.
      Then, generic device_release_driver also calls pm_runtime_get_sync/put_sync.
      Since device_del => device_pm_remove firstly, later _get_sync wouldn't really wake up the device.
      I git log -p to find the patch which moves the calling to device_pm_remove ahead.
      It's below patch:
      commit  775b64d2
      Author: Rafael J. Wysocki <rjw@sisk.pl>
      Date:   Sat Jan 12 20:40:46 2008 +0100
           PM: Acquire device locks on suspend
           This patch reorganizes the way suspend and resume notifications are
           sent to drivers.  The major changes are that now the PM core acquires
           every device semaphore before calling the methods, and calls to
           device_add() during suspends will fail, while calls to device_del()
           during suspends will block.
           It also provides a way to safely remove a suspended device with the
           help of the PM core, by using the device_pm_schedule_removal() callback
           introduced specifically for this purpose, and updates two drivers (msr
           and cpuid) that need to use it.
      As device_pm_schedule_removal is deleted by another patch, we need also revert other parts of the patch,
      i.e. move the calling of device_pm_remove after the calling to bus_remove_device.
      Signed-off-by: default avatarLongX Zhang <longx.zhang@intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  14. 26 Oct, 2012 1 commit
  15. 17 Sep, 2012 3 commits
  16. 19 Aug, 2012 1 commit
  17. 16 Aug, 2012 2 commits
  18. 17 Jul, 2012 2 commits
  19. 11 Jun, 2012 1 commit
  20. 08 May, 2012 1 commit
  21. 23 Apr, 2012 1 commit
  22. 18 Apr, 2012 1 commit
  23. 08 Mar, 2012 2 commits
    • Greg Kroah-Hartman's avatar
      driver core: move the deferred probe pointer into the private area · ef8a3fd6
      Greg Kroah-Hartman authored
      Nothing outside of the driver core needs to get to the deferred probe
      pointer, so move it inside the private area of 'struct device' so no one
      tries to mess around with it.
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Grant Likely's avatar
      drivercore: Add driver probe deferral mechanism · d1c3414c
      Grant Likely authored
      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: default avatarGrant 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: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: default avatarDavid Daney <david.daney@cavium.com>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  24. 01 Feb, 2012 1 commit
    • Grant Likely's avatar
      drivercore: Output common devicetree information in uevent · 07d57a32
      Grant Likely authored
      When userspace needs to find a specific device, it currently isn't easy to
      resolve a /sys/devices/ path from a specific device tree node.  Nor is it
      easy to obtain the compatible list for devices.
      This patch generalizes the code that inserts OF_* values into the uevent
      device attribute so that any device that is attached to an OF node will
      have that information exported to userspace.  Without this patch only
      platform devices and some powerpc-specific busses have access to this
      The original function also creates a MODALIAS property for the compatible
      list, but that code has not been generalized into the common case because
      it has the potential to break module loading on a lot of bus types.  Bus
      types are still responsible for their own MODALIAS properties.
      Boot tested on ARM and compile tested on PowerPC and SPARC.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Tobias Klauser <tklauser@distanz.ch>
      Cc: Frederic Lambert <frdrc66@gmail.com>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Mark Brown <broonie@sirena.org.uk>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
  25. 24 Jan, 2012 2 commits
  26. 04 Jan, 2012 1 commit
  27. 14 Dec, 2011 1 commit
    • Kay Sievers's avatar
      driver-core: implement 'sysdev' functionality for regular devices and buses · ca22e56d
      Kay Sievers authored
      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
      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: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  28. 07 Dec, 2011 1 commit
    • Alan Stern's avatar
      PM / Driver core: leave runtime PM enabled during system shutdown · fe6b91f4
      Alan Stern authored
      Disabling all runtime PM during system shutdown turns out not to be a
      good idea, because some devices may need to be woken up from a
      low-power state at that time.
      The whole point of disabling runtime PM for system shutdown was to
      prevent untimely runtime-suspend method calls.  This patch (as1504)
      accomplishes the same result by incrementing the usage count for each
      device and waiting for ongoing runtime-PM callbacks to finish.  This
      is what we already do during system suspend and hibernation, which
      makes sense since the shutdown method is pretty much a legacy analog
      of the pm->poweroff method.
      This fixes a recent regression on some OMAP systems introduced by
      commit af8db150
       (PM / driver core:
      disable device's runtime PM during shutdown).
      Reported-and-tested-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
  29. 15 Nov, 2011 1 commit
    • Peter Chen's avatar
      PM / driver core: disable device's runtime PM during shutdown · af8db150
      Peter Chen authored
      There may be an issue when the user issue "reboot/shutdown" command, then
      the device has shut down its hardware, after that, this runtime-pm featured
      device's driver will probably be scheduled to do its suspend routine,
      and at its suspend routine, it may access hardware, but the device has
      already shutdown physically, then the system hang may be occurred.
      I ran out this issue using an auto-suspend supported USB devices, like
      3G modem, keyboard. The usb runtime suspend routine may be scheduled
      after the usb controller has been shut down, and the usb runtime suspend
      routine will try to suspend its roothub(controller), it will access
      register, then the system hang occurs as the controller is shutdown.
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Acked-by: default avatarMing Lei <tom.leiming@gmail.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Cc: stable@kernel.org
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>