IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Add the RPMH regulators exposed by the PMM8654au PMIC and its variants.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230406192811.460888-3-brgl@bgdev.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
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: eaa7995c52 ("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@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
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: f8702f9e4a ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230329143317.RFC.v2.1.I4e9d433ea26360c06dd1381d091c82bb1a4ce843@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 71ca776a88 ("regulator: qcom-rpmh: Add pmc8180 and pmc8180c")
introduced these compatible's but the yaml conversion commit
7255f98d08 ("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.org
Signed-off-by: Mark Brown <broonie@kernel.org>
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.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Following commit b0de7fa706
("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>
This reverts commit 58973046c1 ("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: 58973046c1 ("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>
Restore synchronous probing for 'qcom,pm8150-rpmh-regulators' because
otherwise the UFSHC device is not properly initialized on QRB5165-RB5
board.
Fixes: ed6962cc3e ("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>
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: 259b93b21a ("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>
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: 259b93b21a ("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>
Restore synchronous probing for wm8994 regulators because otherwise the
sound device is never initialized on Exynos5250-based Arndale board.
Fixes: 259b93b21a ("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>
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
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>
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>
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>
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>
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>
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 2ece646c90 ("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>
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>
This is very close to a straight revert of commit 218320fec2
("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 218320fec2 ("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 218320fec2 ("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 d21f4b7ffc
("pinctrl: qcom: Avoid glitching lines when we first mux to output")
Fixes: 218320fec2 ("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>
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>
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>
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>
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>
This reverts part of commit 015b8cc5e7 ("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: 015b8cc5e7 ("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>
-----BEGIN PGP SIGNATURE-----
iIgEABYIADAWIQRE6pSOnaBC00OEHEIaerohdGur0gUCZA5EKRIcamFya2tvQGtl
cm5lbC5vcmcACgkQGnq6IXRrq9JJ8AEAsyyMKJ73ETZlac1S4ZOfEsEl1gZ6+cFb
UuuNcz+XfuYBAOHmrFy3DKqLM58Jgf3OUn4C0i7ldNbkv6WTidifVG8B
=rCK8
-----END PGP SIGNATURE-----
Merge tag 'tpm-v6.3-rc3' of 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
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 b006c439d5 ("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: b006c439d5 ("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>
* 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.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZAYvQwAKCRBKO3ySh0YR
pjMXAP9X9HozNYESlg/cMq6nY2XfbHIR2qvNOfopiRpWby5xQAEAqBiEhafIJ0A1
mTt+0TqQxDsH+uxr/QEUm76Q7F3f1gE=
=0zU0
-----END PGP SIGNATURE-----
Merge tag 'xfs-6.3-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
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
Here are 4 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.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZA3mHQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ykZRgCeJOPM59FrL5n6MUnxyBfjLW8v/rUAmweESb6C
ofjiP1rkzkE9zocXSQiI
=clcQ
-----END PGP SIGNATURE-----
Merge tag 'staging-6.3-rc2' of 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
impact to anything as those machines will fallback to XSAVEC which is
equivalent there.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmQNtvAACgkQEsHwGGHe
VUpGiRAAjlYpvaQK24s8MiQr3LBC0pKsgKstf1Jx5C+HspmS5JAdF83646kMOUKm
MUGPfQwK1nN5kO0/fOlo4O6vhSIF2Ft/Xfrd/APZm6qJhR3pli9675NeF8fH2D5t
Ypgtl6psRudkB3RUmE1cmHWbr9dMnHZZLnL6iA/qHYXCY3kaw96ncM6HjdnrjXRd
OV2+N4dyhTet3MdUdw7dSr1uz75O5PQH/1FwR1V2zroF1sjImaIwQ7JN51hIITxw
DzfTbfuJzdAqwfztBFG/yZ5K+DEoU5BemHHIuhq+X9/7GeLMd059DdnZuXSX8mcH
jjzOa/E5r/PjYze0XRWT3RbI5fbSc1qhNbmj3kLNP3KE/F3S74n6FR58oLNqosVk
zw1TYP8oocdjG1VxJdm5qndIzwHMSj3qkd+BSNZZ1fwINVLXtSDubtThkN/i+81+
nqnMA8HFrcwy1bhwq4jd5dmP7tjlODATfeL4ZV6/6J1RX8Vwu+bjdy8PM+vJYJ0d
pnFLT20cf6Or0MQHUssO+uh6oC3aQ6AxPWJcuUfbdSLYzjr2EObgCHXGZOhCjvhC
CsALcmwnLh5XzwglzWoXyyv+tsJar63XYcPSEIt+gIfXpLf7ZbzcOSDLDkri6B3Z
fCABGASFnoXr7ZYnGxH4L5WKWOk1W+pgpxyC4mnzD9oHtXIzUPU=
=u6kj
-----END PGP SIGNATURE-----
Merge tag 'x86_urgent_for_v6.3_rc2' of 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
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCZA2l2QAKCRCRxhvAZXjc
okR1AP9UjPVvVTU3DRp7Giqyv1rdv/iaCVRtEDQmhzDflksioQEAyJXTt+3YOTNl
sSocNYBhVBsijelICeq7hZrmVP9CrgM=
=C0cC
-----END PGP SIGNATURE-----
Merge tag 'kernel.fork.v6.3-rc2' of 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
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCZA2yXAAKCRCRxhvAZXjc
opK7AP0fqkk75P1bRZL36iNOgCV0RDiSN/Ynk/oMYpsOyBndlAD7BKCEZFF2OKzP
aeJrY0F+guwL67X+18X+yiLZrk2rag4=
=2Wa/
-----END PGP SIGNATURE-----
Merge tag 'vfs.misc.v6.3-rc2' of 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
potential deadlock during directory renames that was introduced during
the merge window discovered by a combination of syzbot and lockdep.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEK2m5VNv+CHkogTfJ8vlZVpUNgaMFAmQNVwIACgkQ8vlZVpUN
gaMwmgf/ZAasXZEMV0zaQZa8zP4KvMKZjWe6azkcJg4sb/HG9Q7JzeJDCurhhWUj
8+QnyUcuKTyWKYWjGf0f5CZaYEM5AZYij41UJzu2qMkz5hVXSqBVuY8KywxuiJv5
kfuIvQh0Onv0Yrg2qAc52/kZkq1lu2sl/F5ertBWjdpTUXdBUdrCxkUk+1BgQWAj
vNwi1/+gNuX7RxMboHqYmwXFP39vECd+wteNdsiK1hR8bLqL68duLLq8xQdHt4gS
sbVmJKR4j2Giw4ZnlYi9RiwKIO0beqocanp+cfOPulyj5mTM8X1lr0uvaLZgx2AF
lqrS3/5ksp45cRT70qCIz8je70hTSg==
=nN3T
-----END PGP SIGNATURE-----
Merge tag 'ext4_for_linus_stable' of 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
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: 596ff4a09b ("cpumask: re-introduce constant-sized cpumask optimizations")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* final coversions of drivers away from deprecated .probe
* make .probe_new the standard probe and convert I2C core to use it
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmQMKqcACgkQFA3kzBSg
KbYXLg/9GuZdcLgodr+h1xckLPYLP8+AL4RKr0O7Cm9M4z4h8eIAkFIumuDaL5sd
fe/zEbvA9ldP2t0tAp5JPsrYJNOr4RAoYyeOz05Ijdy5cLgWrldwD9JFVtsDECyU
sKHQZyrhTmQUUOmgleu5WKFnlDJLGe/HGv3XPsuKldXCyBii2yKZ4FG3Z0h25lPX
/SPWYS3VXGNBDIYv6U63dm/Hd2YiuDR6r+4+DyuoDkI3Wmg97X+N4nwzOBO7iJLe
PXNX9oN3hbZipTrXut3fm13+PL3XBauqtdr3i/Fkm5UO45rTW21vK+6NO1relylh
TvaV2wcE9Wobrua1CS7f1BJ9C7PdQ6wphhSE3EQav6oBWTYHsFbkrbsKoOpBJjyW
DxyC+y8DhwQDfQksQH+ifF4tVNNF6MXLehXGQtAMjTKa+tRTnQbC4WhPVXVFi2PK
8eloIH3xuSxBB24n6O7TThqGOV/IY3mIIhEJtKanDKT5s7MXuvx4B6ehYtPy2JrS
W5M8Swe5syWlPkJLC/gCZdID89YPhLd0UaJ1i0HuLZt6ZOgr7mYkFu8EPaEHPoLz
mxa0Qm+TGpfwCIj+t0mksXfnoDiSOpMjB1wEpBo4D14AKcbyJGHDN5OVw3I3OOHj
1wr5x31HOBUobpcUt8wWKMF+7nw7l4O4LJ0oNLFzsnmZ23mEKJQ=
=jm/G
-----END PGP SIGNATURE-----
Merge tag 'i2c-for-6.3-rc2' of 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()
Switching to BLK_MQ_F_BLOCKING wrongly removed the call to
blk_mq_end_request(). Add it back to have our IOs finished
Fixes: 91cc8fbcc8 ("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>
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>
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>
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>
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
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
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>
20 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.
Signed-off-by: James E.J. Bottomley <jejb@linux.ibm.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCZAuqwyYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishVm/AP4t1E3w
Jc19sSzMV6OZc5x1eTSGzso80fkTeFgVXWOmcQD9G6ymH78hS0cb7FRIwtnHcV5r
6TwbInHF2LwNKzPhuMI=
=BdqN
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of 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()
