On Tue, Nov 12, 2024 at 3:02 PM Len Brown lenb@kernel.org wrote:

On Tue, Nov 12, 2024 at 8:14 AM Rafael J. Wysocki rafael@kernel.org wrote:

...

On Tue, Nov 12, 2024 at 2:12 PM Len Brown lenb@kernel.org wrote:

...

On Tue, Nov 12, 2024 at 6:44 AM Rafael J. Wysocki rafael@kernel.org wrote:

...

...

•   if (boot_cpu_has(X86_FEATURE_MWAIT) && c->x86_vfm == INTEL_ATOM_GOLDMONT)
  

•   if (boot_cpu_has(X86_FEATURE_MWAIT) &&
  

•       (c->x86_vfm == INTEL_ATOM_GOLDMONT
  

•        || c->x86_vfm == INTEL_LUNARLAKE_M))
  

I would put the || at the end of the previous line, that is

It isn't my personal preference for human readability either, but this is what scripts/Lindent does...

Well, it doesn't match the coding style of the first line ...

Fair observation.

I'll bite.

If you took the existing intel.c and added it as a patch to the kernel, the resulting checkpatch would have 6 errors and 33 warnings.

If you ran Lindent on the existing intel.c, the resulting diff would be 408 lines -- 1 file changed, 232 insertions(+), 176 deletions(-)

This for a file that is only 1300 lines long.

If whitespace nirvana is the goal, tools are the answer, not the valuable cycles of human reviewers.

Well, the advice always given is to follow the coding style of the given fine in the first place.

checkpatch reflects the preferences of its author is this particular respect and maintainers' preferences tend to differ from one to another.