From: Stewart Smith <stewart@linux.ibm.com>
To: rjw@rjwysocki.net, daniel.lezcano@linaro.org,
benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Cc: Abhishek Goel <huntbag@linux.vnet.ibm.com>
Subject: Re: [PATCH] cpuidle/powernv : Add Description for cpuidle state
Date: Tue, 29 May 2018 11:39:01 +1000 [thread overview]
Message-ID: <87d0xf6y16.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180528173442.100642-1-huntbag@linux.vnet.ibm.com>
Abhishek Goel <huntbag@linux.vnet.ibm.com> writes:
> @@ -215,7 +216,7 @@ static inline void add_powernv_state(int index, const char *name,
> u64 psscr_val, u64 psscr_mask)
> {
> strlcpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
> - strlcpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
> + strlcpy(powernv_states[index].desc, desc, CPUIDLE_DESC_LEN);
We should still fall back to using name in the event of desc being null,
as not all firmware will expose the descriptions.
> @@ -311,6 +313,11 @@ static int powernv_add_idle_states(void)
> pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-names in DT\n");
> goto out;
> }
> + if (of_property_read_string_array(power_mgt,
> + "ibm,cpu-idle-state-descs", descs, dt_idle_states) < 0) {
> + pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-descs in DT\n");
> + goto out;
> + }
I don't think pr_warn is appropriate here, as for all current released
firmware we don't have that property. I think perhaps just silently
continuing on is okay, as we have to keep compatibility with that firmware.
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -17,7 +17,7 @@
>
> #define CPUIDLE_STATE_MAX 10
> #define CPUIDLE_NAME_LEN 16
> -#define CPUIDLE_DESC_LEN 32
> +#define CPUIDLE_DESC_LEN 60
Do we really get that long?
--
Stewart Smith
OPAL Architect, IBM.
WARNING: multiple messages have this Message-ID (diff)
From: Stewart Smith <stewart@linux.ibm.com>
To: Abhishek Goel <huntbag@linux.vnet.ibm.com>,
rjw@rjwysocki.net, daniel.lezcano@linaro.org,
benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Cc: Abhishek Goel <huntbag@linux.vnet.ibm.com>
Subject: Re: [PATCH] cpuidle/powernv : Add Description for cpuidle state
Date: Tue, 29 May 2018 11:39:01 +1000 [thread overview]
Message-ID: <87d0xf6y16.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180528173442.100642-1-huntbag@linux.vnet.ibm.com>
Abhishek Goel <huntbag@linux.vnet.ibm.com> writes:
> @@ -215,7 +216,7 @@ static inline void add_powernv_state(int index, const char *name,
> u64 psscr_val, u64 psscr_mask)
> {
> strlcpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
> - strlcpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
> + strlcpy(powernv_states[index].desc, desc, CPUIDLE_DESC_LEN);
We should still fall back to using name in the event of desc being null,
as not all firmware will expose the descriptions.
> @@ -311,6 +313,11 @@ static int powernv_add_idle_states(void)
> pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-names in DT\n");
> goto out;
> }
> + if (of_property_read_string_array(power_mgt,
> + "ibm,cpu-idle-state-descs", descs, dt_idle_states) < 0) {
> + pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-descs in DT\n");
> + goto out;
> + }
I don't think pr_warn is appropriate here, as for all current released
firmware we don't have that property. I think perhaps just silently
continuing on is okay, as we have to keep compatibility with that firmware.
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -17,7 +17,7 @@
>
> #define CPUIDLE_STATE_MAX 10
> #define CPUIDLE_NAME_LEN 16
> -#define CPUIDLE_DESC_LEN 32
> +#define CPUIDLE_DESC_LEN 60
Do we really get that long?
--
Stewart Smith
OPAL Architect, IBM.
next prev parent reply other threads:[~2018-05-29 1:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-28 17:34 [PATCH] cpuidle/powernv : Add Description for cpuidle state Abhishek Goel
2018-05-29 1:39 ` Stewart Smith [this message]
2018-05-29 1:39 ` Stewart Smith
2018-05-29 12:30 ` Michael Ellerman
2018-05-29 12:30 ` Michael Ellerman
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=87d0xf6y16.fsf@linux.vnet.ibm.com \
--to=stewart@linux.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=daniel.lezcano@linaro.org \
--cc=huntbag@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=rjw@rjwysocki.net \
/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.