From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) (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 30385762E8; Tue, 23 Apr 2024 11:13:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713870833; cv=none; b=HR6PJwJM9UJUIcw1KN0jmdP7UkRlPfEPDzGLwBVDv9v3y9JHnWcCu2NC9YOuhUwTrKrL9j0cJfZ7AjbUSZxGxrpgsWChaUMDhJQbcxJfLqScitIeqhQA38wrLWvv4rv7LQz8jGzTOJmAd/eVt+6+CSN7CMscO/aWeC0Ae+uNYdo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713870833; c=relaxed/simple; bh=V1BUX1QiySmoJgp9S3EXm+goKQR4Zi8n7fSWoAHAIus=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=alN8X//B8smWt+eF6wRFb1bO5cpnYctSj244riHjWHQIJwreu+FJCUpSwkkg/REgAKwmaxx2eaTnObPG1zb6A6NLeQTltcJY2ogtJZLGFgjnadwgGhLoWQbx9mHFQL5w/smznD3YpEuiidY94CGoXa5xzbwXm0YHaFla7f657uA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4VNztM487GzXlBp; Tue, 23 Apr 2024 19:10:19 +0800 (CST) Received: from dggpemm500002.china.huawei.com (unknown [7.185.36.229]) by mail.maildlp.com (Postfix) with ESMTPS id 8C64A140136; Tue, 23 Apr 2024 19:13:47 +0800 (CST) Received: from [10.174.178.247] (10.174.178.247) by dggpemm500002.china.huawei.com (7.185.36.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 23 Apr 2024 19:13:46 +0800 Subject: Re: [PATCH v7 03/16] ACPI: processor: Drop duplicated check on _STA (enabled + present) To: "Rafael J. Wysocki" CC: Jonathan Cameron , Thomas Gleixner , Peter Zijlstra , , , , , , , , , Russell King , Miguel Luis , James Morse , Salil Mehta , Jean-Philippe Brucker , Catalin Marinas , Will Deacon , Ingo Molnar , Borislav Petkov , Dave Hansen , , , References: <20240418135412.14730-1-Jonathan.Cameron@huawei.com> <20240418135412.14730-4-Jonathan.Cameron@huawei.com> From: Hanjun Guo Message-ID: Date: Tue, 23 Apr 2024 19:13:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500002.china.huawei.com (7.185.36.229) On 2024/4/23 17:31, Rafael J. Wysocki wrote: > On Tue, Apr 23, 2024 at 8:49 AM Hanjun Guo wrote: >> >> On 2024/4/18 21:53, Jonathan Cameron wrote: >>> The ACPI bus scan will only result in acpi_processor_add() being called >>> if _STA has already been checked and the result is that the >>> processor is enabled and present. Hence drop this additional check. >>> >>> Suggested-by: Rafael J. Wysocki >>> Signed-off-by: Jonathan Cameron >>> >>> --- >>> v7: No change >>> v6: New patch to drop this unnecessary code. Now I think we only >>> need to explicitly read STA to print a warning in the ARM64 >>> arch_unregister_cpu() path where we want to know if the >>> present bit has been unset as well. >>> --- >>> drivers/acpi/acpi_processor.c | 6 ------ >>> 1 file changed, 6 deletions(-) >>> >>> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c >>> index 7fc924aeeed0..ba0a6f0ac841 100644 >>> --- a/drivers/acpi/acpi_processor.c >>> +++ b/drivers/acpi/acpi_processor.c >>> @@ -186,17 +186,11 @@ static void __init acpi_pcc_cpufreq_init(void) {} >>> #ifdef CONFIG_ACPI_HOTPLUG_CPU >>> static int acpi_processor_hotadd_init(struct acpi_processor *pr) >>> { >>> - unsigned long long sta; >>> - acpi_status status; >>> int ret; >>> >>> if (invalid_phys_cpuid(pr->phys_id)) >>> return -ENODEV; >>> >>> - status = acpi_evaluate_integer(pr->handle, "_STA", NULL, &sta); >>> - if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_PRESENT)) >>> - return -ENODEV; >>> - >>> cpu_maps_update_begin(); >>> cpus_write_lock(); >> >> Since the status bits were checked before acpi_processor_add() being >> called, do we need to remove the if (!acpi_device_is_enabled(device)) >> check in acpi_processor_add() as well? > > No, because its caller only checks the present bit. The function > itself checks the enabled bit. Thanks for the pointer, I can see the detail in the acpi_bus_attach() now, Reviewed-by: Hanjun Guo Thanks Hanjun