From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6FA9C433F5 for ; Tue, 2 Nov 2021 14:24:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CF5076109D for ; Tue, 2 Nov 2021 14:24:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231558AbhKBO0t (ORCPT ); Tue, 2 Nov 2021 10:26:49 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:36172 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231588AbhKBO0l (ORCPT ); Tue, 2 Nov 2021 10:26:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635863046; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1YjJj9IqpDhJ07HE33uojzp5DuJdOMzvHOGPrvOy2QU=; b=b9AsSj6i1AcGLKQ2t8BdJ0vCpxnWC0HdlpYBh5pxxWKgBWDtFzzLMvO4Xxp3Dn5ZSfEEa0 NpSZPzESE3IJ+sQv6LxmfUj0jjFUyuBy8xnLGnXkX0Av9fDqW/FUQPJMp1pdBedcjTHJuU 3pxZ/bH7AS9W6DoBxOXHSbbsMeZtiQ0= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-357-P5jU7uSbMhmYTibpklrgqg-1; Tue, 02 Nov 2021 10:24:05 -0400 X-MC-Unique: P5jU7uSbMhmYTibpklrgqg-1 Received: by mail-ed1-f72.google.com with SMTP id v9-20020a50d849000000b003dcb31eabaaso19072850edj.13 for ; Tue, 02 Nov 2021 07:24:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=1YjJj9IqpDhJ07HE33uojzp5DuJdOMzvHOGPrvOy2QU=; b=U/0FKA0eAd7yg+w98RKpaTpU12SjLdHU+o9B5JB2IWUm+5X5D+0t5EzXaWkxdzYmzI Y3n8ywFq5PyaJa1OAjHcOdBE/j0De8Uofl6pou6iJvMnOeIs+2EEMsaqtLGYyg53NGul 4yQkS47XDiELBAywIgKCM/FEvIN6HqigSjpENyVuujVP4MfqI0KT49tDiQSzFOP291O9 aK9Bq8gZ7ch8vFL2yU2bu6fzg+ujs6C5/NuJRwXrxRyhmbq+WbcPX8TqOIHVSELasiiY bhZCm9cJma+JAezF8nZE3ZtFLLHJZbf1KcbYqIiJTPPSHukTLG28unb978yYyfySDkx4 VpKg== X-Gm-Message-State: AOAM532PIPl3ek0ISoD652wdSSWhA2wAMLePcctIOXhGTUF4uN9VsYkt OhVrUBeVoWNyeiTiVdpWWwS6DPi4Q7O+Eu1V7k2IuzO3LpBHqtSqefYnDFi9wvlrpR4q/1aIfGJ lqBttIEDkrnCmWjg2VSUPYFXV X-Received: by 2002:a17:907:7f8b:: with SMTP id qk11mr46491565ejc.313.1635863043786; Tue, 02 Nov 2021 07:24:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxkmvL1HIl9M3KIUQMmw+yeeX/QNnPDpALyKPCkIFoHEdHZkwzBVyQbxiHQ+ACffR2u+1RHkA== X-Received: by 2002:a17:907:7f8b:: with SMTP id qk11mr46491524ejc.313.1635863043578; Tue, 02 Nov 2021 07:24:03 -0700 (PDT) Received: from ?IPV6:2001:1c00:c1e:bf00:1054:9d19:e0f0:8214? (2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:1054:9d19:e0f0:8214]) by smtp.gmail.com with ESMTPSA id sg17sm3448785ejc.72.2021.11.02.07.24.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Nov 2021 07:24:02 -0700 (PDT) Message-ID: <8eaeca66-f719-6b5d-bd7c-ccbd15a0b91c@redhat.com> Date: Tue, 2 Nov 2021 15:24:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v5 07/11] platform/x86: int3472: Split into 2 drivers Content-Language: en-US To: Andy Shevchenko Cc: "Rafael J . Wysocki" , Mark Gross , Andy Shevchenko , Wolfram Sang , Mika Westerberg , Daniel Scally , Laurent Pinchart , Mauro Carvalho Chehab , Liam Girdwood , Mark Brown , Michael Turquette , Stephen Boyd , Len Brown , ACPI Devel Maling List , Platform Driver , Linux Kernel Mailing List , linux-i2c , Sakari Ailus , Kate Hsuan , Linux Media Mailing List , linux-clk References: <20211102094907.31271-1-hdegoede@redhat.com> <20211102094907.31271-8-hdegoede@redhat.com> From: Hans de Goede In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 11/2/21 15:16, Andy Shevchenko wrote: > On Tue, Nov 2, 2021 at 11:49 AM Hans de Goede 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