* Merlijn Wajer <merlijn@xxxxxxxxxx> [211213 10:45]:
> Hi Tony,
>
> On 13/12/2021 11:36, Merlijn Wajer wrote:
>
> >>
> >> OK so it's not omap_hsmmc vs sdhci-omap issue. So does setting the thermal
> >> driver to status = "disabled" make the issue disappear?
> >
> > In my kernel I have CONFIG_OMAP3_THERMAL disabled currently (per my
> > other email), but my understanding is that you're suggesting that
> > disabling the node all together in the dts can help. Would this be the
> > bandgap node, thermal_sensors or cpu_thermal node(s)?
>
> I made this change (I just disabled all three of them, not knowing which
> one was the right one, will try to narrow that down further if useful):
>
> > diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> > index 1746a44e96bc..e97b7efbd790 100644
> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -28,6 +28,19 @@ &aes2_target {
> > status = "disabled";
> > };
> >
> > +&cpu_thermal {
> > + status = "disabled";
> > +};
> > +
> > +&bandgap {
> > + status = "disabled";
> > +};
> > +
> > +&thermal_zones {
> > + status = "disabled";
> > +};
> > +
>
> and I am no longer seeing the oopses or resets when running "sleep 30;
> blkid" from minimal userspace.
If disabling the cpu_thermal makes things behave, chances are we have wrong
thermal values in the dts for n900 and possible all 34xx devices. The 36xx
values are behaving AFAIK.
Regards,
Tony
