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 9028AD216A6 for ; Tue, 15 Oct 2024 13:37:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 276246B0092; Tue, 15 Oct 2024 09:37:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 226366B0095; Tue, 15 Oct 2024 09:37:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C7456B0096; Tue, 15 Oct 2024 09:37:54 -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 E1AA66B0092 for ; Tue, 15 Oct 2024 09:37:53 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 17988C02A7 for ; Tue, 15 Oct 2024 13:37:44 +0000 (UTC) X-FDA: 82675939332.19.4B08795 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf27.hostedemail.com (Postfix) with ESMTP id 3D75F4000C for ; Tue, 15 Oct 2024 13:37:44 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ETB4zcJ1; spf=pass (imf27.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=1728999281; 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=ovC4n+7LWKxzS9TBlY1W1C0W2JaG3Y90ELjF7Q8BBAs=; b=id4ik4vZEtvZqxPY9P807M0bf5yHc4FPmeUPDCpWsQ2O/rSqY5qwhihqMiKYbTFWrlAHsh +Hx4SMyKkp0g8vJWZeQQpO904TH5coxmGwuF5/du5vOpbSZS1IAFkkwRYksTc+jNkyWAZV 0g9lWgKenG1WtE6Y8MA60STmLuZH/hw= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ETB4zcJ1; spf=pass (imf27.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=1728999281; a=rsa-sha256; cv=none; b=QAuxOeT6UxWKtw3av5vtFmokQQ+Dr5ValZzjLTTXmvNe+aqYq6MBJJNDnqY45a01y3Qddr Exoj9H98CP+U7QaTG0iuwSQS943LUmBV02NHPrcpUQ1RJo+AymMjN52AiOtdeg81dXQ3UY WPckok14aB2dsAI5cn7tCsSyVxHlURw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id C9906A4296B for ; Tue, 15 Oct 2024 13:37:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E85DAC4CED4 for ; Tue, 15 Oct 2024 13:37:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728999469; bh=0lvh4hdmAOb0s83k6vRo9pwBzqdkcx+VSvXBxzdAwRM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ETB4zcJ1bvQRIrZfCBt/w7Dc7v09G+KDOEM7YA4g1rZeu3T+oRmH729LpkIJVyRrp TKWzd8XULvEqZs8Cs7RueHcOrDG1bRcl9CsJ/G53W921B1+FCaTd7etqPafMQlAI0F ib1oBpW41pJegIROlzO+OLuAWgdgYvDh9dot00AOBkeIuy2X2pRb4KuI75dNMm3YaB PKyHbRIBBhJ81yitlfck0J8ZWBasEmNmcgxAbnCFKDFuFRHNLa/MAj6RyrO8gI7htp ojSbErckGxeUdLcaSzMJSYwi3eqYbzz1Fp+7CvxDRrqTs2c2DOWLf89K/2qzMJPY1Z x28xzBhSZpQAw== Received: by mail-oo1-f48.google.com with SMTP id 006d021491bc7-5e7ff233e12so3038725eaf.1 for ; Tue, 15 Oct 2024 06:37:49 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUeonPsq5YgpqCYhEnZn6fnmXz8QmMR2XTEgsvRakaclZ2WQTut7CZkqOyOPPCP7gSfIClI63URvg==@kvack.org X-Gm-Message-State: AOJu0Yx3oP/mdttEksB3cHPzg2J5369ISwapb9/1Rgze2fx7nk/Xi9Nx QCVXURdXU9G9hTVZM7p+n9OwpwxqDg9iL6ib8AjAdQlgQU6JITCoUkDaPQZmmmiiPjWNuDnHZR8 lMqSOUD7dTzk0i57IhNztwCmvLog= X-Google-Smtp-Source: AGHT+IHfAX/cxRLnscOYJv3CtQRPKm7/cRU8i/lagw3N7aaUlIjeOz1E8fXmGihj25bXbFeQaFWbA5ocgWv+38FeYL4= X-Received: by 2002:a05:6871:14f:b0:287:4904:7125 with SMTP id 586e51a60fabf-288ede0f330mr289191fac.14.1728999469127; Tue, 15 Oct 2024 06:37:49 -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> <20241015143426.00002e5b@Huawei.com> In-Reply-To: <20241015143426.00002e5b@Huawei.com> From: "Rafael J. Wysocki" Date: Tue, 15 Oct 2024 15:37:38 +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: Jonathan Cameron Cc: Greg KH , "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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3D75F4000C X-Stat-Signature: goztwhso47cn8knp9yx93qq9z5j7eq93 X-Rspam-User: X-HE-Tag: 1728999464-583064 X-HE-Meta: U2FsdGVkX1+6PA0i/SD7WNHIPq8CDhlWe13wNLIa1mvN5POOGmHH2Sti9YlSji9r5cwHrAjYiNZe1gGVJPxMjujRH4i/Dwr2IrQl3/rDdwpT7ULrWh4Z1DBqNaagUm8+pDA6Q1EMe8dIsx51LnxFUlN1R9OdWTO/YLtlydSdW87iGtce23wM0SP6S9Fjs+loNF6wVNakCrdYmJ/V/nGoP+U3qGGgFVvZffEpskamCCa2ZyZ4S20gd152VbiF9yuzts2b+gwSuSIoZf0hDVIvc1a949kPrCXnSk73uKcsM/VELQIrtZTqYryfU4kPL/4UBUvJVjcDj4TX6XxoOYbH1JDVx32u5MalVxqzAWHVqg3kvc76v9L5jvYoDvaGSiLGtMAFQ+PpPwgbNZtRbl3IZXCvH1F3cAk/UD93I8pLaT5EAxHTn+Vo1a7BS3IWcyTyaOqC7/weuB1aZAptsrAkvpEqqbYiuB6yWKqIKnZvPTPNHVzQy37MZ1lqP+ZM0B+L4MxN/NjQ2K6So5Se/LRCtLhcWisCdjKHmxYYd+GQF9XQoVdYT/67okYck5/E6YofRfJSsgqCrZH8IgounK0ha+ok6T96tA/wT2PyMvSj+QGT9aJFEGdp5lDjlr5tTVPxJkvgTrfS/k4rg+1PmSBXQ1g+9dfEkm+Fk/QW5aHHERWmDyMZpAE0ZAlwsnE6WJ8KUKgKf4FR1yoW/czV2so/PlXKGRTeP9dj4gleW7XiUN72rNnXWXv1Ue8lg2wBkmKAKafEgOf9vPOfhDaJSvEIk5K/Z/PPUNzkavoVJU8RPSe4pKcbGB5yCK9BZ2Ks3GkmlLu2Sn/Wua2beamwYqy77w+mcYNtTiqhBqEnTt5P28wN7aNfEHBxK019lCTBE9lR7wlXIKYR44t8hUf4PlASqmVj9erESjmFMohv0BIQHL6s9AY5gMtAIklSE+AT3FJFs9JFKt/TGNVnJM3Zc7Z yn5ZITF4 2stt4l8iR3w+tC9iFUC4S4iVQEFmCxd4AlA1aTZqsrDolm7vUJwTNDdC0PyCcB7206HdttncAtjfV9Lzxp701wYx6lgBwL6EYz4UKWTUqqlCzpoP31A5ZQmipP3L0uQdt+T3eEkRXjwXb4yJbrylB4rxpC14Ri+S34AAVYtaw1iEAHlB+XMmKJnoU/z/cIJ4jw9b0+OY42jIeQbUNXaEtOpN7ObGKnE8vuTI7XJxjIIKY2kWx3a9OaqmuA/mBbztHlejyFnrDUQSEHXXDIVsr1G7DdG26zFNTnQGkeQ8bzQF6xPKAxl4idimo0qRc/SyRAsS/MQB6mCmCaXDVNiPeVm0KO/4VnsIjWnziG2Ldb95t1p+pQqisTqum48EddKzzMe4kJuZHBhER1QSYNOQrFO8tBWZU5VDmkmkiN7UUioBV7tdnydXBq2a+NNfjkHfxDHzicl6kha2HycwcDTn/7FHYAObXCZ5cPHF3JMw2cWk/K/aEXYyF+Xup/Y3SwtgNXqME 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 3:34=E2=80=AFPM Jonathan Cameron wrote: > > 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: > > > > > > > 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 = 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_devic= e *, 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 fr= om 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? H= ave a pointer > > > > > > > > to a patch that uses this? > > > > > > > > > > > > > > Ah, is it this one: > > > > > > > https://lore.kernel.org/all/20241014164955.00003439@Hua= wei.com/ > > > > > > > ? > > > > > > > > > > > > > > If so, no, that's an abuse of a platform device, don't do tha= t, make a > > > > > > > REAL device on the bus that this device lives on. If it does= n't live on > > > > > > > a real bus, then put it on the virtual bus but do NOT abuse t= he platform > > > > > > > device layer for something like this. > > > > > > > > > > > > Ok. Probably virtual bus it is then. Rafael, what do you thin= k makes sense > > > > > > for a 'feature' that is described only by an ACPI table (here R= AS2)? > > > > > > Kind of similar(ish) to say IORT. > > > > > > > > > > Good question. > > > > > > > > > > I guess it depends on whether or not there are any registers to a= ccess > > > > > or AML to interact with. If so, I think that a platform device m= akes > > > > > 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 indirec= tly > > > > 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 d= on'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 rea= son! > > > > > > > > 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 bu= s > > > working here. So before we spend too much time implementing the wron= g 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 (t= hese > > > are one per independent feature). Each feature has its own mailbox su= b > > > 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 understan= d > > why ACPI isn't creating your devices for you, as this is ACPI code, > > perhaps just fix that up instead? > > 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 par= sed > (maybe Rafael can point at another) one of two things happen: > 1) The table is parsed and platform devices are created for the entries f= ound > (IORT etc) to which drivers later bind. > 2) There is a 'fake' device in DSDT. E.g. ACPI0012 for NFIT, ACPI0017 for= CEDT > (the CXL table) that are there to trigger enumeration of the static table= and > 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. Have you looked at auxiliary devices?