There is commonality between acpi_create_platform_device() and
hisi_lpc_acpi_add_child(), in that it covers 2x main steps:
- Read resources for the acpi_device
- Create platform device
Refactor acpi_create_platform_device() so that it may be reused by
hisi_lpc_acpi_add_child() to reduce duplication.
The following extended support is added:
- Allow custom platform device name be set
- Support platform data
- Support custom platform device id
- Support translating resources for Indirect PIO
Signed-off-by: John Garry <john.garry@huawei.com>
---
drivers/acpi/acpi_platform.c | 37 ++++++++++++++++++++++++++++--------
include/linux/acpi.h | 17 +++++++++++++++--
2 files changed, 44 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index de3cbf152dee..f153372a0b11 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -84,9 +84,14 @@ static void acpi_platform_fill_resource(struct acpi_device *adev,
}
/**
- * acpi_create_platform_device - Create platform device for ACPI device node
+ * acpi_create_platform_device_ops - Create platform device for ACPI device node
* @adev: ACPI device node to create a platform device for.
+ * @name: Name for platform device, may be unset
* @properties: Optional collection of build-in properties.
+ * @data: platform data pointer
+ * @size_data: platform data size
+ * @xlat: callback translate function for resources
+ * @id: platform device id
*
* Check if the given @adev can be represented as a platform device and, if
* that's the case, create and register a platform device, populate its common
@@ -94,8 +99,15 @@ static void acpi_platform_fill_resource(struct acpi_device *adev,
*
* Name of the platform device will be the same as @adev's.
*/
-struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
- const struct property_entry *properties)
+struct platform_device *acpi_create_platform_device_ops(
+ struct acpi_device *adev,
+ const char *name,
+ const struct property_entry *properties,
+ void *data, size_t size_data,
+ int (*xlat)(struct acpi_device *adev,
+ struct resource *res,
+ void *data, size_t size_data),
+ int id)
{
struct platform_device *pdev = NULL;
struct platform_device_info pdevinfo;
@@ -124,9 +136,13 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
return ERR_PTR(-ENOMEM);
}
count = 0;
- list_for_each_entry(rentry, &resource_list, node)
+ list_for_each_entry(rentry, &resource_list, node) {
acpi_platform_fill_resource(adev, rentry->res,
- &resources[count++]);
+ &resources[count]);
+ if (xlat)
+ xlat(adev, &resources[count], data, size_data);
+ count++;
+ }
acpi_dev_free_resource_list(&resource_list);
}
@@ -139,12 +155,17 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
*/
pdevinfo.parent = adev->parent ?
acpi_get_first_physical_node(adev->parent) : NULL;
- pdevinfo.name = dev_name(&adev->dev);
- pdevinfo.id = -1;
+ if (name)
+ pdevinfo.name = name;
+ else
+ pdevinfo.name = dev_name(&adev->dev);
+ pdevinfo.id = id;
pdevinfo.res = resources;
pdevinfo.num_res = count;
pdevinfo.fwnode = acpi_fwnode_handle(adev);
pdevinfo.properties = properties;
+ pdevinfo.data = data;
+ pdevinfo.size_data = size_data;
if (acpi_dma_supported(adev))
pdevinfo.dma_mask = DMA_BIT_MASK(32);
@@ -165,7 +186,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
return pdev;
}
-EXPORT_SYMBOL_GPL(acpi_create_platform_device);
+EXPORT_SYMBOL_GPL(acpi_create_platform_device_ops);
void __init acpi_platform_init(void)
{
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 6f64b2f3dc54..d657731086fd 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -28,6 +28,7 @@
#include <linux/dynamic_debug.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/platform_device.h>
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
@@ -721,8 +722,20 @@ extern bool acpi_driver_match_device(struct device *dev,
int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
int acpi_device_modalias(struct device *, char *, int);
-struct platform_device *acpi_create_platform_device(struct acpi_device *,
- const struct property_entry *);
+struct platform_device *acpi_create_platform_device_ops(
+ struct acpi_device *adev,
+ const char *name,
+ const struct property_entry *properties,
+ void *data, size_t size_data,
+ int (*xlat)(struct acpi_device *adev,
+ struct resource *res,
+ void *data, size_t size_data),
+ int id);
+
+#define acpi_create_platform_device(adev, properties) \
+ acpi_create_platform_device_ops(adev, NULL, properties, NULL, 0, \
+ NULL, PLATFORM_DEVID_NONE)
+
#define ACPI_PTR(_ptr) (_ptr)
static inline void acpi_device_set_enumerated(struct acpi_device *adev)
--
2.35.3On Tue, Aug 16, 2022 at 2:33 PM John Garry <john.garry@huawei.com> wrote:
>
> There is commonality between acpi_create_platform_device() and
> hisi_lpc_acpi_add_child(), in that it covers 2x main steps:
> - Read resources for the acpi_device
> - Create platform device
>
> Refactor acpi_create_platform_device() so that it may be reused by
> hisi_lpc_acpi_add_child() to reduce duplication.
...
> + * acpi_create_platform_device_ops - Create platform device for ACPI device node
Not sure I understand why _ops is a suffix for the function. I would
expect _ops to be a data struct where the ->xlate() and perhaps other
callbacks may be collected. It may be that I have missed that portion
in the previous discussion.
...
> + if (name)
> + pdevinfo.name = name;
> + else
> + pdevinfo.name = dev_name(&adev->dev);
> + pdevinfo.data = data;
> + pdevinfo.size_data = size_data;
It rather reminds me of platform device registration full with this
device info. May be what you need is
struct acpi_platfrom_device_info {
properties;
name;
id;
->xlate();
...
};
?
...
> +struct platform_device *acpi_create_platform_device_ops(
> + struct acpi_device *adev,
> + const char *name,
> + const struct property_entry *properties,
> + void *data, size_t size_data,
> + int (*xlat)(struct acpi_device *adev,
> + struct resource *res,
> + void *data, size_t size_data),
> + int id);
...because this looks a bit too much from the amount of parameters
point of view.
--
With Best Regards,
Andy Shevchenko
On 18/08/2022 20:41, Andy Shevchenko wrote:
> On Tue, Aug 16, 2022 at 2:33 PM John Garry <john.garry@huawei.com> wrote:
>>
>> There is commonality between acpi_create_platform_device() and
>> hisi_lpc_acpi_add_child(), in that it covers 2x main steps:
>> - Read resources for the acpi_device
>> - Create platform device
>>
>> Refactor acpi_create_platform_device() so that it may be reused by
>> hisi_lpc_acpi_add_child() to reduce duplication.
>
> ...
>
>> + * acpi_create_platform_device_ops - Create platform device for ACPI device node
>
> Not sure I understand why _ops is a suffix for the function. I would
> expect _ops to be a data struct where the ->xlate() and perhaps other
> callbacks may be collected. It may be that I have missed that portion
> in the previous discussion.
ok, maybe I can put all the members into a struct, but I don't think
that it improves the overall code too much.
>
> ...
>
>> + if (name)
>> + pdevinfo.name = name;
>> + else
>> + pdevinfo.name = dev_name(&adev->dev);
>
>> + pdevinfo.data = data;
>> + pdevinfo.size_data = size_data;
>
> It rather reminds me of platform device registration full with this
> device info. May be what you need is
> struct acpi_platfrom_device_info {
> properties;
> name;
> id;
> ->xlate();
> ...
> };
>
> ?
>
> ...
>
>> +struct platform_device *acpi_create_platform_device_ops(
>> + struct acpi_device *adev,
>> + const char *name,
>> + const struct property_entry *properties,
>> + void *data, size_t size_data,
>> + int (*xlat)(struct acpi_device *adev,
>> + struct resource *res,
>> + void *data, size_t size_data),
>> + int id);
>
> ...because this looks a bit too much from the amount of parameters
> point of view.
>
ok, agreed.
But even if we improve this code, the hisi_lpc changes are quite large
and unwieldly.
Thanks,
John
On Fri, Aug 19, 2022 at 10:10 AM John Garry <john.garry@huawei.com> wrote:
>
> On 18/08/2022 20:41, Andy Shevchenko wrote:
> > On Tue, Aug 16, 2022 at 2:33 PM John Garry <john.garry@huawei.com> wrote:
> >>
> >> There is commonality between acpi_create_platform_device() and
> >> hisi_lpc_acpi_add_child(), in that it covers 2x main steps:
> >> - Read resources for the acpi_device
> >> - Create platform device
> >>
> >> Refactor acpi_create_platform_device() so that it may be reused by
> >> hisi_lpc_acpi_add_child() to reduce duplication.
> >
> > ...
> >
> >> + * acpi_create_platform_device_ops - Create platform device for ACPI device node
> >
> > Not sure I understand why _ops is a suffix for the function. I would
> > expect _ops to be a data struct where the ->xlate() and perhaps other
> > callbacks may be collected. It may be that I have missed that portion
> > in the previous discussion.
>
> ok, maybe I can put all the members into a struct, but I don't think
> that it improves the overall code too much.
>
> >
> > ...
> >
> >> + if (name)
> >> + pdevinfo.name = name;
> >> + else
> >> + pdevinfo.name = dev_name(&adev->dev);
> >
> >> + pdevinfo.data = data;
> >> + pdevinfo.size_data = size_data;
> >
> > It rather reminds me of platform device registration full with this
> > device info. May be what you need is
> > struct acpi_platfrom_device_info {
> > properties;
> > name;
> > id;
> > ->xlate();
> > ...
> > };
> >
> > ?
> >
> > ...
> >
> >> +struct platform_device *acpi_create_platform_device_ops(
> >> + struct acpi_device *adev,
> >> + const char *name,
> >> + const struct property_entry *properties,
> >> + void *data, size_t size_data,
> >> + int (*xlat)(struct acpi_device *adev,
> >> + struct resource *res,
> >> + void *data, size_t size_data),
> >> + int id);
> >
> > ...because this looks a bit too much from the amount of parameters
> > point of view.
> >
>
> ok, agreed.
>
> But even if we improve this code, the hisi_lpc changes are quite large
> and unwieldly.
Well, they allow you to drop quite a few LOC ...
On 23/08/2022 17:42, Rafael J. Wysocki wrote: >>> >>>> +struct platform_device *acpi_create_platform_device_ops( >>>> + struct acpi_device *adev, >>>> + const char *name, >>>> + const struct property_entry *properties, >>>> + void *data, size_t size_data, >>>> + int (*xlat)(struct acpi_device *adev, >>>> + struct resource *res, >>>> + void *data, size_t size_data), >>>> + int id); >>> ...because this looks a bit too much from the amount of parameters >>> point of view. >>> >> ok, agreed. Hi Rafael, >> >> But even if we improve this code, the hisi_lpc changes are quite large >> and unwieldly. > Well, they allow you to drop quite a few LOC ... Sure, but the ACPI platform device code here is growing by about the same amount :) However maybe we can reduce that with Andy's idea to create a struct of function args. But first I will go with using platform_device_register_full() in hisi_lpc. And you please also check the PNP patch? I am not so keen on pushing for that. thanks, John
© 2016 - 2026 Red Hat, Inc.