1. 27 1月, 2018 1 次提交
  2. 26 1月, 2018 6 次提交
  3. 07 12月, 2017 1 次提交
  4. 20 7月, 2017 1 次提交
    • T
      regulator: core: fix a possible race in disable_work handling · c9ccaa0c
      Tirupathi Reddy 提交于
      A race condition between queueing and processing the disable_work
      instances results in having a work instance in the queue and the
      deferred_disables variable of regulator device structure having a
      value '0'. If no new regulator_disable_deferred() call later from
      clients, the deferred_disables variable value remains '0' and hits
      BUG() in regulator_disable_work() when the queued instance scheduled
      for processing the work.
      
      The race occurs as below:
      
      	Core-0					     Core-1
      	.....	       /* deferred_disables = 2 */   .....
      	.....	       /* disable_work is queued */  .....
      	.....					     .....
      regulator_disable_deferred: 		regulator_disable_work:
         mutex_lock(&rdev->mutex);			     .....
         rdev->deferred_disables++;		             .....
         mutex_unlock(&rdev->mutex);			     .....
         queue_delayed_work(...)		    mutex_lock(&rdev->mutex);
      	.....				    count =rdev->deferred_disables;
      	.....				    rdev->deferred_disables = 0;
      	.....					     .....
      	.....				    mutex_unlock(&rdev->mutex);
      	.....					     .....
      	.....				    return;
      	.....					     .....
      	/* No new regulator_disable_deferred() calls from clients */
      	/* The newly queued instance is scheduled for processing */
      	.....					     .....
      regulator_disable_work:
      	.....
         mutex_lock(&rdev->mutex);
         BUG_ON(!rdev->deferred_disables); /* deferred_disables = 0 */
      
      The race is fixed by removing the work instance that is queued while
      processing the previous queued instance. Cancel the newly queued instance
      from disable_work() handler just after reset the deferred_disables variable
      to value '0'. Also move the work queueing step before mutex_unlock in
      regulator_disable_deferred().
      
      Also use mod_delayed_work() in the pace of queue_delayed_work() as
      queue_delayed_work() always uses the delay requested in the first call
      when multiple consumers call regulator_disable_deferred() close in time
      and does not guarantee the semantics of regulator_disable_deferred().
      Signed-off-by: NTirupathi Reddy <tirupath@codeaurora.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      c9ccaa0c
  5. 19 7月, 2017 1 次提交
  6. 30 6月, 2017 1 次提交
  7. 29 6月, 2017 1 次提交
  8. 14 6月, 2017 1 次提交
  9. 17 5月, 2017 1 次提交
  10. 15 4月, 2017 2 次提交
  11. 06 4月, 2017 1 次提交
  12. 29 3月, 2017 2 次提交
  13. 25 3月, 2017 1 次提交
  14. 17 3月, 2017 1 次提交
  15. 07 3月, 2017 1 次提交
  16. 17 2月, 2017 1 次提交
    • J
      regulator: core: Resolve supplies before disabling unused regulators · 3827b64d
      Javier Martinez Canillas 提交于
      After commit 66d228a2 ("regulator: core: Don't use regulators as
      supplies until the parent is bound"), input supplies aren't resolved
      if the input supplies parent device has not been bound. This prevent
      regulators to hold an invalid reference if its supply parent device
      driver probe is deferred.
      
      But this causes issues on some boards where a PMIC's regulator use as
      input supply a regulator from another PMIC whose driver is registered
      after the driver for the former.
      
      In this case the regulators for the first PMIC will fail to resolve
      input supplies on regulators registration (since the other PMIC wasn't
      probed yet). And when the core attempts to resolve again latter when
      the other PMIC registers its own regulators, it will fail again since
      the parent device isn't bound yet.
      
      This will cause some parent supplies to never be resolved and wrongly
      be disabled on boot due taking them as unused.
      
      To solve this problem, also attempt to resolve the pending regulators
      input supplies before disabling the unused regulators.
      Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      3827b64d
  17. 16 2月, 2017 1 次提交
  18. 09 2月, 2017 1 次提交
    • D
      regulator: core: simplify _regulator_get() · a4d7641f
      Dmitry Torokhov 提交于
      The code in _regulator_get() got a bit confusing over time, with control
      flow jumping to a label from couple of places. Let's untangle it a bit by
      doing the following:
      
      1. Make handling of missing supplies and substituting them with dummy
      regulators more explicit:
      
      - check if we not have full constraints and refuse considering dummy
        regulators with appropriate message;
      
      - use "switch (get_type)" to handle different types of request explicitly
        as well. "Normal" requests will get dummies, exclusive will not and
        will notify user about that; optional will fail silently.
      
      2. Stop jumping to a label in the middle of the function but instead have
      proper conditional flow. I believe jumps should be reserved for error
      handling, breaking from inner loop, or restarting a loop, but not for
      implementing normal conditional flow.
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      a4d7641f
  19. 06 2月, 2017 1 次提交
  20. 04 2月, 2017 4 次提交
  21. 13 1月, 2017 1 次提交
    • J
      regulator: core: Don't use regulators as supplies until the parent is bound · 66d228a2
      Jon Hunter 提交于
      When regulators are successfully registered, we check to see if the
      regulator is a supply for any other registered regulator and if so
      add the new regulator as the supply for the existing regulator(s).
      
      Some devices, such as Power Management ICs, may register a series of
      regulators when probed and there are cases where one of the regulators
      may fail to register and defer the probing of the parent device. In this
      case any successfully registered regulators would be unregistered so
      that they can be re-registered at some time later when the probe is
      attempted again. However, if one of the regulators that was registered
      was added as a supply to another registered regulator (that did not
      belong to the same parent device), then this supply regulator was
      unregister again because the parent device is probe deferred, then a
      regulator could be holding an invalid reference to a supply regulator
      that has been unregistered. This will lead to a system crash if that
      regulator is then used.
      
      Although it would be possible to check when unregistering a regulator
      if any other regulator in the system is using it as a supply, it still
      may not be possible to remove it as a supply if this other regulator is
      in use. Therefore, fix this by preventing any regulator from adding
      another regulator as a supply if the parent device for the supply
      regulator has not been bound and if the parent device for the supply
      and the regulator are different. This will allow a parent device that is
      registering regulators to be probe deferred and ensure that none of the
      regulators it has registered are used as supplies for any other
      regulator from another device.
      Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      66d228a2
  22. 05 12月, 2016 1 次提交
  23. 01 12月, 2016 1 次提交
  24. 05 11月, 2016 1 次提交
  25. 29 10月, 2016 1 次提交
    • H
      regulator: core: silence warning: "VDD1: ramp_delay not set" · ba14fa1a
      H. Nikolaus Schaller 提交于
      commit 73e705bf ("regulator: core: Add set_voltage_time op")
      
      introduced a new rdev_warn() if the ramp_delay is 0.
      
      Apparently, on omap3/twl4030 platforms with dynamic voltage
      management this results in non-ending spurious messages like
      
      [  511.143066] VDD1: ramp_delay not set
      [  511.662322] VDD1: ramp_delay not set
      [  513.903625] VDD1: ramp_delay not set
      [  514.222198] VDD1: ramp_delay not set
      [  517.062835] VDD1: ramp_delay not set
      [  517.382568] VDD1: ramp_delay not set
      [  520.142791] VDD1: ramp_delay not set
      [  520.502593] VDD1: ramp_delay not set
      [  523.062896] VDD1: ramp_delay not set
      [  523.362701] VDD1: ramp_delay not set
      [  526.143035] VDD1: ramp_delay not set
      
      I have observed this on GTA04 while it is reported to occur on
      N900 as well: https://bugzilla.kernel.org/show_bug.cgi?id=178371
      
      This patch makes the warning appear only in debugging mode.
      Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      ba14fa1a
  26. 25 9月, 2016 1 次提交
    • J
      regulator: core: don't return error with inadequate reason · 57776617
      Joonwoo Park 提交于
      drms_uA_update() always returns failure when it cannot find regulator's
      input voltage.  But if hardware supports load configuration with
      ops->set_load() and the input regulator isn't specified with valid reason
      such as the input regulator is battery, not finding input voltage is
      normal so such case should not return with an error.
      
      Avoid such inadequate error return by checking input/output voltages
      only when drms_uA_update() is about to configure load with enum based
      ops->set_mode().
      
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NJoonwoo Park <joonwoop@codeaurora.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      57776617
  27. 17 9月, 2016 3 次提交
  28. 15 9月, 2016 1 次提交