Message-ID: <20241015101025.00005305@Huawei.com>
Date: Tue, 15 Oct 2024 10:10:25 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
CC: Greg KH <gregkh@...uxfoundation.org>, <shiju.jose@...wei.com>,
	<linux-edac@...r.kernel.org>, <linux-cxl@...r.kernel.org>,
	<linux-acpi@...r.kernel.org>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>, <bp@...en8.de>, <tony.luck@...el.com>,
	<lenb@...nel.org>, <mchehab@...nel.org>, <dan.j.williams@...el.com>,
	<dave@...olabs.net>, <dave.jiang@...el.com>, <alison.schofield@...el.com>,
	<vishal.l.verma@...el.com>, <ira.weiny@...el.com>, <david@...hat.com>,
	<Vilas.Sridharan@....com>, <leo.duran@....com>, <Yazen.Ghannam@....com>,
	<rientjes@...gle.com>, <jiaqiyan@...gle.com>, <Jon.Grimm@....com>,
	<dave.hansen@...ux.intel.com>, <naoya.horiguchi@....com>,
	<james.morse@....com>, <jthoughton@...gle.com>, <somasundaram.a@....com>,
	<erdemaktas@...gle.com>, <pgonda@...gle.com>, <duenwen@...gle.com>,
	<gthelen@...gle.com>, <wschwartz@...erecomputing.com>,
	<dferguson@...erecomputing.com>, <wbs@...amperecomputing.com>,
	<nifan.cxl@...il.com>, <tanxiaofei@...wei.com>, <prime.zeng@...ilicon.com>,
	<roberto.sassu@...wei.com>, <kangkang.shen@...urewei.com>,
	<wanghuiqiang@...wei.com>, <linuxarm@...wei.com>
Subject: Re: [PATCH v13 12/18] platform: Add __free() based cleanup function
 for platform_device_put

On Mon, 14 Oct 2024 20:06:40 +0200
"Rafael J. Wysocki" <rafael@...nel.org> wrote:

> On Mon, Oct 14, 2024 at 7:17 PM Jonathan Cameron
> <Jonathan.Cameron@...wei.com> wrote:
> >
> > On Mon, 14 Oct 2024 18:04:37 +0200
> > Greg KH <gregkh@...uxfoundation.org> 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
> > > > > <shiju.jose@...wei.com> wrote:
> > > > >  
> > > > > > From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> > > > > >
> > > > > > Add __free() based cleanup function for platform_device_put().
> > > > > >
> > > > > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> > > > > > Signed-off-by: Shiju Jose <shiju.jose@...wei.com>
> > > > > > ---
> > > > > >  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



> 
> > 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.  
> 

Powered by blists - more mailing lists