1. 10 Aug, 2020 1 commit
  2. 04 Aug, 2020 1 commit
  3. 30 Jul, 2020 1 commit
  4. 28 Jul, 2020 1 commit
  5. 27 Jul, 2020 2 commits
  6. 24 Jul, 2020 1 commit
    • Vladimir Zapolskiy's avatar
      regulator: fix memory leak on error path of regulator_register() · 9177514c
      Vladimir Zapolskiy authored
      The change corrects registration and deregistration on error path
      of a regulator, the problem was manifested by a reported memory
      leak on deferred probe:
      
          as3722-regulator as3722-regulator: regulator 13 register failed -517
      
          # cat /sys/kernel/debug/kmemleak
          unreferenced object 0xecc43740 (size 64):
            comm "swapper/0", pid 1, jiffies 4294937640 (age 712.880s)
            hex dump (first 32 bytes):
              72 65 67 75 6c 61 74 6f 72 2e 32 34 00 5a 5a 5a  regulator.24.ZZZ
              5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
            backtrace:
              [<0c4c3d1c>] __kmalloc_track_caller+0x15c/0x2c0
              [<40c0ad48>] kvasprintf+0x64/0xd4
              [<109abd29>] kvasprintf_const+0x70/0x84
              [<c4215946>] kobject_set_name_vargs+0x34/0xa8
              [<62282ea2>] dev_set_name+0x40/0x64
              [<a39b6757>] regulator_register+0x3a4/0x1344
              [<16a9543f>] devm_regulator_register+0x4c/0x84
              [<51a4c6a1>] as3722_regulator_probe+0x294/0x754
              ...
      
      The memory leak problem was introduced as a side ef another fix in
      regulator_register() error path, I believe that the proper fix is
      to decouple device_register() function into its two compounds and
      initialize a struct device before assigning any values to its fields
      and then using it before actual registration of a device happens.
      
      This lets to call put_device() safely after initialization, and, since
      now a release callback is called, kfree(rdev->constraints) shall be
      removed to exclude a double free condition.
      
      Fixes: a3cde953 ("regulator: core: fix regulator_register() error paths to properly release rdev")
      Signed-off-by: default avatarVladimir Zapolskiy <vz@mleia.com>
      Cc: Wen Yang <wenyang@linux.alibaba.com>
      Link: https://lore.kernel.org/r/20200724005013.23278-1-vz@mleia.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      9177514c
  7. 22 Jul, 2020 1 commit
  8. 21 Jul, 2020 1 commit
  9. 20 Jul, 2020 3 commits
    • Mark Brown's avatar
      Merge series "regulator_sync_state() support" from Saravana Kannan <saravanak@google.com>: · f70e472d
      Mark Brown authored
      Consider the following example:
      - regulator-X is provided by device-X.
      - regulator-X is a supplier to device-A, device-B and device-C.
      - device-A is off/inactive from boot.
      - device-B and device-C are left on/active by the bootloader
      - regulator-X is left on boot by the bootloader at 2000 mV to supply
        device-B and device-C.
      
      Example boot sequence 1:
      1. device-X is probed successfully.
      2. device-A is probed by driver-A
         a. driver-A gets regulator-X
         b. driver-A votes on regulator-X
         c. driver-A initializes device-A
         d. driver-A votes off regulator-X
         e. regulator-X is turned off.
      3. System crashes or device-B and device-C become unreliable because
         regulator-X was turned off without following the proper quiescing
         steps for device-B and device-C.
      
      Example boot sequence 2:
      1. device-X is probed successfully.
      2. device-B is probed by driver-B
         a. driver-B gets regulator-X
         b. driver-B votes on regulator-X
         c. driver-B lowers device-B performance point.
         d. driver-B lowers voltage vote to 1000 mV.
         e. regulator-X voltage is lowered to 1000 mV.
      3. System crashes or device-C becomes unreliable because regulator-X
         voltage was lowered to 1000 mV when device-C still needed it at 2000 mV
      
      This patch series makes sure these examples are handled correctly and
      system crash or device instability is avoided and the system remains
      usable.
      
      More details provided in the commit texts.
      
      v2->v3:
      Patch 2/4 - No functional change. Simple refactor.
      Patch 3/4
      - Was Patch 2/2 in v2.
      - Rewrote commit text to hopefully address all previous points.
      - Renamed variable/functions. Hope it's clearer.
      - Added more comments.
      - Added logging
      - Fixed timeout functionality.
      - Handle exclusive consumers properly
      - Handle coupled regulators properly
      Patch 4/4 - Prevents voltage from going too low during boot.
      
      v1->v2:
      Patch 1/2
      - New patch
      Patch 2/2
      - This was the only patch in v1
      - Made the late_initcall_sync timeout a commandline param
      - If timeout is set, we also give up waiting for all consumers after
        the timeout expires.
      - Made every regulator driver add sync_state() support
      
      Saravana Kannan (4):
        driver core: Add dev_set_drv_sync_state()
        regulator: core: Add destroy_regulator()
        regulator: core: Add basic enable/disable support for sync_state()
          callbacks
        regulator: core: Add voltage support for sync_state() callbacks
      
       drivers/regulator/core.c         | 200 ++++++++++++++++++++++++++++---
       include/linux/device.h           |  12 ++
       include/linux/regulator/driver.h |   2 +
       3 files changed, 198 insertions(+), 16 deletions(-)
      
      --
      2.28.0.rc0.105.gf9edc3c819-goog
      f70e472d
    • Chen-Yu Tsai's avatar
      regulator: gpio: Honor regulator-boot-on property · 3acff11c
      Chen-Yu Tsai authored
      When requesting the enable GPIO, the driver should do so with the
      correct output level matching some expected state. This is especially
      important if the regulator is a critical one, such as a supply for
      the boot CPU. This is currently done by checking for the enable-at-boot
      property, but this is not documented in the device tree binding, nor
      does it match the common regulator properties.
      
      Honor the common regulator-boot-on property by checking the boot_on
      constraint setting within the DT probe path. This is the same as what
      is done in the fixed regulator driver.
      
      Also add a comment stating that the enable-at-boot property should not
      be used.
      
      Fixes: 006694d0 ("regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT")
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Link: https://lore.kernel.org/r/20200720132809.26908-1-wens@kernel.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      3acff11c
    • Saravana Kannan's avatar
      regulator: core: Add destroy_regulator() · e1794aa4
      Saravana Kannan authored
      Part of the regulator_get() code is already factored out into
      create_regulator(). This patch factors out some of the regulator_put()
      code into destroy_regulator() so that create_regulator() has a
      corresponding unwind function. Subsequent patches will use this
      function.
      Signed-off-by: default avatarSaravana Kannan <saravanak@google.com>
      Link: https://lore.kernel.org/r/20200716042053.1927676-3-saravanak@google.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      e1794aa4
  10. 16 Jul, 2020 1 commit
  11. 15 Jul, 2020 3 commits
  12. 13 Jul, 2020 1 commit
  13. 08 Jul, 2020 3 commits
  14. 07 Jul, 2020 1 commit
  15. 06 Jul, 2020 4 commits
  16. 03 Jul, 2020 2 commits
  17. 02 Jul, 2020 13 commits