[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <752f92ba-4957-545c-51f7-7e71648d92e4@huawei.com>
Date: Tue, 5 Jul 2022 16:16:56 +0100
From: John Garry <john.garry@...wei.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
CC: Andy Shevchenko <andy.shevchenko@...il.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux ACPI <linux-acpi@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Yang Yingliang <yangyingliang@...wei.com>
Subject: Re: [PATCH v3] hisi_lpc: Use acpi_dev_for_each_child()
> Next, I'd look at introducing something like
>
> acpi_create_platform_device_ops(struct acpi_device *adev, const struct
> property_entry *properties, const struct *platform_device_create_ops
> *ops);
>
> where ops would be a set of callbacks to invoke as a matter of customization.
>
> Then, acpi_create_platform_device() can be defined as a wrapper around
> the above.
> .
ok, that seems easiest. But alternatively do you see any scope to have
that platform_device_create_ops * ops in the acpi_device struct (so that
we don't need to create this new API)?
Thanks,
John
Powered by blists - more mailing lists