On Tue, Oct 15, 2024 at 4:19 PM Jonathan Cameron
<Jonathan.Cameron@xxxxxxxxxx> wrote:
>
> On Tue, 15 Oct 2024 15:32:28 +0200
> "Rafael J. Wysocki" <rafael@xxxxxxxxxx> wrote:
>
> > On Tue, Oct 15, 2024 at 12:17 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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 <Jonathan.Cameron@xxxxxxxxxx> wrote:
> > > >
> > > > > On Mon, 14 Oct 2024 20:06:40 +0200
> > > > > "Rafael J. Wysocki" <rafael@xxxxxxxxxx> wrote:
> > > > >
> > > > > > 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.
> > > > >
> > > > > 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
> > > > >
> > > >
> > > > Greg,
> > > >
> > > > I'm struggling a little to figure out how you envision the virtual bus
> > > > working here. So before we spend too much time implementing the wrong 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 (these
> > > > are one per independent feature). Each feature has its own mailbox sub
> > > > 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 understand
> > > why ACPI isn't creating your devices for you, as this is ACPI code,
> > > perhaps just fix that up instead? That would make much more sense to
> > > me...
> >
> > Because it is a data-only table, not AML.
> >
> > It looks to me like this could be an auxiliary device, similar to the
> > Intel VSEC driver: see intel_vsec_add_aux() etc.
> >
>
> That was in the other branch of the thread abbreviated as auxbus.
> My concern with that approach is we have no parent device and the
> auxiliary bus is always described as being for sub parts of a
> compound device. In the intel_vsec case there is always a parent
> pci device or platform device.
>
> I don't think there is any functional requirement for a real parent,
> it just feels like abuse given the stated purpose of auxiliary bus.
> Greg, auxiliary bus or separate acpi_ras2 bus feel better to you?
>
> We'd need to parent it off something to avoid the check in
> auxiliary_device_init() + all devices should have a parent anyway.
Wouldn't that be the platform device providing the mailbox memory
addresses mentioned in one of the previous messages?
