Message ID | E1qvJBQ-00AqS8-8B@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:ce89:0:b0:403:3b70:6f57 with SMTP id p9csp2023465vqx; Tue, 24 Oct 2023 08:30:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFOApvMdAKRDI8gW/Pe9scmYe5RY3lWLg8/EL20tHgeZRuDfKM4y6bltf2OGDTDF1/T3XaQ X-Received: by 2002:a17:902:f251:b0:1ca:8b90:1cbd with SMTP id j17-20020a170902f25100b001ca8b901cbdmr8338356plc.0.1698161458129; Tue, 24 Oct 2023 08:30:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698161458; cv=none; d=google.com; s=arc-20160816; b=YdH1fmKfedAW+g4B1I/rCGc35aSvPMjDpNsxOrE5QJHfRTyKmCz+JeE6tWwfLFgewK 03w0yqGxl8u0ybORFrVOHi9uihZOM1SvuPrppfETwaSDpZ93y2sLuV7+hhCL/dWLaRRj zu0iX4kSVGjWlsAaNtH+P5h6n2yB6YqxOhOkgNV07xGthD+8yhGbc5YEZOr20COkhxZl miM9L9jWbJp4mrv60HJaqtOb9q6TgeOy8Tr7VUAKQpyh764Levpsy0mXZtPH1zjya0U8 DC/8bFLR5wwoxPaXnaW/5dGwcfEi/iyiDv2oa+zA0RdpGeTK0bqclEE5EYfiCQKEnigc IphQ== 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:references :in-reply-to:dkim-signature; bh=wObq1ZtL38GoyXrpykUfQ+L3NY/VXeUmDZFIelovoYM=; fh=BEqjJ3zNQfLDKaXUPbrUk0t1iIFPLFn3HtuST6qMUkI=; b=L6RRTsTx+c92UqCw8lYz9pKU2jmqtBM8f/zpokvNthXR+NXoCVAHAPxKdypstovw+s PKk1whuu62NGxHLoNZcphY3dd8VzSrrKEua4Mla4h/5h7f2SWOGtNUkkERIbNhd/GKo5 B1ZGn2wBxxRCBjTxBPV/AZ+v/2BdVhvYlV4vphipKpBjBMUrAYsrvplUWGXXjGINggwY ezP1dxB5yBIZMBVtE3nJt2DPa0sKSnzz230C0Biatf9HhP8MSl9Ui4AkW3pPkwZdRQyv AL7iI8WWjhsQUUhsNgkswH44zAMTtymBm0tur9AUHBIa9YWY9TnDaJJ5L4nVyw87zhfw qtDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=FZDrLbP5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 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 groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id t12-20020a170902bc4c00b001c73e886f68si8156169plz.316.2023.10.24.08.30.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Oct 2023 08:30:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=FZDrLbP5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 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 groat.vger.email (Postfix) with ESMTP id 9B2B880A8013; Tue, 24 Oct 2023 08:30:54 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343898AbjJXPa2 (ORCPT <rfc822;aposhian.dev@gmail.com> + 27 others); Tue, 24 Oct 2023 11:30:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40018 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234838AbjJXP3w (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 24 Oct 2023 11:29:52 -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 E64241720; Tue, 24 Oct 2023 08:19:11 -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:References: In-Reply-To:Reply-To: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=wObq1ZtL38GoyXrpykUfQ+L3NY/VXeUmDZFIelovoYM=; b=FZDrLbP5QGr0Bfm6ivhiO1LbjQ Y4iafTUgbHLhkHP38WYvvVy6wgsx3XPMAkOraEF/gFnmpk/e9X8NZoY39Fs82GsEQOi/AN3hzJ2z/ AKclEoxu7/BMPGlEBiHrVD+WGnT9K6F7yHYlIdOhSJ2tG/uPgN7TE9h8GpOG9WAE91evCIgpZBP3I fNhegreY0+W0QGkObxdbNBGb1DIqOBJzYV1rmlxYQLBApbk5ERid6ZuTH8skj0JKRp7i3gwXyHFeE sSLJw4ITb6s22exlxYg9WpCPCaWm2XP1LB3GblSxuM+VwsqI4Bu6lJ4uGAL4IC/+A7rVLNhjbUQUr pajifeoQ==; Received: from e0022681537dd.dyn.armlinux.org.uk ([fd8f:7570:feb6:1:222:68ff:fe15:37dd]:46028 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 1qvJBO-0004WC-2a; Tue, 24 Oct 2023 16:19:03 +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 1qvJBQ-00AqS8-8B; Tue, 24 Oct 2023 16:19:04 +0100 In-Reply-To: <ZTffkAdOqL2pI2la@shell.armlinux.org.uk> References: <ZTffkAdOqL2pI2la@shell.armlinux.org.uk> From: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> To: 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, linux-csky@vger.kernel.org, linux-doc@vger.kernel.org, linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org Cc: Salil Mehta <salil.mehta@huawei.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, jianyong.wu@arm.com, justin.he@arm.com, James Morse <james.morse@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Lorenzo Pieralisi <lpieralisi@kernel.org> Subject: [PATCH 34/39] arm64: psci: Ignore DENIED CPUs MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Message-Id: <E1qvJBQ-00AqS8-8B@rmk-PC.armlinux.org.uk> Sender: Russell King <rmk@armlinux.org.uk> Date: Tue, 24 Oct 2023 16:19:04 +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 groat.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 (groat.vger.email [0.0.0.0]); Tue, 24 Oct 2023 08:30:54 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780651348718745100 X-GMAIL-MSGID: 1780651348718745100 |
Series |
ACPI/arm64: add support for virtual cpuhotplug
|
|
Commit Message
Russell King (Oracle)
Oct. 24, 2023, 3:19 p.m. UTC
From: Jean-Philippe Brucker <jean-philippe@linaro.org> When a CPU is marked as disabled, but online capable in the MADT, PSCI applies some firmware policy to control when it can be brought online. PSCI returns DENIED to a CPU_ON request if this is not currently permitted. The OS can learn the current policy from the _STA enabled bit. Handle the PSCI DENIED return code gracefully instead of printing an error. See https://developer.arm.com/documentation/den0022/f/?lang=en page 58. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> [ morse: Rewrote commit message ] Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- Changes since RFC v2 * Add specification reference * Use EPERM rather than EPROBE_DEFER --- arch/arm64/kernel/psci.c | 2 +- arch/arm64/kernel/smp.c | 3 ++- drivers/firmware/psci/psci.c | 2 ++ 3 files changed, 5 insertions(+), 2 deletions(-)
Comments
Hi Russell, One inline comment. > -----Original Message----- > From: Russell King <rmk@armlinux.org.uk> On Behalf Of Russell King > Sent: 2023年10月24日 23:19 > To: 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; > linux-csky@vger.kernel.org; linux-doc@vger.kernel.org; > linux-ia64@vger.kernel.org; linux-parisc@vger.kernel.org > Cc: Salil Mehta <salil.mehta@huawei.com>; Jean-Philippe Brucker > <jean-philippe@linaro.org>; Jianyong Wu <Jianyong.Wu@arm.com>; Justin He > <Justin.He@arm.com>; James Morse <James.Morse@arm.com>; Catalin > Marinas <Catalin.Marinas@arm.com>; Will Deacon <will@kernel.org>; Mark > Rutland <Mark.Rutland@arm.com>; Lorenzo Pieralisi <lpieralisi@kernel.org> > Subject: [PATCH 34/39] arm64: psci: Ignore DENIED CPUs > > From: Jean-Philippe Brucker <jean-philippe@linaro.org> > > When a CPU is marked as disabled, but online capable in the MADT, PSCI applies > some firmware policy to control when it can be brought online. > PSCI returns DENIED to a CPU_ON request if this is not currently permitted. The > OS can learn the current policy from the _STA enabled bit. > > Handle the PSCI DENIED return code gracefully instead of printing an error. > > See https://developer.arm.com/documentation/den0022/f/?lang=en page 58. > > Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> [ morse: > Rewrote commit message ] > Signed-off-by: James Morse <james.morse@arm.com> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > Changes since RFC v2 > * Add specification reference > * Use EPERM rather than EPROBE_DEFER > --- > arch/arm64/kernel/psci.c | 2 +- > arch/arm64/kernel/smp.c | 3 ++- > drivers/firmware/psci/psci.c | 2 ++ > 3 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c index > 29a8e444db83..4fcc0cdd757b 100644 > --- a/arch/arm64/kernel/psci.c > +++ b/arch/arm64/kernel/psci.c > @@ -40,7 +40,7 @@ static int cpu_psci_cpu_boot(unsigned int cpu) { > phys_addr_t pa_secondary_entry = __pa_symbol(secondary_entry); > int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry); > - if (err) > + if (err && err != -EPROBE_DEFER) Should this be EPERM? As the following psci cpu_on op will return it. I think you miss to change this when apply Jean-Philippe's patch. Thanks Jianyong > pr_err("failed to boot CPU%d (%d)\n", cpu, err); > > return err; > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c index > 8c8f55721786..68ec7fbe166f 100644 > --- a/arch/arm64/kernel/smp.c > +++ b/arch/arm64/kernel/smp.c > @@ -124,7 +124,8 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle) > /* Now bring the CPU into our world */ > ret = boot_secondary(cpu, idle); > if (ret) { > - pr_err("CPU%u: failed to boot: %d\n", cpu, ret); > + if (ret != -EPERM) > + pr_err("CPU%u: failed to boot: %d\n", cpu, ret); > return ret; > } > > diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c index > d9629ff87861..ee82e7880d8c 100644 > --- a/drivers/firmware/psci/psci.c > +++ b/drivers/firmware/psci/psci.c > @@ -218,6 +218,8 @@ static int __psci_cpu_on(u32 fn, unsigned long cpuid, > unsigned long entry_point) > int err; > > err = invoke_psci_fn(fn, cpuid, entry_point, 0); > + if (err == PSCI_RET_DENIED) > + return -EPERM; > return psci_to_linux_errno(err); > } > > -- > 2.30.2
On Thu, Nov 16, 2023 at 07:45:51AM +0000, Jianyong Wu wrote: > Hi Russell, > > One inline comment. ... > > Changes since RFC v2 > > * Add specification reference > > * Use EPERM rather than EPROBE_DEFER ... > > @@ -40,7 +40,7 @@ static int cpu_psci_cpu_boot(unsigned int cpu) { > > phys_addr_t pa_secondary_entry = __pa_symbol(secondary_entry); > > int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry); > > - if (err) > > + if (err && err != -EPROBE_DEFER) > > Should this be EPERM? As the following psci cpu_on op will return it. I > think you miss to change this when apply Jean-Philippe's patch. It looks like James didn't properly update all places. Also, > > diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c index > > d9629ff87861..ee82e7880d8c 100644 > > --- a/drivers/firmware/psci/psci.c > > +++ b/drivers/firmware/psci/psci.c > > @@ -218,6 +218,8 @@ static int __psci_cpu_on(u32 fn, unsigned long cpuid, > > unsigned long entry_point) > > int err; > > > > err = invoke_psci_fn(fn, cpuid, entry_point, 0); > > + if (err == PSCI_RET_DENIED) > > + return -EPERM; > > return psci_to_linux_errno(err); This change is unnecessary - probably comes from when -EPROBE_DEFER was being used. psci_to_linux_errno() already does: case PSCI_RET_DENIED: return -EPERM; Thanks.
> -----Original Message----- > From: Russell King <linux@armlinux.org.uk> > Sent: 2023年11月20日 17:25 > To: Jianyong Wu <Jianyong.Wu@arm.com> > Cc: 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; > linux-csky@vger.kernel.org; linux-doc@vger.kernel.org; > linux-ia64@vger.kernel.org; linux-parisc@vger.kernel.org; Salil Mehta > <salil.mehta@huawei.com>; Jean-Philippe Brucker <jean-philippe@linaro.org>; > Justin He <Justin.He@arm.com>; James Morse <James.Morse@arm.com>; > Catalin Marinas <Catalin.Marinas@arm.com>; Will Deacon <will@kernel.org>; > Mark Rutland <Mark.Rutland@arm.com>; Lorenzo Pieralisi > <lpieralisi@kernel.org> > Subject: Re: [PATCH 34/39] arm64: psci: Ignore DENIED CPUs > > On Thu, Nov 16, 2023 at 07:45:51AM +0000, Jianyong Wu wrote: > > Hi Russell, > > > > One inline comment. > ... > > > Changes since RFC v2 > > > * Add specification reference > > > * Use EPERM rather than EPROBE_DEFER > ... > > > @@ -40,7 +40,7 @@ static int cpu_psci_cpu_boot(unsigned int cpu) { > > > phys_addr_t pa_secondary_entry = __pa_symbol(secondary_entry); > > > int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry); > > > - if (err) > > > + if (err && err != -EPROBE_DEFER) > > > > Should this be EPERM? As the following psci cpu_on op will return it. > > I think you miss to change this when apply Jean-Philippe's patch. > > It looks like James didn't properly update all places. Also, > > > > diff --git a/drivers/firmware/psci/psci.c > > > b/drivers/firmware/psci/psci.c index d9629ff87861..ee82e7880d8c > > > 100644 > > > --- a/drivers/firmware/psci/psci.c > > > +++ b/drivers/firmware/psci/psci.c > > > @@ -218,6 +218,8 @@ static int __psci_cpu_on(u32 fn, unsigned long > > > cpuid, unsigned long entry_point) > > > int err; > > > > > > err = invoke_psci_fn(fn, cpuid, entry_point, 0); > > > + if (err == PSCI_RET_DENIED) > > > + return -EPERM; > > > return psci_to_linux_errno(err); > > This change is unnecessary - probably comes from when -EPROBE_DEFER was > being used. psci_to_linux_errno() already does: But may print lots of noise like: [ 0.008955] smp: Bringing up secondary CPUs ... [ 0.009661] psci: failed to boot CPU1 (-1) [ 0.010360] psci: failed to boot CPU2 (-1) [ 0.011164] psci: failed to boot CPU3 (-1) [ 0.011946] psci: failed to boot CPU4 (-1) [ 0.012764] psci: failed to boot CPU5 (-1) [ 0.013534] psci: failed to boot CPU6 (-1) [ 0.014349] psci: failed to boot CPU7 (-1) [ 0.014820] smp: Brought up 1 node, 1 CPU Is this expected? Thanks Jianyong > > case PSCI_RET_DENIED: > return -EPERM; > > Thanks. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Mon, Nov 20, 2023 at 09:36:05AM +0000, Jianyong Wu wrote: > > > > -----Original Message----- > > From: Russell King <linux@armlinux.org.uk> > > Sent: 2023年11月20日 17:25 > > To: Jianyong Wu <Jianyong.Wu@arm.com> > > Cc: 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; > > linux-csky@vger.kernel.org; linux-doc@vger.kernel.org; > > linux-ia64@vger.kernel.org; linux-parisc@vger.kernel.org; Salil Mehta > > <salil.mehta@huawei.com>; Jean-Philippe Brucker <jean-philippe@linaro.org>; > > Justin He <Justin.He@arm.com>; James Morse <James.Morse@arm.com>; > > Catalin Marinas <Catalin.Marinas@arm.com>; Will Deacon <will@kernel.org>; > > Mark Rutland <Mark.Rutland@arm.com>; Lorenzo Pieralisi > > <lpieralisi@kernel.org> > > Subject: Re: [PATCH 34/39] arm64: psci: Ignore DENIED CPUs > > > > On Thu, Nov 16, 2023 at 07:45:51AM +0000, Jianyong Wu wrote: > > > Hi Russell, > > > > > > One inline comment. > > ... > > > > Changes since RFC v2 > > > > * Add specification reference > > > > * Use EPERM rather than EPROBE_DEFER > > ... > > > > @@ -40,7 +40,7 @@ static int cpu_psci_cpu_boot(unsigned int cpu) { > > > > phys_addr_t pa_secondary_entry = __pa_symbol(secondary_entry); > > > > int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry); > > > > - if (err) > > > > + if (err && err != -EPROBE_DEFER) > > > > > > Should this be EPERM? As the following psci cpu_on op will return it. > > > I think you miss to change this when apply Jean-Philippe's patch. > > > > It looks like James didn't properly update all places. Also, > > > > > > diff --git a/drivers/firmware/psci/psci.c > > > > b/drivers/firmware/psci/psci.c index d9629ff87861..ee82e7880d8c > > > > 100644 > > > > --- a/drivers/firmware/psci/psci.c > > > > +++ b/drivers/firmware/psci/psci.c > > > > @@ -218,6 +218,8 @@ static int __psci_cpu_on(u32 fn, unsigned long > > > > cpuid, unsigned long entry_point) > > > > int err; > > > > > > > > err = invoke_psci_fn(fn, cpuid, entry_point, 0); > > > > + if (err == PSCI_RET_DENIED) > > > > + return -EPERM; > > > > return psci_to_linux_errno(err); > > > > This change is unnecessary - probably comes from when -EPROBE_DEFER was > > being used. psci_to_linux_errno() already does: > > But may print lots of noise like: > > [ 0.008955] smp: Bringing up secondary CPUs ... > [ 0.009661] psci: failed to boot CPU1 (-1) > [ 0.010360] psci: failed to boot CPU2 (-1) > [ 0.011164] psci: failed to boot CPU3 (-1) > [ 0.011946] psci: failed to boot CPU4 (-1) > [ 0.012764] psci: failed to boot CPU5 (-1) > [ 0.013534] psci: failed to boot CPU6 (-1) > [ 0.014349] psci: failed to boot CPU7 (-1) > [ 0.014820] smp: Brought up 1 node, 1 CPU > > Is this expected? Please read my email again, and take note of the _context_ above the places that I've commented. Context matters. What I'm saying is that this change: err = invoke_psci_fn(fn, cpuid, entry_point, 0); + if (err == PSCI_RET_DENIED) + return -EPERM; return psci_to_linux_errno(err); Is unnecessary when psci_to_linux_errno() already does: static __always_inline int psci_to_linux_errno(int errno) { switch (errno) { ... case PSCI_RET_DENIED: return -EPERM; So, a return of PSCI_RET_DENIED from invoke_psci_fn() above will _already_ be translated to -EPERM (which is -1) by psci_to_linux_errno(). There is no need to add that extra if() statement in __psci_cpu_on(). I was _not_ saying that the entire patch was unnecessary. Context matters. That's why we include context in replies. Standard email etiquette (before Microsoft messed it up) is to quote the email that is being replied to, trimming hard irrelevant content, and to place the reply comments immediately below the original content to which the comments relate, to give the reply comments the context necessary for correct interpretation. Thanks.
> -----Original Message----- > From: Russell King <linux@armlinux.org.uk> > Sent: 2023年11月20日 17:58 > To: Jianyong Wu <Jianyong.Wu@arm.com> > Cc: 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; > linux-csky@vger.kernel.org; linux-doc@vger.kernel.org; > linux-ia64@vger.kernel.org; linux-parisc@vger.kernel.org; Salil Mehta > <salil.mehta@huawei.com>; Jean-Philippe Brucker <jean-philippe@linaro.org>; > Justin He <Justin.He@arm.com>; James Morse <James.Morse@arm.com>; > Catalin Marinas <Catalin.Marinas@arm.com>; Will Deacon <will@kernel.org>; > Mark Rutland <Mark.Rutland@arm.com>; Lorenzo Pieralisi > <lpieralisi@kernel.org> > Subject: Re: [PATCH 34/39] arm64: psci: Ignore DENIED CPUs > > On Mon, Nov 20, 2023 at 09:36:05AM +0000, Jianyong Wu wrote: > > > > > > > -----Original Message----- > > > From: Russell King <linux@armlinux.org.uk> > > > Sent: 2023年11月20日 17:25 > > > To: Jianyong Wu <Jianyong.Wu@arm.com> > > > Cc: 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; linux-csky@vger.kernel.org; > > > linux-doc@vger.kernel.org; linux-ia64@vger.kernel.org; > > > linux-parisc@vger.kernel.org; Salil Mehta <salil.mehta@huawei.com>; > > > Jean-Philippe Brucker <jean-philippe@linaro.org>; Justin He > > > <Justin.He@arm.com>; James Morse <James.Morse@arm.com>; Catalin > > > Marinas <Catalin.Marinas@arm.com>; Will Deacon <will@kernel.org>; > > > Mark Rutland <Mark.Rutland@arm.com>; Lorenzo Pieralisi > > > <lpieralisi@kernel.org> > > > Subject: Re: [PATCH 34/39] arm64: psci: Ignore DENIED CPUs > > > > > > On Thu, Nov 16, 2023 at 07:45:51AM +0000, Jianyong Wu wrote: > > > > Hi Russell, > > > > > > > > One inline comment. > > > ... > > > > > Changes since RFC v2 > > > > > * Add specification reference > > > > > * Use EPERM rather than EPROBE_DEFER > > > ... > > > > > @@ -40,7 +40,7 @@ static int cpu_psci_cpu_boot(unsigned int cpu) { > > > > > phys_addr_t pa_secondary_entry = __pa_symbol(secondary_entry); > > > > > int err = psci_ops.cpu_on(cpu_logical_map(cpu), > pa_secondary_entry); > > > > > - if (err) > > > > > + if (err && err != -EPROBE_DEFER) > > > > > > > > Should this be EPERM? As the following psci cpu_on op will return it. > > > > I think you miss to change this when apply Jean-Philippe's patch. > > > > > > It looks like James didn't properly update all places. Also, > > > > > > > > diff --git a/drivers/firmware/psci/psci.c > > > > > b/drivers/firmware/psci/psci.c index d9629ff87861..ee82e7880d8c > > > > > 100644 > > > > > --- a/drivers/firmware/psci/psci.c > > > > > +++ b/drivers/firmware/psci/psci.c > > > > > @@ -218,6 +218,8 @@ static int __psci_cpu_on(u32 fn, unsigned > > > > > long cpuid, unsigned long entry_point) > > > > > int err; > > > > > > > > > > err = invoke_psci_fn(fn, cpuid, entry_point, 0); > > > > > + if (err == PSCI_RET_DENIED) > > > > > + return -EPERM; > > > > > return psci_to_linux_errno(err); > > > > > > This change is unnecessary - probably comes from when -EPROBE_DEFER > > > was being used. psci_to_linux_errno() already does: > > > > But may print lots of noise like: > > > > [ 0.008955] smp: Bringing up secondary CPUs ... > > [ 0.009661] psci: failed to boot CPU1 (-1) > > [ 0.010360] psci: failed to boot CPU2 (-1) > > [ 0.011164] psci: failed to boot CPU3 (-1) > > [ 0.011946] psci: failed to boot CPU4 (-1) > > [ 0.012764] psci: failed to boot CPU5 (-1) > > [ 0.013534] psci: failed to boot CPU6 (-1) > > [ 0.014349] psci: failed to boot CPU7 (-1) > > [ 0.014820] smp: Brought up 1 node, 1 CPU > > > > Is this expected? > > Please read my email again, and take note of the _context_ above the places > that I've commented. Context matters. > > What I'm saying is that this change: > > err = invoke_psci_fn(fn, cpuid, entry_point, 0); > + if (err == PSCI_RET_DENIED) > + return -EPERM; > return psci_to_linux_errno(err); > > Is unnecessary when psci_to_linux_errno() already does: > > static __always_inline int psci_to_linux_errno(int errno) { > switch (errno) { > ... > case PSCI_RET_DENIED: > return -EPERM; > > So, a return of PSCI_RET_DENIED from invoke_psci_fn() above will _already_ be > translated to -EPERM (which is -1) by psci_to_linux_errno(). There is no need to > add that extra if() statement in __psci_cpu_on(). > > I was _not_ saying that the entire patch was unnecessary. > > Context matters. That's why we include context in replies. > > Standard email etiquette (before Microsoft messed it up) is to quote the email > that is being replied to, trimming hard irrelevant content, and to place the reply > comments immediately below the original content to which the comments > relate, to give the reply comments the context necessary for correct > interpretation. > Oh, sorry, my mistake. Ignore my last comment. Thanks Jianyong > Thanks. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c index 29a8e444db83..4fcc0cdd757b 100644 --- a/arch/arm64/kernel/psci.c +++ b/arch/arm64/kernel/psci.c @@ -40,7 +40,7 @@ static int cpu_psci_cpu_boot(unsigned int cpu) { phys_addr_t pa_secondary_entry = __pa_symbol(secondary_entry); int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry); - if (err) + if (err && err != -EPROBE_DEFER) pr_err("failed to boot CPU%d (%d)\n", cpu, err); return err; diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c index 8c8f55721786..68ec7fbe166f 100644 --- a/arch/arm64/kernel/smp.c +++ b/arch/arm64/kernel/smp.c @@ -124,7 +124,8 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle) /* Now bring the CPU into our world */ ret = boot_secondary(cpu, idle); if (ret) { - pr_err("CPU%u: failed to boot: %d\n", cpu, ret); + if (ret != -EPERM) + pr_err("CPU%u: failed to boot: %d\n", cpu, ret); return ret; } diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c index d9629ff87861..ee82e7880d8c 100644 --- a/drivers/firmware/psci/psci.c +++ b/drivers/firmware/psci/psci.c @@ -218,6 +218,8 @@ static int __psci_cpu_on(u32 fn, unsigned long cpuid, unsigned long entry_point) int err; err = invoke_psci_fn(fn, cpuid, entry_point, 0); + if (err == PSCI_RET_DENIED) + return -EPERM; return psci_to_linux_errno(err); }