From: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>
To: Wolfram Sang <wsa@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
linux-pm@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH 2/2] drivers/thermal/rcar_gen3_thermal: Fix device initialization
Date: Wed, 8 Feb 2023 11:12:04 +0100 [thread overview]
Message-ID: <Y+N1dDVKqUTnHLQj@oden.dyn.berto.se> (raw)
In-Reply-To: <Y+NWKZuQm6uLMkTD@ninjato>
Hi Wolfram,
Thanks for your review.
On 2023-02-08 08:58:33 +0100, Wolfram Sang wrote:
> On Tue, Feb 07, 2023 at 06:10:11PM +0100, Niklas Söderlund wrote:
> > The thermal zone is registered before the device is register and the
> > thermal coefficients are calculated, providing a window for very
> > incorrect readings.
>
> While I could never actually be in this race window, the patch makes a
> lot of sense to me.
>
> > The reason why the zone was register before the device was fully
> > initialized was that the presence of the set_trips() callback is used to
> > determine if the driver supports interrupt or not, as it is not defined
> > if the device is incapable of interrupts.
> >
> > Fix this by using the operations structure in the private data instead
> > of the zone to determine if interrupts are available or not, and
> > initialize the device before registering the zone.
> >
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> One minor question:
>
> > - if (status)
> > + if (status && priv->tscs[i]->zone)
> > thermal_zone_device_update(priv->tscs[i]->zone,
> > THERMAL_EVENT_UNSPECIFIED);
>
> Isn't this a seperate change?
Not really.
This patch changes the driver to enable interrupts just before the zone
is created. So this just guards from the very small window where an
interrupt could be fired and the zone is created, which if it would
happen would cause a null pointer dereference.
While not updating a not yet created zone is fine. But this should never
happen (tm) as the trip points have not been set when this window
exists, but better safe then sorry.
--
Kind Regards,
Niklas Söderlund
next prev parent reply other threads:[~2023-02-08 10:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 17:10 [PATCH 0/2] drivers/thermal/rcar_gen3_thermal: Fix device initialization Niklas Söderlund
2023-02-07 17:10 ` [PATCH 1/2] drivers/thermal/rcar_gen3_thermal: Create device local ops struct Niklas Söderlund
2023-02-08 7:56 ` Wolfram Sang
2023-02-07 17:10 ` [PATCH 2/2] drivers/thermal/rcar_gen3_thermal: Fix device initialization Niklas Söderlund
2023-02-08 7:58 ` Wolfram Sang
2023-02-08 10:12 ` Niklas Söderlund [this message]
2023-02-08 14:14 ` Wolfram Sang
2023-02-08 11:06 ` Daniel Lezcano
2023-02-08 18:44 ` Niklas Söderlund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y+N1dDVKqUTnHLQj@oden.dyn.berto.se \
--to=niklas.soderlund+renesas@ragnatech.se \
--cc=daniel.lezcano@linaro.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox