Hi, On 11/2/21 15:16, Andy Shevchenko wrote: > On Tue, Nov 2, 2021 at 11:49 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >> >> The intel_skl_int3472.ko module contains 2 separate drivers, >> the int3472_discrete platform driver and the int3472_tps68470 >> I2C-driver. >> >> These 2 drivers contain very little shared code, only >> skl_int3472_get_acpi_buffer() and skl_int3472_fill_cldb() are >> shared. >> >> Split the module into 2 drivers, linking the little shared code >> directly into both. >> >> This will allow us to add soft-module dependencies for the >> tps68470 clk, gpio and regulator drivers to the new >> intel_skl_int3472_tps68470.ko to help with probe ordering issues >> without causing these modules to get loaded on boards which only >> use the int3472_discrete platform driver. >> >> While at it also rename the .c and .h files to remove the >> cumbersome intel_skl_int3472_ prefix. > > ... > >> +union acpi_object *skl_int3472_get_acpi_buffer(struct acpi_device *adev, char *id) >> +{ >> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; >> + acpi_handle handle = adev->handle; >> + union acpi_object *obj; >> + acpi_status status; >> + >> + status = acpi_evaluate_object(handle, id, NULL, &buffer); >> + if (ACPI_FAILURE(status)) >> + return ERR_PTR(-ENODEV); >> + >> + obj = buffer.pointer; >> + if (!obj) >> + return ERR_PTR(-ENODEV); >> + >> + if (obj->type != ACPI_TYPE_BUFFER) { >> + acpi_handle_err(handle, "%s object is not an ACPI buffer\n", id); > >> + kfree(obj); > > I'm wondering if we should use more of the ACPI_FREE() calls as > opposed to ACPI_ALLOCATE_BUFFER. Ditto for all such cases. Basically the situation surrounding this is a mess, most code seems to simply use plain kfree() which I find much more readable, but some code indeed is using ACPI_FREE(), which I believe is really mostly meant for internal use by the acpica code. Eitherway until one of the ACPI maintainers clearly states that we really should use ACPI_FREE() here I plan to stick with kfree() because: 1. I find it much more readable. 2. AFAICT ACPI_FREE() is meant for acpica internal use (basically it is part of the OS abstraction bits of acpica) Regards, Hans