summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-03-29regulator: dt-bindings: Add Richtek RT4803ChiYuan Huang
Add the binding document for Richtek RT4803. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/1680050606-461-1-git-send-email-cy_huang@richtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-28dt-bindings: regulator: pf8x00: Remove restrictions for regulator-namePeng Fan
Following commit b0de7fa706506 ("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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-24regulator: qcom-rpmh: Revert "regulator: qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS"Douglas Anderson
This reverts commit 58973046c1bf ("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: 58973046c1bf ("regulator: qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUS") Cc: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230324063357.1.Ifdf3625a3c5c9467bd87bfcdf726c884ad220a35@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-23regulator: qcom-rpmh: Use PROBE_FORCE_SYNCHRONOUSMarek Szyprowski
Restore synchronous probing for 'qcom,pm8150-rpmh-regulators' because otherwise the UFSHC device is not properly initialized on QRB5165-RB5 board. Fixes: ed6962cc3e05 ("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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-23regulator: arizona-micsupp: Use PROBE_FORCE_SYNCHRONOUSCharles Keepax
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: 259b93b21a9f ("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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-23regulator: arizona-ldo1: Use PROBE_FORCE_SYNCHRONOUSCharles Keepax
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: 259b93b21a9f ("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-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-23regulator: wm8994: Use PROBE_FORCE_SYNCHRONOUSMarek Szyprowski
Restore synchronous probing for wm8994 regulators because otherwise the sound device is never initialized on Exynos5250-based Arndale board. Fixes: 259b93b21a9f ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230323083312.199189-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-20regulator: Set PROBE_PREFER_ASYNCHRONOUS forMark Brown
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
2023-03-20regulator: dt-bindings: Drop unneeded quotesRob Herring
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: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230317233616.3968003-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-20regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that are newer than 6.1Douglas Anderson
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 <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.7.I31771918f1d8dbe4bfb9f1fef7ff987f2b7504b5@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-20regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.15 and 6.1Douglas Anderson
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 <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.6.Ibc8a86ddd5055ebbbe487a529199db7b36ccad1a@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-20regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.10 and 5.15Douglas Anderson
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 <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.5.Ia0e6d859bdfe42ea5c187fb1eb4705c1b5ea23a1@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-20regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.4 and 5.10Douglas Anderson
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 <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.4.I01f21c98901641a009890590ddc1354c0f294e5e@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-20regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.19 and 5.4Douglas Anderson
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 <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.3.I45bf925ca9537da5f647e2acb0ad207c0c98af81@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-20regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.14 and 4.19Douglas Anderson
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 2ece646c90c5 ("regulator: bd718xx: rename bd71837 to 718xx") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.2.Iad1f25517bb46a6c7fca8d8c80ed4fc258a79ed9@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-20regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14Douglas Anderson
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: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-14regulator: core: Shorten off-on-delay-us for always-on/boot-on by time since ↵Douglas Anderson
booted This is very close to a straight revert of commit 218320fec294 ("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 218320fec294 ("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 218320fec294 ("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 d21f4b7ffc22 ("pinctrl: qcom: Avoid glitching lines when we first mux to output") Fixes: 218320fec294 ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators") Cc: Christian Kohlschütter <christian@kohlschutter.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230313111806.1.I2eaad872be0932a805c239a7c7a102233fb0b03b@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-13regulator: mt6397-regulator: Mark OF related data as maybe unusedKrzysztof Kozlowski
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: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230310214553.275450-4-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-13regulator: mp8859: Mark OF related data as maybe unusedKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230310214553.275450-3-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-13regulator: max20086: Mark OF related data as maybe unusedKrzysztof Kozlowski
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: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20230310214553.275450-2-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-13regulator: lp872x: Mark OF related data as maybe unusedKrzysztof Kozlowski
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: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230310214553.275450-1-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-13Merge tag 'v6.3-rc2' into regulator-6.4 to fix clock related boot issuesMark Brown
Linux 6.3-rc2
2023-03-12Linux 6.3-rc2v6.3-rc2Linus Torvalds
2023-03-12wifi: cfg80211: Partial revert "wifi: cfg80211: Fix use after free for wext"Hector Martin
This reverts part of commit 015b8cc5e7c4 ("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: 015b8cc5e7c4 ("wifi: cfg80211: Fix use after free for wext") Cc: stable@kernel.org Link: https://lore.kernel.org/linux-wireless/ZAx0TWRBlGfv7pNl@kroah.com/T/#m11e6e0915ab8fa19ce8bc9695ab288c0fe018edf Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-03-12Merge tag 'tpm-v6.3-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd 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
2023-03-12tpm: disable hwrng for fTPM on some AMD designsMario Limonciello
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 b006c439d58db ("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: b006c439d58d ("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: 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: Jarkko Sakkinen <jarkko@kernel.org>
2023-03-12tpm/eventlog: Don't abort tpm_read_log on faulty ACPI addressMorten Linderud
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: 0cf577a03f21 ("tpm: Fix handling of missing event log") Tested-by: Erkki Eilonen <erkki@bearmetal.eu> Signed-off-by: Morten Linderud <morten@linderud.pw> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-03-12Merge tag 'xfs-6.3-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds
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
2023-03-12Merge tag 'staging-6.3-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging 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
2023-03-12Merge tag 'x86_urgent_for_v6.3_rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 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
2023-03-12Merge tag 'kernel.fork.v6.3-rc2' of ↵Linus Torvalds
gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux 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
2023-03-12Merge tag 'vfs.misc.v6.3-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping 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
2023-03-12Merge tag 'ext4_for_linus_stable' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 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
2023-03-12cpumask: relax sanity checking constraintsLinus Torvalds
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=96cae094d90877641f32 Reported-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: 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask optimizations") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-03-11Merge tag 'i2c-for-6.3-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: "This marks the end of a transition to let I2C have the same probe semantics as other subsystems. Uwe took care that no drivers in the current tree nor in -next use the deprecated .probe call. So, it is a good time to switch to the new, standard semantics now. There is also a regression fix: - regression fix for the notifier handling of the I2C core - final coversions of drivers away from deprecated .probe - make .probe_new the standard probe and convert I2C core to use it * tag 'i2c-for-6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: dev: Fix bus callback return values i2c: Convert drivers to new .probe() callback i2c: mux: Convert all drivers to new .probe() callback i2c: Switch .probe() to not take an id parameter media: i2c: ov2685: convert to i2c's .probe_new() media: i2c: ov5695: convert to i2c's .probe_new() w1: ds2482: Convert to i2c's .probe_new() serial: sc16is7xx: Convert to i2c's .probe_new() mtd: maps: pismo: Convert to i2c's .probe_new() misc: ad525x_dpot-i2c: Convert to i2c's .probe_new()
2023-03-11ubi: block: Fix missing blk_mq_end_requestRichard Weinberger
Switching to BLK_MQ_F_BLOCKING wrongly removed the call to blk_mq_end_request(). Add it back to have our IOs finished Fixes: 91cc8fbcc8c7 ("ubi: block: set BLK_MQ_F_BLOCKING") Analyzed-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Daniel Palmer <daniel@0x0f.com> Link: https://lore.kernel.org/linux-mtd/CAHk-=wi29bbBNh3RqJKu3PxzpjDN5D5K17gEVtXrb7-6bfrnMQ@mail.gmail.com/ Signed-off-by: Richard Weinberger <richard@nod.at> Reviewed-by: Christoph Hellwig <hch@lst.de> Tested-by: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-03-11regulator: Use of_property_read_bool() for boolean propertiesRob Herring
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230310144722.1544843-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-11regulator: Use of_property_present() for testing DT property presenceRob Herring
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230310144721.1544756-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-11ext4: zero i_disksize when initializing the bootloader inodeZhihao Cheng
If the boot loader inode has never been used before, the EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the i_size to 0. However, if the "never before used" boot loader has a non-zero i_size, then i_disksize will be non-zero, and the inconsistency between i_size and i_disksize can trigger a kernel warning: WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 Call Trace: vfs_write+0x3b1/0x5c0 ksys_write+0x77/0x160 __x64_sys_write+0x22/0x30 do_syscall_64+0x39/0x80 Reproducer: 1. create corrupted image and mount it: mke2fs -t ext4 /tmp/foo.img 200 debugfs -wR "sif <5> size 25700" /tmp/foo.img mount -t ext4 /tmp/foo.img /mnt cd /mnt echo 123 > file 2. Run the reproducer program: posix_memalign(&buf, 1024, 1024) fd = open("file", O_RDWR | O_DIRECT); ioctl(fd, EXT4_IOC_SWAP_BOOT); write(fd, buf, 1024); Fix this by setting i_disksize as well as i_size to zero when initiaizing the boot loader inode. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159 Cc: stable@kernel.org Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Link: https://lore.kernel.org/r/20230308032643.641113-1-chengzhihao1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-11ext4: make sure fs error flag setted before clear journal errorYe Bin
Now, jounral error number maybe cleared even though ext4_commit_super() failed. This may lead to error flag miss, then fsck will miss to check file system deeply. Signed-off-by: Ye Bin <yebin10@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230307061703.245965-3-yebin@huaweicloud.com
2023-03-11ext4: commit super block if fs record error when journal record without errorYe Bin
Now, 'es->s_state' maybe covered by recover journal. And journal errno maybe not recorded in journal sb as IO error. ext4_update_super() only update error information when 'sbi->s_add_error_count' large than zero. Then 'EXT4_ERROR_FS' flag maybe lost. To solve above issue just recover 'es->s_state' error flag after journal replay like error info. Signed-off-by: Ye Bin <yebin10@huawei.com> Reviewed-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230307061703.245965-2-yebin@huaweicloud.com
2023-03-11ext4, jbd2: add an optimized bmap for the journal inodeTheodore Ts'o
The generic bmap() function exported by the VFS takes locks and does checks that are not necessary for the journal inode. So allow the file system to set a journal-optimized bmap function in journal->j_bmap. Reported-by: syzbot+9543479984ae9e576000@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=e4aaa78795e490421c79f76ec3679006c8ff4cf0 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-11ext4: fix WARNING in ext4_update_inline_dataYe Bin
Syzbot found the following issue: EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none. fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni" fscrypt: AES-256-XTS using implementation "xts-aes-aesni" ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525 Modules linked in: CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525 RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246 RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000 RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248 RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220 R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40 R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __alloc_pages_node include/linux/gfp.h:237 [inline] alloc_pages_node include/linux/gfp.h:260 [inline] __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113 __do_kmalloc_node mm/slab_common.c:956 [inline] __kmalloc+0xfe/0x190 mm/slab_common.c:981 kmalloc include/linux/slab.h:584 [inline] kzalloc include/linux/slab.h:720 [inline] ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346 ext4_update_inline_dir fs/ext4/inline.c:1115 [inline] ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307 ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385 ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772 ext4_create+0x36c/0x560 fs/ext4/namei.c:2817 lookup_open fs/namei.c:3413 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x12ac/0x2dd0 fs/namei.c:3711 do_filp_open+0x264/0x4f0 fs/namei.c:3741 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_openat fs/open.c:1342 [inline] __se_sys_openat fs/open.c:1337 [inline] __x64_sys_openat+0x243/0x290 fs/open.c:1337 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Above issue happens as follows: ext4_iget ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60 ext4_try_add_inline_entry __ext4_mark_inode_dirty ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44 ext4_xattr_shift_entries ->after shift i_inline_off is incorrect, actually is change to 176 ext4_try_add_inline_entry ext4_update_inline_dir get_max_inline_xattr_value_size if (EXT4_I(inode)->i_inline_off) entry = (struct ext4_xattr_entry *)((void *)raw_inode + EXT4_I(inode)->i_inline_off); free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size)); ->As entry is incorrect, then 'free' may be negative ext4_update_inline_data value = kzalloc(len, GFP_NOFS); -> len is unsigned int, maybe very large, then trigger warning when 'kzalloc()' To resolve the above issue we need to update 'i_inline_off' after 'ext4_xattr_shift_entries()'. We do not need to set EXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty() already sets this flag if needed. Setting EXT4_STATE_MAY_INLINE_DATA when it is needed may trigger a BUG_ON in ext4_writepages(). Reported-by: syzbot+d30838395804afc2fa6f@syzkaller.appspotmail.com Cc: stable@kernel.org Signed-off-by: Ye Bin <yebin10@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230307015253.2232062-3-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-11ext4: move where set the MAY_INLINE_DATA flag is setYe Bin
The only caller of ext4_find_inline_data_nolock() that needs setting of EXT4_STATE_MAY_INLINE_DATA flag is ext4_iget_extra_inode(). In ext4_write_inline_data_end() we just need to update inode->i_inline_off. Since we are going to add one more caller that does not need to set EXT4_STATE_MAY_INLINE_DATA, just move setting of EXT4_STATE_MAY_INLINE_DATA out to ext4_iget_extra_inode(). Signed-off-by: Ye Bin <yebin10@huawei.com> Cc: stable@kernel.org Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230307015253.2232062-2-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-10Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Twenty fixes all in drivers except the one zone storage revalidation fix to sd. The megaraid_sas fixes are more on the level of a driver update (enabling crash dump and increasing lun number) but I thought you could let this slide on -rc1 and the next most extensive update is a load of fixes to mpi3mr" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: sd: Fix wrong zone_write_granularity value during revalidate scsi: storvsc: Handle BlockSize change in Hyper-V VHD/VHDX file scsi: megaraid_sas: Driver version update to 07.725.01.00-rc1 scsi: megaraid_sas: Add crash dump mode capability bit in MFI capabilities scsi: megaraid_sas: Update max supported LD IDs to 240 scsi: mpi3mr: Bad drive in topology results kernel crash scsi: mpi3mr: NVMe command size greater than 8K fails scsi: mpi3mr: Return proper values for failures in firmware init path scsi: mpi3mr: Wait for diagnostic save during controller init scsi: mpi3mr: Driver unload crashes host when enhanced logging is enabled scsi: mpi3mr: ioctl timeout when disabling/enabling interrupt scsi: lpfc: Avoid usage of list iterator variable after loop scsi: lpfc: Check kzalloc() in lpfc_sli4_cgn_params_read() scsi: ufs: mcq: qcom: Clean the return path of ufs_qcom_mcq_config_resource() scsi: ufs: mcq: qcom: Fix passing zero to PTR_ERR scsi: ufs: ufs-qcom: Remove impossible check scsi: ufs: core: Add soft dependency on governor_simpleondemand scsi: hisi_sas: Check devm_add_action() return value scsi: qla2xxx: Add option to disable FC2 Target support scsi: target: iscsi: Fix an error message in iscsi_check_key()
2023-03-10Merge tag 'block-6.3-2023-03-09' of git://git.kernel.dk/linuxLinus Torvalds
Pull block fixes from Jens Axboe: - Fix a regression in exclusive mode handling of the partition code, introduced in this merge windoe (Yu) - Fix for a use-after-free in BFQ (Yu) - Add sysfs documentation for the 'hidden' attribute (Sagi) * tag 'block-6.3-2023-03-09' of git://git.kernel.dk/linux: block, bfq: fix uaf for 'stable_merge_bfqq' docs: sysfs-block: document hidden sysfs entry block: fix wrong mode for blkdev_put() from disk_scan_partitions()
2023-03-10Merge tag 'pull-highmem' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull put_and_unmap_page() helper from Al Viro: "kmap_local_page() conversions in local filesystems keep running into kunmap_local_page()+put_page() combinations. We can keep inventing names for identical inline helpers, but it's getting rather inconvenient. I've added a trivial helper to linux/highmem.h instead. I would've held that back until the merge window, if not for the mess it causes in tree topology - I've several branches merging from that one, and it's only going to get worse if e.g. ext2 stuff gets picked by Jan" * tag 'pull-highmem' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: new helper: put_and_unmap_page()
2023-03-10Merge tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds
Pull misc fixes from Al Viro: "pick_file() speculation fix + fix for alpha mis(merge,cherry-pick) The fs/file.c one is a genuine missing speculation barrier in pick_file() (reachable e.g. via close(2)). The alpha one is strictly speaking not a bug fix, but only because confusion between preempt_enable() and preempt_disable() is harmless on architecture without CONFIG_PREEMPT. Looks like alpha.git picked the wrong version of patch - that braino used to be there in early versions, but it had been fixed quite a while ago..." * tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fs: prevent out-of-bounds array speculation when closing a file descriptor alpha: fix lazy-FPU mis(merged/applied/whatnot)
2023-03-10Merge tag 'thermal-6.3-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fix from Rafael Wysocki: "Fix a recently introduced deadlock in the int340x thermal control driver (Srinivas Pandruvada)" * tag 'thermal-6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: intel: int340x: processor_thermal: Fix deadlock
2023-03-10Merge tag 'riscv-for-linus-6.3-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - RISC-V architecture-specific ELF attributes have been disabled in the kernel builds - A fix for a locking failure while during errata patching that manifests on SiFive-based systems - A fix for a KASAN failure during stack unwinding - A fix for some lockdep failures during text patching * tag 'riscv-for-linus-6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: RISC-V: Don't check text_mutex during stop_machine riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack mode RISC-V: fix taking the text_mutex twice during sifive errata patching RISC-V: Stop emitting attributes
generated by cgit v1.2.3-70-g09d2 (git 2.47.1) at 2025-01-01 04:54:03 +0000