Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 12月, 2022 1 次提交
    • J
      regulator: core: fix deadlock on regulator enable · cb3543cf
      由 Johan Hovold 提交于 
      When updating the operating mode as part of regulator enable, the caller
has already locked the regulator tree and drms_uA_update() must not try
to do the same in order not to trigger a deadlock.

The lock inversion is reported by lockdep as:

  ======================================================
  WARNING: possible circular locking dependency detected
  6.1.0-next-20221215 #142 Not tainted
  ------------------------------------------------------
  udevd/154 is trying to acquire lock:
  ffffc11f123d7e50 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x280

  but task is already holding lock:
  ffff80000e4c36e8 (regulator_ww_class_acquire){+.+.}-{0:0}, at: regulator_enable+0x34/0x80

  which lock already depends on the new lock.

  ...

   Possible unsafe locking scenario:

         CPU0                    CPU1
         ----                    ----
    lock(regulator_ww_class_acquire);
                                 lock(regulator_list_mutex);
                                 lock(regulator_ww_class_acquire);
    lock(regulator_list_mutex);

   *** DEADLOCK ***

just before probe of a Qualcomm UFS controller (occasionally) deadlocks
when enabling one of its regulators.

Fixes: 9243a195 ("regulator: core: Change voltage setting path")
Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking")
Cc: stable@vger.kernel.org      # 5.0
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20221215104646.19818-1-johan+linaro@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>
      cb3543cf
  3. 14 12月, 2022 1 次提交
  5. 08 12月, 2022 1 次提交
  7. 07 12月, 2022 1 次提交
  9. 02 12月, 2022 3 次提交
  11. 01 12月, 2022 1 次提交
    • R
      regulator: core: fix use_count leakage when handling boot-on · 0591b14c
      由 Rui Zhang 提交于 
      I found a use_count leakage towards supply regulator of rdev with
boot-on option.

┌───────────────────┐           ┌───────────────────┐
│  regulator_dev A  │           │  regulator_dev B  │
│     (boot-on)     │           │     (boot-on)     │
│    use_count=0    │◀──supply──│    use_count=1    │
│                   │           │                   │
└───────────────────┘           └───────────────────┘

In case of rdev(A) configured with `regulator-boot-on', the use_count
of supplying regulator(B) will increment inside
regulator_enable(rdev->supply).

Thus, B will acts like always-on, and further balanced
regulator_enable/disable cannot actually disable it anymore.

However, B was also configured with `regulator-boot-on', we wish it
could be disabled afterwards.
Signed-off-by: NRui Zhang <zr.zhang@vivo.com>
Link: https://lore.kernel.org/r/20221201033806.2567812-1-zr.zhang@vivo.comSigned-off-by: NMark Brown <broonie@kernel.org>
      0591b14c
  13. 28 11月, 2022 2 次提交
  15. 25 11月, 2022 1 次提交
    • J
      regulator: Drop obsolete dependencies on COMPILE_TEST · c4b02c92
      由 Jean Delvare 提交于 
      Since commit 0166dc11 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.

It is actually better to always build such drivers with OF enabled,
so that the test builds are closer to how each driver will actually be
built on its intended target. Building them without OF may not test
much as the compiler will optimize out potentially large parts of the
code. In the worst case, this could even pop false positive warnings.
Dropping COMPILE_TEST here improves the quality of our testing and
avoids wasting time on non-existent issues.

As a minor optimization, this also lets us drop several occurrences of
of_match_ptr(), __maybe_unused and some ifdef guarding, as we now know
what all of this will resolve to, we might as well save cpp some work.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Icenowy Zheng <icenowy@aosc.io>
Link: https://lore.kernel.org/r/20221124144708.64371b98@endymion.delvareSigned-off-by: NMark Brown <broonie@kernel.org>
      c4b02c92
  17. 24 11月, 2022 6 次提交
  19. 23 11月, 2022 23 次提交