1. 13 8月, 2013 2 次提交
  2. 17 7月, 2013 3 次提交
  3. 26 6月, 2013 1 次提交
    • M
      driver core: device.h: fix doc compilation warnings · bfd63cd2
      Michael Opdenacker 提交于
      This patch fixes the below 3 warnings running "make htmldocs",
      by adding descriptions for recently added structure members:
      
      DOCPROC Documentation/DocBook/device-drivers.xml
      Warning(/work/git.free-electrons.com/users/michael-opdenacker/linux//include/linux/device.h:116): No description found for parameter 'lock_key'
      Warning(/work/git.free-electrons.com/users/michael-opdenacker/linux//include/linux/device.h:723): No description found for parameter 'cma_area'
      Warning(/work/git.free-electrons.com/users/michael-opdenacker/linux//include/linux/device.h:723): No description found for parameter 'iommu_group'
      
      Don't hesitate to propose better descriptions!
      Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bfd63cd2
  4. 12 5月, 2013 1 次提交
    • R
      Driver core: Add offline/online device operations · 4f3549d7
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: NToshi Kani <toshi.kani@hp.com>
      4f3549d7
  5. 12 4月, 2013 1 次提交
  6. 08 4月, 2013 1 次提交
    • K
      driver core: add uid and gid to devtmpfs · 3c2670e6
      Kay Sievers 提交于
      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: NKay Sievers <kay@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c2670e6
  7. 13 3月, 2013 2 次提交
    • M
      device: separate all subsys mutexes · be871b7e
      Michal Hocko 提交于
      ca22e56d (driver-core: implement 'sysdev' functionality for regular
      devices and buses) has introduced bus_register macro with a static
      key to distinguish different subsys mutex classes.
      
      This however doesn't work for different subsys which use a common
      registering function. One example is subsys_system_register (and
      mce_device and cpu_device).
      
      In the end this leads to the following lockdep splat:
      [  207.271924] ======================================================
      [  207.271932] [ INFO: possible circular locking dependency detected ]
      [  207.271942] 3.9.0-rc1-0.7-default+ #34 Not tainted
      [  207.271948] -------------------------------------------------------
      [  207.271957] bash/10493 is trying to acquire lock:
      [  207.271963]  (subsys mutex){+.+.+.}, at: [<ffffffff8134af27>] bus_remove_device+0x37/0x1c0
      [  207.271987]
      [  207.271987] but task is already holding lock:
      [  207.271995]  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81046ccf>] cpu_hotplug_begin+0x2f/0x60
      [  207.272012]
      [  207.272012] which lock already depends on the new lock.
      [  207.272012]
      [  207.272023]
      [  207.272023] the existing dependency chain (in reverse order) is:
      [  207.272033]
      [  207.272033] -> #4 (cpu_hotplug.lock){+.+.+.}:
      [  207.272044]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.272056]        [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360
      [  207.272069]        [<ffffffff81046ba9>] get_online_cpus+0x29/0x40
      [  207.272082]        [<ffffffff81185210>] drain_all_stock+0x30/0x150
      [  207.272094]        [<ffffffff811853da>] mem_cgroup_reclaim+0xaa/0xe0
      [  207.272104]        [<ffffffff8118775e>] __mem_cgroup_try_charge+0x51e/0xcf0
      [  207.272114]        [<ffffffff81188486>] mem_cgroup_charge_common+0x36/0x60
      [  207.272125]        [<ffffffff811884da>] mem_cgroup_newpage_charge+0x2a/0x30
      [  207.272135]        [<ffffffff81150531>] do_wp_page+0x231/0x830
      [  207.272147]        [<ffffffff8115151e>] handle_pte_fault+0x19e/0x8d0
      [  207.272157]        [<ffffffff81151da8>] handle_mm_fault+0x158/0x1e0
      [  207.272166]        [<ffffffff814b6153>] do_page_fault+0x2a3/0x4e0
      [  207.272178]        [<ffffffff814b2578>] page_fault+0x28/0x30
      [  207.272189]
      [  207.272189] -> #3 (&mm->mmap_sem){++++++}:
      [  207.272199]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.272208]        [<ffffffff8114c5ad>] might_fault+0x6d/0x90
      [  207.272218]        [<ffffffff811a11e3>] filldir64+0xb3/0x120
      [  207.272229]        [<ffffffffa013fc19>] call_filldir+0x89/0x130 [ext3]
      [  207.272248]        [<ffffffffa0140377>] ext3_readdir+0x6b7/0x7e0 [ext3]
      [  207.272263]        [<ffffffff811a1519>] vfs_readdir+0xa9/0xc0
      [  207.272273]        [<ffffffff811a15cb>] sys_getdents64+0x9b/0x110
      [  207.272284]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b
      [  207.272296]
      [  207.272296] -> #2 (&type->i_mutex_dir_key#3){+.+.+.}:
      [  207.272309]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.272319]        [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360
      [  207.272329]        [<ffffffff8119c254>] link_path_walk+0x6f4/0x9a0
      [  207.272339]        [<ffffffff8119e7fa>] path_openat+0xba/0x470
      [  207.272349]        [<ffffffff8119ecf8>] do_filp_open+0x48/0xa0
      [  207.272358]        [<ffffffff8118d81c>] file_open_name+0xdc/0x110
      [  207.272369]        [<ffffffff8118d885>] filp_open+0x35/0x40
      [  207.272378]        [<ffffffff8135c76e>] _request_firmware+0x52e/0xb20
      [  207.272389]        [<ffffffff8135cdd6>] request_firmware+0x16/0x20
      [  207.272399]        [<ffffffffa03bdb91>] request_microcode_fw+0x61/0xd0 [microcode]
      [  207.272416]        [<ffffffffa03bd554>] microcode_init_cpu+0x104/0x150 [microcode]
      [  207.272431]        [<ffffffffa03bd61c>] mc_device_add+0x7c/0xb0 [microcode]
      [  207.272444]        [<ffffffff8134a419>] subsys_interface_register+0xc9/0x100
      [  207.272457]        [<ffffffffa04fc0f4>] 0xffffffffa04fc0f4
      [  207.272472]        [<ffffffff81000202>] do_one_initcall+0x42/0x180
      [  207.272485]        [<ffffffff810bbeff>] load_module+0x19df/0x1b70
      [  207.272499]        [<ffffffff810bc376>] sys_init_module+0xe6/0x130
      [  207.272511]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b
      [  207.272523]
      [  207.272523] -> #1 (umhelper_sem){++++.+}:
      [  207.272537]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.272548]        [<ffffffff814ae9c4>] down_read+0x34/0x50
      [  207.272559]        [<ffffffff81062bff>] usermodehelper_read_trylock+0x4f/0x100
      [  207.272575]        [<ffffffff8135c7dd>] _request_firmware+0x59d/0xb20
      [  207.272587]        [<ffffffff8135cdd6>] request_firmware+0x16/0x20
      [  207.272599]        [<ffffffffa03bdb91>] request_microcode_fw+0x61/0xd0 [microcode]
      [  207.272613]        [<ffffffffa03bd554>] microcode_init_cpu+0x104/0x150 [microcode]
      [  207.272627]        [<ffffffffa03bd61c>] mc_device_add+0x7c/0xb0 [microcode]
      [  207.272641]        [<ffffffff8134a419>] subsys_interface_register+0xc9/0x100
      [  207.272654]        [<ffffffffa04fc0f4>] 0xffffffffa04fc0f4
      [  207.272666]        [<ffffffff81000202>] do_one_initcall+0x42/0x180
      [  207.272678]        [<ffffffff810bbeff>] load_module+0x19df/0x1b70
      [  207.272690]        [<ffffffff810bc376>] sys_init_module+0xe6/0x130
      [  207.272702]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b
      [  207.272715]
      [  207.272715] -> #0 (subsys mutex){+.+.+.}:
      [  207.272729]        [<ffffffff810ae002>] __lock_acquire+0x13b2/0x15f0
      [  207.272740]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.272751]        [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360
      [  207.272763]        [<ffffffff8134af27>] bus_remove_device+0x37/0x1c0
      [  207.272775]        [<ffffffff81349114>] device_del+0x134/0x1f0
      [  207.272786]        [<ffffffff813491f2>] device_unregister+0x22/0x60
      [  207.272798]        [<ffffffff814a24ea>] mce_cpu_callback+0x15e/0x1ad
      [  207.272812]        [<ffffffff814b6402>] notifier_call_chain+0x72/0x130
      [  207.272824]        [<ffffffff81073d6e>] __raw_notifier_call_chain+0xe/0x10
      [  207.272839]        [<ffffffff81498f76>] _cpu_down+0x1d6/0x350
      [  207.272851]        [<ffffffff81499130>] cpu_down+0x40/0x60
      [  207.272862]        [<ffffffff8149cc55>] store_online+0x75/0xe0
      [  207.272874]        [<ffffffff813474a0>] dev_attr_store+0x20/0x30
      [  207.272886]        [<ffffffff812090d9>] sysfs_write_file+0xd9/0x150
      [  207.272900]        [<ffffffff8118e10b>] vfs_write+0xcb/0x130
      [  207.272911]        [<ffffffff8118e924>] sys_write+0x64/0xa0
      [  207.272923]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b
      [  207.272936]
      [  207.272936] other info that might help us debug this:
      [  207.272936]
      [  207.272952] Chain exists of:
      [  207.272952]   subsys mutex --> &mm->mmap_sem --> cpu_hotplug.lock
      [  207.272952]
      [  207.272973]  Possible unsafe locking scenario:
      [  207.272973]
      [  207.272984]        CPU0                    CPU1
      [  207.272992]        ----                    ----
      [  207.273000]   lock(cpu_hotplug.lock);
      [  207.273009]                                lock(&mm->mmap_sem);
      [  207.273020]                                lock(cpu_hotplug.lock);
      [  207.273031]   lock(subsys mutex);
      [  207.273040]
      [  207.273040]  *** DEADLOCK ***
      [  207.273040]
      [  207.273055] 5 locks held by bash/10493:
      [  207.273062]  #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff81209049>] sysfs_write_file+0x49/0x150
      [  207.273080]  #1:  (s_active#150){.+.+.+}, at: [<ffffffff812090c2>] sysfs_write_file+0xc2/0x150
      [  207.273099]  #2:  (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff81027557>] cpu_hotplug_driver_lock+0x17/0x20
      [  207.273121]  #3:  (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff8149911c>] cpu_down+0x2c/0x60
      [  207.273140]  #4:  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81046ccf>] cpu_hotplug_begin+0x2f/0x60
      [  207.273158]
      [  207.273158] stack backtrace:
      [  207.273170] Pid: 10493, comm: bash Not tainted 3.9.0-rc1-0.7-default+ #34
      [  207.273180] Call Trace:
      [  207.273192]  [<ffffffff810ab373>] print_circular_bug+0x223/0x310
      [  207.273204]  [<ffffffff810ae002>] __lock_acquire+0x13b2/0x15f0
      [  207.273216]  [<ffffffff812086b0>] ? sysfs_hash_and_remove+0x60/0xc0
      [  207.273227]  [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.273239]  [<ffffffff8134af27>] ? bus_remove_device+0x37/0x1c0
      [  207.273251]  [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360
      [  207.273263]  [<ffffffff8134af27>] ? bus_remove_device+0x37/0x1c0
      [  207.273274]  [<ffffffff812086b0>] ? sysfs_hash_and_remove+0x60/0xc0
      [  207.273286]  [<ffffffff8134af27>] bus_remove_device+0x37/0x1c0
      [  207.273298]  [<ffffffff81349114>] device_del+0x134/0x1f0
      [  207.273309]  [<ffffffff813491f2>] device_unregister+0x22/0x60
      [  207.273321]  [<ffffffff814a24ea>] mce_cpu_callback+0x15e/0x1ad
      [  207.273332]  [<ffffffff814b6402>] notifier_call_chain+0x72/0x130
      [  207.273344]  [<ffffffff81073d6e>] __raw_notifier_call_chain+0xe/0x10
      [  207.273356]  [<ffffffff81498f76>] _cpu_down+0x1d6/0x350
      [  207.273368]  [<ffffffff81027557>] ? cpu_hotplug_driver_lock+0x17/0x20
      [  207.273380]  [<ffffffff81499130>] cpu_down+0x40/0x60
      [  207.273391]  [<ffffffff8149cc55>] store_online+0x75/0xe0
      [  207.273402]  [<ffffffff813474a0>] dev_attr_store+0x20/0x30
      [  207.273413]  [<ffffffff812090d9>] sysfs_write_file+0xd9/0x150
      [  207.273425]  [<ffffffff8118e10b>] vfs_write+0xcb/0x130
      [  207.273436]  [<ffffffff8118e924>] sys_write+0x64/0xa0
      [  207.273447]  [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b
      
      Which reports a false possitive deadlock because it sees:
      1) load_module -> subsys_interface_register -> mc_deveice_add (*) -> subsys->p->mutex -> link_path_walk -> lookup_slow -> i_mutex
      2) sys_write -> _cpu_down -> cpu_hotplug_begin -> cpu_hotplug.lock -> mce_cpu_callback -> mce_device_remove(**) -> device_unregister -> bus_remove_device -> subsys mutex
      3) vfs_readdir -> i_mutex -> filldir64 -> might_fault -> might_lock_read(mmap_sem) -> page_fault -> mmap_sem -> drain_all_stock -> cpu_hotplug.lock
      
      but
      1) takes cpu_subsys subsys (*) but 2) takes mce_device subsys (**) so
      the deadlock is not possible AFAICS.
      
      The fix is quite simple. We can pull the key inside bus_type structure
      because they are defined per device so the pointer will be unique as
      well. bus_register doesn't need to be a macro anymore so change it
      to the inline. We could get rid of __bus_register as there is no other
      caller but maybe somebody will want to use a different key so keep it
      around for now.
      Reported-by: NLi Zefan <lizefan@huawei.com>
      Signed-off-by: NMichal Hocko <mhocko@suse.cz>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be871b7e
    • T
      driver/base: implement subsys_virtual_register() · d73ce004
      Tejun Heo 提交于
      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: NTejun Heo <tj@kernel.org>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      d73ce004
  8. 26 2月, 2013 1 次提交
  9. 07 2月, 2013 1 次提交
  10. 23 1月, 2013 2 次提交
    • L
      drivers/pinctrl: grab default handles from device core · ab78029e
      Linus Walleij 提交于
      This makes the device core auto-grab the pinctrl handle and set
      the "default" (PINCTRL_STATE_DEFAULT) state for every device
      that is present in the device model right before probe. This will
      account for the lion's share of embedded silicon devcies.
      
      A modification of the semantics for pinctrl_get() is also done:
      previously if the pinctrl handle for a certain device was already
      taken, the pinctrl core would return an error. Now, since the
      core may have already default-grabbed the handle and set its
      state to "default", if the handle was already taken, this will
      be disregarded and the located, previously instanitated handle
      will be returned to the caller.
      
      This way all code in drivers explicitly requesting their pinctrl
      handlers will still be functional, and drivers that want to
      explicitly retrieve and switch their handles can still do that.
      But if the desired functionality is just boilerplate of this
      type in the probe() function:
      
      struct pinctrl  *p;
      
      p = devm_pinctrl_get_select_default(&dev);
      if (IS_ERR(p)) {
         if (PTR_ERR(p) == -EPROBE_DEFER)
              return -EPROBE_DEFER;
              dev_warn(&dev, "no pinctrl handle\n");
      }
      
      The discussion began with the addition of such boilerplate
      to the omap4 keypad driver:
      http://marc.info/?l=linux-input&m=135091157719300&w=2
      
      A previous approach using notifiers was discussed:
      http://marc.info/?l=linux-kernel&m=135263661110528&w=2
      This failed because it could not handle deferred probes.
      
      This patch alone does not solve the entire dilemma faced:
      whether code should be distributed into the drivers or
      if it should be centralized to e.g. a PM domain. But it
      solves the immediate issue of the addition of boilerplate
      to a lot of drivers that just want to grab the default
      state. As mentioned, they can later explicitly retrieve
      the handle and set different states, and this could as
      well be done by e.g. PM domains as it is only related
      to a certain struct device * pointer.
      
      ChangeLog v4->v5 (Stephen):
      - Simplified the devicecore grab code.
      - Deleted a piece of documentation recommending that pins
        be mapped to a device rather than hogged.
      ChangeLog v3->v4 (Linus):
      - Drop overzealous NULL checks.
      - Move kref initialization to pinctrl_create().
      - Seeking Tested-by from Stephen Warren so we do not disturb
        the Tegra platform.
      - Seeking ACK on this from Greg (and others who like it) so I
        can merge it through the pinctrl subsystem.
      ChangeLog v2->v3 (Linus):
      - Abstain from using IS_ERR_OR_NULL() in the driver core,
        Russell recently sent a patch to remove it. Handle the
        NULL case explicitly even though it's a bogus case.
      - Make sure we handle probe deferral correctly in the device
        core file. devm_kfree() the container on error so we don't
        waste memory for devices without pinctrl handles.
      - Introduce reference counting into the pinctrl core using
        <linux/kref.h> so that we don't release pinctrl handles
        that have been obtained for two or more places.
      ChangeLog v1->v2 (Linus):
      - Only store a pointer in the device struct, and only allocate
        this if it's really used by the device.
      
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Mitch Bradley <wmb@firmworks.com>
      Cc: Ulf Hansson <ulf.hansson@linaro.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      Cc: Rickard Andersson <rickard.andersson@stericsson.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      [swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to
      correctly handle deferred probe. Removed admonition from docs not to use
      pinctrl hogs for devices]
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      ab78029e
    • T
      lib: devres: Introduce devm_ioremap_resource() · 75096579
      Thierry Reding 提交于
      The devm_request_and_ioremap() function is very useful and helps avoid a
      whole lot of boilerplate. However, one issue that keeps popping up is
      its lack of a specific error code to determine which of the steps that
      it performs failed. Furthermore, while the function gives an example and
      suggests what error code to return on failure, a wide variety of error
      codes are used throughout the tree.
      
      In an attempt to fix these problems, this patch adds a new function that
      drivers can transition to. The devm_ioremap_resource() returns a pointer
      to the remapped I/O memory on success or an ERR_PTR() encoded error code
      on failure. Callers can check for failure using IS_ERR() and determine
      its cause by extracting the error code using PTR_ERR().
      
      devm_request_and_ioremap() is implemented as a wrapper around the new
      API and return NULL on failure as before. This ensures that backwards
      compatibility is maintained until all users have been converted to the
      new API, at which point the old devm_request_and_ioremap() function
      should be removed.
      
      A semantic patch is included which can be used to convert from the old
      devm_request_and_ioremap() API to the new devm_ioremap_resource() API.
      Some non-trivial cases may require manual intervention, though.
      Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75096579
  11. 21 11月, 2012 1 次提交
  12. 15 11月, 2012 1 次提交
    • M
      driver core / ACPI: Move ACPI support to core device and driver types · 06f64c8f
      Mika Westerberg 提交于
      With ACPI 5 we are starting to see devices that don't natively support
      discovery but can be enumerated with the help of the ACPI namespace.
      Typically, these devices can be represented in the Linux device driver
      model as platform devices or some serial bus devices, like SPI or I2C
      devices.
      
      Since we want to re-use existing drivers for those devices, we need a
      way for drivers to specify the ACPI IDs of supported devices, so that
      they can be matched against device nodes in the ACPI namespace.  To
      this end, it is sufficient to add a pointer to an array of supported
      ACPI device IDs, that can be provided by the driver, to struct device.
      
      Moreover, things like ACPI power management need to have access to
      the ACPI handle of each supported device, because that handle is used
      to invoke AML methods associated with the corresponding ACPI device
      node.  The ACPI handles of devices are now stored in the archdata
      member structure of struct device whose definition depends on the
      architecture and includes the ACPI handle only on x86 and ia64. Since
      the pointer to an array of supported ACPI IDs is added to struct
      device_driver in an architecture-independent way, it is logical to
      move the ACPI handle from archdata to struct device itself at the same
      time.  This also makes code more straightforward in some places and
      follows the example of Device Trees that have a poiter to struct
      device_node in there too.
      
      This changeset is based on Mika Westerberg's work.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      06f64c8f
  13. 26 10月, 2012 1 次提交
  14. 27 9月, 2012 1 次提交
  15. 17 9月, 2012 3 次提交
  16. 11 9月, 2012 1 次提交
  17. 04 9月, 2012 1 次提交
    • R
      PM: Do not use the syscore flag for runtime PM · feb70af0
      Rafael J. Wysocki 提交于
      The syscore device PM flag used to mark the devices (belonging to
      PM domains) that should never be turned off, except for the system
      core (syscore) suspend/hibernation and resume stages, need not be
      accessed by the runtime PM core functions, because all of the devices
      it is set for need to be marked as "irq safe" anyway and are
      protected from being turned off by runtime PM by ensuring that their
      usage counters are always set.
      
      For this reason, make the syscore flag system-wide PM-specific
      and simplify the code used for manipulating it, because it need not
      acquire the device's power.lock any more.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      feb70af0
  18. 17 8月, 2012 1 次提交
  19. 19 7月, 2012 1 次提交
    • L
      Make wait_for_device_probe() also do scsi_complete_async_scans() · eea03c20
      Linus Torvalds 提交于
      Commit a7a20d10 ("sd: limit the scope of the async probe domain")
      make the SCSI device probing run device discovery in it's own async
      domain.
      
      However, as a result, the partition detection was no longer synchronized
      by async_synchronize_full() (which, despite the name, only synchronizes
      the global async space, not all of them).  Which in turn meant that
      "wait_for_device_probe()" would not wait for the SCSI partitions to be
      parsed.
      
      And "wait_for_device_probe()" was what the boot time init code relied on
      for mounting the root filesystem.
      
      Now, most people never noticed this, because not only is it
      timing-dependent, but modern distributions all use initrd.  So the root
      filesystem isn't actually on a disk at all.  And then before they
      actually mount the final disk filesystem, they will have loaded the
      scsi-wait-scan module, which not only does the expected
      wait_for_device_probe(), but also does scsi_complete_async_scans().
      
      [ Side note: scsi_complete_async_scans() had also been partially broken,
        but that was fixed in commit 43a8d39d ("fix async probe
        regression"), so that same commit a7a20d10 had actually broken
        setups even if you used scsi-wait-scan explicitly ]
      
      Solve this problem by just moving the scsi_complete_async_scans() call
      into wait_for_device_probe().  Everybody who wants to wait for device
      probing to finish really wants the SCSI probing to complete, so there's
      no reason not to do this.
      
      So now "wait_for_device_probe()" really does what the name implies, and
      properly waits for device probing to finish.  This also removes the now
      unnecessary extra calls to scsi_complete_async_scans().
      Reported-and-tested-by: NArtem S. Tashkinov <t.artem@mailcity.com>
      Cc: Dan Williams <dan.j.williams@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: James Bottomley <jbottomley@parallels.com>
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: linux-scsi <linux-scsi@vger.kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eea03c20
  20. 17 7月, 2012 1 次提交
  21. 25 6月, 2012 1 次提交
  22. 21 5月, 2012 1 次提交
  23. 15 5月, 2012 1 次提交
    • A
      sysfs: get rid of some lockdep false positives · 356c05d5
      Alan Stern 提交于
      This patch (as1554) fixes a lockdep false-positive report.  The
      problem arises because lockdep is unable to deal with the
      tree-structured locks created by the device core and sysfs.
      
      This particular problem involves a sysfs attribute method that
      unregisters itself, not from the device it was called for, but from a
      descendant device.  Lockdep doesn't understand the distinction and
      reports a possible deadlock, even though the operation is safe.
      
      This is the sort of thing that would normally be handled by using a
      nested lock annotation; unfortunately it's not feasible to do that
      here.  There's no sensible way to tell sysfs when attribute removal
      occurs in the context of a parent attribute method.
      
      As a workaround, the patch adds a new flag to struct attribute
      telling sysfs not to inform lockdep when it acquires a readlock on a
      sysfs_dirent instance for the attribute.  The readlock is still
      acquired, but lockdep doesn't know about it and hence does not
      complain about impossible deadlock scenarios.
      
      Also added are macros for static initialization of attribute
      structures with the ignore_lockdep flag set.  The three offending
      attributes in the USB subsystem are converted to use the new macros.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NTejun Heo <tj@kernel.org>
      CC: Eric W. Biederman <ebiederm@xmission.com>
      CC: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      356c05d5
  24. 14 5月, 2012 1 次提交
  25. 05 5月, 2012 2 次提交
  26. 20 4月, 2012 1 次提交
  27. 19 4月, 2012 1 次提交
  28. 10 3月, 2012 1 次提交
  29. 09 3月, 2012 3 次提交
    • S
      driver-core: remove legacy iSeries hack · fcd6f762
      Stephen Rothwell 提交于
      The PowerPC legacy iSeries plateform is being removed along with the
      "one looney iseries driver", so this code can now be removed as well.
      
      cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      fcd6f762
    • G
      driver core: move the deferred probe pointer into the private area · ef8a3fd6
      Greg Kroah-Hartman 提交于
      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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef8a3fd6
    • 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
  30. 25 1月, 2012 1 次提交