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 X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED, USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 103D1C2BA1A for ; Tue, 7 Apr 2020 17:49:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D29D02075E for ; Tue, 7 Apr 2020 17:49:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726339AbgDGRth (ORCPT ); Tue, 7 Apr 2020 13:49:37 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:42814 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726277AbgDGRth (ORCPT ); Tue, 7 Apr 2020 13:49:37 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: andrzej.p) with ESMTPSA id 086692972A7 From: Andrzej Pietrasiewicz To: linux-pm@vger.kernel.org Cc: Zhang Rui , "Rafael J . Wysocki" , Len Brown , Jiri Pirko , Ido Schimmel , "David S . Miller" , Peter Kaestle , Darren Hart , Andy Shevchenko , Support Opensource , Daniel Lezcano , Amit Kucheria , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Allison Randal , Enrico Weigelt , Gayatri Kammela , Thomas Gleixner , linux-acpi@vger.kernel.org, netdev@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kernel@collabora.com, Andrzej Pietrasiewicz Subject: [RFC 0/8] Stop monitoring disabled devices Date: Tue, 7 Apr 2020 19:49:18 +0200 Message-Id: <20200407174926.23971-1-andrzej.p@collabora.com> X-Mailer: git-send-email 2.17.1 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org The current kernel behavior is to keep polling the thermal zone devices regardless of their current mode. This is not desired, as all such "disabled" devices are meant to be handled by userspace, so polling them makes no sense. There was an attempt to solve this issue: https://lkml.org/lkml/2018/2/26/498 and it ultimately has not succeeded: https://lkml.org/lkml/2018/2/27/910 This is a new attempt addressing all the relevant drivers, and I have identified them with: $ git grep "thermal_zone_device_ops" | grep "= {" | cut -f1 -d: | sort | uniq The idea is to modify thermal_zone_device_update() and monitor_thermal_zone() in such a way that they stop polling a disabled device. To do decide what to do they should call ->get_mode() operation of the specialized thermal zone device in question (e.g. drivers/acpi/thermal.c's). But here comes problem: sometimes a thermal zone device must be initially disabled and becomes enabled only after its sensors appear on the system. If such thermal zone's ->get_mode() /* in the context of thermal_zone_device_update() or monitor_thermal_zone() */ is called _before_ the sensors are available, it will be reported as "disabled" and consequently polling it will be ceased. This is a change in behavior from userspace's perspective. To solve the above described problem I want to introduce the third mode of a thermal_zone_device: initial. The idea is that when the device is in its initial mode, then its polling will be handled as it is now. This is a good thing: should the temperature be just about hitting the critical treshnold early during the boot process, it might be too late if we wait for the userspace to run to save the system from overheating. The initial mode should be reported in sysfs as "enabled" to keep the userspace interface intact. >From the initial mode there will be two possible transitions: to enabled or disabled mode, but there will be no transition back to initial. If the transition is from initial to enabled, then keep polling. If the transition is from initial to disabled, then stop polling. If the transition is from enabled to disabled, then stop polling. The transition from disabled to enabled must be handled in a special way: there must be a mandatory call to monitor_thermal_zone(), otherwise the polling will not start. If this transition is triggeted from sysfs, then it can be easily handled at the thermal framework level. However, if drivers call their own ->set_mode() operation then they must also call "monitor_thermal_zone()" afterwards. The latter being a sensible thing anyway, so perhaps all/most of the drivers in question do. The plan for implementation is this: - ensure ALL users use symbolic enum names (THERMAL_DEVICE_DISABLED, THERMAL_DEVICE_ENABLED) for thermal device mode rather than the numeric values of enum thermal_device_mode elements - add THERMAL_DEVICE_INITIAL to the said enum making its value 0 (so that kzalloc() results in the initial state) - modify thermal zone device's mode_show() (thermal framework level) so that it reports "enabled" for THERMAL_DEVICE_INITIAL - modify thermal zone device's mode_store() (thermal framework level) so that it calls monitor_thermal_zone() upon mode change - modify ALL thermal drivers so that their code is prepared to return THERMAL_DEVICE_INITIAL before they call thermal_zone_device_register(); when the invocation of the latter completes then polling is expected to be started - verify ALL drivers which call their own ->set_mode() to ensure they do call monitor_thermal_zone() afterwards - modify thermal_zone_device_update() and monitor_thermal_zone() so that they cancel polling for disabled thermal zone devices (but not for those in THERMAL_DEVICE_INITIAL mode) This RFC series does all the above steps in more or less that order. I kindly ask for comments/suggestions/improvements. Rebased onto v5.6. Andrzej Pietrasiewicz (8): thermal: int3400_thermal: Statically initialize .get_mode()/.set_mode() ops thermal: Properly handle mode values in .set_mode() thermal: Store thermal mode in a dedicated enum thermal: core: Introduce THERMAL_DEVICE_INITIAL thermal: core: Monitor thermal zone after mode change thermal: Set initial state to THERMAL_DEVICE_INITIAL thermal: of: Monitor thermal zone after enabling it thermal: Stop polling DISABLED thermal devices drivers/acpi/thermal.c | 28 +++++----- .../ethernet/mellanox/mlxsw/core_thermal.c | 11 +++- drivers/platform/x86/acerhdf.c | 17 ++++-- drivers/thermal/da9062-thermal.c | 2 +- drivers/thermal/imx_thermal.c | 5 +- .../intel/int340x_thermal/int3400_thermal.c | 24 ++++----- .../thermal/intel/intel_quark_dts_thermal.c | 6 ++- drivers/thermal/of-thermal.c | 9 +++- drivers/thermal/thermal_core.c | 52 ++++++++++++++++++- drivers/thermal/thermal_core.h | 2 + drivers/thermal/thermal_sysfs.c | 12 +++-- include/linux/thermal.h | 3 +- 12 files changed, 123 insertions(+), 48 deletions(-) -- 2.17.1 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrzej Pietrasiewicz Subject: [RFC 0/8] Stop monitoring disabled devices Date: Tue, 7 Apr 2020 19:49:18 +0200 Message-ID: <20200407174926.23971-1-andrzej.p@collabora.com> Return-path: Sender: linux-acpi-owner@vger.kernel.org To: linux-pm@vger.kernel.org Cc: Zhang Rui , "Rafael J . Wysocki" , Len Brown , Jiri Pirko , Ido Schimmel , "David S . Miller" , Peter Kaestle , Darren Hart , Andy Shevchenko , Support Opensource , Daniel Lezcano , Amit Kucheria , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Allison Randal , Enrico Weigelt , Gayatri Kammela List-Id: platform-driver-x86.vger.kernel.org The current kernel behavior is to keep polling the thermal zone devices regardless of their current mode. This is not desired, as all such "disabled" devices are meant to be handled by userspace, so polling them makes no sense. There was an attempt to solve this issue: https://lkml.org/lkml/2018/2/26/498 and it ultimately has not succeeded: https://lkml.org/lkml/2018/2/27/910 This is a new attempt addressing all the relevant drivers, and I have identified them with: $ git grep "thermal_zone_device_ops" | grep "= {" | cut -f1 -d: | sort | uniq The idea is to modify thermal_zone_device_update() and monitor_thermal_zone() in such a way that they stop polling a disabled device. To do decide what to do they should call ->get_mode() operation of the specialized thermal zone device in question (e.g. drivers/acpi/thermal.c's). But here comes problem: sometimes a thermal zone device must be initially disabled and becomes enabled only after its sensors appear on the system. If such thermal zone's ->get_mode() /* in the context of thermal_zone_device_update() or monitor_thermal_zone() */ is called _before_ the sensors are available, it will be reported as "disabled" and consequently polling it will be ceased. This is a change in behavior from userspace's perspective. To solve the above described problem I want to introduce the third mode of a thermal_zone_device: initial. The idea is that when the device is in its initial mode, then its polling will be handled as it is now. This is a good thing: should the temperature be just about hitting the critical treshnold early during the boot process, it might be too late if we wait for the userspace to run to save the system from overheating. The initial mode should be reported in sysfs as "enabled" to keep the userspace interface intact. >From the initial mode there will be two possible transitions: to enabled or disabled mode, but there will be no transition back to initial. If the transition is from initial to enabled, then keep polling. If the transition is from initial to disabled, then stop polling. If the transition is from enabled to disabled, then stop polling. The transition from disabled to enabled must be handled in a special way: there must be a mandatory call to monitor_thermal_zone(), otherwise the polling will not start. If this transition is triggeted from sysfs, then it can be easily handled at the thermal framework level. However, if drivers call their own ->set_mode() operation then they must also call "monitor_thermal_zone()" afterwards. The latter being a sensible thing anyway, so perhaps all/most of the drivers in question do. The plan for implementation is this: - ensure ALL users use symbolic enum names (THERMAL_DEVICE_DISABLED, THERMAL_DEVICE_ENABLED) for thermal device mode rather than the numeric values of enum thermal_device_mode elements - add THERMAL_DEVICE_INITIAL to the said enum making its value 0 (so that kzalloc() results in the initial state) - modify thermal zone device's mode_show() (thermal framework level) so that it reports "enabled" for THERMAL_DEVICE_INITIAL - modify thermal zone device's mode_store() (thermal framework level) so that it calls monitor_thermal_zone() upon mode change - modify ALL thermal drivers so that their code is prepared to return THERMAL_DEVICE_INITIAL before they call thermal_zone_device_register(); when the invocation of the latter completes then polling is expected to be started - verify ALL drivers which call their own ->set_mode() to ensure they do call monitor_thermal_zone() afterwards - modify thermal_zone_device_update() and monitor_thermal_zone() so that they cancel polling for disabled thermal zone devices (but not for those in THERMAL_DEVICE_INITIAL mode) This RFC series does all the above steps in more or less that order. I kindly ask for comments/suggestions/improvements. Rebased onto v5.6. Andrzej Pietrasiewicz (8): thermal: int3400_thermal: Statically initialize .get_mode()/.set_mode() ops thermal: Properly handle mode values in .set_mode() thermal: Store thermal mode in a dedicated enum thermal: core: Introduce THERMAL_DEVICE_INITIAL thermal: core: Monitor thermal zone after mode change thermal: Set initial state to THERMAL_DEVICE_INITIAL thermal: of: Monitor thermal zone after enabling it thermal: Stop polling DISABLED thermal devices drivers/acpi/thermal.c | 28 +++++----- .../ethernet/mellanox/mlxsw/core_thermal.c | 11 +++- drivers/platform/x86/acerhdf.c | 17 ++++-- drivers/thermal/da9062-thermal.c | 2 +- drivers/thermal/imx_thermal.c | 5 +- .../intel/int340x_thermal/int3400_thermal.c | 24 ++++----- .../thermal/intel/intel_quark_dts_thermal.c | 6 ++- drivers/thermal/of-thermal.c | 9 +++- drivers/thermal/thermal_core.c | 52 ++++++++++++++++++- drivers/thermal/thermal_core.h | 2 + drivers/thermal/thermal_sysfs.c | 12 +++-- include/linux/thermal.h | 3 +- 12 files changed, 123 insertions(+), 48 deletions(-) -- 2.17.1 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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BAE6BC2BB55 for ; Tue, 7 Apr 2020 17:49:41 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8E7FA2075E for ; Tue, 7 Apr 2020 17:49:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="sDOR4GCP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E7FA2075E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=MIBfEQIyCeNHfWKfwXiqRu+XsQF8Aa42U1OvBco3MkA=; b=sDO R4GCPTWcIDCuZbtpbMxhabl2fqRAFgL5gRM/NzX0hrhV6SK8EFJjoPiVZXCdQQeWy655qxyrGpWSB T5PEDBZNmEHVMJWAVckd21LXUUxmqYtHMaFawJ5P/++kcj2T7/PfJgpuQgPJE0i1eECFTUwNQvikD Lx307jCVZb2cXx6DmMh+lOluTSq1GgU2NQplrjubz59nU7livLz/9PqWDkLfldBtvT3wm1zAgyxsa vSgLL5bRMlzmJd+Coh6rvZ/DEXsLSkhNNtc0NCGvjQsl5ml+n82vynPkIQy7Q+MMagU6doryPr4XV IQWSBWt3mbzHZGYOOdcZtWrikD2+kWA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jLsM0-0007TW-RZ; Tue, 07 Apr 2020 17:49:40 +0000 Received: from bhuna.collabora.co.uk ([46.235.227.227]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jLsLx-0007Sc-Od for linux-arm-kernel@lists.infradead.org; Tue, 07 Apr 2020 17:49:39 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: andrzej.p) with ESMTPSA id 086692972A7 From: Andrzej Pietrasiewicz To: linux-pm@vger.kernel.org Subject: [RFC 0/8] Stop monitoring disabled devices Date: Tue, 7 Apr 2020 19:49:18 +0200 Message-Id: <20200407174926.23971-1-andrzej.p@collabora.com> X-Mailer: git-send-email 2.17.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200407_104938_059164_CED086A2 X-CRM114-Status: GOOD ( 14.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Rafael J . Wysocki" , platform-driver-x86@vger.kernel.org, kernel@collabora.com, Fabio Estevam , Amit Kucheria , Daniel Lezcano , linux-acpi@vger.kernel.org, NXP Linux Team , Darren Hart , Zhang Rui , Gayatri Kammela , Len Brown , Sascha Hauer , Ido Schimmel , Jiri Pirko , Thomas Gleixner , Allison Randal , linux-arm-kernel@lists.infradead.org, Support Opensource , Shawn Guo , Peter Kaestle , Andrzej Pietrasiewicz , Pengutronix Kernel Team , netdev@vger.kernel.org, Enrico Weigelt , "David S . Miller" , Andy Shevchenko MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org The current kernel behavior is to keep polling the thermal zone devices regardless of their current mode. This is not desired, as all such "disabled" devices are meant to be handled by userspace, so polling them makes no sense. There was an attempt to solve this issue: https://lkml.org/lkml/2018/2/26/498 and it ultimately has not succeeded: https://lkml.org/lkml/2018/2/27/910 This is a new attempt addressing all the relevant drivers, and I have identified them with: $ git grep "thermal_zone_device_ops" | grep "= {" | cut -f1 -d: | sort | uniq The idea is to modify thermal_zone_device_update() and monitor_thermal_zone() in such a way that they stop polling a disabled device. To do decide what to do they should call ->get_mode() operation of the specialized thermal zone device in question (e.g. drivers/acpi/thermal.c's). But here comes problem: sometimes a thermal zone device must be initially disabled and becomes enabled only after its sensors appear on the system. If such thermal zone's ->get_mode() /* in the context of thermal_zone_device_update() or monitor_thermal_zone() */ is called _before_ the sensors are available, it will be reported as "disabled" and consequently polling it will be ceased. This is a change in behavior from userspace's perspective. To solve the above described problem I want to introduce the third mode of a thermal_zone_device: initial. The idea is that when the device is in its initial mode, then its polling will be handled as it is now. This is a good thing: should the temperature be just about hitting the critical treshnold early during the boot process, it might be too late if we wait for the userspace to run to save the system from overheating. The initial mode should be reported in sysfs as "enabled" to keep the userspace interface intact. >From the initial mode there will be two possible transitions: to enabled or disabled mode, but there will be no transition back to initial. If the transition is from initial to enabled, then keep polling. If the transition is from initial to disabled, then stop polling. If the transition is from enabled to disabled, then stop polling. The transition from disabled to enabled must be handled in a special way: there must be a mandatory call to monitor_thermal_zone(), otherwise the polling will not start. If this transition is triggeted from sysfs, then it can be easily handled at the thermal framework level. However, if drivers call their own ->set_mode() operation then they must also call "monitor_thermal_zone()" afterwards. The latter being a sensible thing anyway, so perhaps all/most of the drivers in question do. The plan for implementation is this: - ensure ALL users use symbolic enum names (THERMAL_DEVICE_DISABLED, THERMAL_DEVICE_ENABLED) for thermal device mode rather than the numeric values of enum thermal_device_mode elements - add THERMAL_DEVICE_INITIAL to the said enum making its value 0 (so that kzalloc() results in the initial state) - modify thermal zone device's mode_show() (thermal framework level) so that it reports "enabled" for THERMAL_DEVICE_INITIAL - modify thermal zone device's mode_store() (thermal framework level) so that it calls monitor_thermal_zone() upon mode change - modify ALL thermal drivers so that their code is prepared to return THERMAL_DEVICE_INITIAL before they call thermal_zone_device_register(); when the invocation of the latter completes then polling is expected to be started - verify ALL drivers which call their own ->set_mode() to ensure they do call monitor_thermal_zone() afterwards - modify thermal_zone_device_update() and monitor_thermal_zone() so that they cancel polling for disabled thermal zone devices (but not for those in THERMAL_DEVICE_INITIAL mode) This RFC series does all the above steps in more or less that order. I kindly ask for comments/suggestions/improvements. Rebased onto v5.6. Andrzej Pietrasiewicz (8): thermal: int3400_thermal: Statically initialize .get_mode()/.set_mode() ops thermal: Properly handle mode values in .set_mode() thermal: Store thermal mode in a dedicated enum thermal: core: Introduce THERMAL_DEVICE_INITIAL thermal: core: Monitor thermal zone after mode change thermal: Set initial state to THERMAL_DEVICE_INITIAL thermal: of: Monitor thermal zone after enabling it thermal: Stop polling DISABLED thermal devices drivers/acpi/thermal.c | 28 +++++----- .../ethernet/mellanox/mlxsw/core_thermal.c | 11 +++- drivers/platform/x86/acerhdf.c | 17 ++++-- drivers/thermal/da9062-thermal.c | 2 +- drivers/thermal/imx_thermal.c | 5 +- .../intel/int340x_thermal/int3400_thermal.c | 24 ++++----- .../thermal/intel/intel_quark_dts_thermal.c | 6 ++- drivers/thermal/of-thermal.c | 9 +++- drivers/thermal/thermal_core.c | 52 ++++++++++++++++++- drivers/thermal/thermal_core.h | 2 + drivers/thermal/thermal_sysfs.c | 12 +++-- include/linux/thermal.h | 3 +- 12 files changed, 123 insertions(+), 48 deletions(-) -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel