1. 28 5月, 2014 3 次提交
  2. 29 4月, 2014 1 次提交
    • G
      drivercore: deferral race condition fix · 58b116bc
      Grant Likely 提交于
      When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
      when all modules loaded but some driver still stuck in the deferred list
      and there is a need for external event to kick the deferred queue to probe
      these drivers.
      
      The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
      audio support built as modules and using nfsroot for root filesystem.
      
      The following log fragment shows such sequence when all audio modules
      were loaded but the sound card is not present since the machine driver has
      failed to probe due to missing dependency during it's probe.
      The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
      machine driver:
      
      ...
      [   12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
      [   12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
      [   12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
      [   12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
      [   12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
      [   12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
      [   12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
      [   13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
      [   13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
      [   13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
      [   13.346755] davinci_mcasp_driver_init: LEAVE
      [   13.377446] platform sound.3: Driver davinci_evm requests probe deferral
      [   13.592527] platform sound.3: really_probe: probe_count = 0
      
      In the log the machine driver enters it's probe at 12.719969 (this point it
      has been removed from the deferred lists). McASP driver already executing
      it's probing (since 12.615118).
      The machine driver tries to construct the sound card (12.950839) but did
      not found one of the components so it fails. After this McASP driver
      registers all the ASoC components (the machine driver still in it's probe
      function after it failed to construct the card) and the deferred work is
      prepared at 13.099026 (note that this time the machine driver is not in the
      lists so it is not going to be handled when the work is executing).
      Lastly the machine driver exit from it's probe and the core places it to
      the deferred list but there will be no other driver going to load and the
      deferred queue is not going to be kicked again - till we have external event
      like connecting USB stick, etc.
      
      The proposed solution is to try the deferred queue once more when the last
      driver is asking for deferring and we had drivers loaded while this last
      driver was probing.
      
      This way we can avoid drivers stuck in the deferred queue.
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Reviewed-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Stable <stable@vger.kernel.org> # v3.4+
      58b116bc
  3. 26 4月, 2014 1 次提交
  4. 25 4月, 2014 1 次提交
    • R
      of/irq: do irq resolution in platform_get_irq · 9ec36caf
      Rob Herring 提交于
      Currently we get the following kind of errors if we try to use interrupt
      phandles to irqchips that have not yet initialized:
      
      irq: no irq domain found for /ocp/pinmux@48002030 !
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
      (show_stack+0x14/0x1c)
      (dump_stack+0x6c/0xa0)
      (warn_slowpath_common+0x64/0x84)
      (warn_slowpath_null+0x1c/0x24)
      (of_device_alloc+0x144/0x184)
      (of_platform_device_create_pdata+0x44/0x9c)
      (of_platform_bus_create+0xd0/0x170)
      (of_platform_bus_create+0x12c/0x170)
      (of_platform_populate+0x60/0x98)
      
      This is because we're wrongly trying to populate resources that are not
      yet available. It's perfectly valid to create irqchips dynamically, so
      let's fix up the issue by resolving the interrupt resources when
      platform_get_irq is called.
      
      And then we also need to accept the fact that some irqdomains do not
      exist that early on, and only get initialized later on. So we can
      make the current WARN_ON into just into a pr_debug().
      
      We still attempt to populate irq resources when we create the devices.
      This allows current drivers which don't use platform_get_irq to continue
      to function. Once all drivers are fixed, this code can be removed.
      Suggested-by: NRussell King <linux@arm.linux.org.uk>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Cc: stable@vger.kernel.org # v3.10+
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      9ec36caf
  5. 17 4月, 2014 3 次提交
  6. 07 4月, 2014 1 次提交
  7. 01 4月, 2014 1 次提交
  8. 28 3月, 2014 1 次提交
  9. 27 3月, 2014 2 次提交
  10. 26 3月, 2014 2 次提交
  11. 20 3月, 2014 1 次提交
    • S
      drivers/base/topology.c: Fix CPU hotplug callback registration · e12b7111
      Srivatsa S. Bhat 提交于
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the topology code by using this latter form of callback registration.
      
      Cc: Ingo Molnar <mingo@kernel.org>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e12b7111
  12. 19 3月, 2014 2 次提交
  13. 18 3月, 2014 2 次提交
  14. 14 3月, 2014 1 次提交
  15. 12 3月, 2014 1 次提交
  16. 11 3月, 2014 1 次提交
  17. 10 3月, 2014 1 次提交
  18. 09 3月, 2014 2 次提交
    • X
      numa: fix NULL pointer access and memory leak in unregister_one_node() · 92d585ef
      Xishi Qiu 提交于
      When doing socket hot remove, "node_devices[nid]" is set to NULL;
      acpi_processor_remove()
      	try_offline_node()
      		unregister_one_node()
      
      Then hot add a socket, but do not echo 1 > /sys/devices/system/cpu/cpuXX/online,
      so register_one_node() will not be called, and "node_devices[nid]"
      is still NULL.
      
      If doing socket hot remove again, NULL pointer access will be happen.
      unregister_one_node()
      	unregister_node()
      
      Another, we should free the memory used by "node_devices[nid]" in
      unregister_one_node().
      Signed-off-by: NXishi Qiu <qiuxishi@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      92d585ef
    • R
      Revert "driver core: synchronize device shutdown" · aa0689b3
      Roland Dreier 提交于
      This reverts commit 401097ea.  The
      original changelog said:
      
          A patch series to make .shutdown execute asynchronously.  Some drivers's
          shutdown can take a lot of time.  The patches can help save some shutdown
          time.  The patches use Arjan's async API.
      
          This patch:
      
          synchronize all tasks submitted by .shutdown
      
      However, I'm not able to find any evidence that any other patches from
      this series were applied, nor am I able to find any async tasks that are
      scheduled in a .shutdown context.
      
      On the other hand, we see occasional hangs on shutdown that appear to be
      caused by the async_synchronize_full() in device_shutdown() waiting
      forever for the async probing in sd if a SCSI disk shows up at just the
      wrong time — the system starts the probe, but begins shutting down and
      tears down too much of the SCSI driver to finish the probe.
      
      If we had any async shutdown tasks, I guess the right fix would be to
      create a "shutdown" async domain and have device_shutdown() only wait
      for that domain.  But since there apparently are no async shutdown
      tasks, we can just revert the waiting.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa0689b3
  19. 06 3月, 2014 2 次提交
    • V
      cpufreq: suspend governors on system suspend/hibernate · 2f0aea93
      Viresh Kumar 提交于
      This patch adds cpufreq suspend/resume calls to dpm_{suspend|resume}()
      for handling suspend/resume of cpufreq governors.
      
      Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found an issue where the
      tunables configuration for clusters/sockets with non-boot CPUs was
      lost after system suspend/resume, as we were notifying governors with
      CPUFREQ_GOV_POLICY_EXIT on removal of the last CPU for that policy
      which caused the tunables memory to be freed.
      
      This is fixed by preventing any governor operations from being
      carried out between the device suspend and device resume stages of
      system suspend and resume, respectively.
      
      We could have added these callbacks at dpm_{suspend|resume}_noirq()
      level, but there is an additional problem that the majority of I/O
      devices is already suspended at that point and if cpufreq drivers
      want to change the frequency before suspending, then that not be
      possible on some platforms (which depend on peripherals like i2c,
      regulators, etc).
      Reported-and-tested-by: NLan Tianyu <tianyu.lan@intel.com>
      Reported-by: NJinhyuk Choi <jinchoi@broadcom.com>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      [rjw: Changelog]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2f0aea93
    • N
      regmap: add regmap_parse_val api · 13ff50c8
      Nenghua Cao 提交于
          In some cases, we need regmap's format parse_val function
      to do be/le translation according to the bus configuration.
      For example, snd_soc_bytes_put() uses regmap to write/read values,
      and use cpu_to_be() directly to covert MASK into big endian. This
      is a defect, and should use regmap's format function to do it according
      to bus configuration.
      Signed-off-by: NNenghua Cao <nhcao@marvell.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      13ff50c8
  20. 02 3月, 2014 2 次提交
    • U
      PM: Add pm_runtime_suspend|resume_force functions · 37f20416
      Ulf Hansson 提交于
      This patch provides two new runtime PM helper functions which intend to
      be used from system suspend/resume callbacks, to make sure devices are
      put into low power state during system suspend and brought back to full
      power at system resume.
      
      The prerequisite is to have all levels of a device's runtime PM
      callbacks to be defined through the SET_PM_RUNTIME_PM_OPS macro, which
      means these are available for CONFIG_PM.
      
      By using the new runtime PM helper functions especially the two
      scenarios below will be addressed.
      
      1) The PM core prevents .runtime_suspend callbacks from being invoked
      during system suspend. That means even for a runtime PM centric
      subsystem and driver, the device needs to be put into low power state
      from a system suspend callback. Otherwise it may very well be left in
      full power state (runtime resumed) while the system is suspended. By
      using the new helper functions, we make sure to walk the hierarchy of
      a device's power domain, subsystem and driver.
      
      2) Subsystems and drivers need to cope with all the combinations of
      CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME. The two new helper functions
      smothly addresses this.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      37f20416
    • U
      PM / runtime: Fetch runtime PM callbacks using a macro · 5f59df79
      Ulf Hansson 提交于
      While fetching the proper runtime PM callback, we walk the hierarchy of
      device's power domains, subsystems and drivers.
      
      This is common for rpm_suspend(), rpm_idle() and rpm_resume(). Let's
      clean up the code by using a macro that handles this.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5f59df79
  21. 01 3月, 2014 1 次提交
  22. 26 2月, 2014 4 次提交
  23. 22 2月, 2014 2 次提交
  24. 20 2月, 2014 2 次提交