2023-07-18 15:32:14

by Mark Brown

[permalink] [raw]
Subject: [PATCH] thermal/drivers/sun8i: Don't fail probe due to zone registration failure

Currently the sun8i thermal driver will fail to probe if any of the
thermal zones it is registering fails to register with the thermal core.
Since we currently do not define any trip points for the GPU thermal
zones on at least A64 or H5 this means that we have no thermal support
on these platforms:

[ 1.698703] thermal_sys: Failed to find 'trips' node
[ 1.698707] thermal_sys: Failed to find trip points for thermal-sensor id=1

even though the main CPU thermal zone on both SoCs is fully configured.
This does not seem ideal, while we may not be able to use all the zones
it seems better to have those zones which are usable be operational.
Instead just carry on registering zones if we get any non-deferral
error, allowing use of those zones which are usable.

This means that we also need to update the interrupt handler to not
attempt to notify the core for events on zones which we have not
registered, I didn't see an ability to mask individual interrupts and
I would expect that interrupts would still be indicated in the ISR even
if they were masked.

Signed-off-by: Mark Brown <[email protected]>
---
I noticed this while trying to debug an issue with memory corruption on
boot which since the merge window has prevented Pine64 Plus (an A64)
from booting at all:

https://storage.kernelci.org/mainline/master/v6.5-rc2/arm64/defconfig/gcc-10/lab-baylibre/baseline-sun50i-a64-pine64-plus.txt

(which I bisected to a random memory management change that clearly
wasn't at fault) and has been causing less consistent but still very
severe boot issues on Libretech Tritium (a H3). The corruption appears
to happen when unbinding a the one thermal zone that does register, I've
not figured out exactly where.

The memory corruption issue obviously needs to be dealt with properly
(I'm still digging into it) but this does allow both platforms to boot
reliably and seems like a sensible thing to do independently, ideally we
could get this in as a fix.
---
drivers/thermal/sun8i_thermal.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
index 195f3c5d0b38..b69134538867 100644
--- a/drivers/thermal/sun8i_thermal.c
+++ b/drivers/thermal/sun8i_thermal.c
@@ -190,6 +190,9 @@ static irqreturn_t sun8i_irq_thread(int irq, void *data)
int i;

for_each_set_bit(i, &irq_bitmap, tmdev->chip->sensor_num) {
+ /* We allow some zones to not register. */
+ if (IS_ERR(tmdev->sensor[i].tzd))
+ continue;
thermal_zone_device_update(tmdev->sensor[i].tzd,
THERMAL_EVENT_UNSPECIFIED);
}
@@ -465,8 +468,17 @@ static int sun8i_ths_register(struct ths_device *tmdev)
i,
&tmdev->sensor[i],
&ths_ops);
- if (IS_ERR(tmdev->sensor[i].tzd))
- return PTR_ERR(tmdev->sensor[i].tzd);
+
+ /*
+ * If an individual zone fails to register for reasons
+ * other than probe deferral (eg, a bad DT) then carry
+ * on, other zones might register successfully.
+ */
+ if (IS_ERR(tmdev->sensor[i].tzd)) {
+ if (PTR_ERR(tmdev->sensor[i].tzd) == -EPROBE_DEFER)
+ return PTR_ERR(tmdev->sensor[i].tzd);
+ continue;
+ }

devm_thermal_add_hwmon_sysfs(tmdev->dev, tmdev->sensor[i].tzd);
}

---
base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c
change-id: 20230718-thermal-sun8i-registration-df3a136ccafa

Best regards,
--
Mark Brown <[email protected]>



2023-07-18 17:33:06

by Vasily Khoruzhick

[permalink] [raw]
Subject: Re: [PATCH] thermal/drivers/sun8i: Don't fail probe due to zone registration failure

