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@xxxxxxxx> 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) 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. Also, if you want you can drop all 5 (all before and including 28f06f770454), and I can add them again in the series that fixes the problem that Yousaf reported. Thanks, Ionela. > If that is done timely enough, it may still be possible to push those patches > for 5.11-rc1. > > Thanks! > > >
