Re: [PATCH 6.6 000/484] 6.6.148-rc1 review

[Frank Scheiner <frank.scheiner@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2653 bytes --]

On 03.08.26 10:14, Greg Kroah-Hartman wrote:
> [...]
> Ugh.  This is what happens when we are trying to deal with stable stuff
> that is not upstream, we almost always get it wrong.
> 
> Can you send me a revert patch for this, so we can fix your build?

Locally I use [1] for now, also attached, based on linux-6.6.y at
aa0e49877a2e61e9f4ca10e039727a34f59e9964, tag: v6.6.148.

[1]: https://raw.githubusercontent.com/linux-ia64/linux-stable-rc/refs/heads/__mirror/patches/linux-6.6.y/0001-Revert-ia64-Make-acpi_cpufreq_cpu_exit-return-void.patch

>  ANd
> going forward, I think we're just going to have to stick to the "it has
> to be usptream" stuff, and if you wish to keep this arch alive outside
> of upstream, the api/build/whatever fallout will have to be on you, as
> we just can't handle it here, sorry.

I kind of understand the issue here. But if it's impossible to maintain
all architectures in an LTS kernel that were present during its first
release, the LTS somewhat loses its meaning IMHO - unless this never
covered all architectures present in a release. But then I also don't
understand:

"The ia64 architecture gets its well-earned retirement as planned,
 now that there is one last (mostly) working release that will be
 maintained as an LTS kernel."

...from [2].

[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e0c505e13162a2abe7c984309cfe2ae976b428d

But I also wonder: if a mainline patch that should go into a stable
kernel branch but won't work as is, it needs to be backported somewhow,
or?

Which is IMHO exactly the situation we have here: A mainline patch ([3])
from a Linux version (6.11) after an arch removal "failed" to modify all
relevant files in a stable Linux version (6.6) before that arch removal.
Hence that mainline patch requires modifications.

[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b4b1ddc9dfe997a5f492fa3a36487f8e7a5de30d

I assume there must have been already cases where a mainline patch was
desired, but didn't fit as is and so required modifications. If that
case is supported, it should also work for the few stable Linux branches
that still have support for ia64 included (linux-5.10.y, linux-5.15.y,
linux-6.1.y and linux-6.6.y)), no?

****

But if you can't handle that case, sure, we can do it on our own. Though
again I think there is not much of a difference to cases where a
mainline patch breaks some still supported arch, device driver, whatever
in a stable branch and people like to have both working: they cannot fix
it in mainline.

Cheers,
Frank

[-- Attachment #2: 0001-Revert-ia64-Make-acpi_cpufreq_cpu_exit-return-void.patch --]
[-- Type: text/x-patch, Size: 1296 bytes --]

From 7d213dde115b77ee5759ffffcdcd4a5026464d49 Mon Sep 17 00:00:00 2001
From: Frank Scheiner <frank.scheiner@web.de>
Date: Tue, 4 Aug 2026 15:48:08 +0200
Subject: [PATCH] Revert "ia64: Make acpi_cpufreq_cpu_exit return void"

Commit b4b1ddc9dfe9 ("cpufreq: Make cpufreq_driver->exit() return
void") was part of v6.6.145-rc1. But as it was derived from a
later Linux version w/o support for ia64 it didn't touch all
relevant parts in linux-6.6.y. Which now required an extra fix to
build correctly for ia64. But b4b1ddc9dfe9 was then not part of
the release v6.6.145. So the extra fix can go now, too.

This reverts commit bb51b626b5a8ef349b11876572540f19ad4d5030.

Signed-off-by: Frank Scheiner <frank.scheiner@web.de>
---
 drivers/cpufreq/ia64-acpi-cpufreq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/ia64-acpi-cpufreq.c b/drivers/cpufreq/ia64-acpi-cpufreq.c
index f692729068f5..c6bdc455517f 100644
--- a/drivers/cpufreq/ia64-acpi-cpufreq.c
+++ b/drivers/cpufreq/ia64-acpi-cpufreq.c
@@ -302,7 +302,7 @@ acpi_cpufreq_cpu_init (
 }
 
 
-static void
+static int
 acpi_cpufreq_cpu_exit (
 	struct cpufreq_policy   *policy)
 {
@@ -316,6 +316,8 @@ acpi_cpufreq_cpu_exit (
 		kfree(policy->freq_table);
 		kfree(data);
 	}
+
+	return (0);
 }
 
 
-- 
2.25.1