Received: by 2002:a05:7412:8598:b0:f9:33c2:5753 with SMTP id n24csp91722rdh; Mon, 18 Dec 2023 12:31:57 -0800 (PST) X-Google-Smtp-Source: AGHT+IE7AE4ZOMspbAVE1Jo+dtVf6g8WuOAEYFdYDKT2ZlGSjxdHGWKP1H/PFcjUqtCP/idik7CW X-Received: by 2002:a05:6102:4b03:b0:466:8fa7:f292 with SMTP id ia3-20020a0561024b0300b004668fa7f292mr1921265vsb.58.1702931517191; Mon, 18 Dec 2023 12:31:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702931517; cv=none; d=google.com; s=arc-20160816; b=JTV3DKHDFVf7OvbR4nJH6lnR9th3cOXQEobXVHNYu1BCYMJApW9hqF1SIqgT7BZYFH 1qBDW0qJ1NvOv+2hQzzdSbYp6VXBmVAxCFA9iUDw1/UAPTX5hJEpDYJW13LDFPh/Dnam zX/E5BB55UcbOTYveaiQAmUfNCTZXKyn/ijXhBP+VpHSu5v0W+bEVjtcT4fX/MoLE1ri DZTDCiOz+h6MKTdhYL3R0FdMpaWFKUY9enLvasl/EMwj+Vk8u6V+jJdB1QU5XFl+tN6D +UqS7vbT/79X5mP+oZvIPmUnMW525zT3V0j1qCQu+tiraxfjWCB6qjY8NvdBJA5urc1R ac+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence; bh=5tAlFGdRk7dsOpEqAvR+OuH9VoSVkSPM03m6WEM5ITU=; fh=FdKLH5Lkv+cCalk9mliJbP8ks5hX326lBveelCIbs6Y=; b=kHDozOwoFsbfTJd06PrtXpKPBHVIF2IL0m9A2fF2/eWrtoESrrN323HBy3V/fAmKRd eRm0BQ1uqU5gnOWDjDdN+AZ+G44PIgShz1LcdnZuAJHHHNAPyp+f3/p3Qies3M/2UVG7 oQLnW3HBNhEDl0uRCdq3M8XnQ4/dQp3ZTCXxOsAS89PaFZI7WWVh5LUtzq4NJQUkIUeI DZ7cG/12N1c1mLK0fHaWn5/i1ZYS/eld1xB7otA/AJ6eyJvo09RP8r4fE5R4nRPZrTym TlCJGd80gEcuwlUZ8H+xLnAFMWc/BE28ac/EdEwOZTb7YQ9w29UGMr32CJx0VqhVd1gf l+5A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-4357-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4357-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id t14-20020a67ad0e000000b004668c5a519csi641226vsl.135.2023.12.18.12.31.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 12:31:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-4357-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-4357-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4357-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id CFCD01C2181F for ; Mon, 18 Dec 2023 20:31:56 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B0C143034F; Mon, 18 Dec 2023 20:31:04 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from mail-oa1-f46.google.com (mail-oa1-f46.google.com [209.85.160.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C44D438DCC; Mon, 18 Dec 2023 20:31:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-2037ef59df0so464204fac.1; Mon, 18 Dec 2023 12:31:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702931461; x=1703536261; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5tAlFGdRk7dsOpEqAvR+OuH9VoSVkSPM03m6WEM5ITU=; b=lLSY1grXNSgRmqW+NumJef57v+1tmNXKx5BClN6X/JNvoU/+V3VzolZMECP1FIrfXw ocreDOEjzUfCLkcs7F3Nmr1Ro19zKup+xkm1rs23Cgnk+olYd4jYkwu/uzxw+xnF6iGx KJo9u5BzL6VVrrkmxkYG3frnILXsEDN6GUySQ6V8pvOoP/nCXYkVagNzrZJKX2yKJ4q2 jSLmnlKVpLlK+yGxuhthkfDPRhbcQOe0Etr2o8/ch6C8hMkIis+XihwJXx+bk0b+i/qn qErnTRziEyfECUSb4xhT8QENyLqj3G6Igl0+RETL/jjHay+0pdqhgp2FVOVdQEvTWnIT 5AUw== X-Gm-Message-State: AOJu0Yw8jKDZae1wKPzR/oau0/Urx/ooBsK4xKa/boF0Br3tgkhtDEV2 1zUAQoeoutEpqdfxv0MrxnJMlTYPWA2kcwXzA/gQsMt0 X-Received: by 2002:a05:6870:420d:b0:1fb:5d05:685e with SMTP id u13-20020a056870420d00b001fb5d05685emr31445963oac.2.1702931460922; Mon, 18 Dec 2023 12:31:00 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: In-Reply-To: From: "Rafael J. Wysocki" Date: Mon, 18 Dec 2023 21:30:50 +0100 Message-ID: Subject: Re: [PATCH RFC v3 04/21] ACPI: processor: Register all CPUs from acpi_processor_get_info() To: Russell King 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, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 13, 2023 at 1:49=E2=80=AFPM Russell King wrote: > > From: James Morse > > To allow ACPI to skip the call to arch_register_cpu() when the _STA > value indicates the CPU can't be brought online right now, move the > arch_register_cpu() call into acpi_processor_get_info(). This kind of looks backwards to me and has a potential to become super-confusing. I would instead add a way for the generic code to ask the platform firmware whether or not the given CPU is enabled and so it can be registered. > Systems can still be booted with 'acpi=3Doff', or not include an > ACPI description at all. For these, the CPUs continue to be > registered by cpu_dev_register_generic(). > > This moves the CPU register logic back to a subsys_initcall(), > while the memory nodes will have been registered earlier. Isn't this somewhat risky? > Signed-off-by: James Morse > Reviewed-by: Gavin Shan > Tested-by: Miguel Luis > Tested-by: Vishnu Pajjuri > Tested-by: Jianyong Wu > Signed-off-by: Russell King (Oracle) > --- > Changes since RFC v2: > * Fixup comment in acpi_processor_get_info() (Gavin Shan) > * Add comment in cpu_dev_register_generic() (Gavin Shan) > --- > drivers/acpi/acpi_processor.c | 12 ++++++++++++ > drivers/base/cpu.c | 6 +++++- > 2 files changed, 17 insertions(+), 1 deletion(-) > > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.= c > index 0511f2bc10bc..e7ed4730cbbe 100644 > --- a/drivers/acpi/acpi_processor.c > +++ b/drivers/acpi/acpi_processor.c > @@ -314,6 +314,18 @@ static int acpi_processor_get_info(struct acpi_devic= e *device) > cpufreq_add_device("acpi-cpufreq"); > } > > + /* > + * Register CPUs that are present. get_cpu_device() is used to sk= ip > + * duplicate CPU descriptions from firmware. > + */ > + if (!invalid_logical_cpuid(pr->id) && cpu_present(pr->id) && > + !get_cpu_device(pr->id)) { > + int ret =3D arch_register_cpu(pr->id); > + > + if (ret) > + return ret; > + } > + > /* > * Extra Processor objects may be enumerated on MP systems with > * less than the max # of CPUs. They should be ignored _iff > diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c > index 47de0f140ba6..13d052bf13f4 100644 > --- a/drivers/base/cpu.c > +++ b/drivers/base/cpu.c > @@ -553,7 +553,11 @@ static void __init cpu_dev_register_generic(void) > { > int i, ret; > > - if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES)) > + /* > + * When ACPI is enabled, CPUs are registered via > + * acpi_processor_get_info(). > + */ > + if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES) || !acpi_disabled) > return; > > for_each_present_cpu(i) { > -- > 2.30.2 > >