On Tue, Jul 18, 2023 at 8:05 AM Mark Brown <[email protected]> wrote:
>
> Currently the sun8i thermal driver will fail to probe if any of the
> thermal zones it is registering fails to register with the thermal core.
> Since we currently do not define any trip points for the GPU thermal
> zones on at least A64 or H5 this means that we have no thermal support
> on these platforms:
>
> [ 1.698703] thermal_sys: Failed to find 'trips' node
> [ 1.698707] thermal_sys: Failed to find trip points for thermal-sensor id=1
>
> even though the main CPU thermal zone on both SoCs is fully configured.
> This does not seem ideal, while we may not be able to use all the zones
> it seems better to have those zones which are usable be operational.
> Instead just carry on registering zones if we get any non-deferral
> error, allowing use of those zones which are usable.
>
> This means that we also need to update the interrupt handler to not
> attempt to notify the core for events on zones which we have not
> registered, I didn't see an ability to mask individual interrupts and
> I would expect that interrupts would still be indicated in the ISR even
> if they were masked.
>
> Signed-off-by: Mark Brown <[email protected]>

Reviewed-by: Vasily Khoruzhick <[email protected]>

2023-07-19 20:29:30

by Jernej Škrabec

[permalink] [raw]
Subject: Re: [PATCH] thermal/drivers/sun8i: Don't fail probe due to zone registration failure

Dne torek, 18. julij 2023 ob 17:04:22 CEST je Mark Brown napisal(a):
> Currently the sun8i thermal driver will fail to probe if any of the
> thermal zones it is registering fails to register with the thermal core.
> Since we currently do not define any trip points for the GPU thermal
> zones on at least A64 or H5 this means that we have no thermal support
> on these platforms:
>
> [ 1.698703] thermal_sys: Failed to find 'trips' node
> [ 1.698707] thermal_sys: Failed to find trip points for thermal-sensor
> id=1
>
> even though the main CPU thermal zone on both SoCs is fully configured.
> This does not seem ideal, while we may not be able to use all the zones
> it seems better to have those zones which are usable be operational.
> Instead just carry on registering zones if we get any non-deferral
> error, allowing use of those zones which are usable.
>
> This means that we also need to update the interrupt handler to not
> attempt to notify the core for events on zones which we have not
> registered, I didn't see an ability to mask individual interrupts and
> I would expect that interrupts would still be indicated in the ISR even
> if they were masked.
>
> Signed-off-by: Mark Brown <[email protected]>

Acked-by: Jernej Skrabec <[email protected]>

Best regards,
Jernej

> ---
> I noticed this while trying to debug an issue with memory corruption on
> boot which since the merge window has prevented Pine64 Plus (an A64)
> from booting at all:
>
>
> https://storage.kernelci.org/mainline/master/v6.5-rc2/arm64/defconfig/gcc-1
> 0/lab-baylibre/baseline-sun50i-a64-pine64-plus.txt
>
> (which I bisected to a random memory management change that clearly
> wasn't at fault) and has been causing less consistent but still very
> severe boot issues on Libretech Tritium (a H3). The corruption appears
> to happen when unbinding a the one thermal zone that does register, I've
> not figured out exactly where.
>
> The memory corruption issue obviously needs to be dealt with properly
> (I'm still digging into it) but this does allow both platforms to boot
> reliably and seems like a sensible thing to do independently, ideally we
> could get this in as a fix.
> ---
> drivers/thermal/sun8i_thermal.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/sun8i_thermal.c
> b/drivers/thermal/sun8i_thermal.c index 195f3c5d0b38..b69134538867 100644
> --- a/drivers/thermal/sun8i_thermal.c
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -190,6 +190,9 @@ static irqreturn_t sun8i_irq_thread(int irq, void *data)
> int i;
>
> for_each_set_bit(i, &irq_bitmap, tmdev->chip->sensor_num) {
> + /* We allow some zones to not register. */
> + if (IS_ERR(tmdev->sensor[i].tzd))
> + continue;
> thermal_zone_device_update(tmdev->sensor[i].tzd,
>
THERMAL_EVENT_UNSPECIFIED);
> }
> @@ -465,8 +468,17 @@ static int sun8i_ths_register(struct ths_device *tmdev)
> i,
>
&tmdev->sensor[i],
>
&ths_ops);
> - if (IS_ERR(tmdev->sensor[i].tzd))
> - return PTR_ERR(tmdev->sensor[i].tzd);
> +
> + /*
> + * If an individual zone fails to register for reasons
> + * other than probe deferral (eg, a bad DT) then carry
> + * on, other zones might register successfully.
> + */
> + if (IS_ERR(tmdev->sensor[i].tzd)) {
> + if (PTR_ERR(tmdev->sensor[i].tzd) == -
EPROBE_DEFER)
> + return PTR_ERR(tmdev-
>sensor[i].tzd);
> + continue;
> + }
>
> devm_thermal_add_hwmon_sysfs(tmdev->dev, tmdev-
>sensor[i].tzd);
> }
>
> ---
> base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c
> change-id: 20230718-thermal-sun8i-registration-df3a136ccafa
>
> Best regards,





