Re: [PATCH 1/2] acpi: cppc: add cpufreq device

["Rafael J. Wysocki" <rafael@kernel.org>]

On Thu, Dec 10, 2020 at 6:23 PM Ionela Voinescu <ionela.voinescu@arm.com> wrote:
>
> Hi Rafael,
>
> On Thursday 10 Dec 2020 at 17:55:56 (+0100), Rafael J. Wysocki wrote:
> > On Thursday, December 10, 2020 4:04:40 PM CET Mian Yousaf Kaukab wrote:
> > > On Thu, Dec 10, 2020 at 03:32:09PM +0100, Rafael J. Wysocki wrote:
> > > > On Thu, Dec 10, 2020 at 3:23 PM Mian Yousaf Kaukab
> > > > <yousaf.kaukab@suse.com> wrote:
> > > > >
> > > > > Convert cppc-cpufreq driver to a platform driver (done in a separate patch)
> > > > > and add cppc-cpufreq device when acpi_cppc_processor_probe() succeeds.
> > > >
> > > > Honestly, I prefer to drop 28f06f770454 (along with its follower)
> > > > instead of making this change.
> > > >
> > > Even if we revert 28f06f770454 there is still one more small issue that these
> > > patches fix. Currently, ACPI_PROCESSOR_DEVICE_HID is used to load cppc-cpufreq
> > > module. In case when CPPC is disabled, some cycles will be wasted in loading
> > > cppc-cpufreq module. The module will return error from the init call though
> > > so no memory is wasted.
> > >
> > > After converting to platform-driver, cppc-cpufreq module will only be loaded
> > > when the platform-device is available.
> >
> > Even so, that issue is low-impact AFAICS and may be addressed later and I'd
> > rather not let known breakage go into the mainline.
> >
> > I'm going to do drop the problematic commit now and please work with Ionela
> > to produce a clean series of patches in the right order to avoid introducing
> > issues between them.
> >
>
> The following commit will be easy to drop:
> a37afa60de38  cppc_cpufreq: optimise memory allocation for HW and NONE coordination (2 weeks ago)
>
> 28f06f770454  will be more difficult to drop as it's embedded in the
> series, and removing that one will produce conflicts in the patches
> that follow it:
>
> f9f5baa8b2a8  ACPI: processor: fix NONE coordination for domain mapping failure (3 weeks ago)
> cdb4ae5de6f7  cppc_cpufreq: expose information on frequency domains (3 weeks ago)
> c783a4d94848  cppc_cpufreq: clarify support for coordination types (3 weeks ago)
> 3bd412fb2c7f  cppc_cpufreq: use policy->cpu as driver of frequency setting (3 weeks ago)
> 28f06f770454  cppc_cpufreq: replace per-cpu structures with lists (3 weeks ago)

I dropped the commits above along with a37afa60de38 (and regenerated
my pm-cpufreq branch).

> bb025fb6c276  cppc_cpufreq: simplify use of performance capabilities (3 weeks ago)
> 48ad8dc94032  cppc_cpufreq: clean up cpu, cpu_num and cpunum variable use (3 weeks ago)
> 63087265c288  cppc_cpufreq: fix misspelling, code style and readability issues (3 weeks ago)
>
> Let me know how you want to proceed and I can either send a replacement
> series or reverts with conflicts fixed.

Please feel free to resubmit with the issue at hand addressed.

Thanks!