On Thu, Dec 10, 2020 at 6:23 PM Ionela Voinescu <[email protected]> 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 > > > > <[email protected]> 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!
