All of lore.kernel.org
 help / color / mirror / Atom feed
From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: cpuidle: fix !cpuidle_ops[cpu].init case during init
Date: Wed, 30 Mar 2016 11:31:39 +0200	[thread overview]
Message-ID: <56FB9CFB.8050305@linaro.org> (raw)
In-Reply-To: <20160330164342.10cf1830@xhacker>

On 03/30/2016 10:43 AM, Jisheng Zhang wrote:
> On Wed, 30 Mar 2016 10:41:09 +0200 Daniel Lezcano wrote:
>
>> On 03/30/2016 10:17 AM, Jisheng Zhang wrote:
>>> On Wed, 30 Mar 2016 10:09:12 +0200 Daniel Lezcano wrote:
>>>
>>>> On 03/30/2016 09:16 AM, Jisheng Zhang wrote:
>>>>> Hi Daniel,
>>>>
>>>> [ ... ]
>>>>
>>>> Added Lorenzo and Catalin.
>>>>
>>>>>> Hi Jisheng,
>>>>>>
>>>>>> this should be handled in the arm_cpuidle_read_ops function.
>>>>>>
>>>>>
>>>>> Thanks for reviewing. After some consideration, I think this patch isn't correct
>>>>> There may be platforms which doesn't need the init member at all, although
>>>>> currently I don't see such platforms in mainline, So I'll drop this patch
>>>>> and send out one v2 only does the optimization.
>>>>
>>>> There is an inconsistency between ARM and ARM64. The 'cpu_get_ops', the
>>>> arm_cpuidle_read_ops from the ARM64 side, returns -EOPNOTSUPP when the
>>>> init function is not there for cpuidle.
>>>
>>> yes.
>>> arm64's arm_cpuidle_init() returns -EOPNOTSUPP if init callback isn't defined
>>>
>>>>
>>>> I don't think it is a problem, but as ARM/ARM64 are sharing the same
>>>> cpuidle-arm.c driver it would make sense to unify the behavior between
>>>> both archs.
>>>
>>> yes, agree with you. From "unify" point of view, could I move back the suspend
>>> callback check and init callback check into arm_cpuidle_init() for arm as V1 does?
>>
>> Why ? To be consistent with ARM64 ?
>
> Yes, that's my intention.

Well, I don't have a strong opinion on that. ARM64 cpu_ops is slightly 
different from cpuidle_ops as the cpu boot / hotplug operations are 
placed in a different place and that explains why on ARM64 we can have 
an successful 'get_ops' because we use the partially filled structure. 
On ARM, it is cpuidle_ops only, so we can gracefully fail if the ops are 
not defined.

IMO, it still make sense to keep the checks in arm_cpuidle_read_ops for ARM.


-- 
  <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

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Jisheng Zhang <jszhang@marvell.com>
Cc: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] ARM: cpuidle: fix !cpuidle_ops[cpu].init case during init
Date: Wed, 30 Mar 2016 11:31:39 +0200	[thread overview]
Message-ID: <56FB9CFB.8050305@linaro.org> (raw)
In-Reply-To: <20160330164342.10cf1830@xhacker>

On 03/30/2016 10:43 AM, Jisheng Zhang wrote:
> On Wed, 30 Mar 2016 10:41:09 +0200 Daniel Lezcano wrote:
>
>> On 03/30/2016 10:17 AM, Jisheng Zhang wrote:
>>> On Wed, 30 Mar 2016 10:09:12 +0200 Daniel Lezcano wrote:
>>>
>>>> On 03/30/2016 09:16 AM, Jisheng Zhang wrote:
>>>>> Hi Daniel,
>>>>
>>>> [ ... ]
>>>>
>>>> Added Lorenzo and Catalin.
>>>>
>>>>>> Hi Jisheng,
>>>>>>
>>>>>> this should be handled in the arm_cpuidle_read_ops function.
>>>>>>
>>>>>
>>>>> Thanks for reviewing. After some consideration, I think this patch isn't correct
>>>>> There may be platforms which doesn't need the init member at all, although
>>>>> currently I don't see such platforms in mainline, So I'll drop this patch
>>>>> and send out one v2 only does the optimization.
>>>>
>>>> There is an inconsistency between ARM and ARM64. The 'cpu_get_ops', the
>>>> arm_cpuidle_read_ops from the ARM64 side, returns -EOPNOTSUPP when the
>>>> init function is not there for cpuidle.
>>>
>>> yes.
>>> arm64's arm_cpuidle_init() returns -EOPNOTSUPP if init callback isn't defined
>>>
>>>>
>>>> I don't think it is a problem, but as ARM/ARM64 are sharing the same
>>>> cpuidle-arm.c driver it would make sense to unify the behavior between
>>>> both archs.
>>>
>>> yes, agree with you. From "unify" point of view, could I move back the suspend
>>> callback check and init callback check into arm_cpuidle_init() for arm as V1 does?
>>
>> Why ? To be consistent with ARM64 ?
>
> Yes, that's my intention.

Well, I don't have a strong opinion on that. ARM64 cpu_ops is slightly 
different from cpuidle_ops as the cpu boot / hotplug operations are 
placed in a different place and that explains why on ARM64 we can have 
an successful 'get_ops' because we use the partially filled structure. 
On ARM, it is cpuidle_ops only, so we can gracefully fail if the ops are 
not defined.

IMO, it still make sense to keep the checks in arm_cpuidle_read_ops for ARM.


-- 
  <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

  reply	other threads:[~2016-03-30  9:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-24  5:11 [PATCH 0/2] ARM: cpuidle: bug fix and a trivial improvement Jisheng Zhang
2016-03-24  5:11 ` Jisheng Zhang
2016-03-24  5:11 ` [PATCH 1/2] ARM: cpuidle: fix !cpuidle_ops[cpu].init case during init Jisheng Zhang
2016-03-24  5:11   ` Jisheng Zhang
2016-03-25 11:46   ` Daniel Lezcano
2016-03-25 11:46     ` Daniel Lezcano
2016-03-30  7:16     ` Jisheng Zhang
2016-03-30  7:16       ` Jisheng Zhang
2016-03-30  8:09       ` Daniel Lezcano
2016-03-30  8:09         ` Daniel Lezcano
2016-03-30  8:17         ` Jisheng Zhang
2016-03-30  8:17           ` Jisheng Zhang
2016-03-30  8:41           ` Daniel Lezcano
2016-03-30  8:41             ` Daniel Lezcano
2016-03-30  8:43             ` Jisheng Zhang
2016-03-30  8:43               ` Jisheng Zhang
2016-03-30  9:31               ` Daniel Lezcano [this message]
2016-03-30  9:31                 ` Daniel Lezcano
2016-03-30  9:42                 ` Jisheng Zhang
2016-03-30  9:42                   ` Jisheng Zhang
2016-03-30 10:36         ` Lorenzo Pieralisi
2016-03-30 10:36           ` Lorenzo Pieralisi
2016-03-24  5:11 ` [PATCH 2/2] ARM: cpuidle: make arm_cpuidle_suspend() a bit more efficient Jisheng Zhang
2016-03-24  5:11   ` Jisheng Zhang
2016-03-25 11:52   ` Daniel Lezcano
2016-03-25 11:52     ` Daniel Lezcano

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=56FB9CFB.8050305@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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.