Received: by 2002:a05:7412:ba23:b0:fa:4c10:6cad with SMTP id jp35csp233982rdb; Thu, 18 Jan 2024 01:47:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IGqxoaSOpYYaZKHVyf82Yw4kO+Hgnich8XxhA1+o73fm05fAT3L7K+SDG6Kv919qdTlZ2hW X-Received: by 2002:a17:906:b3a1:b0:a2c:535a:7c00 with SMTP id uh33-20020a170906b3a100b00a2c535a7c00mr224709ejc.195.1705571227348; Thu, 18 Jan 2024 01:47:07 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705571227; cv=pass; d=google.com; s=arc-20160816; b=g0Jgk1BfqMJ2eOpvM6MqkFlDDIgdpdppve8ny9Gs9BuTLRXoJp/UPBt67u4UnQF72o v3rosPIvo/O00oaqF8Znx1gbX4oTbCI6tODQHg7neDUpuPbmNqYxeWIQvge3Kh8cClRU XR0RAtqIlNOdqqGVxI/ZQKjBAqJ23SXicnduOhrKflPMtELhw/G5mt+t/E+WOZ3eTVWz 3IRSJfOr6B++9a84wLCJVRgJgeZFyZfDgDwS6esxCVjwwmb+WojE1MwpCZ4FCzGCkZbY Nfrh68GmkA+ojhGskikLwQngqCqQz7XsUxuqwaZ8QR2WDFmQ/EX/dlXtEwtz6X4s6aIS ukYw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=yJqyDbF++QfvZ17hb6RNGcr1MDo2P/j4gHOz0THr8DM=; fh=ehwy1zhPAPZS8vX6yUCG8BmjOgIGQp5CVdYpD2Wn31s=; b=bL8UZMHhPnOtlNag3oGjUAAj2XLweu2oYKfZpIT5MCPrFyS+vBmrvafUvN6UHEb9eu f86NVp52hVn/NQinVzuVAFiCiNbkwW97cf7nKmN8U9k07+M7TGmSQTaEDjY8Fn4wLEGJ 0tJi5Y6IFBl5yrZG97od6s1qCj+R4tq8Vt5UcSJZR23i7CapwXu7/nn9famUkI9pG2G3 F1Pf9RP4uyteSjgU8aVA3eOYjgz1ZLOLX9AEqtOF/Eamh+hqozOGXhOqkfYui+vLkcTi t7JHjwPUclr8m+u0bHO7nVlte5Pf210nfc5cH63UC2bk7Q3PkVRqA3bs71wWpjm0+ty4 AKNw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=hyWPPuKt; arc=pass (i=1 spf=pass spfdomain=collabora.com dkim=pass dkdomain=collabora.com dmarc=pass fromdomain=collabora.com); spf=pass (google.com: domain of linux-kernel+bounces-29980-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-29980-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id b17-20020a170906491100b00a2e9ef8928fsi1972819ejq.473.2024.01.18.01.47.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jan 2024 01:47:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-29980-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=hyWPPuKt; arc=pass (i=1 spf=pass spfdomain=collabora.com dkim=pass dkdomain=collabora.com dmarc=pass fromdomain=collabora.com); spf=pass (google.com: domain of linux-kernel+bounces-29980-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-29980-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id ED6A71F21B95 for ; Thu, 18 Jan 2024 09:47:06 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CB2161F94D; Thu, 18 Jan 2024 09:46:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="hyWPPuKt" Received: from madrid.collaboradmins.com (madrid.collaboradmins.com [46.235.227.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 805261F934; Thu, 18 Jan 2024 09:46:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.235.227.194 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705571213; cv=none; b=LmnbsapaHuwT1u7yOD8qbhFPmUqDRqsqQRs3ynxAMP726hB1GZW/Er5TIZcG6D+flDWdGL28N7UVRqrbBth7kIw8h8SJpup05+6ALoWneTRz7NkimJGA8a7dbsHib4vU64czo2pWJtq1qP3ZaQ6+jDbSsYVFff6APi6yAflDiwo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705571213; c=relaxed/simple; bh=saLotL2mkh07t8TficsUVCmF3iC0FBVXR0Jxq4GNmnU=; h=DKIM-Signature:Received:Message-ID:Date:MIME-Version:User-Agent: Subject:Content-Language:From:To:Cc:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=lOoNzKXtv8QDGe8NLhVn0p66SdmAux3chEq2EkrFhVc0ORHuorGWy5oE9dbm/fQH8xtE+FAU3tFDiNMzwaVOdYMPDd/jxCvk8AjaH45U2N0KyzLQiAQcBKS5R87d/2uzqDbB0OO6F6iqt6MWre0L6louzRzyIpbEWmLyqE4AFtk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=hyWPPuKt; arc=none smtp.client-ip=46.235.227.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1705571209; bh=saLotL2mkh07t8TficsUVCmF3iC0FBVXR0Jxq4GNmnU=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=hyWPPuKtVRq0gPMYXRbwAle3sGCxvgsC7rImkS7RK3Q17ixVoJ0sUeATsbsO7C6gV Z6/1H8hcvsv2ICU3P9lVdRCFRwX8n7L7+fNqCsS0biYlXU3vO6DegYXM6dIlOc0w3P KP1OPluN3YZyzSCDTUyoK6vSXqPYgfnY/oEKTNnp1Iv6afony7rGnWvqh75ODZzVii oGnbY68/4RJzS8qDS1OugmedUgWbW12JaL7G2XI0PocLx7jhdE8VZP2VMbRm+STIkF 2+Q2+DOQIy/e1FvRsJtUUcxJJtSD4M8heB2evVVyKRyU9r7nZA3FzlmohXE4NfOR7E dJ+UVEoQqSZwQ== Received: from [100.113.186.2] (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madrid.collaboradmins.com (Postfix) with ESMTPSA id 3A9833781F8E; Thu, 18 Jan 2024 09:46:49 +0000 (UTC) Message-ID: <7db00375-23cc-45eb-b91b-6846fde2302c@collabora.com> Date: Thu, 18 Jan 2024 10:46:48 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 01/26] thermal: Introduce thermal_zone_device_register() and params structure Content-Language: en-US From: AngeloGioacchino Del Regno To: Daniel Lezcano Cc: rafael@kernel.org, rui.zhang@intel.com, lukasz.luba@arm.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, kernel@collabora.com References: <20231221124825.149141-1-angelogioacchino.delregno@collabora.com> <20231221124825.149141-2-angelogioacchino.delregno@collabora.com> <7417c498-2439-485d-9f78-fbb22f9ce393@linaro.org> <33c7d36d-c2f5-477f-946a-6ad926a277d7@collabora.com> <9783d2a6-7395-4516-9fd1-d7c42ea35d07@collabora.com> In-Reply-To: <9783d2a6-7395-4516-9fd1-d7c42ea35d07@collabora.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Il 18/01/24 10:39, AngeloGioacchino Del Regno ha scritto: > Il 16/01/24 10:58, AngeloGioacchino Del Regno ha scritto: >> Il 15/01/24 13:39, Daniel Lezcano ha scritto: >>> On 21/12/2023 13:48, AngeloGioacchino Del Regno wrote: >>>> In preparation for extending the thermal zone devices to actually have >>>> a name and disambiguation of thermal zone types/names, introduce a new >>>> thermal_zone_device_params structure which holds all of the parameters >>>> that are necessary to register a thermal zone device, then add a new >>>> function thermal_zone_device_register(). >>>> >>>> The latter takes as parameter the newly introduced structure and is >>>> made to eventually replace all usages of the now deprecated function >>>> thermal_zone_device_register_with_trips() and of >>>> thermal_tripless_zone_device_register(). >>>> >>>> Signed-off-by: AngeloGioacchino Del Regno >>>> >>>> --- >>>>   drivers/thermal/thermal_core.c | 27 +++++++++++++++++++++++++++ >>>>   include/linux/thermal.h        | 33 +++++++++++++++++++++++++++++++++ >>>>   2 files changed, 60 insertions(+) >>>> >>>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c >>>> index e5434cdbf23b..6be508eb2d72 100644 >>>> --- a/drivers/thermal/thermal_core.c >>>> +++ b/drivers/thermal/thermal_core.c >>>> @@ -1235,6 +1235,8 @@ EXPORT_SYMBOL_GPL(thermal_zone_get_crit_temp); >>>>    *           whether trip points have been crossed (0 for interrupt >>>>    *           driven systems) >>>>    * >>>> + * This function is deprecated. See thermal_zone_device_register(). >>>> + * >>>>    * This interface function adds a new thermal zone device (sensor) to >>>>    * /sys/class/thermal folder as thermal_zone[0-*]. It tries to bind all the >>>>    * thermal cooling devices registered at the same time. >>>> @@ -1409,6 +1411,7 @@ thermal_zone_device_register_with_trips(const char *type, >>>> struct thermal_trip *t >>>>   } >>>>   EXPORT_SYMBOL_GPL(thermal_zone_device_register_with_trips); >>>> +/* This function is deprecated. See thermal_zone_device_register(). */ >>>>   struct thermal_zone_device *thermal_tripless_zone_device_register( >>>>                       const char *type, >>>>                       void *devdata, >>>> @@ -1420,6 +1423,30 @@ struct thermal_zone_device >>>> *thermal_tripless_zone_device_register( >>>>   } >>>>   EXPORT_SYMBOL_GPL(thermal_tripless_zone_device_register); >>>> +/** >>>> + * thermal_zone_device_register() - register a new thermal zone device >>>> + * @tzdp:    Parameters of the new thermal zone device >>>> + *        See struct thermal_zone_device_register. >>>> + * >>>> + * This interface function adds a new thermal zone device (sensor) to >>>> + * /sys/class/thermal folder as thermal_zone[0-*]. It tries to bind all the >>>> + * thermal cooling devices registered at the same time. >>>> + * thermal_zone_device_unregister() must be called when the device is no >>>> + * longer needed. The passive cooling depends on the .get_trend() return value. >>>> + * >>>> + * Return: a pointer to the created struct thermal_zone_device or an >>>> + * in case of error, an ERR_PTR. Caller must check return value with >>>> + * IS_ERR*() helpers. >>>> + */ >>>> +struct thermal_zone_device *thermal_zone_device_register(struct >>>> thermal_zone_device_params *tzdp) >>>> +{ >>>> +    return thermal_zone_device_register_with_trips(tzdp->type, tzdp->trips, >>>> tzdp->num_trips, >>>> +                               tzdp->mask, tzdp->devdata, tzdp->ops, >>>> +                               &tzdp->tzp, tzdp->passive_delay, >>>> +                               tzdp->polling_delay); >>>> +} >>>> +EXPORT_SYMBOL_GPL(thermal_zone_device_register); >>>> + >>>>   void *thermal_zone_device_priv(struct thermal_zone_device *tzd) >>>>   { >>>>       return tzd->devdata; >>>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h >>>> index 98957bae08ff..c6ed33a7e468 100644 >>>> --- a/include/linux/thermal.h >>>> +++ b/include/linux/thermal.h >>>> @@ -258,6 +258,33 @@ struct thermal_zone_params { >>>>       int offset; >>>>   }; >>>> +/** >>>> + * struct thermal_zone_device_params - parameters for a thermal zone device >>>> + * @type:        the thermal zone device type >>>> + * @tzp:        thermal zone platform parameters >>>> + * @ops:        standard thermal zone device callbacks >>>> + * @devdata:        private device data >>>> + * @trips:        a pointer to an array of thermal trips, if any >>>> + * @num_trips:        the number of trip points the thermal zone support >>>> + * @mask:        a bit string indicating the writeablility of trip points >>>> + * @passive_delay:    number of milliseconds to wait between polls when >>>> + *            performing passive cooling >>>> + * @polling_delay:    number of milliseconds to wait between polls when checking >>>> + *            whether trip points have been crossed (0 for interrupt >>>> + *            driven systems) >>>> + */ >>>> +struct thermal_zone_device_params { >>>> +    const char *type; >>>> +    struct thermal_zone_params tzp; >>>> +    struct thermal_zone_device_ops *ops; >>>> +    void *devdata; >>>> +    struct thermal_trip *trips; >>>> +    int num_trips; >>>> +    int mask; >>>> +    int passive_delay; >>>> +    int polling_delay; >>>> +}; >>> >>>  From my POV, this "struct thermal_zone_params" has been always a inadequate and >>> catch-all structure. It will confuse with thermal_zone_device_params >>> >>> I suggest to cleanup a bit that by sorting the parameters in the right >>> structures where the result could be something like: >>> >>> eg. >>> >>> struct thermal_zone_params { >>> >>>      const char *type; >>>      struct thermal_zone_device_ops *ops; >>>      struct thermal_trip *trips; >>>      int num_trips; >>> >>>      int passive_delay; >>>      int polling_delay; >>> >>>      void *devdata; >>>          bool no_hwmon; >>> }; >>> >>> struct thermal_governor_ipa_params { >>>          u32 sustainable_power; >>>          s32 k_po; >>>          s32 k_pu; >>>          s32 k_i; >>>          s32 k_d; >>>          s32 integral_cutoff; >>>          int slope; >>>          int offset; >>> }; >>> >>> struct thermal_governor_params { >>>      char governor_name[THERMAL_NAME_LENGTH]; >>>      union { >>>          struct thermal_governor_ipa_params ipa_params; >>>      }; >>> }; >>> >>> struct thermal_zone_device_params { >>>      struct thermal_zone_params *tzp; >>>      struct thermal_governor_params *tgp; >>> } >>> >>> No functional changes just code reorg, being a series to be submitted before the >>> rest on these RFC changes (2->26) >>> >> >> Could work. It's true that thermal_zone_params is a catch-all structure, and it's >> not really the best... but I also haven't checked how complex and/or how much time >> would your proposed change take. >> >> Shouldn't take much as far as I can foresee, but I really have to check a bit. >> If I'm right as in it's not something huge, the next series will directly have >> this stuff sorted - if not, I'll reach to you. >> > > So... I've checked the situation and coded some. > > I came to the conclusion that doing it as suggested is possible but realistically > suboptimal, because that will need multiple immutable branches to actually end up > in upstream as changes would otherwise break kernel build. > > Then, here I am suggesting a different way forward, while still performing this > much needed cleanup and reorganization: > > First, we introduce thermal_zone_device_register() and params structure with > this commit, which will have > > /* Structure to define Thermal Zone parameters */ > struct thermal_zone_params { >     /* Scheduled for removal - see struct thermal_zone_governor_params. */ >     char governor_name[THERMAL_NAME_LENGTH]; > >     /* Scheduled for removal - see struct thermal_zone_governor_params. */ >     bool no_hwmon; > >     /* >      * Sustainable power (heat) that this thermal zone can dissipate in >      * mW >      */ >     u32 sustainable_power; > >     /* >      * Proportional parameter of the PID controller when >      * overshooting (i.e., when temperature is below the target) >      */ >     s32 k_po; > >     /* >      * Proportional parameter of the PID controller when >      * undershooting >      */ >     s32 k_pu; > >     /* Integral parameter of the PID controller */ >     s32 k_i; > >     /* Derivative parameter of the PID controller */ >     s32 k_d; > >     /* threshold below which the error is no longer accumulated */ >     s32 integral_cutoff; > >     /* >      * @slope:    slope of a linear temperature adjustment curve. >      *         Used by thermal zone drivers. >      */ >     int slope; >     /* >      * @offset:    offset of a linear temperature adjustment curve. >      *         Used by thermal zone drivers (default 0). >      */ >     int offset; > }; > > struct thermal_governor_params { >     char governor_name[THERMAL_NAME_LENGTH]; >     struct thermal_zone_params ipa_params; > }; > > struct thermal_zone_platform_params { >     const char *type; >     struct thermal_zone_device_ops *ops; >     struct thermal_trip *trips; >     int num_trips; >     int mask; > >     int passive_delay; >     int polling_delay; > >     void *devdata; >     bool no_hwmon; > }; > > > struct thermal_zone_device_params { >     struct thermal_zone_platform_params tzp; >     struct thermal_governor_params *tgp; > }; > > (Note that the `no_hwmon` and `governor_name` are *temporarily* duplicated, but > there are good reasons to do that!) > > Drivers will follow with the migration to `thermal_zone_device_register()`, > and that will be done *strictly* like so: > > struct thermal_zone_device_params tzdp = { >     .tzp = { >         .type = "acerhdf", >         .tzp = { .governor_name = "bang_bang" }, Whoops, sorry, this .tzp should've been removed, my bad! >         .ops = &acerhdf_dev_ops, >         .trips = trips, >         .num_trips = ARRAY_SIZE(trips), >         .polling_delay = kernelmode ? interval * 1000 : 0, >         /* devdata, no_hwmon go here later in the code */ >     }, >     .tgp = { .governor_name = "bang_bang" } > }; Looks like this instead: struct thermal_zone_device_params tzdp = { .tzp = { .type = "acerhdf", .ops = &acerhdf_dev_ops, .trips = trips, .num_trips = ARRAY_SIZE(trips), .polling_delay = kernelmode ? interval * 1000 : 0, }, .tgp = { .governor_name = "bang_bang" } }; > > Notice how in this case we're never *ever* referencing to any struct name, > apart from struct thermal_zone_device_params (meaning, I'm never creating > vars/pointers to struct thermal_zone_platform_params). > > If we follow this style, at least temporarily and at least during this cleanup, > we will end up with a plan such that: > > 1. In the first merge window: >    - Drivers get migrated to thermal_zone_device_register() >    - Functions register_with_trips()/tripless get deprecated but not yet removed > > 2. In the next merge window (expecting all users updated from the first window): >    - Functions register_with_trips/tripless get removed (<- no more external refs >      to struct thermal_zone_params, which can be then safely renamed!) >    - Duplicated members governor_name and no_hwmon get removed from >      struct thermal_zone_params >    - Some structures get renamed to give them the proposed better names (which >      I also genuinely like) >    - Only Thermal API internal changes, as users (all the ones that are not in >      drivers/thermal/) won't need to get updated at all! >      ... and that's why I said "strictly like so" in the example up there. > > I think that this is the best strategy, for both ease of merging the changes and > internal reorganization. > > Sure in the first merge window we'll be wasting a byte or two, but I am confident > in that this is a very low price to pay - and even better, only temporarily - for > other bigger benefits. > > What do you think? > > Cheers! > Angelo