| Message ID | 1660649244-146842-3-git-send-email-john.garry@huawei.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
| Series | ACPI/PNP/HISI_LPC: Refactor ACPI platform code for reuse | expand |
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. ... > + 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.
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
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)
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(-)