1. 13 3月, 2013 1 次提交
    • 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
  2. 07 2月, 2013 1 次提交
  3. 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
  4. 21 11月, 2012 1 次提交
  5. 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
  6. 26 10月, 2012 1 次提交
  7. 27 9月, 2012 1 次提交
  8. 17 9月, 2012 3 次提交
  9. 11 9月, 2012 1 次提交
  10. 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
  11. 17 8月, 2012 1 次提交
  12. 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
  13. 17 7月, 2012 1 次提交
  14. 25 6月, 2012 1 次提交
  15. 21 5月, 2012 1 次提交
  16. 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
  17. 14 5月, 2012 1 次提交
  18. 05 5月, 2012 2 次提交
  19. 20 4月, 2012 1 次提交
  20. 19 4月, 2012 1 次提交
  21. 10 3月, 2012 1 次提交
  22. 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
  23. 25 1月, 2012 3 次提交
    • A
      Eliminate get_driver() and put_driver() · 9875bb48
      Alan Stern 提交于
      Now that there are no users of get_driver() or put_driver(), this
      patch (as1513) removes those routines completely.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9875bb48
    • J
      dynamic_debug: make dynamic-debug supersede DEBUG ccflag · b558c96f
      Jim Cromie 提交于
      If CONFIG_DYNAMIC_DEBUG is defined, honor it over DEBUG, so that
      pr_debug()s are controllable, instead of always-on.  When DEBUG is
      also defined, change _DPRINTK_FLAGS_DEFAULT to enable printing by
      default.
      
      Also adding _DPRINTK_FLAGS_INCL_MODNAME would be nice, but there are
      numerous cases of pr_debug(NAME ": ...), which would result in double
      printing of module-name.  So defer this until things settle.
      
      Cc: David Miller <davem@davemloft.net>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: NJim Cromie <jim.cromie@gmail.com>
      Signed-off-by: NJason Baron <jbaron@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b558c96f
    • R
      kernel-doc: fix new warnings in device.h · 1a5e29fc
      Randy Dunlap 提交于
      Fix new kernel-doc warnings:
      
      Warning(include/linux/device.h:299): No description found for parameter 'name'
      Warning(include/linux/device.h:299): No description found for parameter 'subsys'
      Warning(include/linux/device.h:299): No description found for parameter 'node'
      Warning(include/linux/device.h:299): No description found for parameter 'add_dev'
      Warning(include/linux/device.h:299): No description found for parameter 'remove_dev'
      Warning(include/linux/device.h:685): No description found for parameter 'id'
      Warning(include/linux/device.h:1009): No description found for parameter '__driver'
      Warning(include/linux/device.h:1009): No description found for parameter '__register'
      Warning(include/linux/device.h:1009): No description found for parameter '__unregister'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1a5e29fc
  24. 24 1月, 2012 1 次提交
    • R
      kernel-doc: fix new warnings in device.h · 2eda013f
      Randy Dunlap 提交于
      Fix new kernel-doc warnings:
      
      Warning(include/linux/device.h:299): No description found for parameter 'name'
      Warning(include/linux/device.h:299): No description found for parameter 'subsys'
      Warning(include/linux/device.h:299): No description found for parameter 'node'
      Warning(include/linux/device.h:299): No description found for parameter 'add_dev'
      Warning(include/linux/device.h:299): No description found for parameter 'remove_dev'
      Warning(include/linux/device.h:685): No description found for parameter 'id'
      Warning(include/linux/device.h:1009): No description found for parameter '__driver'
      Warning(include/linux/device.h:1009): No description found for parameter '__register'
      Warning(include/linux/device.h:1009): No description found for parameter '__unregister'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2eda013f
  25. 05 1月, 2012 1 次提交
  26. 04 1月, 2012 1 次提交
  27. 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
  28. 18 11月, 2011 2 次提交
    • R
      PM Sleep: Do not extend wakeup paths to devices with ignore_children set · 8b258cc8
      Rafael J. Wysocki 提交于
      Commit 4ca46ff3 (PM / Sleep: Mark
      devices involved in wakeup signaling during suspend) introduced
      the power.wakeup_path field in struct dev_pm_info to mark devices
      whose children are enabled to wake up the system from sleep states,
      so that power domains containing the parents that provide their
      children with wakeup power and/or relay their wakeup signals are not
      turned off.  Unfortunately, that introduced a PM regression on SH7372
      whose power consumption in the system "memory sleep" state increased
      as a result of it, because it prevented the power domain containing
      the I2C controller from being turned off when some children of that
      controller were enabled to wake up the system, although the
      controller was not necessary for them to signal wakeup.
      
      To fix this issue use the observation that devices whose
      power.ignore_children flag is set for runtime PM should be treated
      analogously during system suspend.  Namely, they shouldn't be
      included in wakeup paths going through their children.  Since the
      SH7372 I2C controller's power.ignore_children flag is set, doing so
      will restore the previous behavior of that SOC.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8b258cc8
    • L
      drivercore: Generalize module_platform_driver · 907d0ed1
      Lars-Peter Clausen 提交于
      This patch generalizes the module_platform_driver macro and introduces a new
      module_driver macro. The module_driver macro takes a driver name, a register
      and a unregister function for this driver type. Using these it construct the
      module init and exit sections which register and unregister the driver. Since
      such init/exit sections are commonly found in drivers this macro can be used
      to eliminate a lot of boilerplate code.
      
      The macro is not intended to be used by driver modules directly, instead it
      should be used to generate bus specific macros for registering drivers like
      the module_platform_driver macro.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Acked-by: NJonathan Cameron <jic23@kernel.org>
      Acked-by: NWolfram Sang <w.sang@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      907d0ed1
  29. 16 11月, 2011 2 次提交
  30. 01 11月, 2011 1 次提交