On 5/21/25 13:05, Maud Spierings wrote:
On 5/21/25 12:08, Christian Heusel wrote:
On 25/05/21 12:03PM, Maud Spierings wrote:
On 5/21/25 11:48, Maud Spierings wrote:
On 5/21/25 11:29, Christian Heusel wrote:
On 25/05/21 10:53AM, Maud Spierings wrote:
I've just experienced an Issue that I think may be a regression.
I'm enabling a device which incorporates a lis2dw12 accelerometer, currently I am running 6.12 lts, so 6.12.29 as of typing this message.
Could you check whether the latest mainline release (at the time this is v6.15-rc7) is also affected? If that's not the case the bug might already be fixed ^_^
Unfortunately doesn't seem to be the case, still gets the panic. I also tried 6.12(.0), but that also has the panic, so it is definitely older than this lts.
Also as you said that this is a regression, what is the last revision that the accelerometer worked with?
Thats a difficult one to pin down, I'm moving from the nxp vendor kernel to mainline, the last working one that I know sure is 5.10.72 of that vendor kernel.
I did some more digging and the latest lts it seems to work with is 6.1.139, 6.6.91 also crashes. So it seems to be a very old regression.
Could you check whether the issue also exists for 6.1 & 6.6 and bisect the issue between those two? Knowing which commit caused the breakage is the best way of getting a fix for the issue!
Also see https://docs.kernel.org/admin-guide/bug-bisect.html for that, feel free to ask if you need help with it!
Thanks for the link, I had heard of it but never done it before. This is the result:
ed6962cc3e05ca77f526590f62587678149d5e58 is the first bad commit commit ed6962cc3e05ca77f526590f62587678149d5e58 (HEAD) Author: Douglas Anderson dianders@chromium.org Date: Thu Mar 16 12:54:39 2023 -0700
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.14 and 4.19
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
drivers/regulator/88pg86x.c | 1 + drivers/regulator/bd718x7-regulator.c | 1 + drivers/regulator/qcom-rpmh-regulator.c | 1 + drivers/regulator/sc2731-regulator.c | 1 + drivers/regulator/sy8106a-regulator.c | 1 + drivers/regulator/uniphier-regulator.c | 1 + 6 files changed, 6 insertions(+)
bd718x7 is the PMIC on this board, and one of its regulators is the supply for the lis2dw12. However I feel this regulator driver is not the actual problem, but the actual probing of regulators in that driver just doesn't work well with the asynchronous probing.
I have found a fix but I don't know if it is correct to do. This deals with the deferred probe correctly, no longer panics and registers the device properly. This is the patch I have come up with:
diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c b/drivers/iio/common/st_sensors/st_sensors_core.c index 1b4287991d00a..494206f8de5b0 100644 --- a/drivers/iio/common/st_sensors/st_sensors_core.c +++ b/drivers/iio/common/st_sensors/st_sensors_core.c @@ -231,7 +231,7 @@ int st_sensors_power_enable(struct iio_dev *indio_dev) ARRAY_SIZE(regulator_names), regulator_names); if (err) - return dev_err_probe(&indio_dev->dev, err, + return dev_err_probe(parent, err, "unable to enable supplies\n");
return 0;
Kind regards, Maud