|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH][pvops_dom0][2/4] Introduce the external control
On 07/20/09 20:02, Yu, Ke wrote:
>> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
>> Sent: Tuesday, July 21, 2009 4:32 AM
>> To: Yu, Ke
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Tian, Kevin
>> Subject: Re: [PATCH][pvops_dom0][2/4] Introduce the external control
>> operation interface for domain0 ACPI parser
>>
>> On 07/18/09 23:46, Yu, Ke wrote:
>>
>>> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
>>> index abbe2bb..49ccb84 100644
>>> --- a/drivers/acpi/processor_idle.c
>>> +++ b/drivers/acpi/processor_idle.c
>>> @@ -425,6 +425,12 @@ static int
>>>
>> acpi_processor_get_power_info_cst(struct acpi_processor *pr)
>>
>>> cx.power = obj->integer.value;
>>>
>>> +#ifdef CONFIG_PROCESSOR_EXTERNAL_CONTROL
>>> + /* cache control methods to notify external logic */
>>> + if (processor_pm_external())
>>> + memcpy(&cx.reg, reg, sizeof(*reg));
>>> +#endif /* CONFIG_PROCESSOR_EXTERNAL_CONTROL */
>>>
>>>
>> This #ifdef should be unnecessary.
>>
>
> This "#ifdef" is the counterpart of the following patch. The cx.reg
> definition is embraced by CONFIG_PROCESSOR_EXTERNAL_CONTROL, so the code
> manipulating on the cx.reg also need "#ifdef
> CONFIG_PROCESSOR_EXTERNAL_CONTROL"
>
I see. In that case it might be better to wrap the memcpy up with an
inline function which can be defined either way, to keep the #ifdef out
of the code itself.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|