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 8FFE0CFC279 for ; Tue, 15 Oct 2024 09:10:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC8076B0089; Tue, 15 Oct 2024 05:10:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C509E6B008A; Tue, 15 Oct 2024 05:10:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF1116B008C; Tue, 15 Oct 2024 05:10:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8D1D06B0089 for ; Tue, 15 Oct 2024 05:10:40 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B8B8F814D8 for ; Tue, 15 Oct 2024 09:10:32 +0000 (UTC) X-FDA: 82675266072.05.A98F717 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf10.hostedemail.com (Postfix) with ESMTP id E4368C0013 for ; Tue, 15 Oct 2024 09:10:33 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.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=1728983391; 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=fY+9R56RFbrqZ49hxUN9vQKdOJZa/0KHxxp7djcRkD4=; b=4RyRdA3uxhgipVbMZO8HtFuOzuOXyxO4XQSFz8aX66vToNJa6lkIVcIoKtMH4wVjg4qaMM z2Lo0A67sh1kr1RwKxwpkoWhuPTGJGJbMa6/tvUzbatmJOmCEzl19qhRoEZNHH/Qy8BC6v J4bGVKuUi5YEwem4ap5jJow4DFApuhk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.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=1728983391; a=rsa-sha256; cv=none; b=xVD0LqjlNQCmqiFDVr1eRYSWj398PRfsKxHo14VBUj45M/IMsfvGEMOhjGbxDkwaSvMgSu tEWNixqwHfpyKF8Y62g9bTaghXadTgiVO2NNRjoCxPoSxkaZwS5Lym5Lh4uswIqO38xc3d LacHD3Kc7PGL2c8dNl5qOvyRQprwRII= Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XSSwf4c5Rz6K93g; Tue, 15 Oct 2024 17:09:54 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id A73B7140AA7; Tue, 15 Oct 2024 17:10:28 +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:10:27 +0200 Date: Tue, 15 Oct 2024 10:10:25 +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: <20241015101025.00005305@Huawei.com> In-Reply-To: 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> 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: lhrpeml100001.china.huawei.com (7.191.160.183) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspam-User: X-Stat-Signature: z346ox87s5fpaz7nnkukoggyyptauksx X-Rspamd-Queue-Id: E4368C0013 X-Rspamd-Server: rspam11 X-HE-Tag: 1728983433-805151 X-HE-Meta: U2FsdGVkX18QtX8UBgi8rcTPoxkf1OijhIuSACgB289O1GH1J8jOhII0TX8VPZ0S+w9usKuz4vICPbuuDgCKVx+Zkv9UJC3ELQzf21KAhFxbVn9/dRQiDFGZymP5Ilkxqk12mL7zZzjfctytmKmhzuY0jWzxNTI1ZrNBYujF6SjL8LPPOHLCTpQNTM3SAxZ3tatcsJjbmK1gS0s8mFWYJobuptbmsSKTMwF41kO+9oGU/hpnyKd3ZnkcUFWutVJbMwNNxdJyPg6eqkI050AMQBgoRCje+22jalLI27FJ/Q9IAJAwCqAQkMWNEaGZcJS3LXNxnefWLItklvXNiaJODGNwUw6r+3Gk0CwwIcPvaM93PLiOn8cEFVLN6ZAtPZ10oG7yEo/Lbic/5u4fAaqmqt7LddKkIZEDdUPFHDoFCPqDkJ/4xwUFY8Wz1aaN0zFAawKLO3McrK6RfwQ+JOCkqm/7sncnpz0zdVSvLg0ppBEK1I9t3gywB8mCHoAJ7+wrzyRirsF9kQ2m6Q9b6sYwFQlin+O63X5qNodVDqpNLwvBhl7dpmbZxtNxUEp8mEVbuANT6zn6jAHNPdjZ1imKRFlaiLCbnSNq8m2OstslzAhJJ2FqdCkGlwFca9/lYEg+O9a42LtyGjeFK4vlH5C1Dt+LmCfnQk5fHjC4hjNL3lMzvqSlm4IomZX/XNSLKNZTUXK6hcb0KObQ0p6YHkHM0tX1A7BIOAfZu1yQnbxX4Q4EVqD8tzgiG6EZI5Prj8WwYj548YoLKLw06YvYnLRml8hwsnRCsq5tOWPhydiwJnJ1FUO4h2vsnxmiSlsy9il2oEhv6GuiFa5IQeArJ3aOz1DW0yJna5pWYP7eT00jjY5qx+JIYb7KXpXyw/17WmGHuzACdJfip4hX2tAb/YZ2+cCW1YmPemEnUZoBqmbAkf5e5XdFRqq6DOCxRQWh2DiLD5tDl1LZTy61EsH23/L WBdYJmtE ZiURliwOZp1ZAEusoEwOSJ/TXAlVbGD/Mfn+O3OMR7AVFoXmxCm4SMfvMJaTz8/epOzx0nY4xDtdXlVTPVL80S7MowAeUwhIsDU2zPgxP++sz3rSqHJBzFo3pDej65Ac1aWZhBDWFe4euvMLD5iwBP4g8pEd45+W5+RG+j2Ra91QecbT2oB29ZYhnTtcdMDfe+JS5caeCHhkjhHfkrv/+5Fz07CoVmyqfGyJjKhBycy1CvwyhGl2YyRyRKmFS00Uf9sSVhUyHj0BTPe8bHSlkws4DXPihQzO58Jy92UsmzWs2C9/qtsHJQj1LzjTKwO34AxveozA0eaiMt/ZcSouydTUD7dNvESsfecg82BnR5kUPgGWX58NHzuPjRqG4O9kmAsGPqQ3k59UELsJ9lbDqgXe3/HOaxiBsrhUIThhxaSxZDP6a7rQY1BVKow== 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 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: > > =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/pl= atform_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 *); =20 > > > > > > > > > > +CC Greg KH and Rafael. > > > > > > > > > > Makes sure to include them on v14 as this needs review from a dri= ver core point > > > > > of view I think. =20 > > > > > > > > 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 po= inter > > > > to a patch that uses this? =20 > > > > > > 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 platf= orm > > > 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 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. 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. =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! We'll explore alternatives and see what they end up looking like. Jonathan >=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