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.
> + return ERR_PTR(-EINVAL);
> + }
> +
> + return obj;
> +}
--
With Best Regards,
Andy Shevchenko
