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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D609AC433FE for ; Tue, 17 May 2022 16:51:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351206AbiEQQvT (ORCPT ); Tue, 17 May 2022 12:51:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351207AbiEQQu7 (ORCPT ); Tue, 17 May 2022 12:50:59 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E5AE2BE7; Tue, 17 May 2022 09:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652806257; x=1684342257; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=9E/vttDFy0EFq5zSJDnsg0HX9OScE43/QxlsTcLOYjs=; b=UJP/OC/2KaLR5AWSQouaN1Gn86vjq8OiJlF4rj4czHPCzl1W20K28/yj E48d3/mnsQq9MGhMPHzQhwRhrS6Y9ylFqNVpHBMnlQzakcyonIljuzsw2 /Wlm3MGAXM1oMtPb2hLe8UQuNX3atEIBNZ9vkcedVhvpUGBy4ergUvyFX USfbcdLREcD1wZsXsiZkkCqkqs3CEOdeqtxwb/KkLBc1nYuLP1tD28tAR WclN2XblDZRwtPIi/cwTw74EfMRQWhqcVg5SJNkZoebwdvVUp/h9Mi/k8 UV1rn/PnmsWXLJovpJLIVBzc1DbLDpUNsAlV4eHBj+wSiX16F1JMgMiJl g==; X-IronPort-AV: E=McAfee;i="6400,9594,10350"; a="271371030" X-IronPort-AV: E=Sophos;i="5.91,233,1647327600"; d="scan'208";a="271371030" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2022 09:50:57 -0700 X-IronPort-AV: E=Sophos;i="5.91,233,1647327600"; d="scan'208";a="672939443" Received: from abhuwalk-mobl1.amr.corp.intel.com (HELO spandruv-desk1.amr.corp.intel.com) ([10.212.246.60]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2022 09:50:55 -0700 Message-ID: <7b1a9f3b5b5087f47bf4839858c7bfebdb60aa2f.camel@linux.intel.com> Subject: Re: [PATCH v2 01/14] thermal/core: Change thermal_zone_ops to thermal_sensor_ops From: srinivas pandruvada To: "Rafael J. Wysocki" , Daniel Lezcano Cc: Daniel Lezcano , Kevin Hilman , Alexandre Bailon , Linux PM , Linux Kernel Mailing List , Amit Kucheria , Zhang Rui , Jonathan Corbet , Len Brown , Raju Rangoju , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Ido Schimmel , Petr Machata , Luca Coelho , Kalle Valo , Peter Kaestle , Hans de Goede , Mark Gross , Sebastian Reichel , Miquel Raynal , Support Opensource , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Niklas =?ISO-8859-1?Q?S=F6derlund?= , Miri Korenblit , Johannes Berg , Sumeet Pawnikar , Dan Carpenter , Chuansheng Liu , Jiasheng Jiang , Antoine Tenart , Andy Shevchenko , "open list:DOCUMENTATION" , "open list:ACPI THERMAL DRIVER" , "open list:CXGB4 ETHERNET DRIVER (CXGB4)" , "open list:INTEL WIRELESS WIFI LINK (iwlwifi)" , "open list:ACER ASPIRE ONE TEMPERATURE AND FAN DRIVER" , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , "open list:RENESAS R-CAR THERMAL DRIVERS" Date: Tue, 17 May 2022 09:50:54 -0700 In-Reply-To: References: <20220507125443.2766939-1-daniel.lezcano@linexp.org> <20220507125443.2766939-2-daniel.lezcano@linexp.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Tue, 2022-05-17 at 17:42 +0200, Rafael J. Wysocki wrote: > On Sat, May 7, 2022 at 2:55 PM Daniel Lezcano > wrote: > > > > A thermal zone is software abstraction of a sensor associated with > > properties and cooling devices if any. > > > > The fact that we have thermal_zone and thermal_zone_ops mixed is > > confusing and does not clearly identify the different components > > entering in the thermal management process. A thermal zone appears > > to > > be a sensor while it is not. > > Well, the majority of the operations in thermal_zone_ops don't apply > to thermal sensors.  For example, ->set_trips(), ->get_trip_type(), > ->get_trip_temp(). > In past we discussed adding thermal sensor sysfs with threshold to notify temperature. So sensor can have set/get_threshold() functions instead of the set/get_trip for zones. Like we have /sys/class/thermal_zone* we can have /sys/class/thermal_sensor*. Thermal sensor(s) are bound to thermal zones. This can also include multiple sensors in a zone and can create a virtual sensor also. Thanks, Srinivas > > In order to set the scene for multiple thermal sensors aggregated > > into > > a single thermal zone. Rename the thermal_zone_ops to > > thermal_sensor_ops, that will appear clearyl the thermal zone is > > not a > > sensor but an abstraction of one [or multiple] sensor(s). > > So I'm not convinced that the renaming mentioned above is > particularly > clean either. > > IMV the way to go would be to split the thermal sensor operations, > like ->get_temp(), out of thermal_zone_ops. > > But then it is not clear what a thermal zone with multiple sensors in > it really means.  I guess it would require an aggregation function to > combine the thermal sensors in it that would produce an effective > temperature to check against the trip points. > > Honestly, I don't think that setting a separate set of trips for each > sensor in a thermal zone would make a lot of sense.