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 B4A92D216A3 for ; Tue, 15 Oct 2024 13:32:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A9866B0089; Tue, 15 Oct 2024 09:32:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 332D86B008A; Tue, 15 Oct 2024 09:32:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AC936B0093; Tue, 15 Oct 2024 09:32:45 -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 ECF026B0089 for ; Tue, 15 Oct 2024 09:32:44 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1FB74ABD05 for ; Tue, 15 Oct 2024 13:32:27 +0000 (UTC) X-FDA: 82675926438.23.471B0E4 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf05.hostedemail.com (Postfix) with ESMTP id 8257D100013 for ; Tue, 15 Oct 2024 13:32:28 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ew1MCGii; spf=pass (imf05.hostedemail.com: domain of rafael@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=rafael@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728999089; a=rsa-sha256; cv=none; b=rsi7/DL/ZUCC5eXHqLEgbtTrJKW9LoWoXjPPnDwzCbiAzGcWpGDVJpjUpaltVQ5Q0xfA53 aYA7mrSsR8S90M1rwL0nog9oFI3W56g5PXTfSW9d7SmrfH51Fz24ZsjbX9Tue8lkKg5nZs leFXdW+vyGkfqKPAFcmUX1Q/tO7oRzo= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ew1MCGii; spf=pass (imf05.hostedemail.com: domain of rafael@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=rafael@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728999089; 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=lYvTzvxnEJ0rX4juqRsvqnzc0W43NIJLaWTGKTkMbWI=; b=wrUmvvsU4cMHm6+rH6qdGUSm4FxoOGTWr1PAHzz4vqi620lR8RM8AWDi4UpULLKoFOxkjc 2Zt/zWY6jZQ/de5Et3ChRyAcBbKDju2m6FJIjWv3cDodXX2fdgYs5avLb81cUjs6fPvxz/ QaIn4wKNqaE31LhW3PA3E/aPojJE7EQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 84882A418B5 for ; Tue, 15 Oct 2024 13:32:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD6A7C4CEE1 for ; Tue, 15 Oct 2024 13:32:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728999160; bh=5fIT9OmKwq1xHPg4nWK9yuoW/kODnF5lwDlL5KHxdbE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ew1MCGiimUYdnMV2OnA9mPw2zX+Lo/8sQxlvO3xGOROD8DmGJzveF+N2QQ0Ij3DOh JzRTfn6ziFZ3c+2epd/w6ubYtOKv2IqHe66K1aQan++eU14Dk8mUqVJo1RkorVIKU8 exWfBmXZsC9+rHDDeyKIUnwZSiq39Is3dl+htJaQVHueBpuwNxKNLp0JDotHLB9b6l PvvSZKBW8bgXPQWobmMITW2ZVqHevhQ8tbXmcKsGyCTv3Yow5BnrPa6uNZsnnsYsEK AZQcQ2TTEuXz/Ec6rku+BrfQRQRZUdIigyHq431wGjIyiPWxugOUuDDjRdpRKrBVx2 p9O5nyiQ4PZCQ== Received: by mail-oa1-f44.google.com with SMTP id 586e51a60fabf-2888165800fso1779942fac.3 for ; Tue, 15 Oct 2024 06:32:40 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWF6AGEYWCRpVjBjNTwif2quA6HRzk3g6x1zfcMCC646B+jfp3Ulq7MiIiSkjC+g2ruC6T5OnSs3g==@kvack.org X-Gm-Message-State: AOJu0YzbHdwY25g6LlJhtQ5htwP3q+hN+2GasOHjusGzlY297RISoGWr uxm7aLEbAkJBYxc4DxoBX5ELLs1gl/TzrrsKDmJ8LDm86N50KQMJgMWm6vI79osfHpcud7cPp12 xbNabP05TgFgezrb4Yjgh77d6BE0= X-Google-Smtp-Source: AGHT+IHuO1i4hxtn/TwfVt+toXC1+oAP+6GnGpmajF9HnA2MJ52+I8CyfiFQ6xobfIYee3MmOj6Drz38cNmnbBK/tZA= X-Received: by 2002:a05:6870:2896:b0:277:cc56:2300 with SMTP id 586e51a60fabf-2886dd70fd1mr11104236fac.12.1728999159750; Tue, 15 Oct 2024 06:32:39 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <2024101517-bubbling-deploy-1be0@gregkh> From: "Rafael J. Wysocki" Date: Tue, 15 Oct 2024 15:32:28 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v13 12/18] platform: Add __free() based cleanup function for platform_device_put To: Greg KH Cc: Jonathan Cameron , "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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 66nhazejcgxsxirenir8gepqy71n9hq6 X-Rspamd-Queue-Id: 8257D100013 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1728999148-650251 X-HE-Meta: U2FsdGVkX1+um9IPGl68HPgDXyy6PdFWFGfT/g0PHq1lbNchT3j2UVXax9DKtQvMrGiAXAjH38fX43nNaeSKN+SKUuevhaJhKGCdpTdO4NDM87dWqDzBeZHsw28DcVrLAUez4AhVQmZ4t7m9xoPvDDxOJmmAXrDvf1/Q4DkT01UelP7uNie53cNI5QNoy4QAaj5Y6w4xXN4L0BFCKo3R1g7srMl8nc2ZTWW+YLT02y7+679/J7kmZowdbo6vyo6/wvONomRSPZuw6aNFRmSH2CqYSyoqJHfnZAoV+S6TFg2BU1x1AIhltVNpDxzi+C7pjB6EWWI5gBmMyeTYicdbwy39301kQ/19BgNs77C8sDjsBjqa5by9Hh4O5mGci/TYhL/ClHhrtZb7Hg+J0/9GjEBWpkjMbqOiNQbY3amZR53K7USZbRSgnSnjZGLdNmsPppij7aNrV7AKf5oPi2cTHvSh8bvG8UEKfwwBxLvKmuVK8HdBsVuXK17RYLI/Tiwx2FXMXCGzuDqUO4V3MqD7sMq652+C2J1HzYDJsRucj372P2Hbaiv5wnzlWfbHi0dIs2jEkyAcGk/kg11YSe+DHxn/JGSa0Y8oHN8B0HdJBV7+qjymsUF7HMbwQOIWXkIFBMPF2Hg0TzP/dLknqXnqcPV1eSrA+2++jH4+ERAD7Jbyuyn76AfSZchuyTAdfEgmCkDWcZTSwufaurDTc9kz5hyUcJCI23hp4/nLktR/kvcbTWWp3boHC/A/6rpGidYdwfam28sTr7fr/mgliW7ag0HDTqMsgBJY3AfASh8m1m5G3SaSHFkU+VvXm0mhDRJ3wS2i5TNhk6UAaWPkp/66HcaNS2tLiT+aDN81rTGwJIMW1SgnDyq9OOp87qziVQswaASR0nBaWB6FY5zObYTITu7lPJ5D6M3mkw03CoDSgLIzu+rH936NUw3qzL9EuSeM3+WyCG2rj3jQHLLQW2D R3jpy92o kBs9RDF13DRGCRbBJdYkbXfx7m9Ryx1VaCfNny1L0QbpMlLJTj1u67FXHgykYO1ozD7LJyN0xTXe4KwODJG0bqkbqzc1QhYhlXdGclN5synntZusAyEugKApUjW4GAPgE8bJ0qLe9BI/71Iw8vQJ2RXRQlD9C5adOsrbuy25rwPGdxRkGbUXP27JKVJyS0RVKn4RGykiYVLQmBLWoOZsJCzeRR2kXFAlfBX1tO+3G71qilolgotGBkXUG/xctxMH/DMFyMnULpXl7IWgvaodrexedsBBWB1AlY1y6gXE51gOn4fgrN3xP0cW2tB46pLhrWkubu8NKlB/vvmJyKz8tVfySagergA7Am6fvX3nvqBU1ly1L/0KF+Kqm/ARHBZ1TkWlqDDAggpYfe1CjepkiHpwHcARf/6nNdL5mGBV4j++pUG/2EOS9i64LZXQPDLjJQQ+dREnvrM717WtmfIzeNJRkni59/i7uzg1bhJ+9poBol7hwYQit829BIDjJQtgSCSAS 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 12:17=E2=80=AFPM 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: > > > > > On Mon, 14 Oct 2024 20:06:40 +0200 > > > "Rafael J. Wysocki" wrote: > > > > > > > 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: > > > > > > > > > > > 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 wr= ote: > > > > > > > > On Wed, 9 Oct 2024 13:41:13 +0100 > > > > > > > > wrote: > > > > > > > > > > > > > > > > > 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 *); > > > > > > > > > > > > > > > > +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 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? > > > > > > > > > > > > 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. > > > > > > > > > > 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. > > > > > > > > Good question. > > > > > > > > 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. > > > > > > 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 indirectl= y > > > 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. > > > > > > 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 reaso= n! > > > > > > 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 (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. > > > > 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... Because it is a data-only table, not AML. It looks to me like this could be an auxiliary device, similar to the Intel VSEC driver: see intel_vsec_add_aux() etc. Cheers, Rafael