Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp716811ybm; Fri, 29 May 2020 10:24:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwk7/HXoKEshusLH0oWYvNPUsqcYOJrM9LE7k7/qMMyHdXmeFO1WWhgUOcmGJxxwcGlwHal X-Received: by 2002:a17:907:2065:: with SMTP id qp5mr8451348ejb.136.1590773097045; Fri, 29 May 2020 10:24:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590773097; cv=none; d=google.com; s=arc-20160816; b=ugCpZlbRe9+a6j0EpCoVxqFunrEV0wafXhZA3MO2OOWa0HIuNAZbIyc+ljQx1NA+eO Vrnu5qoiaSr7F2wBEg+ZCpdNhtWg8FFY0Vl8+o8KkljKv23QWlN6txZ46cCsqZh9onTl A2wW3uRQFuvS0WIxnsxERUoVAqxUycknWh79bzsVOeHtFNUoVjwuH5vT8OZ+12yiOv1v F6+Vhmq6H+JRjre0+sGjBXgLTtOqwQ310AiREgK08ABBORVIUMgdudR0OPxfIJMROYTT kHUgR6b1sbckBvr6YnZbff1G5XzwYjhdQVNfqGbs0LGEdD4RK5iYlczxgrWUeme1FPlI 3QMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject; bh=V+/uJbHCq9s0j8+4nSJY3LbgLcFEQBwj9fkgAJLne0g=; b=Vv98EMxKrMblLCoysIRoyFkCrKSh6UVEipe2rGDkrZWkjGbpsK7BUfKgdTcF2MVbu0 B73ymNUJ+1xD6YzfZckisDIAqbs+5dz6FLwVgtMkrj428FlMJRqNDH6bOFRm7ooFcCEG mdMQVY8sRGMh0Iv8+q2LWx3TlZqh2cKZd/gJegpYUI/H9B583FWQC0IEKFVLeMoqtR33 BmdQUO7PtbQXlB5DHqioFFth0XNGXZ10zqgiISxHxWzbopV6p45BBS2QYlWuma3JuBgm gWo+MuXdSTYMQ0bmxr312dTghZqw/YPob3Iwslihc7U1QHAzcqo/HswdKFVGWWDXsyum 7qkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ba4si5497792edb.479.2020.05.29.10.24.32; Fri, 29 May 2020 10:24:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726943AbgE2RV7 (ORCPT + 99 others); Fri, 29 May 2020 13:21:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725839AbgE2RV6 (ORCPT ); Fri, 29 May 2020 13:21:58 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7CDF4C03E969; Fri, 29 May 2020 10:21:58 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: andrzej.p) with ESMTPSA id F17622A194B Subject: Re: [PATCH v4 04/11] thermal: Store device mode in struct thermal_zone_device From: Andrzej Pietrasiewicz To: Guenter Roeck Cc: linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, Emmanuel Grumbach , Heiko Stuebner , "Rafael J . Wysocki" , Vishal Kulkarni , Luca Coelho , Miquel Raynal , kernel@collabora.com, Fabio Estevam , Amit Kucheria , Chunyan Zhang , Daniel Lezcano , Allison Randal , NXP Linux Team , Darren Hart , Zhang Rui , Gayatri Kammela , Len Brown , Johannes Berg , Intel Linux Wireless , Sascha Hauer , Ido Schimmel , Baolin Wang , Jiri Pirko , Orson Zhai , Thomas Gleixner , Kalle Valo , Support Opensource , Enrico Weigelt , Peter Kaestle , Sebastian Reichel , Bartlomiej Zolnierkiewicz , Pengutronix Kernel Team , =?UTF-8?Q?Niklas_S=c3=b6derlund?= , Shawn Guo , "David S . Miller" , Andy Shevchenko References: <20200529154205.GA157653@roeck-us.net> <5010f7df-59d6-92ef-c99a-0dbd715f0ad2@collabora.com> Message-ID: Date: Fri, 29 May 2020 19:21:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5010f7df-59d6-92ef-c99a-0dbd715f0ad2@collabora.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Hi again, W dniu 29.05.2020 o 18:08, Andrzej Pietrasiewicz pisze: > Hi Guenter, > > W dniu 29.05.2020 o 17:42, Guenter Roeck pisze: >> On Thu, May 28, 2020 at 09:20:44PM +0200, Andrzej Pietrasiewicz wrote: >>> Prepare for eliminating get_mode(). >>> >> Might be worthwhile to explain (not only in the subject) what you are >> doing here. >> >>> Signed-off-by: Andrzej Pietrasiewicz >>> --- >>>   drivers/acpi/thermal.c                        | 18 ++++++---------- >>>   .../ethernet/mellanox/mlxsw/core_thermal.c    | 21 +++++++------------ >>>   drivers/platform/x86/acerhdf.c                | 15 ++++++------- >>>   drivers/thermal/da9062-thermal.c              |  6 ++---- >>>   drivers/thermal/imx_thermal.c                 | 17 +++++++-------- >>>   .../intel/int340x_thermal/int3400_thermal.c   | 12 +++-------- >>>   .../thermal/intel/intel_quark_dts_thermal.c   | 16 +++++++------- >>>   drivers/thermal/thermal_of.c                  | 10 +++------ >> >> After this patch is applied on top of the thermal 'testing' branch, >> there are still local instances of thermal_device_mode in >>     drivers/thermal/st/stm_thermal.c >>     drivers/thermal/ti-soc-thermal/ti-thermal-common.c >> >> If there is a reason not to replace those, it might make sense to explain >> it here. >> > > My understanding is that these two are sensor devices which are "plugged" > into their "parent" thermal zone device. The latter is the "proper" tzd. > They both use thermal_zone_of_device_ops instead of thermal_zone_device_ops. > The former doesn't even have get_mode(). The thermal core, when it calls > get_mode(), operates on the "parent" thermal zone devices. > > Consequently, the drivers you mention use their "mode" members for > their private purpose, not for the purpose of storing the "parent" > thermal zone device mode. > Let me also say it differently. Both drivers which you mention use devm_thermal_zone_of_sensor_register(). It calls thermal_zone_of_sensor_register(), which "will search the list of thermal zones described in device tree and look for the zone that refer to the sensor device pointed by @dev->of_node as temperature providers. For the zone pointing to the sensor node, the sensor will be added to the DT thermal zone device." When a match is found thermal_zone_of_add_sensor() is invoked, which (using thermal_zone_get_zone_by_name()) iterates over all registered thermal_zone_devices. The one eventually found will be returned and propagated to the original caller of devm_thermal_zone_of_sensor_register(). The state of this returned device is managed elsewhere (in that device's struct tzd). The "mode" member you are referring to is thus unrelated. Regards, Andrzej