[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9db21e5e-ede0-87c3-a556-8a5e666d52bc@arm.com>
Date: Wed, 2 Dec 2020 12:37:38 +0000
From: Lukasz Luba <lukasz.luba@....com>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: rjw@...ysocki.net, ulf.hansson@...aro.org,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
Thara Gopinath <thara.gopinath@...aro.org>,
Lina Iyer <ilina@...eaurora.org>,
Ram Chandrasekar <rkumbako@...eaurora.org>,
Zhang Rui <rui.zhang@...el.com>, Arnd Bergmann <arnd@...db.de>,
"open list:GENERIC INCLUDE/ASM HEADER FILES"
<linux-arch@...r.kernel.org>
Subject: Re: [PATCH v4 3/4] powercap/drivers/dtpm: Add API for dynamic thermal
power management
Hi Daniel,
I realized small issue when I went through this new mutex code
(which is safer IMHO).
On 12/1/20 7:28 PM, Daniel Lezcano wrote:
[snip]
> +int dtpm_register(const char *name, struct dtpm *dtpm, struct dtpm *parent)
> +{
> + struct powercap_zone *pcz;
> +
> + if (!pct)
> + return -EAGAIN;
> +
> + if (root && !parent)
> + return -EBUSY;
> +
> + if (!root && parent)
> + return -EINVAL;
> +
> + if (parent && parent->ops)
> + return -EINVAL;
> +
Maybe it worth to add a check of dtpm pointer here, just to play safe?
if (!dtpm)
return -EINVAL;
The dtpm->ops might explode when we don't capture this miss-usage during
reviews of future drivers/shim layers. What do you think?
> + if (dtpm->ops && !(dtpm->ops->set_power_uw &&
> + dtpm->ops->get_power_uw &&
> + dtpm->ops->release))
> + return -EINVAL;
> +
I am going to stress test the whole series with hotplug today
and add review for patch 4/4.
Regards,
Lukasz
Powered by blists - more mailing lists