From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE5C77460 for ; Wed, 10 Apr 2024 19:07:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=140.211.166.138 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712776063; cv=none; b=miUPovOn3B2dcU2JFjg1JT+NpejRj3n8+HzKEMf8C4dtUcO2p9ZTTIa4PAbhkP3cYIghtrx/shlZTwDCIvuq+Cb6m90VDSMq4FaLGPQ+W0BRv+wv/pFKpkeGEqXezdXzDDwWaqRjcKa8Ban/aC7hJs993To5O8yVURhRs6GwdzM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712776063; c=relaxed/simple; bh=z8uL29ol4D/VzeVxNrLkekTvpm9qYZqbPbEmZ0BnNKc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UUVviGC6/G8OUoiKC2ljO3nMrgBmU0FO96Cxe/Si0MCo/4CHeKmzgGg7dTySXmpVrW0RxpekUKGfBHu9G+bkSt6jABw9hJhVaYrQvmurqgUubszwLHQv76kJXNPNVw2ugvzw4nKJQfPXVly/TET7ElGMS1T4pDJRPxMkS5dZ9Kc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=Eih04ugn; arc=none smtp.client-ip=140.211.166.138 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="Eih04ugn" Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 5648C80E9A for ; Wed, 10 Apr 2024 19:07:41 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id gTTlhDxhB6wh for ; Wed, 10 Apr 2024 19:07:40 +0000 (UTC) X-Greylist: delayed 668 seconds by postgrey-1.37 at util1.osuosl.org; Wed, 10 Apr 2024 19:07:39 UTC DMARC-Filter: OpenDMARC Filter v1.4.2 smtp1.osuosl.org 59E7080E7E Authentication-Results: smtp1.osuosl.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 59E7080E7E Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.a=rsa-sha256 header.s=pandora-2019 header.b=Eih04ugn Received-SPF: None (mailfrom) identity=mailfrom; client-ip=2001:4d48:ad52:32c8:5054:ff:fe00:142; helo=pandora.armlinux.org.uk; envelope-from=linux+acpica-devel=lists.linuxfoundation.org@armlinux.org.uk; receiver= Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by smtp1.osuosl.org (Postfix) with ESMTPS id 59E7080E7E for ; Wed, 10 Apr 2024 19:07:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=U8bqg6vv1xN246qvsvrQZYNVGTMrjTXzu9x/4q0URWY=; b=Eih04ugnqStfjTGj8LCSTHRa8I JVKC9gkRyoCXJUkvOs3gxMIVb6pp3NE4PiFgKq38B/dWSfl77kt3RXU5fC9mMMM6OCB3O8hcgUx2S Iv1Pl/+4KblR/zsHS7r1cSKoeP4zO0tKaJGaX6F+EpE3lDTPTujdhDVlzVNGQN9/rLbNsvowxTg2K CWuVQR8+MaNkHOw8BqdKVjxzsNgCldrupd7faINLxt+omBYy9HAtuQW8d1cgHLKwfslwkV2lecqX8 goWQIWe7kLglAMnYY1F9r7DLY0WiKdfvrjCoo58dPUxqUlo+NqnwAQtfmvkjDxde80Y5aYlKd0JtS qpMjAr0Q==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:38784) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rud77-0008Nd-2R; Wed, 10 Apr 2024 19:56:05 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rud73-0006BQ-2Q; Wed, 10 Apr 2024 19:56:01 +0100 Date: Wed, 10 Apr 2024 19:56:00 +0100 From: "Russell King (Oracle)" To: Jonathan Cameron Cc: "Rafael J. Wysocki" , linux-pm@vger.kernel.org, loongarch@lists.linux.dev, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, kvmarm@lists.linux.dev, x86@kernel.org, acpica-devel@lists.linuxfoundation.org, linux-csky@vger.kernel.org, linux-doc@vger.kernel.org, linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org, Salil Mehta , Jean-Philippe Brucker , jianyong.wu@arm.com, justin.he@arm.com, James Morse Subject: Re: [PATCH RFC v4 02/15] ACPI: processor: Register all CPUs from acpi_processor_get_info() Message-ID: References: <20240322185327.00002416@Huawei.com> <20240410134318.0000193c@huawei.com> <20240410145005.00003050@Huawei.com> Precedence: bulk X-Mailing-List: acpica-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240410145005.00003050@Huawei.com> Sender: Russell King (Oracle) On Wed, Apr 10, 2024 at 02:50:05PM +0100, Jonathan Cameron wrote: > If we get rid of this catch all, solution would be to move the > !acpi_disabled check into the arm64 version of arch_cpu_register() > because we would only want the delayed registration path to be > used on ACPI cases where the question of CPU availability can't > yet be resolved. Aren't we then needing two arch_register_cpu() implementations? I'm assuming that you're suggesting that the !acpi_disabled, then do nothing check is moved into arch_register_cpu() - or to put it another way, arch_register_cpu() does nothing if ACPI is enabled. If arch_register_cpu() does nothing if ACPI is enabled, how do CPUs get registered (and sysfs files get created to control them) on ACPI systems? ACPI wouldn't be able to call arch_register_cpu(), so I suspect you'll need an ACPI-specific version of this function. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0723ACD11C2 for ; Wed, 10 Apr 2024 18:58:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=KktmwwNOxg3wRCic5bCvRAliZuMsOoKt1htMmUcTneA=; b=V/yhJhMip4ErXC MNWUbRV6cI50eGCuaWEGXxYXkbGdwZWmwhS4osP0qTo5aPl9rU/q9flk2fKOkGGfIBl05E6XE0eQQ RukKFfbINZHBBmZEqdCsGEt9kFaIIN7seUrokzp0m9DD6mW3rQFPIKSLP5hRT0U8r3JlfXNxPyW4B r0x/h/Bt3IwvOnJKzPuAoXB4VShGAI7zDnzPmB9bMMnX4cTJhO+J0j6vg9BCx97ShnrT/8VGFUOgQ VIN9Jxz3D2wIa4WluHaLrFakET7iaUwdcuknQD05olDmNEzIcKSj+kgMSuOyNQtH/9Gr+rz1NqfPN kG69O48RRGG2ktcvnfLg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rud9e-00000008Zvj-2Puu; Wed, 10 Apr 2024 18:58:42 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rud9R-00000008ZEx-1CkV; Wed, 10 Apr 2024 18:58:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=U8bqg6vv1xN246qvsvrQZYNVGTMrjTXzu9x/4q0URWY=; b=Eih04ugnqStfjTGj8LCSTHRa8I JVKC9gkRyoCXJUkvOs3gxMIVb6pp3NE4PiFgKq38B/dWSfl77kt3RXU5fC9mMMM6OCB3O8hcgUx2S Iv1Pl/+4KblR/zsHS7r1cSKoeP4zO0tKaJGaX6F+EpE3lDTPTujdhDVlzVNGQN9/rLbNsvowxTg2K CWuVQR8+MaNkHOw8BqdKVjxzsNgCldrupd7faINLxt+omBYy9HAtuQW8d1cgHLKwfslwkV2lecqX8 goWQIWe7kLglAMnYY1F9r7DLY0WiKdfvrjCoo58dPUxqUlo+NqnwAQtfmvkjDxde80Y5aYlKd0JtS qpMjAr0Q==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:38784) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rud77-0008Nd-2R; Wed, 10 Apr 2024 19:56:05 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rud73-0006BQ-2Q; Wed, 10 Apr 2024 19:56:01 +0100 Date: Wed, 10 Apr 2024 19:56:00 +0100 From: "Russell King (Oracle)" To: Jonathan Cameron Cc: "Rafael J. Wysocki" , linux-pm@vger.kernel.org, loongarch@lists.linux.dev, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, kvmarm@lists.linux.dev, x86@kernel.org, acpica-devel@lists.linuxfoundation.org, linux-csky@vger.kernel.org, linux-doc@vger.kernel.org, linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org, Salil Mehta , Jean-Philippe Brucker , jianyong.wu@arm.com, justin.he@arm.com, James Morse Subject: Re: [PATCH RFC v4 02/15] ACPI: processor: Register all CPUs from acpi_processor_get_info() Message-ID: References: <20240322185327.00002416@Huawei.com> <20240410134318.0000193c@huawei.com> <20240410145005.00003050@Huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240410145005.00003050@Huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240410_115829_423031_E84C0F44 X-CRM114-Status: GOOD ( 10.98 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Wed, Apr 10, 2024 at 02:50:05PM +0100, Jonathan Cameron wrote: > If we get rid of this catch all, solution would be to move the > !acpi_disabled check into the arm64 version of arch_cpu_register() > because we would only want the delayed registration path to be > used on ACPI cases where the question of CPU availability can't > yet be resolved. Aren't we then needing two arch_register_cpu() implementations? I'm assuming that you're suggesting that the !acpi_disabled, then do nothing check is moved into arch_register_cpu() - or to put it another way, arch_register_cpu() does nothing if ACPI is enabled. If arch_register_cpu() does nothing if ACPI is enabled, how do CPUs get registered (and sysfs files get created to control them) on ACPI systems? ACPI wouldn't be able to call arch_register_cpu(), so I suspect you'll need an ACPI-specific version of this function. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 04531CD1296 for ; Wed, 10 Apr 2024 18:58:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IAQN0c/D8wT3j/klr/HhIfIZSyuWEWM1fFNR+o0CWck=; b=gpS5Zzy2I4z0Fv AJcm7xLFjXgbQycqOzrIs2RWvrvKpehyTGU1v+er1DR0MMmRCpwVyqiBscudyP8z/BNxpT8MUSMxP A1pVKR09WrQ6gP4ZP7+ah57GmgvVawqpYdTNQuyKcGY7WhX1z7sFW+yOCqjJQtQLF5StYMENRSrWG RAp2KEPiIUH8Qk8xHSa3CvgE8vbnvjPHQ9x9OnoxkAyTjVidbznF4foXmiQzwM21zkUN0+79EwhPY ZpIqJEuge9IXaGJOfaijNGyzhk+9oUfOWfdt0YnTS2saaPoMK2RB9fehgiWe+RTfOKmLVGLgR/V3o g9ciTMj5FR2SeOR4fzyQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rud9c-00000008ZuC-1IA6; Wed, 10 Apr 2024 18:58:40 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rud9R-00000008ZEx-1CkV; Wed, 10 Apr 2024 18:58:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=U8bqg6vv1xN246qvsvrQZYNVGTMrjTXzu9x/4q0URWY=; b=Eih04ugnqStfjTGj8LCSTHRa8I JVKC9gkRyoCXJUkvOs3gxMIVb6pp3NE4PiFgKq38B/dWSfl77kt3RXU5fC9mMMM6OCB3O8hcgUx2S Iv1Pl/+4KblR/zsHS7r1cSKoeP4zO0tKaJGaX6F+EpE3lDTPTujdhDVlzVNGQN9/rLbNsvowxTg2K CWuVQR8+MaNkHOw8BqdKVjxzsNgCldrupd7faINLxt+omBYy9HAtuQW8d1cgHLKwfslwkV2lecqX8 goWQIWe7kLglAMnYY1F9r7DLY0WiKdfvrjCoo58dPUxqUlo+NqnwAQtfmvkjDxde80Y5aYlKd0JtS qpMjAr0Q==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:38784) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rud77-0008Nd-2R; Wed, 10 Apr 2024 19:56:05 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rud73-0006BQ-2Q; Wed, 10 Apr 2024 19:56:01 +0100 Date: Wed, 10 Apr 2024 19:56:00 +0100 From: "Russell King (Oracle)" To: Jonathan Cameron Cc: "Rafael J. Wysocki" , linux-pm@vger.kernel.org, loongarch@lists.linux.dev, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, kvmarm@lists.linux.dev, x86@kernel.org, acpica-devel@lists.linuxfoundation.org, linux-csky@vger.kernel.org, linux-doc@vger.kernel.org, linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org, Salil Mehta , Jean-Philippe Brucker , jianyong.wu@arm.com, justin.he@arm.com, James Morse Subject: Re: [PATCH RFC v4 02/15] ACPI: processor: Register all CPUs from acpi_processor_get_info() Message-ID: References: <20240322185327.00002416@Huawei.com> <20240410134318.0000193c@huawei.com> <20240410145005.00003050@Huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240410145005.00003050@Huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240410_115829_423031_E84C0F44 X-CRM114-Status: GOOD ( 10.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Apr 10, 2024 at 02:50:05PM +0100, Jonathan Cameron wrote: > If we get rid of this catch all, solution would be to move the > !acpi_disabled check into the arm64 version of arch_cpu_register() > because we would only want the delayed registration path to be > used on ACPI cases where the question of CPU availability can't > yet be resolved. Aren't we then needing two arch_register_cpu() implementations? I'm assuming that you're suggesting that the !acpi_disabled, then do nothing check is moved into arch_register_cpu() - or to put it another way, arch_register_cpu() does nothing if ACPI is enabled. If arch_register_cpu() does nothing if ACPI is enabled, how do CPUs get registered (and sysfs files get created to control them) on ACPI systems? ACPI wouldn't be able to call arch_register_cpu(), so I suspect you'll need an ACPI-specific version of this function. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel