Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp425570rdd; Tue, 9 Jan 2024 08:13:43 -0800 (PST) X-Google-Smtp-Source: AGHT+IEVp5ATCVwSOWV+cdIrt6/Ov1C49y8UyPMwgZorPrY0DuNOjKgghO2RM2vM+3n3usbq2TUc X-Received: by 2002:a17:90a:4812:b0:28d:28e6:436 with SMTP id a18-20020a17090a481200b0028d28e60436mr2270810pjh.1.1704816822698; Tue, 09 Jan 2024 08:13:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704816822; cv=none; d=google.com; s=arc-20160816; b=XWlZ6AKSeVfP+22AbDlkbOU6lj4dXNzSypFr49aEL6y+M5f1HuRf6a2KPsQilNJTJJ 7OkyO123ZiZX4VXgxWV9E0ZZ3lKGhVe35SvtZhJztssIDea1HbhxVOr1QBWkBQlrcEbQ XQvYsol54FstSlcwihzPIrDq9ECyVuvmiRvXpA3ZZfuzGxTh4YTqqVwfQTQVhfIVZAJK H0M/UcW3dR86dVt8Y2fHVZfiuq3lX6IamRoFr51RUlR4fxUQmt3BIqH0fLNhEO3Gh4ms MdcaY5RNwz2S4jh6OLbqh3Ngo3uNcYCybIFte96uP54GXEKkGfWLiuvyUuS8MbbY4K3e jQtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=hjOpdiFLaU/rl9xnyUOLlrLmtfPs6+yF3otyUbGH/R4=; fh=Z0rgc3VjqdGil5FwRJVQgX89shfTpA6mt4G6EXKjqag=; b=eCWJzs0Dr513SPn8yEFzsfe/KG9AOaMXg+X5zAISvxFiAWZ0Fi8kwM1Gw8yiArkddp 6A9N53w72ix9kKaqaHg0t/+Or0djQFxbuQSfEnXDHgjUc6+3uOkaSfUQhtpJJ6ueZcah 0vX6K4MZF4/TQ1PyloYVubwT7DeTWddOoAEFXJYBZX9cSxH64rpdBmZ2Kwq06YUtz3// KRkIMPWEeqn2b8B8omTAxvZfAq2lpLhgaiPnrsXrAY8xVSeYPusaiQN4nn0cLH83uhSQ gpaWSrnrtu05zhka8eVaU3nRfS2l1AUKYvw3t4Vw8hIWV9QqdLZkhtFKKrMLNmbgGmOF tIoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=a1Ok5Tny; spf=pass (google.com: domain of linux-kernel+bounces-21096-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21096-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id m8-20020a17090a158800b0028cbc17082bsi1732644pja.52.2024.01.09.08.13.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 08:13:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-21096-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=a1Ok5Tny; spf=pass (google.com: domain of linux-kernel+bounces-21096-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21096-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk 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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 02FACB23799 for ; Tue, 9 Jan 2024 16:13:40 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9504D3A1D1; Tue, 9 Jan 2024 16:13:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="a1Ok5Tny" Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (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 2C3033A1AE; Tue, 9 Jan 2024 16:13:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk 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-Transfer-Encoding:Content-Type: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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hjOpdiFLaU/rl9xnyUOLlrLmtfPs6+yF3otyUbGH/R4=; b=a1Ok5TnyDwwEPqkbOv/NhT9x7R vsRGEpXQQuagE84o1GOKB+g5J/3SKZHiq7gO7CVhZ9MwbQLrdnXwckcxFgAGvnY9Nk4loJwUNfWTP dmTT4AEb4pqk4eK2+PIhMHYIuLyFfMQgkCgMxXmxbzNgRuL29tI50v1rDgTaj2mHCxoPuAbNQPrUt Km1OPWQBn9drrgdJHriccMuP6O1dmCKstC1QR2adWEFoMNzjxmXhZjSbPWilyBjDSoIpatoeKnAWZ 8VR9XluXAKu8zzZRWPmIvh+ZGCcd5RXc90I3qF8F9kbHPYQUINZIyz2P07nQPugKYvhC2BMDt30cD fa7z7JPQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:35300) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rNEj9-0004JK-0j; Tue, 09 Jan 2024 16:13:19 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rNEjB-0004Pk-Ap; Tue, 09 Jan 2024 16:13:21 +0000 Date: Tue, 9 Jan 2024 16:13:21 +0000 From: "Russell King (Oracle)" To: "Rafael J. Wysocki" 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 Subject: Re: [PATCH RFC v3 02/21] ACPI: processor: Add support for processors described as container packages Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: Russell King (Oracle) On Tue, Jan 09, 2024 at 05:05:15PM +0100, Rafael J. Wysocki wrote: > On Tue, Jan 9, 2024 at 4:49 PM Russell King (Oracle) > wrote: > > > > On Mon, Dec 18, 2023 at 09:17:34PM +0100, Rafael J. Wysocki wrote: > > > On Wed, Dec 13, 2023 at 1:49 PM Russell King wrote: > > > > > > > > From: James Morse > > > > > > > > ACPI has two ways of describing processors in the DSDT. From ACPI v6.5, > > > > 5.2.12: > > > > > > > > "Starting with ACPI Specification 6.3, the use of the Processor() object > > > > was deprecated. Only legacy systems should continue with this usage. On > > > > the Itanium architecture only, a _UID is provided for the Processor() > > > > that is a string object. This usage of _UID is also deprecated since it > > > > can preclude an OSPM from being able to match a processor to a > > > > non-enumerable device, such as those defined in the MADT. From ACPI > > > > Specification 6.3 onward, all processor objects for all architectures > > > > except Itanium must now use Device() objects with an _HID of ACPI0007, > > > > and use only integer _UID values." > > > > > > > > Also see https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html#declaring-processors > > > > > > > > Duplicate descriptions are not allowed, the ACPI processor driver already > > > > parses the UID from both devices and containers. acpi_processor_get_info() > > > > returns an error if the UID exists twice in the DSDT. > > > > > > I'm not really sure how the above is related to the actual patch. > > > > > > > The missing probe for CPUs described as packages > > > > > > It is unclear what exactly is meant by "CPUs described as packages". > > > > > > From the patch, it looks like those would be Processor() objects > > > defined under a processor container device. > > > > > > > creates a problem for > > > > moving the cpu_register() calls into the acpi_processor driver, as CPUs > > > > described like this don't get registered, leading to errors from other > > > > subsystems when they try to add new sysfs entries to the CPU node. > > > > (e.g. topology_sysfs_init()'s use of topology_add_dev() via cpuhp) > > > > > > > > To fix this, parse the processor container and call acpi_processor_add() > > > > for each processor that is discovered like this. > > > > > > Discovered like what? > > > > > > > The processor container > > > > handler is added with acpi_scan_add_handler(), so no detach call will > > > > arrive. > > > > > > The above requires clarification too. > > > > The above comments... yea. As I didn't write the commit description, but > > James did, and James has basically vanished, I don't think these can be > > answered, short of rewriting the entire commit message, with me spending > > a lot of time with the ACPI specification trying to get the terminology > > right - because at lot of the above on the face of it seems to be things > > to do with wrong terminology being used. > > > > I wasn't expecting this level of issues with this patch set, and I now > > feel completely out of my depth with this series. I'm wondering whether > > I should even continue with it, since I don't have the ACPI knowledge > > to address a lot of these comments. > > Well, sorry about this. > > I met James at the LPC last year, so he seems to be still around, in > some way at least.. On the previous posting, I wanted James to comment on some of the feedback from Jonathan, and despite explicitly asking, there has been nothing but radio silence ever since James' last post of this series. So, I now deem this work to be completely dead in the water, and not going to happen - not unless others can input on your comments. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!