From: Dan Carpenter <dan.carpenter@oracle.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-pm@vger.kernel.org
Subject: Re: [bug report] thermal: Add cooling device's statistics in sysfs
Date: Mon, 17 Oct 2022 16:19:40 +0300 [thread overview]
Message-ID: <Y01WbMOnqnA0riM4@kadam> (raw)
In-Reply-To: <20221017093829.h2yiawwpffn67qme@vireshk-i7>
On Mon, Oct 17, 2022 at 03:08:29PM +0530, Viresh Kumar wrote:
> On 14-10-22, 17:30, Dan Carpenter wrote:
> > (There are some drivers which might cap new_state. I only looked at
> > tc654_set_cur_state() and it doesn't cap the value. It's always going
> > to be safer to do the bounds checking in a central place).
>
> I agree that it is better to do it at central place.
>
> But, tc654_set_cur_state() seems to be doing it just fine:
>
> static int tc654_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
> {
> struct tc654_data *data = tc654_update_client(cdev->devdata);
>
> if (IS_ERR(data))
> return PTR_ERR(data);
>
> return _set_pwm(data, clamp_val(state, 0, TC654_MAX_COOLING_STATE));
Ideally it would return -EINVAL for invalid state values instead of
clamping it to a valid range.
I feel like -EINVAL is generally a better API. But also if we're
relying it to check and return an error code then obviously that's not
what it does.
regards,
dan carpenter
next prev parent reply other threads:[~2022-10-17 13:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-14 14:08 [bug report] thermal: Add cooling device's statistics in sysfs Dan Carpenter
2022-10-14 14:30 ` Dan Carpenter
2022-10-17 9:38 ` Viresh Kumar
2022-10-17 13:19 ` Dan Carpenter [this message]
2022-10-18 4:02 ` Viresh Kumar
2022-10-17 5:57 ` Viresh Kumar
2022-10-17 7:09 ` Dan Carpenter
2022-10-17 7:10 ` Viresh Kumar
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=Y01WbMOnqnA0riM4@kadam \
--to=dan.carpenter@oracle.com \
--cc=linux-pm@vger.kernel.org \
--cc=viresh.kumar@linaro.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