From: Pan Xinhui <xinhuix.pan@intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
"yanmin_zhang@linux.intel.com" <yanmin_zhang@linux.intel.com>,
"mnipxh@163.com" <mnipxh@163.com>
Subject: Re: [PATCH] acpi-cpufreq: Add a miss ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
Date: Tue, 14 Jul 2015 10:09:47 +0800 [thread overview]
Message-ID: <55A46F6B.6030006@intel.com> (raw)
In-Reply-To: <1591472.jfYRX9HXXv@vostro.rjw.lan>
hi, Rafael,
thanks for you reply :)
On 2015年07月14日 07:26, Rafael J. Wysocki wrote:
> On Monday, July 13, 2015 02:33:08 PM Pan Xinhui wrote:
>> hi, Rafeal
>> thanks for your reply. :)
>>
>> On 2015年07月11日 04:44, Rafael J. Wysocki wrote:
>>> Hi,
>>>
>>> On Fri, Jul 10, 2015 at 7:50 AM, Pan Xinhui <xinhuix.pan@intel.com> wrote:
>>>>
>>>> If CONFIG_X86_ACPI_CPUFREQ_CPB has not been defined, the placeholder for
>>>> cpb is not needed. Add ifdef around it.
>>>>
>>>> Signed-off-by: Pan Xinhui <xinhuix.pan@intel.com>
>>>> ---
>>>> drivers/cpufreq/acpi-cpufreq.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
>>>> index e7fcaa6..314a19e 100644
>>>> --- a/drivers/cpufreq/acpi-cpufreq.c
>>>> +++ b/drivers/cpufreq/acpi-cpufreq.c
>>>> @@ -884,7 +884,9 @@ static int acpi_cpufreq_resume(struct cpufreq_policy *policy)
>>>> static struct freq_attr *acpi_cpufreq_attr[] = {
>>>> &cpufreq_freq_attr_scaling_available_freqs,
>>>> &freqdomain_cpus,
>>>> +#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
>>>> NULL, /* this is a placeholder for cpb, do not remove */
>>>> +#endif
>>>
>>> Adding the ifdef here doesn't change anything, because the next NULL
>>> will play the role of the one you've just #ifdefed and the structure
>>> will be filled with zeros from that point on anyway.
>>>
>> Yes, adding ifdef here does not change any binary codes. But I want to make the codes more readable. :)
>> Patch author has noticed two *NULL* here would confuse people, especially who first read this acpi-cpufreq.c file
>> From code style point, it would be better to have #ifdef around it.
>
> Not really.
>
> Why don't you simply drop *both* NULLs?
>
Just like string end with *NULL* :)
1021 static int cpufreq_add_dev_interface(struct cpufreq_policy *policy,
1022 struct device *dev)
1023 {
1024 struct freq_attr **drv_attr;
1025 int ret = 0;
1026
1027 /* set up files for this cpu device */
1028 drv_attr = cpufreq_driver->attr;
1029 while (drv_attr && *drv_attr) {
1030 ret = sysfs_create_file(&policy->kobj, &((*drv_attr)->attr));
1031 if (ret)
1032 return ret;
1033 drv_attr++;
1034 }
If struct freq_attr *acpi_cpufreq_attr[] did not end with NULL, line 1033 will access invalid data area.
If *drv_attr(the data after struct freq_attr * array[]) happened to be not NULL. panic may hit in sysfs_create_file :(
So at least one *NULL* must be in the end of freq_attr *array[].
Actually in acpi-cpufreq.c, in acpi_cpufreq_init function.
957 struct freq_attr **iter;
958
959 pr_debug("adding sysfs entry for cpb\n");
960
961 for (iter = acpi_cpufreq_attr; *iter != NULL; iter++)
962 ;
963
964 /* make sure there is a terminator behind it */
965 if (iter[1] == NULL)
966 *iter = &cpb;
967 }
line965, check of iter[1] is not needed. Maybe the patch author was afraid of an unexpected remove of first *NULL*.
It might be a better solution to add ifdef CONFIG_X86_ACPI_CPUFREQ_CPB around that *NULL*, and remove this !iter[1] check.
thanks
xinhui
>
>>
>>> You'd need to #ifdef it in the struct freq_attr definition, but I'm
>>> not sure it's worth the effort.
>>>
>>
>> struct freq_attr *cpb* is defined in #ifdef section. :)
>
> Ah, OK.
>
>
next prev parent reply other threads:[~2015-07-14 2:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 5:50 [PATCH] acpi-cpufreq: Add a miss ifdef CONFIG_X86_ACPI_CPUFREQ_CPB Pan Xinhui
2015-07-10 20:44 ` Rafael J. Wysocki
2015-07-13 6:33 ` Pan Xinhui
2015-07-13 23:26 ` Rafael J. Wysocki
2015-07-14 2:09 ` Pan Xinhui [this message]
2015-07-14 2:52 ` Pan Xinhui
2015-07-18 0:34 ` Rafael J. Wysocki
2015-07-20 5:14 ` Pan Xinhui
2015-07-20 21:47 ` Rafael J. Wysocki
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=55A46F6B.6030006@intel.com \
--to=xinhuix.pan@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mnipxh@163.com \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.org \
--cc=yanmin_zhang@linux.intel.com \
/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;
as well as URLs for NNTP newsgroup(s).