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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82865CFC27E for ; Tue, 15 Oct 2024 09:41:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82CA76B0082; Tue, 15 Oct 2024 05:41:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DBAD6B0083; Tue, 15 Oct 2024 05:41:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67CCD6B0085; Tue, 15 Oct 2024 05:41:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 492AA6B0082 for ; Tue, 15 Oct 2024 05:41:09 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0E4E61407B6 for ; Tue, 15 Oct 2024 09:41:00 +0000 (UTC) X-FDA: 82675342848.16.C0929B1 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf17.hostedemail.com (Postfix) with ESMTP id 7EBEA40004 for ; Tue, 15 Oct 2024 09:41:00 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728985220; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n7QGMnQkZAw3uUHRpimENZk/xBYUoiqLkPfkyuhr1KM=; b=oeNyXaMaQdjIpwV0psP3pZfCs8SbnxEfJZKFNDrHNBvS/UGaBGJ/y8cXIKfCzLTCX6Uvk0 uR3Aqe2cK6X8VosoZUfc45fcVBc5RqG8jJJWJ1f2xZChE8kFvTu9d2eGWksAJMafZBO1RI 1yWbQRuKd2aWOeNZVsxlqzjposY8tjQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728985220; a=rsa-sha256; cv=none; b=maDJ0FO+nG5McAGI+yEELAznkXJP4uNDMX2loFYdgjhtj/wOMFg8SJ1oXPRifjUjT3AdIz 0cGlLPaXX6/i62WmGEaFBKW3SdufdxDq4oPonazRfizptN9JDPTvgsownU2Dn/Wn5/AoKd JfJrDiLGnaitnnyaV9XTgMiwLNnqmlw= Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XSTZd2llVz6FH5T; Tue, 15 Oct 2024 17:39:21 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id 86E5A140AA7; Tue, 15 Oct 2024 17:40:58 +0800 (CST) Received: from localhost (10.203.177.66) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 15 Oct 2024 11:40:56 +0200 Date: Tue, 15 Oct 2024 10:40:54 +0100 From: Jonathan Cameron To: "Rafael J. Wysocki" , CC: Greg KH , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v13 12/18] platform: Add __free() based cleanup function for platform_device_put Message-ID: <20241015104021.00002906@huawei.com> In-Reply-To: <20241015101025.00005305@Huawei.com> References: <20241009124120.1124-1-shiju.jose@huawei.com> <20241009124120.1124-13-shiju.jose@huawei.com> <20241014164339.00003e73@Huawei.com> <2024101410-turf-junior-7739@gregkh> <2024101451-reword-animation-2179@gregkh> <20241014181654.00005180@Huawei.com> <20241015101025.00005305@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.203.177.66] X-ClientProxiedBy: lhrpeml500006.china.huawei.com (7.191.161.198) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspam-User: X-Stat-Signature: 9xrfqb4xat65hf6mejj4ja6zupjisdy9 X-Rspamd-Queue-Id: 7EBEA40004 X-Rspamd-Server: rspam11 X-HE-Tag: 1728985260-861271 X-HE-Meta: U2FsdGVkX1+aKVZVhRb73VInoeRayvtDG6i1IDGXIpIt+qZx30aS8M9+6Cht4DnXhYQPfWn934Fl45sqkbPcFtHELTBNoO3+6dMa1HQzsXDaMCDghv/YyUhk4XyKv3W4lFdMwz6X7HO+NAdEd9LeolG/GfaTQoDE/BnA6VeXbcpUrgaQ21VNPsrT0BMqXrZGZtCkzWvUpZxUZltVt7tjVahtGXEfEU7BExA/H91PUNf04p14is/0kREIHNvr6pZgEhlV0EMUpmtXVcRHRz0pqRQ6qqXdioLjLcEEw41RKuyrtp7rh1oqtIPHIJs15oEPNEWZplApY0gy9/+5NQrXJE1k/iqf+maYpnTVA+LCXDPuNfcE5maRy8bjKrgudSj1ncOIHbWm2vZVysNcu4g3MrAfE206Hb9B1ZuFibQwcXL7pc0Wa9PN7FNtFhKe88cJt6vI1R8Ra9cdeHnDoIXotJJuwNLyxJPQRQdbvAYIojxSwLlIcEJu53fYOA7v1ERSFJPvBq9sfriZDYrOnrTll8jgzqrZRT6Otq8ZMy11wcs7FcO4U0MN8zRkkoNwM/mwNoSo1dDdjQJ8LSN9PCykL+baHqf3heYeL2zDe0Q/axuOMhTpP0/UthIoVc1bYb9SsUFto/vfjnUjphb85MCd/vA5/pCw3lHptnTc6pF73yXvdhbCMB9cCLMjs5Jc/RtDY2yGKg8e1dpUfBzIho/srw4hqssDSluKK6MwHGVyoae/OhSk0yaO0T8fznVK/iefYer/9kdqoGMD9OCpH78okisLq/RuQ6kbnOXqbSEYDJ2GwY6fRB8KJUGd0gyX9MwvEuv9dNU+csGugNXyOYZsMdCvNw5AoKdigOnTnvvtbgmakEDuXVGth9/xJROha3GrSckkNW3CJD9RjodyGhCckhRU2jCvx7/+mGFOqBPYgVCRaw+tD9jAsdak4I2Teq6+lnb0opSDZ3N9xHVWaTI vXKCIv9/ XvCskBl0tEtyL16HO91RfKydXdjttIhOb3beZ0J6m6wotchJLUvVmPUm7UVpvSilKg3VzHkqTXBRfeGuvYHPOPqVex7+bYwEDEJTmxmZNGkU6PRBuOIlmqPLGcusGE9vFTz+ARYloz61X5C8YH9t8ZRAtxaaxHVV67tFSR/+FEzLvUrRl+5AQ3/kkzW9MNXQ8x8+2/bsbiINkOGRAsdPJQhJiOTfwaRcM4d2MgO0XFmmTzquzInUvxNwiUDiTSWmPk2CNdp506KE141imCSu7IR0R+YhQcq5sbZieueHCqeJAIdnhcef4k4+CuFFEhOG46YgTfb0/I2LU+/+EJzcYYZDlHE8jkA69SqGTbXf1nQSWmWKvp13suLAkG2fD42ry89QOLOcF3zQgv3Q= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, 15 Oct 2024 10:10:25 +0100 Jonathan Cameron wrote: > On Mon, 14 Oct 2024 20:06:40 +0200 > "Rafael J. Wysocki" wrote: >=20 > > On Mon, Oct 14, 2024 at 7:17=E2=80=AFPM Jonathan Cameron > > wrote: > > > > > > On Mon, 14 Oct 2024 18:04:37 +0200 > > > Greg KH wrote: > > > =20 > > > > On Mon, Oct 14, 2024 at 06:00:51PM +0200, Greg KH wrote: =20 > > > > > On Mon, Oct 14, 2024 at 04:43:39PM +0100, Jonathan Cameron wrote:= =20 > > > > > > On Wed, 9 Oct 2024 13:41:13 +0100 > > > > > > wrote: > > > > > > =20 > > > > > > > From: Jonathan Cameron > > > > > > > > > > > > > > Add __free() based cleanup function for platform_device_put(). > > > > > > > > > > > > > > Signed-off-by: Jonathan Cameron > > > > > > > Signed-off-by: Shiju Jose > > > > > > > --- > > > > > > > include/linux/platform_device.h | 1 + > > > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > > > > > diff --git a/include/linux/platform_device.h b/include/linux/= platform_device.h > > > > > > > index d422db6eec63..606533b88f44 100644 > > > > > > > --- a/include/linux/platform_device.h > > > > > > > +++ b/include/linux/platform_device.h > > > > > > > @@ -232,6 +232,7 @@ extern int platform_device_add_data(struc= t platform_device *pdev, > > > > > > > extern int platform_device_add(struct platform_device *pdev); > > > > > > > extern void platform_device_del(struct platform_device *pdev= ); > > > > > > > extern void platform_device_put(struct platform_device *pdev= ); > > > > > > > +DEFINE_FREE(platform_device_put, struct platform_device *, i= f (_T) platform_device_put(_T)) > > > > > > > > > > > > > > struct platform_driver { > > > > > > > int (*probe)(struct platform_device *); =20 > > > > > > > > > > > > +CC Greg KH and Rafael. > > > > > > > > > > > > Makes sure to include them on v14 as this needs review from a d= river core point > > > > > > of view I think. =20 > > > > > > > > > > Why is this needed for a platform device? This feels like you wi= ll have > > > > > to do more work to "keep" the reference on the normal path than y= ou to > > > > > today to release the reference on the error path, right? Have a = pointer > > > > > to a patch that uses this? =20 > > > > > > > > Ah, is it this one: > > > > https://lore.kernel.org/all/20241014164955.00003439@Huawei.co= m/ > > > > ? > > > > > > > > If so, no, that's an abuse of a platform device, don't do that, mak= e a > > > > REAL device on the bus that this device lives on. If it doesn't li= ve on > > > > a real bus, then put it on the virtual bus but do NOT abuse the pla= tform > > > > device layer for something like this. =20 > > > > > > Ok. Probably virtual bus it is then. Rafael, what do you think make= s sense > > > for a 'feature' that is described only by an ACPI table (here RAS2)? > > > Kind of similar(ish) to say IORT. =20 > >=20 > > Good question. > >=20 > > I guess it depends on whether or not there are any registers to access > > or AML to interact with. If so, I think that a platform device makes > > sense. >=20 > Unfortunately still a gray area I think. >=20 > This does access mailbox memory addresses, but they are provided > by an existing platform device, so maybe platform device for this > device is still inappropriate :( >=20 > What this uses is: > PCC channel (mailbox in memory + doorbells, etc but that is indirectly > provided as a service via reference in ACPI to the PCCT table entry > allowing this to find the mailbox device - which is a platform > device drivers/mailbox/pcc.c). > Because it's all spec defined content in the mailbox messages, we don't > have the more flexible (and newer I think) 'register' via operation region > stuff in AML. >=20 > A wrinkle though. The mailbox data is mapped into this driver via > an acpi_os_ioremap() call. =20 >=20 > So I'm thinking we don't have a strong reason for a platform device > other than 'similarity' to other examples. Never the strongest reason! >=20 > We'll explore alternatives and see what they end up looking like. >=20 > Jonathan >=20 Greg, I'm struggling a little to figure out how you envision the virtual bus working here. So before we spend too much time implementing the wrong thing as it feels non trivial, let me check my understanding. Would this mean registering a ras2 bus via subsys_virtual_register(). (Similar to done for memory tiers) On that we'd then add all the devices: one per RAS2 PCC descriptor (these are one per independent feature). Each feature has its own mailbox sub channel (via a reference to the PCC mailbox devices . Typically you have one of these per feature type per numa node, but that isn't guaranteed. That will then need wiring up with bus->probe() etc so that the RAS2 edac feature drivers can find this later and bind to it to register with edac etc. So spinning up a full new bus, to support this? I'm not against that. We could use auxbus I guess but that is at least described with the intent that it is for subfeatures of a device and here we don't ha= ve a top level device (unless we make one for the RAS2 ACPI table which would be odd). So effectively a new subsystem bus? Jonathan >=20 >=20 > >=20 > > > My thinking on a platform device was that this could be described > > > in DSDT and would have ended up as one. No idea why it isn't. > > > Maybe it predated the resource stuff that lets you use PCC channels > > > from methods under devices. Anyhow, it's not something I care about > > > so virtual bus is fine by me. =20 > >=20 >=20 >=20