- 06 Apr, 2023 4 commits
-
-
Bartosz Golaszewski authored
Add the compatible for the pmm8654au RPMH regulators present on the sa8775p-ride development board. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20230406192811.460888-2-brgl@bgdev.plSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Bartosz Golaszewski authored
Add the RPMH regulators exposed by the PMM8654au PMIC and its variants. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230406192811.460888-3-brgl@bgdev.plSigned-off-by:
-
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:Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230329143317.RFC.v2.2.I30d8e1ca10cfbe5403884cdd192253a2e063eb9e@changeidSigned-off-by:
-
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:
-
- 03 Apr, 2023 1 commit
-
-
Vinod Koul authored
Commit 71ca776a ("regulator: qcom-rpmh: Add pmc8180 and pmc8180c") introduced these compatible's but the yaml conversion commit 7255f98d ("regulator: Convert RPMh regulator bindings to YAML") seems to have dropped it So bring it back! Signed-off-by:
Vinod Koul <vkoul@kernel.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230325122444.249507-9-vkoul@kernel.orgSigned-off-by:
-
- 29 Mar, 2023 2 commits
-
-
ChiYuan Huang authored
RT4803 is a boost converter that integrates an internal bypass FET. It will automatically transform the operation mode between bypass and boost based on the voltage difference of the input and output voltage. Signed-off-by:
ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1680050606-461-2-git-send-email-cy_huang@richtek.comSigned-off-by:
-
ChiYuan Huang authored
Add the binding document for Richtek RT4803. Signed-off-by:
-
- 28 Mar, 2023 1 commit
-
-
Peng Fan authored
Following commit b0de7fa7 ("regulator: pca9450: Remove restrictions for regulator-name") to remove the constraints on the regulator-name to allow using arbitrary and descriptive names for the regulators. Signed-off-by:
Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20230328060032.1983381-1-peng.fan@oss.nxp.comSigned-off-by:
-
- 24 Mar, 2023 1 commit
-
-
Douglas Anderson authored
This reverts commit 58973046 ("regulator: qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS"). Further digging into the problems that prompted the us to switch to synchronous probe showed that the root cause was a missing "rootwait" in the kernel command line arguments. Let's reinstate asynchronous probe. Fixes: 58973046 ("regulator: qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS") Cc: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
- 23 Mar, 2023 4 commits
-
-
Marek Szyprowski authored
Restore synchronous probing for 'qcom,pm8150-rpmh-regulators' because otherwise the UFSHC device is not properly initialized on QRB5165-RB5 board. Fixes: ed6962cc ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.14 and 4.19") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20230323220518.3247530-1-m.szyprowski@samsung.comSigned-off-by:
-
Charles Keepax authored
Restore synchronous probing for Arizona regulators as the main MFD relies on the ordering of the devices probing. As these regulators are built into the CODEC and typically have no DT representation the regulator framework is unaware of their existence until the driver probes. These means the probing of the driver needs to be synchronous to ensure the regulators are not substitued for the dummy later when the users request them. Fixes: 259b93b2 ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230323132047.833737-2-ckeepax@opensource.cirrus.comSigned-off-by:
-
Charles Keepax authored
Restore synchronous probing for Arizona regulators because otherwise the main MFD driver will not find its core supplies. As these regulators are built into the CODEC and typically have no DT representation the regulator framework is unaware of their existence until the driver probes. These means the probing of the driver needs to be synchronous to ensure the regulators are not substitued for the dummy later when the users request them. Fixes: 259b93b2 ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") Signed-off-by:
-
Marek Szyprowski authored
Restore synchronous probing for wm8994 regulators because otherwise the sound device is never initialized on Exynos5250-based Arndale board. Fixes: 259b93b2 ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") Signed-off-by:
-
- 20 Mar, 2023 9 commits
-
-
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 -
Rob Herring authored
Cleanup bindings dropping unneeded quotes. Once all these are fixed, checking for this can be enabled in yamllint. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
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: -
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: -
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: -
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: -
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: -
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: -
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:
-
- 14 Mar, 2023 1 commit
-
-
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:
-
- 13 Mar, 2023 5 commits
-
-
Krzysztof Kozlowski authored
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/regulator/mt6397-regulator.c:400:34: error: ‘mt6397_of_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230310214553.275450-4-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/regulator/mp8859.c:132:34: error: ‘mp8859_dt_id’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
-
Krzysztof Kozlowski authored
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/regulator/max20086-regulator.c:289:34: error: ‘max20086_dt_ids’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20230310214553.275450-2-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/regulator/lp872x.c:931:34: error: ‘lp872x_dt_ids’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
-
Mark Brown authored
Linux 6.3-rc2
-
- 12 Mar, 2023 12 commits
-
-
Linus Torvalds authored
-
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:
Hector Martin <marcan@marcan.st> Reported-by:
Ilya <me@0upti.me> Reported-and-tested-by:
Janne Grunau <j@jannau.net> Reviewed-by:
Eric 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:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmddLinus 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
-
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:
Bell <1138267643@qq.com> Co-developed-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
-
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:Erkki Eilonen <erkki@bearmetal.eu> Signed-off-by:
Morten Linderud <morten@linderud.pw> Reviewed-by:
-
git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus 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
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus 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 -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus 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 -
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
-
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmappingLinus 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
-
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4Linus 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
-
Linus Torvalds authored
The cpumask_check() was unnecessarily tight, and causes problems for the users of cpumask_next(). We have a number of users that take the previous return value of one of the bit scanning functions and subtract one to keep it in "range". But since the scanning functions end up returning up to 'small_cpumask_bits' instead of the tighter 'nr_cpumask_bits', the range really needs to be using that widened form. [ This "previous-1" behavior is also the reason we have all those comments about /* -1 is a legal arg here. */ and separate checks for that being ok. So we could have just made "small_cpumask_bits-1" be a similar special "don't check this" value. Tetsuo Handa even suggested a patch that only does that for cpumask_next(), since that seems to be the only actual case that triggers, but that all makes it even _more_ magical and special. So just relax the check ] One example of this kind of pattern being the 'c_start()' function in arch/x86/kernel/cpu/proc.c, but also duplicated in various forms on other architectures. Reported-by: syzbot+96cae094d90877641f32@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=96cae094d90877641f32Reported-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Link: https://lore.kernel.org/lkml/c1f4cc16-feea-b83c-82cf-1a1f007b7eb9@I-love.SAKURA.ne.jp/ Fixes: 596ff4a0 ("cpumask: re-introduce constant-sized cpumask optimizations") Signed-off-by:
-
