linux-kernel - Re: [PATCH v13 12/18] platform: Add __free() based cleanup function for platform_device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0j-mwZmuciSTaL8MyAp530y=n9HbQ=uVvcnvGLR1n+YuQ@mail.gmail.com>
Date: Mon, 14 Oct 2024 20:06:40 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
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, rafael@...nel.org, 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, 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.

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