All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
	Daniel Lezcano
	<daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2] cpuidle: tegra: Correctly handle result of arm_cpuidle_simple_enter()
Date: Thu, 9 Jul 2020 10:51:07 +0100	[thread overview]
Message-ID: <fb6370d9-cae9-15dd-a19b-c3116256b471@nvidia.com> (raw)
In-Reply-To: <55744bfb-af5e-ed2e-654c-d6de9b26b696-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>



On 09/07/2020 10:48, Dmitry Osipenko wrote:
> 09.07.2020 12:06, Jon Hunter пишет:
>>
>> On 08/07/2020 15:32, Dmitry Osipenko wrote:
>>> 08.07.2020 15:34, Jon Hunter пишет:
>>>>
>>>> On 02/07/2020 01:13, Dmitry Osipenko wrote:
>>>>> The enter() callback of CPUIDLE drivers returns index of the entered idle
>>>>> state on success or a negative value on failure. The negative value could
>>>>> any negative value, i.e. it doesn't necessarily needs to be a error code.
>>>>> That's because CPUIDLE core only cares about the fact of failure and not
>>>>> about the reason of the enter() failure.
>>>>>
>>>>> Like every other enter() callback, the arm_cpuidle_simple_enter() returns
>>>>> the entered idle-index on success. Unlike some of other drivers, it never
>>>>> fails. It happened that TEGRA_C1=index=err=0 in the code of cpuidle-tegra
>>>>> driver, and thus, there is no problem for the cpuidle-tegra driver created
>>>>> by the typo in the code which assumes that the arm_cpuidle_simple_enter()
>>>>> returns a error code.
>>>>>
>>>>> The arm_cpuidle_simple_enter() also may return a -ENODEV error if CPU_IDLE
>>>>> is disabled in a kernel's config, but all CPUIDLE drivers are disabled if
>>>>> CPU_IDLE is disabled, including the cpuidle-tegra driver. So we can't ever
>>>>> see the error code from arm_cpuidle_simple_enter() today.
>>>>>
>>>>> Of course the code may get some changes in the future and then the typo
>>>>> may transform into a real bug, so let's correct the typo in the code by
>>>>> making tegra_cpuidle_enter() to directly return the index returned by the
>>>>> arm_cpuidle_simple_enter().
>>>>
>>>> Are you suggesting that arm_cpuidle_simple_enter() could be updated to
>>>> actually return an error? Sorry it is not clear to me what you are implying.
>>>
>>> Hello, Jon!
>>>
>>> Yes, I'm saying that *potentially* arm_cpuidle_simple_enter() could be
>>> updated to actually return error.
>>
>>
>> OK, then I am confused, because after your change, we would now ignore
>> any error that could be returned in the future. Yes the current code
>> does not set the variable 'index' correctly, but before we set the value
>> of 'index' shouldn't we check that the value being returned is not a
>> negative error code first?
> 
> Could you please clarify what do you mean by "ignore any error"? Do you
> mean the error message?

Yes exactly. We would skip that, which seems a bit odd.

Jon

-- 
nvpublic

WARNING: multiple messages have this Message-ID (diff)
From: Jon Hunter <jonathanh@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: <linux-pm@vger.kernel.org>, <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v2] cpuidle: tegra: Correctly handle result of arm_cpuidle_simple_enter()
Date: Thu, 9 Jul 2020 10:51:07 +0100	[thread overview]
Message-ID: <fb6370d9-cae9-15dd-a19b-c3116256b471@nvidia.com> (raw)
In-Reply-To: <55744bfb-af5e-ed2e-654c-d6de9b26b696@gmail.com>