2023-07-22 12:33:48

by Icenowy Zheng

[permalink] [raw]
Subject: Re: [PATCH] thermal/drivers/sun8i: Don't fail probe due to zone registration failure

在 2023-07-18星期二的 16:04 +0100,Mark Brown写道:
> Currently the sun8i thermal driver will fail to probe if any of the
> thermal zones it is registering fails to register with the thermal
> core.
> Since we currently do not define any trip points for the GPU thermal
> zones on at least A64 or H5 this means that we have no thermal
> support
> on these platforms:
>
> [    1.698703] thermal_sys: Failed to find 'trips' node
> [    1.698707] thermal_sys: Failed to find trip points for thermal-
> sensor id=1

I think this is an issue in the core thermal subsystem, and sent a
patch; Unfortunately the patch seems to be rejected by linux-arm-kernel
(and some other mailing lists)...

I will then resend it again and put Mark into CC list.

>
> even though the main CPU thermal zone on both SoCs is fully
> configured.
> This does not seem ideal, while we may not be able to use all the
> zones
> it seems better to have those zones which are usable be operational.
> Instead just carry on registering zones if we get any non-deferral
> error, allowing use of those zones which are usable.
>
> This means that we also need to update the interrupt handler to not
> attempt to notify the core for events on zones which we have not
> registered, I didn't see an ability to mask individual interrupts and
> I would expect that interrupts would still be indicated in the ISR
> even
> if they were masked.
>
> Signed-off-by: Mark Brown <[email protected]>
> ---
> I noticed this while trying to debug an issue with memory corruption
> on
> boot which since the merge window has prevented Pine64 Plus (an A64)
> from booting at all:
>
>   
> https://storage.kernelci.org/mainline/master/v6.5-rc2/arm64/defconfig/gcc-10/lab-baylibre/baseline-sun50i-a64-pine64-plus.txt
>
> (which I bisected to a random memory management change that clearly
> wasn't at fault) and has been causing less consistent but still very
> severe boot issues on Libretech Tritium (a H3).  The corruption
> appears
> to happen when unbinding a the one thermal zone that does register,
> I've
> not figured out exactly where.
>
> The memory corruption issue obviously needs to be dealt with properly
> (I'm still digging into it) but this does allow both platforms to
> boot
> reliably and seems like a sensible thing to do independently, ideally
> we
> could get this in as a fix.
> ---
>  drivers/thermal/sun8i_thermal.c | 16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/sun8i_thermal.c
> b/drivers/thermal/sun8i_thermal.c
> index 195f3c5d0b38..b69134538867 100644
> --- a/drivers/thermal/sun8i_thermal.c
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -190,6 +190,9 @@ static irqreturn_t sun8i_irq_thread(int irq, void
> *data)
>         int i;
>  
>         for_each_set_bit(i, &irq_bitmap, tmdev->chip->sensor_num) {
> +               /* We allow some zones to not register. */
> +               if (IS_ERR(tmdev->sensor[i].tzd))
> +                       continue;
>                 thermal_zone_device_update(tmdev->sensor[i].tzd,
>                                           
> THERMAL_EVENT_UNSPECIFIED);
>         }
> @@ -465,8 +468,17 @@ static int sun8i_ths_register(struct ths_device
> *tmdev)
>                                                       i,
>                                                       &tmdev-
> >sensor[i],
>                                                       &ths_ops);
> -               if (IS_ERR(tmdev->sensor[i].tzd))
> -                       return PTR_ERR(tmdev->sensor[i].tzd);
> +
> +               /*
> +                * If an individual zone fails to register for
> reasons
> +                * other than probe deferral (eg, a bad DT) then
> carry
> +                * on, other zones might register successfully.
> +                */
> +               if (IS_ERR(tmdev->sensor[i].tzd)) {
> +                       if (PTR_ERR(tmdev->sensor[i].tzd) == -
> EPROBE_DEFER)
> +                               return PTR_ERR(tmdev->sensor[i].tzd);
> +                       continue;
> +               }
>  
>                 devm_thermal_add_hwmon_sysfs(tmdev->dev, tmdev-
> >sensor[i].tzd);
>         }
>
> ---
> base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c
> change-id: 20230718-thermal-sun8i-registration-df3a136ccafa
>
> Best regards,

