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

Hi Ashwin.

On 09/07/15 13:25, Ashwin Chaugule wrote:

Hi Sudeep,


On 9 July 2015 at 05:06, Sudeep Holla [off-list ref] wrote:

quoted

Hi,

On 08/07/15 21:28, Ashwin Chaugule wrote:

quoted

On 8 July 2015 at 16:05, Ashwin Chaugule [off-list ref]
wrote:

quoted

On 8 July 2015 at 15:55, Rafael J. Wysocki [off-list ref] 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