On 09/07/2020 10:48, Dmitry Osipenko wrote:
> 09.07.2020 12:06, Jon Hunter пишет:
>>
>> On 08/07/2020 15:32, Dmitry Osipenko wrote:
>>> 08.07.2020 15:34, Jon Hunter пишет:
>>>>
>>>> On 02/07/2020 01:13, Dmitry Osipenko wrote:
>>>>> The enter() callback of CPUIDLE drivers returns index of the entered idle
>>>>> state on success or a negative value on failure. The negative value could
>>>>> any negative value, i.e. it doesn't necessarily needs to be a error code.
>>>>> That's because CPUIDLE core only cares about the fact of failure and not
>>>>> about the reason of the enter() failure.
>>>>>
>>>>> Like every other enter() callback, the arm_cpuidle_simple_enter() returns
>>>>> the entered idle-index on success. Unlike some of other drivers, it never
>>>>> fails. It happened that TEGRA_C1=index=err=0 in the code of cpuidle-tegra
>>>>> driver, and thus, there is no problem for the cpuidle-tegra driver created
>>>>> by the typo in the code which assumes that the arm_cpuidle_simple_enter()
>>>>> returns a error code.
>>>>>
>>>>> The arm_cpuidle_simple_enter() also may return a -ENODEV error if CPU_IDLE
>>>>> is disabled in a kernel's config, but all CPUIDLE drivers are disabled if
>>>>> CPU_IDLE is disabled, including the cpuidle-tegra driver. So we can't ever
>>>>> see the error code from arm_cpuidle_simple_enter() today.
>>>>>
>>>>> Of course the code may get some changes in the future and then the typo
>>>>> may transform into a real bug, so let's correct the typo in the code by
>>>>> making tegra_cpuidle_enter() to directly return the index returned by the
>>>>> arm_cpuidle_simple_enter().
>>>>
>>>> Are you suggesting that arm_cpuidle_simple_enter() could be updated to
>>>> actually return an error? Sorry it is not clear to me what you are implying.
>>>
>>> Hello, Jon!
>>>
>>> Yes, I'm saying that *potentially* arm_cpuidle_simple_enter() could be
>>> updated to actually return error.
>>
>>
>> OK, then I am confused, because after your change, we would now ignore
>> any error that could be returned in the future. Yes the current code
>> does not set the variable 'index' correctly, but before we set the value
>> of 'index' shouldn't we check that the value being returned is not a
>> negative error code first?
> 
> Could you please clarify what do you mean by "ignore any error"? Do you
> mean the error message?

Yes exactly. We would skip that, which seems a bit odd.

Jon

-- 
nvpublic

  parent reply	other threads:[~2020-07-09  9:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-02  0:13 [PATCH v2] cpuidle: tegra: Correctly handle result of arm_cpuidle_simple_enter() Dmitry Osipenko
2020-07-02  0:13 ` Dmitry Osipenko
     [not found] ` <20200702001354.27056-1-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-07-08 12:34   ` Jon Hunter
2020-07-08 12:34     ` Jon Hunter
     [not found]     ` <4ffff3d8-2d41-3fb2-ed16-c9662d18d261-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2020-07-08 14:32       ` Dmitry Osipenko
2020-07-08 14:32         ` Dmitry Osipenko
     [not found]         ` <3bc2064e-e94d-984c-edab-50b4dc2fd2dd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-07-09  9:06           ` Jon Hunter
2020-07-09  9:06             ` Jon Hunter
     [not found]             ` <be99caca-b50a-0e12-29dc-2da0d924af43-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2020-07-09  9:48               ` Dmitry Osipenko
2020-07-09  9:48                 ` Dmitry Osipenko
     [not found]                 ` <55744bfb-af5e-ed2e-654c-d6de9b26b696-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-07-09  9:51                   ` Jon Hunter [this message]
2020-07-09  9:51                     ` Jon Hunter
     [not found]                     ` <fb6370d9-cae9-15dd-a19b-c3116256b471-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2020-07-09 10:21                       ` Dmitry Osipenko
2020-07-09 10:21                         ` Dmitry Osipenko

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=fb6370d9-cae9-15dd-a19b-c3116256b471@nvidia.com \
    --to=jonathanh-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
    --cc=daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.