2023-07-22 17:15:24

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH] thermal/drivers/sun8i: Don't fail probe due to zone registration failure

On Sat, Jul 22, 2023 at 08:11:43PM +0800, Icenowy Zheng wrote:
> 在 2023-07-18星期二的 16:04 +0100,Mark Brown写道:

> > Since we currently do not define any trip points for the GPU thermal
> > zones on at least A64 or H5 this means that we have no thermal
> > support
> > on these platforms:

> > [    1.698703] thermal_sys: Failed to find 'trips' node
> > [    1.698707] thermal_sys: Failed to find trip points for thermal-
> > sensor id=1

> I think this is an issue in the core thermal subsystem, and sent a
> patch; Unfortunately the patch seems to be rejected by linux-arm-kernel
> (and some other mailing lists)...

It did seem to be a bit of an excessively strict requirement, I was
going to poke at that myself. It does seem worthwhile doing the change
in the sun8i driver anyway, there might be some other issue that causes
registration to fail which would have the same issue.

> I will then resend it again and put Mark into CC list.

Thanks.


Attachments:
(No filename) (996.00 B)
signature.asc (499.00 B)
Download all attachments

2023-07-23 10:25:33

by Daniel Lezcano

[permalink] [raw]
Subject: Re: [PATCH] thermal/drivers/sun8i: Don't fail probe due to zone registration failure


Hi Mark,

On 22/07/2023 18:46, Mark Brown wrote:
> On Sat, Jul 22, 2023 at 08:11:43PM +0800, Icenowy Zheng wrote:
>> 在 2023-07-18星期二的 16:04 +0100,Mark Brown写道:
>
>>> Since we currently do not define any trip points for the GPU thermal
>>> zones on at least A64 or H5 this means that we have no thermal
>>> support
>>> on these platforms:
>
>>> [    1.698703] thermal_sys: Failed to find 'trips' node
>>> [    1.698707] thermal_sys: Failed to find trip points for thermal-
>>> sensor id=1
>
>> I think this is an issue in the core thermal subsystem, and sent a
>> patch; Unfortunately the patch seems to be rejected by linux-arm-kernel
>> (and some other mailing lists)...
>
> It did seem to be a bit of an excessively strict requirement, I was
> going to poke at that myself. It does seem worthwhile doing the change
> in the sun8i driver anyway, there might be some other issue that causes
> registration to fail which would have the same issue.

Why do you want a thermal zone if there is no trip point ?


--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


2023-07-23 15:09:12

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH] thermal/drivers/sun8i: Don't fail probe due to zone registration failure

On Sun, Jul 23, 2023 at 11:40:34AM +0200, Daniel Lezcano wrote:
> On 22/07/2023 18:46, Mark Brown wrote:

> > It did seem to be a bit of an excessively strict requirement, I was
> > going to poke at that myself. It does seem worthwhile doing the change
> > in the sun8i driver anyway, there might be some other issue that causes
> > registration to fail which would have the same issue.

> Why do you want a thermal zone if there is no trip point ?

It at least allows you to see what the hardware is monitoring. It's not
terribly useful for thermal management (unless you're doing to try to do
something in userspace I guess) but it seems more helpful than
completely failing to register, especially given the knock on effects
when a single device registers multiple zones.


Attachments:
(No filename) (792.00 B)
signature.asc (499.00 B)
Download all attachments