On Mon, 14 Oct 2024 18:04:37 +0200
Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> wrote:
> > >
> > > > From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
> > > >
> > > > Add __free() based cleanup function for platform_device_put().
> > > >
> > > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
> > > > Signed-off-by: Shiju Jose <shiju.jose@xxxxxxxxxx>
> > > > ---
> > > > 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@xxxxxxxxxx/
> ?
>
> 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.
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.
Jonathan
>
> thanks,
>
> greg k-h
>
