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.
This is where my ability to fix thing fizzles out and so here I am asking for assistance.
Kind regards, Maud
Cheers, Chris
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!
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.Iad1f25517bb46a6c7fca8d8c80ed4fc2... 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.
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
On Thu, May 22, 2025 at 9:15 AM Maud Spierings maud_spierings@hotmail.com wrote:
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;
It's the right fix.
If you look in drivers/iio/accel/st_accel_i2c.c clearly the driver enables the power before calling st_accel_common_probe() which is where devm_iio_device_register() is finally called and the IIO struct device get initialized.
And that's not all: st_sensors_init_sensor is also called before the iio device is present, so this:
} else dev_info(&indio_dev->dev, "Full-scale not possible\n");
and this:
dev_info(&indio_dev->dev, "set interrupt line to open drain mode on pin %d\n", sdata->drdy_int_pin);
is also unacceptable.
I hope there are not more...
They also need to use indio_dev->dev.parent, or a local copy of that struct device *, so please fix them too in the same patch.
I tried to chase down a Fixes: candidate but this misunderstanding goes way back and such prints were introduced several times.
I would just tag on Cc: stable@vger.kernel.org and be done with it.
Thanks for drilling into this!
Yours, Linus Walleij
linux-stable-mirror@lists.linaro.org
-
Christian Heusel -
Linus Walleij -
Maud Spierings