1. 11 Apr, 2023 1 commit
  2. 06 Apr, 2023 4 commits
    • Bartosz Golaszewski's avatar
      regulator: qcom,rpmh: add compatible for pmm8654au RPMH · ba0887a6
      Bartosz Golaszewski authored
      Add the compatible for the pmm8654au RPMH regulators present on the
      sa8775p-ride development board.
      Signed-off-by: default avatarBartosz Golaszewski <bartosz.golaszewski@linaro.org>
      Link: https://lore.kernel.org/r/20230406192811.460888-2-brgl@bgdev.plSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      ba0887a6
    • Bartosz Golaszewski's avatar
      regulator: qcom-rpmh: add support for pmm8654au regulators · 65f1b1dc
      Bartosz Golaszewski authored
      Add the RPMH regulators exposed by the PMM8654au PMIC and its variants.
      Signed-off-by: default avatarBartosz Golaszewski <bartosz.golaszewski@linaro.org>
      Reviewed-by: default avatarKonrad Dybcio <konrad.dybcio@linaro.org>
      Link: https://lore.kernel.org/r/20230406192811.460888-3-brgl@bgdev.plSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      65f1b1dc
    • Douglas Anderson's avatar
      regulator: core: Avoid lockdep reports when resolving supplies · cba6cfdc
      Douglas Anderson authored
      An automated bot told me that there was a potential lockdep problem
      with regulators. This was on the chromeos-5.15 kernel, but I see
      nothing that would be different downstream compared to upstream. The
      bot said:
        ============================================
        WARNING: possible recursive locking detected
        5.15.104-lockdep-17461-gc1e499ed6604 #1 Not tainted
        --------------------------------------------
        kworker/u16:4/115 is trying to acquire lock:
        ffffff8083110170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: create_regulator+0x398/0x7ec
      
        but task is already holding lock:
        ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8
      
        other info that might help us debug this:
         Possible unsafe locking scenario:
      
               CPU0
               ----
          lock(regulator_ww_class_mutex);
          lock(regulator_ww_class_mutex);
      
         *** DEADLOCK ***
      
         May be due to missing lock nesting notation
      
        4 locks held by kworker/u16:4/115:
         #0: ffffff808006a948 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x520/0x1348
         #1: ffffffc00e0a7cc0 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x55c/0x1348
         #2: ffffff80828a2260 (&dev->mutex){....}-{3:3}, at: __device_attach_async_helper+0xd0/0x2a4
         #3: ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8
      
        stack backtrace:
        CPU: 2 PID: 115 Comm: kworker/u16:4 Not tainted 5.15.104-lockdep-17461-gc1e499ed6604 #1 9292e52fa83c0e23762b2b3aa1bacf5787a4d5da
        Hardware name: Google Quackingstick (rev0+) (DT)
        Workqueue: events_unbound async_run_entry_fn
        Call trace:
         dump_backtrace+0x0/0x4ec
         show_stack+0x34/0x50
         dump_stack_lvl+0xdc/0x11c
         dump_stack+0x1c/0x48
         __lock_acquire+0x16d4/0x6c74
         lock_acquire+0x208/0x750
         __mutex_lock_common+0x11c/0x11f8
         ww_mutex_lock+0xc0/0x440
         create_regulator+0x398/0x7ec
         regulator_resolve_supply+0x654/0x7c4
         regulator_register_resolve_supply+0x30/0x120
         class_for_each_device+0x1b8/0x230
         regulator_register+0x17a4/0x1f40
         devm_regulator_register+0x60/0xd0
         reg_fixed_voltage_probe+0x728/0xaec
         platform_probe+0x150/0x1c8
         really_probe+0x274/0xa20
         __driver_probe_device+0x1dc/0x3f4
         driver_probe_device+0x78/0x1c0
         __device_attach_driver+0x1ac/0x2c8
         bus_for_each_drv+0x11c/0x190
         __device_attach_async_helper+0x1e4/0x2a4
         async_run_entry_fn+0xa0/0x3ac
         process_one_work+0x638/0x1348
         worker_thread+0x4a8/0x9c4
         kthread+0x2e4/0x3a0
         ret_from_fork+0x10/0x20
      
      The problem was first reported soon after we made many of the
      regulators probe asynchronously, though nothing I've seen implies that
      the problems couldn't have also happened even without that.
      
      I haven't personally been able to reproduce the lockdep issue, but the
      issue does look somewhat legitimate. Specifically, it looks like in
      regulator_resolve_supply() we are holding a "rdev" lock while calling
      set_supply() -> create_regulator() which grabs the lock of a
      _different_ "rdev" (the one for our supply). This is not necessarily
      safe from a lockdep perspective since there is no documented ordering
      between these two locks.
      
      In reality, we should always be locking a regulator before the
      supplying regulator, so I don't expect there to be any real deadlocks
      in practice. However, the regulator framework in general doesn't
      express this to lockdep.
      
      Let's fix the issue by simply grabbing the two locks involved in the
      same way we grab multiple locks elsewhere in the regulator framework:
      using the "wound/wait" mechanisms.
      
      Fixes: eaa7995c ("regulator: core: avoid regulator_resolve_supply() race condition")
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20230329143317.RFC.v2.2.I30d8e1ca10cfbe5403884cdd192253a2e063eb9e@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      cba6cfdc
    • Douglas Anderson's avatar
      regulator: core: Consistently set mutex_owner when using ww_mutex_lock_slow() · b83a1772
      Douglas Anderson authored
      When a codepath locks a rdev using ww_mutex_lock_slow() directly then
      that codepath is responsible for incrementing the "ref_cnt" and also
      setting the "mutex_owner" to "current".
      
      The regulator core consistently got that right for "ref_cnt" but
      didn't always get it right for "mutex_owner". Let's fix this.
      
      It's unlikely that this truly matters because the "mutex_owner" is
      only needed if we're going to do subsequent locking of the same
      rdev. However, even though it's not truly needed it seems less
      surprising if we consistently set "mutex_owner" properly.
      
      Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking")
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20230329143317.RFC.v2.1.I4e9d433ea26360c06dd1381d091c82bb1a4ce843@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      b83a1772
  3. 03 Apr, 2023 1 commit
  4. 29 Mar, 2023 2 commits
  5. 28 Mar, 2023 1 commit
  6. 24 Mar, 2023 1 commit
  7. 23 Mar, 2023 4 commits
  8. 20 Mar, 2023 9 commits
    • Mark Brown's avatar
      regulator: Set PROBE_PREFER_ASYNCHRONOUS for · 02ce28bc
      Mark Brown authored
      Merge series from Douglas Anderson <dianders@chromium.org>:
      
      This series directly follows from the discussion when I tried to turn
      on PROBE_PREFER_ASYNCHRONOUS just for the fixed-regulator [1] and
      attempts to switch everything in drivers/regulator over to async
      probe.
      
      Like the similar patch series I did for the MMC subsystem a few years
      ago [2], I've split this patch series into batches corresponding to
      drivers corresponding to actively maintained stable kernel trees with
      the idea to break the patch series up somewhat.
      
      Most of the description of this series is contained in the first patch
      of the series and then the further patches simply refer back to the
      first one. The logic and reasoning behind all the patches is exactly
      the same.
      
      As talked about in the first patch, it wouldn't be at all shocking if
      this broke someone. Hopefully this doesn't cause too much of a
      problem. Most of the problems expected would be real underlying bugs
      that already existed and were just tickled by this change. If you're
      facing a problem, it's fairly easy to force individual drivers back to
      "synchronous" probing while the problem is tracked down and fixed.
      
      I am opting _not_ to CC every single person involved in each of these
      regulators on this patch series because I suspect that the mailing
      lists couldn't handle CCing that many people. This should be on LKML
      so hopefully people can find it there and respond to it that
      way. Anyone who responds will get CCed on future versions, if there
      are any.
      
      For reference, the ugly script I used is here:
        import os
        import re
      
        for filename in os.listdir("."):
            found_subsys = False
            found_driver = False
            output = []
            for line in open(filename, "r").readlines():
                if "struct platform_driver" in line or \
                   "struct i2c_driver" in line or \
                   "struct spmi_driver" in line or \
                   "struct spi_driver" in line:
                    found_subsys = True
                if found_subsys and re.search(r"\t\.driver\s*=\s*{", line):
                    found_driver = True
                    found_subsys = False
                mo = re.search(r"(\s*)\.name(\s*)=", line)
                if found_driver and mo:
                    if not line.endswith(",\n"):
                        line = line[:-1] + ",\n"
                    output.append(line)
      
                    if mo.group(2) == " ":
                        space = " "
                    elif mo.group(2) == "\t":
                        # Best we can do
                        space = " "
                    elif mo.group(2).startswith("\t"):
                        # Guess that removing one tab is right
                        space = mo.group(2)[1:]
                    else:
                        # Guess it's all spaces
                        space = mo.group(2)[7:] + " "
      
                    output.append("%s.probe_type%s= PROBE_PREFER_ASYNCHRONOUS,\n" % (mo.group(1), space))
                    found_driver = False
                else:
                    output.append(line)
      
            open(filename, "w").write("".join(output))
      
      I manually split drivers up into groups based on the kernel they were
      introduced in.
      
      I've run a compile test against "allyesconfig" on amd64, arm32, and
      arm64 with this and confirmed it compiled. I've booted this on a
      sc7180-trogdor-lazor board and confirmed it booted OK and got the boot
      speed improvements I expected and that dmesg was as expected.
      
      [1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk
      [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/
      
      Douglas Anderson (7):
        regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in
          4.14
        regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.14 and
          4.19
        regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.19 and
          5.4
        regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.4 and
          5.10
        regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.10 and
          5.15
        regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.15 and
          6.1
        regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that are newer
          than 6.1
      
       drivers/regulator/88pg86x.c                    | 1 +
       drivers/regulator/88pm800-regulator.c          | 1 +
       drivers/regulator/88pm8607.c                   | 1 +
       drivers/regulator/aat2870-regulator.c          | 1 +
       drivers/regulator/ab8500-ext.c                 | 1 +
       drivers/regulator/ab8500.c                     | 1 +
       drivers/regulator/act8865-regulator.c          | 1 +
       drivers/regulator/act8945a-regulator.c         | 1 +
       drivers/regulator/ad5398.c                     | 1 +
       drivers/regulator/anatop-regulator.c           | 1 +
       drivers/regulator/arizona-ldo1.c               | 2 ++
       drivers/regulator/arizona-micsupp.c            | 2 ++
       drivers/regulator/as3711-regulator.c           | 1 +
       drivers/regulator/as3722-regulator.c           | 1 +
       drivers/regulator/atc260x-regulator.c          | 1 +
       drivers/regulator/axp20x-regulator.c           | 1 +
       drivers/regulator/bcm590xx-regulator.c         | 1 +
       drivers/regulator/bd71815-regulator.c          | 1 +
       drivers/regulator/bd71828-regulator.c          | 3 ++-
       drivers/regulator/bd718x7-regulator.c          | 1 +
       drivers/regulator/bd9571mwv-regulator.c        | 1 +
       drivers/regulator/bd9576-regulator.c           | 1 +
       drivers/regulator/cpcap-regulator.c            | 1 +
       drivers/regulator/cros-ec-regulator.c          | 1 +
       drivers/regulator/da903x-regulator.c           | 1 +
       drivers/regulator/da9052-regulator.c           | 1 +
       drivers/regulator/da9055-regulator.c           | 1 +
       drivers/regulator/da9062-regulator.c           | 1 +
       drivers/regulator/da9063-regulator.c           | 1 +
       drivers/regulator/da9121-regulator.c           | 1 +
       drivers/regulator/da9210-regulator.c           | 1 +
       drivers/regulator/da9211-regulator.c           | 1 +
       drivers/regulator/db8500-prcmu.c               | 1 +
       drivers/regulator/dummy.c                      | 1 +
       drivers/regulator/fan53555.c                   | 1 +
       drivers/regulator/fan53880.c                   | 1 +
       drivers/regulator/fixed.c                      | 1 +
       drivers/regulator/gpio-regulator.c             | 1 +
       drivers/regulator/hi6421-regulator.c           | 1 +
       drivers/regulator/hi6421v530-regulator.c       | 1 +
       drivers/regulator/hi6421v600-regulator.c       | 1 +
       drivers/regulator/hi655x-regulator.c           | 1 +
       drivers/regulator/isl6271a-regulator.c         | 1 +
       drivers/regulator/isl9305.c                    | 1 +
       drivers/regulator/lm363x-regulator.c           | 1 +
       drivers/regulator/lochnagar-regulator.c        | 1 +
       drivers/regulator/lp3971.c                     | 1 +
       drivers/regulator/lp3972.c                     | 1 +
       drivers/regulator/lp872x.c                     | 1 +
       drivers/regulator/lp873x-regulator.c           | 1 +
       drivers/regulator/lp8755.c                     | 1 +
       drivers/regulator/lp87565-regulator.c          | 1 +
       drivers/regulator/lp8788-buck.c                | 1 +
       drivers/regulator/lp8788-ldo.c                 | 2 ++
       drivers/regulator/ltc3589.c                    | 1 +
       drivers/regulator/ltc3676.c                    | 1 +
       drivers/regulator/max14577-regulator.c         | 1 +
       drivers/regulator/max1586.c                    | 1 +
       drivers/regulator/max20086-regulator.c         | 1 +
       drivers/regulator/max20411-regulator.c         | 1 +
       drivers/regulator/max597x-regulator.c          | 1 +
       drivers/regulator/max77620-regulator.c         | 1 +
       drivers/regulator/max77650-regulator.c         | 1 +
       drivers/regulator/max77686-regulator.c         | 1 +
       drivers/regulator/max77693-regulator.c         | 1 +
       drivers/regulator/max77802-regulator.c         | 1 +
       drivers/regulator/max77826-regulator.c         | 1 +
       drivers/regulator/max8649.c                    | 1 +
       drivers/regulator/max8660.c                    | 1 +
       drivers/regulator/max8893.c                    | 1 +
       drivers/regulator/max8907-regulator.c          | 1 +
       drivers/regulator/max8925-regulator.c          | 1 +
       drivers/regulator/max8952.c                    | 1 +
       drivers/regulator/max8973-regulator.c          | 1 +
       drivers/regulator/max8997-regulator.c          | 1 +
       drivers/regulator/max8998.c                    | 1 +
       drivers/regulator/mc13783-regulator.c          | 1 +
       drivers/regulator/mc13892-regulator.c          | 1 +
       drivers/regulator/mcp16502.c                   | 1 +
       drivers/regulator/mp5416.c                     | 1 +
       drivers/regulator/mp8859.c                     | 1 +
       drivers/regulator/mp886x.c                     | 1 +
       drivers/regulator/mpq7920.c                    | 1 +
       drivers/regulator/mt6311-regulator.c           | 1 +
       drivers/regulator/mt6315-regulator.c           | 1 +
       drivers/regulator/mt6323-regulator.c           | 1 +
       drivers/regulator/mt6331-regulator.c           | 1 +
       drivers/regulator/mt6332-regulator.c           | 1 +
       drivers/regulator/mt6357-regulator.c           | 1 +
       drivers/regulator/mt6358-regulator.c           | 1 +
       drivers/regulator/mt6359-regulator.c           | 1 +
       drivers/regulator/mt6360-regulator.c           | 1 +
       drivers/regulator/mt6370-regulator.c           | 1 +
       drivers/regulator/mt6380-regulator.c           | 1 +
       drivers/regulator/mt6397-regulator.c           | 1 +
       drivers/regulator/mtk-dvfsrc-regulator.c       | 1 +
       drivers/regulator/palmas-regulator.c           | 1 +
       drivers/regulator/pbias-regulator.c            | 1 +
       drivers/regulator/pca9450-regulator.c          | 1 +
       drivers/regulator/pcap-regulator.c             | 1 +
       drivers/regulator/pcf50633-regulator.c         | 1 +
       drivers/regulator/pf8x00-regulator.c           | 1 +
       drivers/regulator/pfuze100-regulator.c         | 1 +
       drivers/regulator/pv88060-regulator.c          | 1 +
       drivers/regulator/pv88080-regulator.c          | 1 +
       drivers/regulator/pv88090-regulator.c          | 1 +
       drivers/regulator/pwm-regulator.c              | 1 +
       drivers/regulator/qcom-labibb-regulator.c      | 1 +
       drivers/regulator/qcom-rpmh-regulator.c        | 1 +
       drivers/regulator/qcom_rpm-regulator.c         | 1 +
       drivers/regulator/qcom_smd-regulator.c         | 1 +
       drivers/regulator/qcom_spmi-regulator.c        | 1 +
       drivers/regulator/qcom_usb_vbus-regulator.c    | 1 +
       drivers/regulator/rc5t583-regulator.c          | 1 +
       drivers/regulator/rk808-regulator.c            | 3 ++-
       drivers/regulator/rn5t618-regulator.c          | 1 +
       drivers/regulator/rpi-panel-attiny-regulator.c | 1 +
       drivers/regulator/rt4801-regulator.c           | 1 +
       drivers/regulator/rt4831-regulator.c           | 1 +
       drivers/regulator/rt5033-regulator.c           | 1 +
       drivers/regulator/rt5120-regulator.c           | 1 +
       drivers/regulator/rt5190a-regulator.c          | 1 +
       drivers/regulator/rt5739.c                     | 1 +
       drivers/regulator/rt5759-regulator.c           | 1 +
       drivers/regulator/rt6160-regulator.c           | 1 +
       drivers/regulator/rt6190-regulator.c           | 1 +
       drivers/regulator/rt6245-regulator.c           | 1 +
       drivers/regulator/rtmv20-regulator.c           | 1 +
       drivers/regulator/rtq2134-regulator.c          | 1 +
       drivers/regulator/rtq6752-regulator.c          | 1 +
       drivers/regulator/s2mpa01.c                    | 1 +
       drivers/regulator/s2mps11.c                    | 1 +
       drivers/regulator/s5m8767.c                    | 1 +
       drivers/regulator/sc2731-regulator.c           | 1 +
       drivers/regulator/sky81452-regulator.c         | 1 +
       drivers/regulator/slg51000-regulator.c         | 1 +
       drivers/regulator/sm5703-regulator.c           | 1 +
       drivers/regulator/stm32-booster.c              | 1 +
       drivers/regulator/stm32-pwr.c                  | 1 +
       drivers/regulator/stm32-vrefbuf.c              | 1 +
       drivers/regulator/stpmic1_regulator.c          | 1 +
       drivers/regulator/stw481x-vmmc.c               | 1 +
       drivers/regulator/sy7636a-regulator.c          | 1 +
       drivers/regulator/sy8106a-regulator.c          | 1 +
       drivers/regulator/sy8824x.c                    | 1 +
       drivers/regulator/sy8827n.c                    | 1 +
       drivers/regulator/ti-abb-regulator.c           | 1 +
       drivers/regulator/tps51632-regulator.c         | 1 +
       drivers/regulator/tps6105x-regulator.c         | 1 +
       drivers/regulator/tps62360-regulator.c         | 1 +
       drivers/regulator/tps6286x-regulator.c         | 1 +
       drivers/regulator/tps65023-regulator.c         | 1 +
       drivers/regulator/tps6507x-regulator.c         | 1 +
       drivers/regulator/tps65086-regulator.c         | 1 +
       drivers/regulator/tps65090-regulator.c         | 1 +
       drivers/regulator/tps65132-regulator.c         | 1 +
       drivers/regulator/tps65217-regulator.c         | 1 +
       drivers/regulator/tps65218-regulator.c         | 1 +
       drivers/regulator/tps65219-regulator.c         | 1 +
       drivers/regulator/tps6524x-regulator.c         | 1 +
       drivers/regulator/tps6586x-regulator.c         | 1 +
       drivers/regulator/tps65910-regulator.c         | 1 +
       drivers/regulator/tps65912-regulator.c         | 1 +
       drivers/regulator/tps68470-regulator.c         | 1 +
       drivers/regulator/twl-regulator.c              | 1 +
       drivers/regulator/twl6030-regulator.c          | 1 +
       drivers/regulator/uniphier-regulator.c         | 1 +
       drivers/regulator/userspace-consumer.c         | 1 +
       drivers/regulator/vctrl-regulator.c            | 1 +
       drivers/regulator/vexpress-regulator.c         | 1 +
       drivers/regulator/virtual.c                    | 1 +
       drivers/regulator/vqmmc-ipq4019-regulator.c    | 1 +
       drivers/regulator/wm831x-dcdc.c                | 4 ++++
       drivers/regulator/wm831x-isink.c               | 1 +
       drivers/regulator/wm831x-ldo.c                 | 3 +++
       drivers/regulator/wm8350-regulator.c           | 1 +
       drivers/regulator/wm8400-regulator.c           | 1 +
       drivers/regulator/wm8994-regulator.c           | 1 +
       178 files changed, 188 insertions(+), 2 deletions(-)
      
      --
      2.40.0.rc1.284.g88254d51c5-goog
      02ce28bc
    • Rob Herring's avatar
      regulator: dt-bindings: Drop unneeded quotes · cff5c895
      Rob Herring authored
      Cleanup bindings dropping unneeded quotes. Once all these are fixed,
      checking for this can be enabled in yamllint.
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Link: https://lore.kernel.org/r/20230317233616.3968003-1-robh@kernel.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      cff5c895
    • Douglas Anderson's avatar
      regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that are newer than 6.1 · bdce47bb
      Douglas Anderson authored
      This follows on the change ("regulator: Set PROBE_PREFER_ASYNCHRONOUS
      for drivers that existed in 4.14") but changes regulators that were
      not present in kernel 6.1.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20230316125351.7.I31771918f1d8dbe4bfb9f1fef7ff987f2b7504b5@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      bdce47bb
    • Douglas Anderson's avatar
      regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.15 and 6.1 · 41cff178
      Douglas Anderson authored
      This follows on the change ("regulator: Set PROBE_PREFER_ASYNCHRONOUS
      for drivers that existed in 4.14") but changes regulators didn't exist
      in Linux 5.15 but did exist in Linux 6.1.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20230316125351.6.Ibc8a86ddd5055ebbbe487a529199db7b36ccad1a@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      41cff178
    • Douglas Anderson's avatar
      regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.10 and 5.15 · 46600ab1
      Douglas Anderson authored
      This follows on the change ("regulator: Set PROBE_PREFER_ASYNCHRONOUS
      for drivers that existed in 4.14") but changes regulators didn't exist
      in Linux 5.10 but did exist in Linux 5.15.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20230316125351.5.Ia0e6d859bdfe42ea5c187fb1eb4705c1b5ea23a1@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      46600ab1
    • Douglas Anderson's avatar
      regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.4 and 5.10 · 67dc71c6
      Douglas Anderson authored
      This follows on the change ("regulator: Set PROBE_PREFER_ASYNCHRONOUS
      for drivers that existed in 4.14") but changes regulators didn't exist
      in Linux 5.4 but did exist in Linux 5.10.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20230316125351.4.I01f21c98901641a009890590ddc1354c0f294e5e@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      67dc71c6
    • Douglas Anderson's avatar
      regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.19 and 5.4 · d3b81d97
      Douglas Anderson authored
      This follows on the change ("regulator: Set PROBE_PREFER_ASYNCHRONOUS
      for drivers that existed in 4.14") but changes regulators didn't exist
      in Linux 4.19 but did exist in Linux 5.4.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20230316125351.3.I45bf925ca9537da5f647e2acb0ad207c0c98af81@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      d3b81d97
    • Douglas Anderson's avatar
      regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.14 and 4.19 · ed6962cc
      Douglas Anderson authored
      This follows on the change ("regulator: Set PROBE_PREFER_ASYNCHRONOUS
      for drivers that existed in 4.14") but changes regulators didn't exist
      in Linux 4.14 but did exist in Linux 4.19.
      
      NOTE: from a quick "git cherry-pick" it looks as if
      "bd718x7-regulator.c" didn't actually exist in v4.19. In 4.19 it was
      named "bd71837-regulator.c". See commit 2ece646c ("regulator:
      bd718xx: rename bd71837 to 718xx")
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20230316125351.2.Iad1f25517bb46a6c7fca8d8c80ed4fc258a79ed9@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      ed6962cc
    • Douglas Anderson's avatar
      regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14 · 259b93b2
      Douglas Anderson authored
      Probing of regulators can be a slow operation and can contribute to
      slower boot times. This is especially true if a regulator is turned on
      at probe time (with regulator-boot-on or regulator-always-on) and the
      regulator requires delays (off-on-time, ramp time, etc).
      
      While the overall kernel is not ready to switch to async probe by
      default, as per the discussion on the mailing lists [1] it is believed
      that the regulator subsystem is in good shape and we can move
      regulator drivers over wholesale. There is no way to just magically
      opt in all regulators (regulators are just normal drivers like
      platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all
      regulators found in 'drivers/regulator' individually.
      
      Given the number of drivers touched and the impossibility to test this
      ahead of time, it wouldn't be shocking at all if this caused a
      regression for someone. If there is a regression caused by this patch,
      it's likely to be one of the cases talked about in [1]. As a "quick
      fix", drivers involved in the regression could be fixed by changing
      them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix
      would be to directly fix the problem that caused the issue with async
      probe.
      
      The approach here follows a similar approach that was used for the mmc
      subsystem several years ago [2]. In fact, I ran nearly the same python
      script to auto-generate the changes. The only thing I changed was to
      search for "i2c_driver", "spmi_driver", and "spi_driver" in addition
      to "platform_driver".
      
      [1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk
      [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      259b93b2
  9. 14 Mar, 2023 1 commit
    • Douglas Anderson's avatar
      regulator: core: Shorten off-on-delay-us for always-on/boot-on by time since booted · 691c1fcd
      Douglas Anderson authored
      This is very close to a straight revert of commit 218320fe
      ("regulator: core: Fix off-on-delay-us for always-on/boot-on
      regulators"). We've identified that patch as causing a boot speed
      regression on sc7180-trogdor boards. While boot speed certainly isn't
      more important than making sure that power sequencing is correct,
      looking closely at the original change it doesn't seem to have been
      fully justified. It mentions "cycling issues" without describing
      exactly what the issues were. That means it's possible that the
      cycling issues were really a problem that should be fixed in a
      different way.
      
      Let's take a careful look at how we should handle regulators that have
      an off-on-delay and that are boot-on or always-on. Linux currently
      doesn't have any way to identify whether a GPIO regulator was already
      on when the kernel booted. That means that when the kernel boots we
      probe a regulator, see that it wants boot-on / always-on we, and then
      turn the regulator on. We could be in one of two cases when we do
      this:
      
      a) The regulator might have been left on by the bootloader and we're
         ensuring that it stays on.
      b) The regulator might have been left off by the bootloader and we're
         just now turning it on.
      
      For case a) we definitely don't need any sort of delay. For case b) we
      _might_ need some delay in case the bootloader turned the regulator
      off _right_ before booting the kernel. To get the proper delay for
      case b) then we can just assume a `last_off` of 0, which is what it
      gets initialized to by default.
      
      As per above, we can't tell whether we're in case a) or case b) so
      we'll assume the longer delay (case b). This basically puts the code
      to how it was before commit 218320fe ("regulator: core: Fix
      off-on-delay-us for always-on/boot-on regulators"). However, we add
      one important change: we make sure that the delay is actually honored
      if `last_off` is 0. Though the original "cycling issues" cited were
      vague, I'm hopeful that this important extra change will be enough to
      fix the issues that the initial commit mentioned.
      
      With this fix, I've confined that on a sc7180-trogdor board the delay
      at boot goes down from 500 ms to ~250 ms. That's not as good as the 0
      ms that we had prior to commit 218320fe ("regulator: core: Fix
      off-on-delay-us for always-on/boot-on regulators"), but it's probably
      safer because we don't know if the bootloader turned the regulator off
      right before booting.
      
      One note is that it's possible that we could be in a state that's not
      a) or b) if there are other issues in the kernel. The only one I can
      think of is related to pinctrl. If the pinctrl driver being used on a
      board isn't careful about avoiding glitches when setting up a pin then
      it's possible that setting up a pin could cause the regulator to "turn
      off" briefly immediately before the regulator probes. If this is
      indeed causing problems then the pinctrl driver should be fixed,
      perhaps in a similar way to what was done in commit d21f4b7f
      ("pinctrl: qcom: Avoid glitching lines when we first mux to output")
      
      Fixes: 218320fe ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators")
      Cc: Christian Kohlschütter <christian@kohlschutter.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Link: https://lore.kernel.org/r/20230313111806.1.I2eaad872be0932a805c239a7c7a102233fb0b03b@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      691c1fcd
  10. 13 Mar, 2023 5 commits
  11. 12 Mar, 2023 11 commits
    • Linus Torvalds's avatar
      Linux 6.3-rc2 · eeac8ede
      Linus Torvalds authored
      eeac8ede
    • Hector Martin's avatar
      wifi: cfg80211: Partial revert "wifi: cfg80211: Fix use after free for wext" · 79d1ed5c
      Hector Martin authored
      This reverts part of commit 015b8cc5 ("wifi: cfg80211: Fix use after
      free for wext")
      
      This commit broke WPA offload by unconditionally clearing the crypto
      modes for non-WEP connections. Drop that part of the patch.
      Signed-off-by: default avatarHector Martin <marcan@marcan.st>
      Reported-by: default avatarIlya <me@0upti.me>
      Reported-and-tested-by: default avatarJanne Grunau <j@jannau.net>
      Reviewed-by: default avatarEric Curtin <ecurtin@redhat.com>
      Fixes: 015b8cc5 ("wifi: cfg80211: Fix use after free for wext")
      Cc: stable@kernel.org
      Link: https://lore.kernel.org/linux-wireless/ZAx0TWRBlGfv7pNl@kroah.com/T/#m11e6e0915ab8fa19ce8bc9695ab288c0fe018edfSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      79d1ed5c
    • Linus Torvalds's avatar
      Merge tag 'tpm-v6.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd · c4ecd87f
      Linus Torvalds authored
      Pull tpm fixes from Jarkko Sakkinen:
       "Two additional bug fixes for v6.3"
      
      * tag 'tpm-v6.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd:
        tpm: disable hwrng for fTPM on some AMD designs
        tpm/eventlog: Don't abort tpm_read_log on faulty ACPI address
      c4ecd87f
    • Mario Limonciello's avatar
      tpm: disable hwrng for fTPM on some AMD designs · f1324bbc
      Mario Limonciello authored
      AMD has issued an advisory indicating that having fTPM enabled in
      BIOS can cause "stuttering" in the OS.  This issue has been fixed
      in newer versions of the fTPM firmware, but it's up to system
      designers to decide whether to distribute it.
      
      This issue has existed for a while, but is more prevalent starting
      with kernel 6.1 because commit b006c439 ("hwrng: core - start
      hwrng kthread also for untrusted sources") started to use the fTPM
      for hwrng by default. However, all uses of /dev/hwrng result in
      unacceptable stuttering.
      
      So, simply disable registration of the defective hwrng when detecting
      these faulty fTPM versions.  As this is caused by faulty firmware, it
      is plausible that such a problem could also be reproduced by other TPM
      interactions, but this hasn't been shown by any user's testing or reports.
      
      It is hypothesized to be triggered more frequently by the use of the RNG
      because userspace software will fetch random numbers regularly.
      
      Intentionally continue to register other TPM functionality so that users
      that rely upon PCR measurements or any storage of data will still have
      access to it.  If it's found later that another TPM functionality is
      exacerbating this problem a module parameter it can be turned off entirely
      and a module parameter can be introduced to allow users who rely upon
      fTPM functionality to turn it on even though this problem is present.
      
      Link: https://www.amd.com/en/support/kb/faq/pa-410
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=216989
      Link: https://lore.kernel.org/all/20230209153120.261904-1-Jason@zx2c4.com/
      Fixes: b006c439 ("hwrng: core - start hwrng kthread also for untrusted sources")
      Cc: stable@vger.kernel.org
      Cc: Jarkko Sakkinen <jarkko@kernel.org>
      Cc: Thorsten Leemhuis <regressions@leemhuis.info>
      Cc: James Bottomley <James.Bottomley@hansenpartnership.com>
      Tested-by: reach622@mailcuk.com
      Tested-by: default avatarBell <1138267643@qq.com>
      Co-developed-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarMario Limonciello <mario.limonciello@amd.com>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      f1324bbc
    • Morten Linderud's avatar
      tpm/eventlog: Don't abort tpm_read_log on faulty ACPI address · 80a6c216
      Morten Linderud authored
      tpm_read_log_acpi() should return -ENODEV when no eventlog from the ACPI
      table is found. If the firmware vendor includes an invalid log address
      we are unable to map from the ACPI memory and tpm_read_log() returns -EIO
      which would abort discovery of the eventlog.
      
      Change the return value from -EIO to -ENODEV when acpi_os_map_iomem()
      fails to map the event log.
      
      The following hardware was used to test this issue:
          Framework Laptop (Pre-production)
          BIOS: INSYDE Corp, Revision: 3.2
          TPM Device: NTC, Firmware Revision: 7.2
      
      Dump of the faulty ACPI TPM2 table:
          [000h 0000   4]                    Signature : "TPM2"    [Trusted Platform Module hardware interface Table]
          [004h 0004   4]                 Table Length : 0000004C
          [008h 0008   1]                     Revision : 04
          [009h 0009   1]                     Checksum : 2B
          [00Ah 0010   6]                       Oem ID : "INSYDE"
          [010h 0016   8]                 Oem Table ID : "TGL-ULT"
          [018h 0024   4]                 Oem Revision : 00000002
          [01Ch 0028   4]              Asl Compiler ID : "ACPI"
          [020h 0032   4]        Asl Compiler Revision : 00040000
      
          [024h 0036   2]               Platform Class : 0000
          [026h 0038   2]                     Reserved : 0000
          [028h 0040   8]              Control Address : 0000000000000000
          [030h 0048   4]                 Start Method : 06 [Memory Mapped I/O]
      
          [034h 0052  12]            Method Parameters : 00 00 00 00 00 00 00 00 00 00 00 00
          [040h 0064   4]           Minimum Log Length : 00010000
          [044h 0068   8]                  Log Address : 000000004053D000
      
      Fixes: 0cf577a0 ("tpm: Fix handling of missing event log")
      Tested-by: default avatarErkki Eilonen <erkki@bearmetal.eu>
      Signed-off-by: default avatarMorten Linderud <morten@linderud.pw>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      80a6c216
    • Linus Torvalds's avatar
      Merge tag 'xfs-6.3-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · 2e545d69
      Linus Torvalds authored
      Pull xfs fixes from Darrick Wong:
      
       - Fix a crash if mount time quotacheck fails when there are inodes
         queued for garbage collection.
      
       - Fix an off by one error when discarding folios after writeback
         failure.
      
      * tag 'xfs-6.3-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        xfs: fix off-by-one-block in xfs_discard_folio()
        xfs: quotacheck failure can race with background inode inactivation
      2e545d69
    • Linus Torvalds's avatar
      Merge tag 'staging-6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging · 13423166
      Linus Torvalds authored
      Pull staging driver fixes and removal from Greg KH:
       "Here are four small staging driver fixes, and one big staging driver
        deletion for 6.3-rc2.
      
        The fixes are:
      
         - rtl8192e driver fixes for where the driver was attempting to
           execute various programs directly from the disk for unknown reasons
      
         - rtl8723bs driver fixes for issues found by Hans in testing
      
        The deleted driver is the removal of the r8188eu wireless driver as
        now in 6.3-rc1 we have a "real" wifi driver for one that includes
        support for many many more devices than this old driver did. So it's
        time to remove it as it is no longer needed. The maintainers of this
        driver all have acked its removal. Many thanks to them over the years
        for working to clean it up and keep it working while the real driver
        was being developed.
      
        All of these have been in linux-next this week with no reported
        problems"
      
      * tag 'staging-6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
        staging: r8188eu: delete driver
        staging: rtl8723bs: Pass correct parameters to cfg80211_get_bss()
        staging: rtl8723bs: Fix key-store index handling
        staging: rtl8192e: Remove call_usermodehelper starting RadioPower.sh
        staging: rtl8192e: Remove function ..dm_check_ac_dc_power calling a script
      13423166
    • Linus Torvalds's avatar
      Merge tag 'x86_urgent_for_v6.3_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · d3d0cac6
      Linus Torvalds authored
      Pull x86 fix from Borislav Petkov:
       "A single erratum fix for AMD machines:
      
         - Disable XSAVES on AMD Zen1 and Zen2 machines due to an erratum. No
           impact to anything as those machines will fallback to XSAVEC which
           is equivalent there"
      
      * tag 'x86_urgent_for_v6.3_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/CPU/AMD: Disable XSAVES on AMD family 0x17
      d3d0cac6
    • Linus Torvalds's avatar
      Merge tag 'kernel.fork.v6.3-rc2' of gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux · f5eded1f
      Linus Torvalds authored
      Pull clone3 fix from Christian Brauner:
       "A simple fix for the clone3() system call.
      
        The CLONE_NEWTIME allows the creation of time namespaces. The flag
        reuses a bit from the CSIGNAL bits that are used in the legacy clone()
        system call to set the signal that gets sent to the parent after the
        child exits.
      
        The clone3() system call doesn't rely on CSIGNAL anymore as it uses a
        dedicated .exit_signal field in struct clone_args. So we blocked all
        CSIGNAL bits in clone3_args_valid(). When CLONE_NEWTIME was introduced
        and reused a CSIGNAL bit we forgot to adapt clone3_args_valid()
        causing CLONE_NEWTIME with clone3() to be rejected. Fix this"
      
      * tag 'kernel.fork.v6.3-rc2' of gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux:
        selftests/clone3: test clone3 with CLONE_NEWTIME
        fork: allow CLONE_NEWTIME in clone3 flags
      f5eded1f
    • Linus Torvalds's avatar
      Merge tag 'vfs.misc.v6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping · 3b11717f
      Linus Torvalds authored
      Pull vfs fixes from Christian Brauner:
      
       - When allocating pages for a watch queue failed, we didn't return an
         error causing userspace to proceed even though all subsequent
         notifcations would be lost. Make sure to return an error.
      
       - Fix a misformed tree entry for the idmapping maintainers entry.
      
       - When setting file leases from an idmapped mount via
         generic_setlease() we need to take the idmapping into account
         otherwise taking a lease would fail from an idmapped mount.
      
       - Remove two redundant assignments, one in splice code and the other in
         locks code, that static checkers complained about.
      
      * tag 'vfs.misc.v6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping:
        filelocks: use mount idmapping for setlease permission check
        fs/locks: Remove redundant assignment to cmd
        splice: Remove redundant assignment to ret
        MAINTAINERS: repair a malformed T: entry in IDMAPPED MOUNTS
        watch_queue: fix IOC_WATCH_QUEUE_SET_SIZE alloc error paths
      3b11717f
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · 40d0c090
      Linus Torvalds authored
      Pull ext4 fixes from Ted Ts'o:
       "Bug fixes and regressions for ext4, the most serious of which is a
        potential deadlock during directory renames that was introduced during
        the merge window discovered by a combination of syzbot and lockdep"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: zero i_disksize when initializing the bootloader inode
        ext4: make sure fs error flag setted before clear journal error
        ext4: commit super block if fs record error when journal record without error
        ext4, jbd2: add an optimized bmap for the journal inode
        ext4: fix WARNING in ext4_update_inline_data
        ext4: move where set the MAY_INLINE_DATA flag is set
        ext4: Fix deadlock during directory rename
        ext4: Fix comment about the 64BIT feature
        docs: ext4: modify the group desc size to 64
        ext4: fix another off-by-one fsmap error on 1k block filesystems
        ext4: fix RENAME_WHITEOUT handling for inline directories
        ext4: make kobj_type structures constant
        ext4: fix cgroup writeback accounting with fs-layer encryption
      40d0c090