Message ID | E1qkoRr-0088Q8-Da@rmk-PC.armlinux.org.uk |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp1344701vqu; Mon, 25 Sep 2023 09:44:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IED9Smstp8Hw6cfJBaK6WyiCVmqfT0FglJff+WxpioyQRQHLgUjyqHjqkha5wm5j+LqMXj6 X-Received: by 2002:a05:6a20:8e19:b0:15a:f7fd:dd97 with SMTP id y25-20020a056a208e1900b0015af7fddd97mr8308796pzj.2.1695660255629; Mon, 25 Sep 2023 09:44:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695660255; cv=none; d=google.com; s=arc-20160816; b=dfgVxmU7C+EZn5aQmAZbi4Jnbdp3ZZGhChXbtZuVRC4++BdMtqRlyj2ShjR2iOns6D Aytdvns/m+aj4ltMDb3pNO7hGiHO288P5lQEvaDQmmpLuTtFf/W6HSNx7UpFUqdv+3yJ KtzGhGONGPCEJ5O42n5MABKy3L2LStY9duNeAVRU+PiVJBWn3kAJed3mn4eKYAm8+0Pt EItOxIidha9FAqekvtKRq0eNR+kWSEZCKiYgt+G0+SKTb2ezw/qMQgVtOII1oN8cJER+ yixWv58FwI9q5OxqbvGLXmp05s3ww28SJyhTJ0BPRcgx3R39Q0FNCM94G1qCbWnMwK1C lOoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:date:sender:message-id:content-transfer-encoding :content-disposition:mime-version:subject:cc:to:from:dkim-signature; bh=qjYxvP0mrwNQum3AINuFgWcLiPmukjSCAlOcMPWNC70=; fh=nvvPwaR1OLWUo7NXfFyb0oQsr/1AtL5DJpgyJn5ndF8=; b=ya34yS/65pQNGGMQYJ31lr5IRUkhdSYHu58YO/2a8icfP5SfaHvSnq2LJUt4W2a2QD zOnCnMys1GpCxxFJ1dNP0JdPsPFyRZVArYHIDAcAXYF6PA14zbj8QpWiZgrX+23gQs3C 0+Omrcr0IcWmBkWq9gq4GNm/RemzYKJIQWZ7Nh/3gxXMRfrqSTU9sf5VPed6/G2yOZmI GMA5fcf86SL3d/QS4PkALtoIaUsS4vpHC6avkVG7hIjnDH7aabtAAH7e2b/57YXwcPan rjWrPU7AchT5wKz9iSSavpDtR2HDhY/KKh4Uje6uJgZcVEYfOMwFnir9W96gmhikAKSM U4pg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=H7LRzpes; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id o8-20020a056a001bc800b0068a3c575900si9948069pfw.84.2023.09.25.09.44.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 09:44:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=H7LRzpes; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 8636D80B31E4; Mon, 25 Sep 2023 09:29:03 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232062AbjIYQ3A (ORCPT <rfc822;pusanteemu@gmail.com> + 29 others); Mon, 25 Sep 2023 12:29:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229777AbjIYQ2z (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 25 Sep 2023 12:28:55 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7989AFC; Mon, 25 Sep 2023 09:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Date:Sender:Message-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:Subject:Cc:To:From:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qjYxvP0mrwNQum3AINuFgWcLiPmukjSCAlOcMPWNC70=; b=H7LRzpeszu/NjlEcIS+36zsQZ6 1B2GjUbmFECUohpWGtvulUpk25WC7XKYTRHHT/Eml4mDxX0AMEEVJ060wH21PeS3gfykNAY0NM0X4 +GWdzx+YKVVo1kbovXqnfBMQBs1dqZfTnGZ7fo2JV+E0m3nna6kCsI5T89nijgI58vuJn5P29+V4C TXReirRZWjAEDIygIzmuA0o2B8fguAE2q+5Iicf9b35Wzovei5lcs3hzooqVcv2w+BQzFB8kmlAql ls3/NA9AIJUS/9j4ONw4bjJEaiyshFeUbtMhnMk82oY4iHK+oHm6dodVie7aPbYAkW55ITbJCUDoG wexoGNlg==; Received: from e0022681537dd.dyn.armlinux.org.uk ([fd8f:7570:feb6:1:222:68ff:fe15:37dd]:56656 helo=rmk-PC.armlinux.org.uk) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <rmk@armlinux.org.uk>) id 1qkoRq-0001Ke-1k; Mon, 25 Sep 2023 17:28:38 +0100 Received: from rmk by rmk-PC.armlinux.org.uk with local (Exim 4.94.2) (envelope-from <rmk@rmk-PC.armlinux.org.uk>) id 1qkoRr-0088Q8-Da; Mon, 25 Sep 2023 17:28:39 +0100 From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> To: Thomas Gleixner <tglx@linutronix.de> Cc: linux-acpi@vger.kernel.org, James Morse <james.morse@arm.com>, loongarch@lists.linux.dev, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar <mingo@redhat.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, jianyong.wu@arm.com, justin.he@arm.com, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, Salil Mehta <salil.mehta@huawei.com>, x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Peter Zijlstra <peterz@infradead.org>, linux-ia64@vger.kernel.org Subject: [PATCH] cpu-hotplug: provide prototypes for arch CPU registration MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Message-Id: <E1qkoRr-0088Q8-Da@rmk-PC.armlinux.org.uk> Sender: Russell King <rmk@armlinux.org.uk> Date: Mon, 25 Sep 2023 17:28:39 +0100 X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Mon, 25 Sep 2023 09:29:04 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778028648152631770 X-GMAIL-MSGID: 1778028648152631770 |
Series |
cpu-hotplug: provide prototypes for arch CPU registration
|
|
Commit Message
Russell King (Oracle)
Sept. 25, 2023, 4:28 p.m. UTC
Provide common prototypes for arch_register_cpu() and
arch_unregister_cpu(). These are called by acpi_processor.c, with
weak versions, so the prototype for this is already set. It is
generally not necessary for function prototypes to be conditional
on preprocessor macros.
Some architectures (e.g. Loongarch) are missing the prototype for this,
and rather than add it to Loongarch's asm/cpu.h, lets do the job once
for everyone.
Since this covers everyone, remove the now unnecessary prototypes in
asm/cpu.h, and we also need to remove the 'static' from one of ia64's
arch_register_cpu() definitions.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
Changes since RFC v2:
- drop ia64 changes, as ia64 has already been removed.
arch/x86/include/asm/cpu.h | 2 --
arch/x86/kernel/topology.c | 2 +-
include/linux/cpu.h | 2 ++
3 files changed, 3 insertions(+), 3 deletions(-)
Comments
Hi Russell, On 9/26/23 02:28, Russell King (Oracle) wrote: > Provide common prototypes for arch_register_cpu() and > arch_unregister_cpu(). These are called by acpi_processor.c, with > weak versions, so the prototype for this is already set. It is > generally not necessary for function prototypes to be conditional > on preprocessor macros. > > Some architectures (e.g. Loongarch) are missing the prototype for this, > and rather than add it to Loongarch's asm/cpu.h, lets do the job once > for everyone. > > Since this covers everyone, remove the now unnecessary prototypes in > asm/cpu.h, and we also need to remove the 'static' from one of ia64's > arch_register_cpu() definitions. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > Changes since RFC v2: > - drop ia64 changes, as ia64 has already been removed. > > arch/x86/include/asm/cpu.h | 2 -- > arch/x86/kernel/topology.c | 2 +- > include/linux/cpu.h | 2 ++ > 3 files changed, 3 insertions(+), 3 deletions(-) > In Linux 6.6.rc3, the prototypes are still existing in arch/ia64/include/asm/cpu.h. They may have been dropped in other ia64 or x86 git repository, which this patch bases on. In the commit message, 'static' from one of ia64's arch_register_cpu() definitions is removed, but there is no changes related to ia64 in this patch. I guess that's probably x86? > diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h > index 3a233ebff712..25050d953eee 100644 > --- a/arch/x86/include/asm/cpu.h > +++ b/arch/x86/include/asm/cpu.h > @@ -28,8 +28,6 @@ struct x86_cpu { > }; > > #ifdef CONFIG_HOTPLUG_CPU > -extern int arch_register_cpu(int num); > -extern void arch_unregister_cpu(int); > extern void soft_restart_cpu(void); > #endif > > diff --git a/arch/x86/kernel/topology.c b/arch/x86/kernel/topology.c > index ca004e2e4469..0bab03130033 100644 > --- a/arch/x86/kernel/topology.c > +++ b/arch/x86/kernel/topology.c > @@ -54,7 +54,7 @@ void arch_unregister_cpu(int num) > EXPORT_SYMBOL(arch_unregister_cpu); > #else /* CONFIG_HOTPLUG_CPU */ > > -static int __init arch_register_cpu(int num) > +int __init arch_register_cpu(int num) > { > return register_cpu(&per_cpu(cpu_devices, num).cpu, num); > } I think arch/ia64/kernel/topology.c may need same change, as stated in the commit log. In linux 6.6.rc3, 'static' exists in arch/ia64/kernel/topology.c::arch_register_cpu(). Again, your patch may have been based on other git repository. > diff --git a/include/linux/cpu.h b/include/linux/cpu.h > index 0abd60a7987b..eb768a866fe3 100644 > --- a/include/linux/cpu.h > +++ b/include/linux/cpu.h > @@ -80,6 +80,8 @@ extern __printf(4, 5) > struct device *cpu_device_create(struct device *parent, void *drvdata, > const struct attribute_group **groups, > const char *fmt, ...); > +extern int arch_register_cpu(int cpu); > +extern void arch_unregister_cpu(int cpu); > #ifdef CONFIG_HOTPLUG_CPU > extern void unregister_cpu(struct cpu *cpu); > extern ssize_t arch_cpu_probe(const char *, size_t); Thanks, Gavin
On Tue, Sep 26, 2023 at 09:04:46AM +1000, Gavin Shan wrote: > Hi Russell, > > On 9/26/23 02:28, Russell King (Oracle) wrote: > > Provide common prototypes for arch_register_cpu() and > > arch_unregister_cpu(). These are called by acpi_processor.c, with > > weak versions, so the prototype for this is already set. It is > > generally not necessary for function prototypes to be conditional > > on preprocessor macros. > > > > Some architectures (e.g. Loongarch) are missing the prototype for this, > > and rather than add it to Loongarch's asm/cpu.h, lets do the job once > > for everyone. > > > > Since this covers everyone, remove the now unnecessary prototypes in > > asm/cpu.h, and we also need to remove the 'static' from one of ia64's > > arch_register_cpu() definitions. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > --- > > Changes since RFC v2: > > - drop ia64 changes, as ia64 has already been removed. > > > > arch/x86/include/asm/cpu.h | 2 -- > > arch/x86/kernel/topology.c | 2 +- > > include/linux/cpu.h | 2 ++ > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > In Linux 6.6.rc3, the prototypes are still existing in arch/ia64/include/asm/cpu.h. Correct, but I have been told that IA64 has been removed, so I removed those changes from my patch. > They may have been dropped in other ia64 or x86 git repository, which this patch > bases on. I have no idea which repository they have been dropped from. I only know what tglx told me, and despite asking the question, I never got any answer. So I've done the best I can with this patch. If kernel devs want to state things in vague terms, and then go silent when asked questions to elaborate, then that leads to guessing. Maybe someone else should adapt this patch to apply to whatever tree it is going to end up being applied to - because I have no idea _which_ tree it'll end up being applied to.
On Tue, Sep 26, 2023 at 12:17:19AM +0100, Russell King (Oracle) wrote: > On Tue, Sep 26, 2023 at 09:04:46AM +1000, Gavin Shan wrote: > > Hi Russell, > > > > On 9/26/23 02:28, Russell King (Oracle) wrote: > > > Provide common prototypes for arch_register_cpu() and > > > arch_unregister_cpu(). These are called by acpi_processor.c, with > > > weak versions, so the prototype for this is already set. It is > > > generally not necessary for function prototypes to be conditional > > > on preprocessor macros. > > > > > > Some architectures (e.g. Loongarch) are missing the prototype for this, > > > and rather than add it to Loongarch's asm/cpu.h, lets do the job once > > > for everyone. > > > > > > Since this covers everyone, remove the now unnecessary prototypes in > > > asm/cpu.h, and we also need to remove the 'static' from one of ia64's > > > arch_register_cpu() definitions. > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > --- > > > Changes since RFC v2: > > > - drop ia64 changes, as ia64 has already been removed. > > > > > > arch/x86/include/asm/cpu.h | 2 -- > > > arch/x86/kernel/topology.c | 2 +- > > > include/linux/cpu.h | 2 ++ > > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > > > > In Linux 6.6.rc3, the prototypes are still existing in arch/ia64/include/asm/cpu.h. > > Correct, but I have been told that IA64 has been removed, so I removed > those changes from my patch. > > > They may have been dropped in other ia64 or x86 git repository, which this patch > > bases on. > > I have no idea which repository they have been dropped from. I only know > what tglx told me, and despite asking the question, I never got any > answer. So I've done the best I can with this patch. If kernel devs want > to state things in vague terms, and then go silent when asked questions > to elaborate, then that leads to guessing. > > Maybe someone else should adapt this patch to apply to whatever tree it > is going to end up being applied to - because I have no idea _which_ > tree it'll end up being applied to. So, is this how the Linux community is now dysfunctional? Someone sends a patch. Thomas reviews, says it's a good idea and provides some feedback. Author asks questions, gets ignored. Author sends a patch taking in to account that previous feedback. Someone else replies, contradicting the previous feedback. Nothing else happens. What a bloody sorry state of affairs. Makes me wonder what the point of trying to contribute to the Linux kernel outside of the areas I actually maintain anymore is.
On 10/3/2023 7:34 AM, Russell King (Oracle) wrote: >>>> >>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>>> --- >>>> Changes since RFC v2: >>>> - drop ia64 changes, as ia64 has already been removed. >>>> If this is RFC v2, we put "RFC v2" in the subject, then people know you are sending a newer version. People are busy, and your patch could be skipped if it appears the same as a previous one.
On Tue, Oct 03, 2023 at 10:37:02AM -0700, Xin Li wrote: > On 10/3/2023 7:34 AM, Russell King (Oracle) wrote: > > > > > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > > --- > > > > > Changes since RFC v2: > > > > > - drop ia64 changes, as ia64 has already been removed. > > > > > > > If this is RFC v2, we put "RFC v2" in the subject, then people know you > are sending a newer version. Sorry, but this is yet another illustration why the kernel process is broken. Clearly, people do NOT bother reading what is actually written, but instead make up in their minds something completely different. This is *NOT* RFC v2. This is RFC v2: https://lore.kernel.org/all/E1qgnh2-007ZRZ-WD@rmk-PC.armlinux.org.uk/ And what I wrote was "changes **** SINCE **** RFC v2". For those who find English difficult, this means that what follows is the list of changes that are in THIS posting that WERE NOT IN THE PREVIOUS POSTING which was RFC v2. Thanks for making me even more frustrated than I was. > People are busy, and your patch could be > skipped if it appears the same as a previous one. Yet another reason why the kernel process is just completely broken. "appears to be". Even when the changes are spelled out. Yes, right, people don't have time to read. If that's the case, then it's a waste of time adding a change log. It's a waste of time to add a commit message. In fact, it's a total waste of time trying to contribute to a rotten-to-the-core open source project that Linux seems to have turned into.
Okay, I give up. 15 days, still no real progress. I don't see any point in submitting any further patches for the kernel outside of those areas that I maintain. Clearly no one cares enough to bother (a) properly reviewing the patch, (b) applying the patch that Thomas thought "makes tons of sense." If patches that "makes tons of sense" just get ignored, then what does the future of the kernel hold? Crap, that's what, utter crap. As I said, it seems that the Linux kernel process is basically totally broken and rotten. If a six line patch that "makes tons of sense" can't be applied, then there's basically no hope what so ever. FFS. On Mon, Sep 25, 2023 at 05:28:39PM +0100, Russell King (Oracle) wrote: > Provide common prototypes for arch_register_cpu() and > arch_unregister_cpu(). These are called by acpi_processor.c, with > weak versions, so the prototype for this is already set. It is > generally not necessary for function prototypes to be conditional > on preprocessor macros. > > Some architectures (e.g. Loongarch) are missing the prototype for this, > and rather than add it to Loongarch's asm/cpu.h, lets do the job once > for everyone. > > Since this covers everyone, remove the now unnecessary prototypes in > asm/cpu.h, and we also need to remove the 'static' from one of ia64's > arch_register_cpu() definitions. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > Changes since RFC v2: > - drop ia64 changes, as ia64 has already been removed. > > arch/x86/include/asm/cpu.h | 2 -- > arch/x86/kernel/topology.c | 2 +- > include/linux/cpu.h | 2 ++ > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h > index 3a233ebff712..25050d953eee 100644 > --- a/arch/x86/include/asm/cpu.h > +++ b/arch/x86/include/asm/cpu.h > @@ -28,8 +28,6 @@ struct x86_cpu { > }; > > #ifdef CONFIG_HOTPLUG_CPU > -extern int arch_register_cpu(int num); > -extern void arch_unregister_cpu(int); > extern void soft_restart_cpu(void); > #endif > > diff --git a/arch/x86/kernel/topology.c b/arch/x86/kernel/topology.c > index ca004e2e4469..0bab03130033 100644 > --- a/arch/x86/kernel/topology.c > +++ b/arch/x86/kernel/topology.c > @@ -54,7 +54,7 @@ void arch_unregister_cpu(int num) > EXPORT_SYMBOL(arch_unregister_cpu); > #else /* CONFIG_HOTPLUG_CPU */ > > -static int __init arch_register_cpu(int num) > +int __init arch_register_cpu(int num) > { > return register_cpu(&per_cpu(cpu_devices, num).cpu, num); > } > diff --git a/include/linux/cpu.h b/include/linux/cpu.h > index 0abd60a7987b..eb768a866fe3 100644 > --- a/include/linux/cpu.h > +++ b/include/linux/cpu.h > @@ -80,6 +80,8 @@ extern __printf(4, 5) > struct device *cpu_device_create(struct device *parent, void *drvdata, > const struct attribute_group **groups, > const char *fmt, ...); > +extern int arch_register_cpu(int cpu); > +extern void arch_unregister_cpu(int cpu); > #ifdef CONFIG_HOTPLUG_CPU > extern void unregister_cpu(struct cpu *cpu); > extern ssize_t arch_cpu_probe(const char *, size_t); > -- > 2.30.2 > >
On Tue, Oct 10 2023 at 17:23, Russell King wrote: > Okay, I give up. 15 days, still no real progress. I don't see any point > in submitting any further patches for the kernel outside of those areas > that I maintain. Clearly no one cares enough to bother (a) properly > reviewing the patch, (b) applying the patch that Thomas thought > "makes tons of sense." > > If patches that "makes tons of sense" just get ignored, then what does > the future of the kernel hold? Crap, that's what, utter crap. > > As I said, it seems that the Linux kernel process is basically totally > broken and rotten. If a six line patch that "makes tons of sense" can't > be applied, then there's basically no hope what so ever. Oh well. I usually try to keep track of such stuff, but this one fell through the cracks. Shit happens and we are all human, no? Sorry for the wrong information about ia64. The removal did not happen because someone stepped up as a possible maintainer. Thanks, tglx
Hello Thomas, st 11. 10. 2023 v 14:06 odesílatel Thomas Gleixner <tglx@linutronix.de> napsal: > > Sorry for the wrong information about ia64. The removal did not happen > because someone stepped up as a possible maintainer. > Does that mean that the removal patch will be reverted soon in asm-generic and linux-next? Both have no ia64 as of now, and there are already a few patches without ia64 part (e,g, https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git/commit/?id=2fd0ebad27bcd4c8fc61c61a98d4283c47054bcf). Without the revert, patches affecting ia64 will conflict. I am the person who volunteered to maintain the architecture. If the removal was indeed cancelled, me and Frank Scheiner can start testing and reviewing patches affecting ia64. Thanks, Tomas
diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h index 3a233ebff712..25050d953eee 100644 --- a/arch/x86/include/asm/cpu.h +++ b/arch/x86/include/asm/cpu.h @@ -28,8 +28,6 @@ struct x86_cpu { }; #ifdef CONFIG_HOTPLUG_CPU -extern int arch_register_cpu(int num); -extern void arch_unregister_cpu(int); extern void soft_restart_cpu(void); #endif diff --git a/arch/x86/kernel/topology.c b/arch/x86/kernel/topology.c index ca004e2e4469..0bab03130033 100644 --- a/arch/x86/kernel/topology.c +++ b/arch/x86/kernel/topology.c @@ -54,7 +54,7 @@ void arch_unregister_cpu(int num) EXPORT_SYMBOL(arch_unregister_cpu); #else /* CONFIG_HOTPLUG_CPU */ -static int __init arch_register_cpu(int num) +int __init arch_register_cpu(int num) { return register_cpu(&per_cpu(cpu_devices, num).cpu, num); } diff --git a/include/linux/cpu.h b/include/linux/cpu.h index 0abd60a7987b..eb768a866fe3 100644 --- a/include/linux/cpu.h +++ b/include/linux/cpu.h @@ -80,6 +80,8 @@ extern __printf(4, 5) struct device *cpu_device_create(struct device *parent, void *drvdata, const struct attribute_group **groups, const char *fmt, ...); +extern int arch_register_cpu(int cpu); +extern void arch_unregister_cpu(int cpu); #ifdef CONFIG_HOTPLUG_CPU extern void unregister_cpu(struct cpu *cpu); extern ssize_t arch_cpu_probe(const char *, size_t);