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 BA017CFC285 for ; Tue, 15 Oct 2024 10:17:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E58646B0082; Tue, 15 Oct 2024 06:17:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE2776B0083; Tue, 15 Oct 2024 06:17:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5AE56B0085; Tue, 15 Oct 2024 06:17:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A3AF56B0082 for ; Tue, 15 Oct 2024 06:17:32 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F3CC8C1469 for ; Tue, 15 Oct 2024 10:17:22 +0000 (UTC) X-FDA: 82675434450.27.0E4C19A Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf25.hostedemail.com (Postfix) with ESMTP id 9940FA0015 for ; Tue, 15 Oct 2024 10:17:25 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=R1oIn4oH; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf25.hostedemail.com: domain of gregkh@linuxfoundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728987345; a=rsa-sha256; cv=none; b=3qx/GQStoEK6yQoNjWZPqdAdZ6i1fFdev/SHYi7KRI2wW/LdhzfoTDe9U77jZ9NFRwRy2C jPb/pOuiQVXGqTjZvvH+0s2N5TEReOxoOuEKS/KOf058zlhyul+0RSfa0CmKf2HtagEY+P ZR9nIxbQOGnpYDtbUocgwGwoTfYJTzI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=R1oIn4oH; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf25.hostedemail.com: domain of gregkh@linuxfoundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728987345; 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:dkim-signature; bh=NZyCj43p+UPDZQaM4mNmdAD5bS+uPRBcF16bblAUuWo=; b=jYeK5FjgiyjE2jlXi4npYgbxdd7igfg3LKripN6BfpG1h+e1QmJT3V/62uwv/OE4iBjImW km8J/FGwsDrDqfekn9XviJtyQKSAFzq9Rv5AlK/YqTaYD3gGUNgrO2ohzfdXhLur1gi/mG d4C4MrLfkgJ0kwbdP1EfhHHDqOU41sE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id E8022A41B28; Tue, 15 Oct 2024 10:17:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F153FC4CEC6; Tue, 15 Oct 2024 10:17:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1728987448; bh=1XioJJa406lWyL8OF3hTMXDRkaQxQJuPtDiqIJLiZc4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R1oIn4oHXvuLthWWfMkDIUIE9b0m7QWC/zwa5yzcNb4hF3sxtk+62f3meEtAnkhY9 0RGB3CBufJ1vuVpQouiZoriGjbP0RuhutUDKiI4Bdw7NlFAtdKE5ScQg7EOPG/FxKY vmg51dxsQDgi61h4T4Bd4vY6xPcfuTO7mF16imh4= Date: Tue, 15 Oct 2024 12:17:25 +0200 From: Greg KH To: Jonathan Cameron Cc: "Rafael J. Wysocki" , linuxarm@huawei.com, shiju.jose@huawei.com, linux-edac@vger.kernel.org, linux-cxl@vger.kernel.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, bp@alien8.de, tony.luck@intel.com, lenb@kernel.org, mchehab@kernel.org, dan.j.williams@intel.com, dave@stgolabs.net, dave.jiang@intel.com, alison.schofield@intel.com, vishal.l.verma@intel.com, ira.weiny@intel.com, david@redhat.com, Vilas.Sridharan@amd.com, leo.duran@amd.com, Yazen.Ghannam@amd.com, rientjes@google.com, jiaqiyan@google.com, Jon.Grimm@amd.com, dave.hansen@linux.intel.com, naoya.horiguchi@nec.com, james.morse@arm.com, jthoughton@google.com, somasundaram.a@hpe.com, erdemaktas@google.com, pgonda@google.com, duenwen@google.com, gthelen@google.com, wschwartz@amperecomputing.com, dferguson@amperecomputing.com, wbs@os.amperecomputing.com, nifan.cxl@gmail.com, tanxiaofei@huawei.com, prime.zeng@hisilicon.com, roberto.sassu@huawei.com, kangkang.shen@futurewei.com, wanghuiqiang@huawei.com Subject: Re: [PATCH v13 12/18] platform: Add __free() based cleanup function for platform_device_put Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241015104021.00002906@huawei.com> X-Rspamd-Queue-Id: 9940FA0015 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 88h4gz779q4hy97hiq47h43jtsbfs5mz X-HE-Tag: 1728987445-527513 X-HE-Meta: U2FsdGVkX19AJNkIRmsgHOuehwl/P4h9edpbKgeUzdz5zzjB2NPRx5O7sl7tr3j6ppcu2SIQLICKs+eB/E2iEB5k4pHZ5tkqPbLrM7feVfImjsJIjs7d6mLGcx05k4DkydVIpNDbZL7eaV8QVxR/ex6g7HySJzLjLd0A04QdLsNwWYeYgHFsfAMQq40Gv3h5834ETdtPZRTEQL2N+pjZ9VDdzUbEbmRHRW9FgO3PJx2ru9JBtQJMaPY4oRN52u0DvdRDSeboiVo6tOH0pM2Tm+CtOW6UPamnXL4V6SA/70zMZbsKLF7gWxxnr3n7nHXHmuQ0n/4ASAvUY8rldQfmt3uVOC8GQUtZuy0K61MURPUgzxQqRVgsIl0pVOagV2ZOGlEnjXBMpIH3qH4noFx5ch4OqO3BfX1+jlrMJmTnnKocjFlolCIJ+HEwAxW+tJmbSQp2407EaULzlr/ngCKYDOyJKxOdIDstZ5nHIJ4foWonjftY7wV7Sm6zx2JL5lRqe9I7v9iDGzWztz8T4FDA44E84e5sTUte7DtlTiQFQKk/Z0wIbWDxNCea5PaPbt80EHmhipiCuYt36MeXGkQoU4AA1XC1OAzrXHEN2Pz1lAUthmloe6ENIgPmAu3qQil2VbH7ET4TFaxVmkB0Ml4S/yKSBQ0byQaHXypz0xE2wpuvubnvLA79UA8n75MaHT+Z4SIV17cG1lPw64/N2UZ1OkSRlq2zVM0GxwF2b/UevERXSt5Ii749NQvE/aa4j/xvD8wWB4W54X3tBqMsuOhZ2zZ42jnFmI++KXTDcmCzRFqnJ9IspVGyv2AU/EYD+rZ2biM1q4tnSpqucnw03tA6FMPD0rYxewByXKyuuWhcW6IrQBiWkM8SiJ+64oyCTbjhnvmnNIZRfrOZaWl75DTJS41V/cC7Re8EWixQ8dDbTtHn2FouJmv0fRRTeDlHTO8KnvqeoUiCONnThZKQnHP SNDJS1Y6 zd3EEJewALlTROm02KqwNj/gW2CPIFGidODiBZ9p9k/1D8BhhHBoMHgHpY5afjAGsaURDcSdBGksnCYJNnCcHpO9OiJs7h3nBTqw5pjGH7TyCFrCNYQX4Gia3/XHIht92IyHXeUPdglbR55xLbTDCIYCdqjJ5KZUTK95l1RABXtLM8Ib1verLK/ZV7zVCqlbtxZOw1nkj0JXKBHL5qGsrjfeJnK6fSOjgMsU9YVLASKr9v8eDFR9H++nlYfpsiDmGaDWbxD78sRKlSkxKKCnYQ7jzdq8GhfBi1KJSRgPpNeOO+U0uDFu6SyFtMg3PJKJB7iC1EhPOrwQJo/hqjuqFHTzDl0W1ofsXtwQCgnyAsylPtsFs9CoPUKHse84wCs20xjl2igyjHvrfLuIG0jEkwnRPsCQdG3qVEUOCIKAY3jQ2m1JShtrx4O4hYU3JTUaCIPkohB4TpXreJpO0lCX4D6xCBKRh6wZ/uqxLQLMuzSO/VamE5SowUfxExbKkQW7D0qfuOuGc5keLh1dqKPuDk6o6f4EzmiGlDXwaxQRv8QQ8h8Fz4prfNx05xeQYP1FikSlS 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, Oct 15, 2024 at 10:40:54AM +0100, Jonathan Cameron wrote: > 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: > > > > > On Mon, Oct 14, 2024 at 7:17 PM Jonathan Cameron > > > wrote: > > > > > > > > On Mon, 14 Oct 2024 18:04:37 +0200 > > > > Greg KH wrote: > > > > > > > > > On Mon, Oct 14, 2024 at 06:00:51PM +0200, Greg KH wrote: > > > > > > On Mon, Oct 14, 2024 at 04:43:39PM +0100, Jonathan Cameron wrote: > > > > > > > On Wed, 9 Oct 2024 13:41:13 +0100 > > > > > > > wrote: > > > > > > > > > > > > > > > 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(struct 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 *, if (_T) platform_device_put(_T)) > > > > > > > > > > > > > > > > struct platform_driver { > > > > > > > > int (*probe)(struct platform_device *); > > > > > > > > > > > > > > +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. > > > > > > > > > > > > Why is this needed for a platform device? This feels like you will have > > > > > > to do more work to "keep" the reference on the normal path than you to > > > > > > today to release the reference on the error path, right? Have a pointer > > > > > > to a patch that uses this? > > > > > > > > > > Ah, is it this one: > > > > > https://lore.kernel.org/all/20241014164955.00003439@Huawei.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. > > > > > > > > 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 RAS2)? > > > > Kind of similar(ish) to say IORT. > > > > > > Good question. > > > > > > 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. > > > > Unfortunately still a gray area I think. > > > > 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 :( > > > > 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. > > > > A wrinkle though. The mailbox data is mapped into this driver via > > an acpi_os_ioremap() call. > > > > 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! > > > > We'll explore alternatives and see what they end up looking like. > > > > Jonathan > > > > 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) It should show up under /sys/devices/virtual/ is what I mean. > 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. No, again, see how the stuff that shows up in /sys/devices/virtual works, that should be much simpler. 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? That would make much more sense to me... thanks, greg k-h