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 26A8BD216A2 for ; Tue, 15 Oct 2024 13:34:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AFE266B0089; Tue, 15 Oct 2024 09:34:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A877D6B008A; Tue, 15 Oct 2024 09:34:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 900B06B008C; Tue, 15 Oct 2024 09:34:36 -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 6DE686B0089 for ; Tue, 15 Oct 2024 09:34:36 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6F7F7AAFFA for ; Tue, 15 Oct 2024 13:34:18 +0000 (UTC) X-FDA: 82675931100.25.7C08A0F Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf01.hostedemail.com (Postfix) with ESMTP id 6A3464001F for ; Tue, 15 Oct 2024 13:34:26 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf01.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728999242; a=rsa-sha256; cv=none; b=FF0saCtAugrMn7o0A+d0tlw+BC0jRUMF4SGpMEHhS3SQHJWzP8GSD/EF7w/CPi2wCWsrqO 8sHz8AXQTJQCorjMy1RIhos3Yllht63y7sJbzhH7gSELnW2XfkIpBjGkvItBhAh2j22sSE mDia0W+1xUdCS55QufXTT9LWzHk3YoE= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf01.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728999242; 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=9/PGVrps8S1RGvmE4dBFYK2zNFCDVDwPGiQr4msofuU=; b=DJTC+72/xPcaOtchxX+l7ucYKgKJyVOAYwhwXRhovQxdbDv6pi/BU76cRNq51DS+M2wnAD jR9W27AGTkqLnPX7zPr7f+8OnVPv3te9qmnPsF2zvo5AlnWp8PD22wqwWRFt1iv0v6h3pm MQAb2VWQYJ0RkOp5biFZEcvLcnCDVb8= Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XSZnH22jlz6HJ5h; Tue, 15 Oct 2024 21:33:55 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id CCAFB140451; Tue, 15 Oct 2024 21:34:29 +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 15:34:28 +0200 Date: Tue, 15 Oct 2024 14:34:26 +0100 From: Jonathan Cameron To: Greg KH CC: "Rafael J. Wysocki" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v13 12/18] platform: Add __free() based cleanup function for platform_device_put Message-ID: <20241015143426.00002e5b@Huawei.com> In-Reply-To: <2024101517-bubbling-deploy-1be0@gregkh> 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> <20241015104021.00002906@huawei.com> <2024101517-bubbling-deploy-1be0@gregkh> 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: lhrpeml500001.china.huawei.com (7.191.163.213) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspam-User: X-Stat-Signature: rqpfnzeqoim8hum4ntpt49r8ad761phx X-Rspamd-Queue-Id: 6A3464001F X-Rspamd-Server: rspam02 X-HE-Tag: 1728999266-301511 X-HE-Meta: U2FsdGVkX188d7Klqg8oNOMiso1kC2XqeaiXg8yl1GkYwu2U8dU4uQ8PKgeNkZAPk3jkS839CAZPAS4oDRxXlBtltVJyoc4k2vhKs8F7RFYRGfWGKGwXnBHD7FQAD7rCDV6z8HiETDJt4+HMhFUiQdXuIbIbN1wjKvSyYjzce4LaxVH5xSw5IG747we4xU3O4d+nKpUWXJsEp5GUPXYnNAzbbsjRxneZlPGIV4/6KvA2MSoG7BwJdwtuothA8F0YQEgVNV9eHx3iSIKIesnyfOcLC/69rwMxHOvGsWe0PkFbYg2F+P877dVk9z6pQ2jroOiQ1pmdJ3xqFjKJ//mSKxOyIoA4fdmO92DmoP/Q7dW/aVlLUcu3fzJm7DWo4Lvfz6ooO1LiUDDUBuEsbvXPMs5KSLMKkbzAgxLxMIq9zVBCJDD4rTku5FKlYuPtniAwJ7pguGStYq8nPBquZE6qUe1VeRnZ0H+4+hwliRTv/NPZnDIs6mQlZ85oqV9MExce9uUFwkV1RQx8LvoJLyF3VF786wXOb5ESz4EXKAWy/6qssvbM/DsWv8IwsXnzXGUUsLpfEFWVhp6SCF7wY8j9vjZkAKcP/rmSkarsEMPYDON3uyQYL8ahw5tzrYZwdSq+deTJg4knfwCzqgypnEHjuA9uRJJfVOSoSJDTVTbqVsAKckm1eycgVIWNOnpH4uh7slfSgcABHZ6iJhvVnb/83m7+lFYnkXvd9JCykNlTLnuMpx3JPRBcvBPD4p08oOxXGrOTWV+OcuGz8yiJipBUd6DwbBTxAYELFfE0ogxw2pOli4EVOPNKup1MN2pSXQaMntEt4UMTo+TtsNUSDRf0Kvzchz5Mn4pOAvSHnSyIkSn7kBJTr+0bZ/J8BRcndpJhTCixHjkX2ZUUbVR5mLihn2Ax9RqLKOS7jp0PaMjZ/rv17yDTpfEZwQpHbaW8BnlpstxsHtXBdNvEj7vZ0Dp Fko8mgIn ALbjCfCGg713zIb4vZWojomgdY0VZs5d0Be/467vP3vzxvPN9G7N6t7E5z6uCkGrUsBwC/2RvSvO8Oy9u8YwS7ohQaOPqx/4MUSIHQuRfiFC3PYk73isDuBSAmkWOptif4FYEzbMgQr/WyzxTIqeTPsbmDnsaPzyYg6mRGIx2wKpkYJt1Xaz/tV1rkymLEAEYTwjDtbJAZn038RhzBwtX8kSPFwuBbGxWJ5rTaDvsUGmFYQZzCsADfyDTFpfcJlCctN+UoZpQKuoVx+tkswJEhGx2EHk5dH2WXDFwMbUN9b0UrxbdaHEmE7Y6s+MACTpCvei1cq2oscWMMBug6/Php7Rwp2tqk9HQR/gW7DnPIE2yJUN6oGyu0nFBmWSF2wrcfhyfYqEtyW2l4hNUfTATjo8wfsPqaXY4+D31YFmH40SEMm1qFeO9kFoUAA== 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 12:17:25 +0200 Greg KH wrote: > On Tue, Oct 15, 2024 at 10:40:54AM +0100, Jonathan Cameron wrote: > > On Tue, 15 Oct 2024 10:10:25 +0100 > > Jonathan Cameron wrote: > > =20 > > > 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: =20 > > > > > > > > > > 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 wr= ote: =20 > > > > > > > > On Wed, 9 Oct 2024 13:41:13 +0100 > > > > > > > > wrote: > > > > > > > > =20 > > > > > > > > > From: Jonathan Cameron > > > > > > > > > > > > > > > > > > Add __free() based cleanup function for platform_device_p= ut(). > > > > > > > > > > > > > > > > > > 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/li= nux/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(s= truct platform_device *pdev, > > > > > > > > > extern int platform_device_add(struct platform_device *p= dev); > > > > > > > > > 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 = *, if (_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 driver core point > > > > > > > > of view I think. =20 > > > > > > > > > > > > > > Why is this needed for a platform device? This feels like yo= u will have > > > > > > > to do more work to "keep" the reference on the normal path th= an you to > > > > > > > today to release the reference on the error path, right? Hav= e a pointer > > > > > > > to a patch that uses this? =20 > > > > > > > > > > > > Ah, is it this one: > > > > > > https://lore.kernel.org/all/20241014164955.00003439@Huawe= i.com/ > > > > > > ? > > > > > > > > > > > > If so, no, that's an abuse of a platform device, don't do that,= make a > > > > > > REAL device on the bus that this device lives on. If it doesn'= t live on > > > > > > a real bus, then put it on the virtual bus but do NOT abuse the= platform > > > > > > device layer for something like this. =20 > > > > > > > > > > Ok. Probably virtual bus it is then. Rafael, what do you think = makes sense > > > > > for a 'feature' that is described only by an ACPI table (here RAS= 2)? > > > > > 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 acc= ess > > > > or AML to interact with. If so, I think that a platform device mak= es > > > > sense. =20 > > >=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 r= egion > > > 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 reaso= n! > > >=20 > > > We'll explore alternatives and see what they end up looking like. > > >=20 > > > Jonathan > > > =20 > >=20 > > Greg, > >=20 > > 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. > >=20 > > Would this mean registering a ras2 bus via subsys_virtual_register(). > > (Similar to done for memory tiers) =20 >=20 > It should show up under /sys/devices/virtual/ is what I mean. >=20 > > On that we'd then add all the devices: one per RAS2 PCC descriptor (the= se > > 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 i= t to > > register with edac etc. > >=20 > > So spinning up a full new bus, to support this? I'm not against that. = =20 >=20 > No, again, see how the stuff that shows up in /sys/devices/virtual > works, that should be much simpler. >=20 > But really, as this is a "bus", just make a new one. I don't understand > why ACPI isn't creating your devices for you, as this is ACPI code, > perhaps just fix that up instead? =20 Filling in that registration gap was the purpose of the next patch. In all the similar cases that I can find where a static ACPI table is parsed (maybe Rafael can point at another) one of two things happen: 1) The table is parsed and platform devices are created for the entries fou= nd (IORT etc) to which drivers later bind. 2) There is a 'fake' device in DSDT. E.g. ACPI0012 for NFIT, ACPI0017 for C= EDT (the CXL table) that are there to trigger enumeration of the static table a= nd those are done via device on the acpi bus. That allows late enumeration and registration of devices with the appropriate classes etc. We'll explore the options but right now I'm thinking a new bus/acpi_ras2 is= probably the way to go. Jonathan > That would make much more sense to > me... >=20 > thanks, >=20 > greg k-h >=20