Re: [PATCH v6 2/7] ACPI: Make ACPI processor driver more extensible

[Sudeep Holla <sudeep.holla@arm.com>]

Hi Ashwin.

On 09/07/15 13:25, Ashwin Chaugule wrote:
> Hi Sudeep,
>
>
> On 9 July 2015 at 05:06, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> Hi,
>>
>> On 08/07/15 21:28, Ashwin Chaugule wrote:
>>>
>>> On 8 July 2015 at 16:05, Ashwin Chaugule <ashwin.chaugule@linaro.org>
>>> wrote:
>>>>
>>>> On 8 July 2015 at 15:55, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>> Perhaps the confusion is coming from the introduction of ACPI_CST in
>>> this file. I could leave it as it is and just separate out the
>>> ACPI_PSS bits. But I figured, while I'm at it, I'd introduce ACPI_CST,
>>> since we know the LPI stuff is coming up soon as a CST alternative
>>> anyway. So if you prefer, I can drop the CST bits and maybe Sudeep can
>>> address that as part of his LPI patchset?
>>>
>>
>> Correct, I will handle it as a prerequisite for introducing _LPI
>> support. I had posted an RFC long back, will revive those patches and
>> repost them soon.
>>
>> It's better to enable ACPI_PROCESSOR on ARM64 only after we have all
>> these dependencies resolved. Until then we need to carry some patches
>> locally for testing.
>
> With Rafaels latest suggestion of adding ACPI_PROCESSOR_IDLE, we dont
> need to wait until all dependencies are resolved to enable
> acpi_processor on ARM64. CPPC patchwork has been up for review for
> quite a long time and has been validated on hardware. There is no
> reason for it to be blocked until LPI is upstream ready.
>

Agreed, by the way I didn't mean to block CPPC work. It can be merged
when/if it's ready irrespective of _LPI support, what I meant is to
enable ACPI_PROCESSOR on ARM64 when other dependencies are resolved
rather than introducing just build fixes for time-being.

I think we still have one dependency for hotplug. I don't like the weak
definitions introduced, but don't have a better solution either.

Regards,
Sudeep