On Mon, Oct 14, 2024 at 7:17 PM Jonathan Cameron
<Jonathan.Cameron@xxxxxxxxxx> wrote:
>
> 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.
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.
