Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1135071pxb; Fri, 1 Oct 2021 04:23:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzO9WFs1OufGb5fcMdPJ9Hm2kQRP3v1KgB8wocLJEFY5DyC/P8N3l2y918p2ke+Wudtc5NJ X-Received: by 2002:a17:90a:71c5:: with SMTP id m5mr9685558pjs.105.1633087432924; Fri, 01 Oct 2021 04:23:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633087432; cv=none; d=google.com; s=arc-20160816; b=pWFAEXV5QoZtEurIcdGBL9kfV1g/dzcskf5eLkYw5rVvGPBkY3zbNp1/WFGIe6BmWQ BBrXMWjDnQsNxdYwTBiLWQtuMyZJcyOsKzZhsx9D6pKjTK6lYBnjJfr38MRKBlfF+pW1 LopKiOFX7MoC7d6StnhehBDj2Z9TmeJytSkulkFX+g6NyJU88C2LOKvtN5WHXWAN8Ox1 tfGipuj1Q2WolqHHIBFBlR0FeE34snrfoodwHQW6PU4Dwy4s907sS0OmwL00/vledcE6 s0daFylz7JbnmF3wqcGdJ/5dbw74sjv+PVCJEFOd/ckc+1BakdnjlZSzFOwg1g/jK2Z6 logw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=mk0/iWSkoOVoe7IcEPFG/ItQ+jrZcQ4g2zGvnDHTxzI=; b=rhtemg1HP5Dazo908iBkUdGGhc1A+uORl8oh3A5PzHAYxt6or5hREIP7ViP1YL07d8 WiImcSslzlsdx7bLVaYu8tHbDtjPoZe3wXSFIIRrsPSQM6mrSuaHSlYMI9dc2T+nWmKy bOGabYnRj3meLFJiiNHy4N2l4YHcbWYvyNP+8sH5BLTgo9QspMa2ba5gNDpYT/NII9r3 EQqug7LKWLV8Dpa6YAE3eEgrboO6gnUQiIcY7+h7GQ5hPTZrFP759mVbOfHD59fTl2x8 746NszGVqG/hV1sVbk4tt8twtUWIyqgxyLjOeY1CiiGNFog5epwDa6SYVdEKPZnL1uV2 GVVg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f33si7221051pgb.580.2021.10.01.04.23.39; Fri, 01 Oct 2021 04:23:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353592AbhJALNi (ORCPT + 99 others); Fri, 1 Oct 2021 07:13:38 -0400 Received: from foss.arm.com ([217.140.110.172]:40486 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352896AbhJALNh (ORCPT ); Fri, 1 Oct 2021 07:13:37 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0F548106F; Fri, 1 Oct 2021 04:11:53 -0700 (PDT) Received: from [10.57.23.247] (unknown [10.57.23.247]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 034B43F70D; Fri, 1 Oct 2021 04:11:51 -0700 (PDT) Subject: Re: [RFD] Remove the userspace governor and the cooling device set state sysfs entry To: Daniel Lezcano Cc: Zhang Rui , "Rafael J. Wysocki" , Linux Kernel Mailing List , Linux PM mailing list References: <39728f24-7781-543c-ad28-fd1c7552d96a@arm.com> <2b8300b2-4678-3e3c-71e3-6d276b99eb07@linaro.org> From: Lukasz Luba Message-ID: Date: Fri, 1 Oct 2021 12:11:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <2b8300b2-4678-3e3c-71e3-6d276b99eb07@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/1/21 11:30 AM, Daniel Lezcano wrote: > > Hi Lukasz, > > On 30/09/2021 12:10, Lukasz Luba wrote: >> Hi Daniel, >> >> On 9/22/21 10:59 AM, Daniel Lezcano wrote: >>> >>> Hi, >>> >>> the userspace governor is sending temperature when polling is active and >>> trip point crossed events. Nothing else. >>> >>> In the other side, the cooling device have their cooling device >>> set_cur_state read-writable all the time. >>> >>> The thermal framework is wrongly used by userspace as a power capping >>> framework by acting on the cooling device opaque state. This one then >>> competes with the in-kernel governor decision. >>> >>> As the new netlink thermal notification is able to provide the same >>> information than the userspace governor. >>> >>> I propose to remove the userspace governor and the cur_state entry in >>> the sysfs exported file. >>> >>> The DTPM framework is the right framework to do power capping and >>> moreover it deals with the aggregation via the dev pm qos. >>> >>> Does it make sense ? >> >> It sounds that we should be OK with the information from netlink. >> I don't see objections. We can also extend the netlink packet when >> needed. I'm fine with removing the user-space governor. > > thank you for your answer. I'll propose a patch with a warn when the > userspace governor is registered in order to let know people the > governor is deprecated. > > Probably, it would make sense to emit a warning also when the cooling > device state is set from userspace. > > For the next release, we should be able to drop the userspace governor > and make the cooling device state read-only. > > Does it make sense ? > > Yes, it makes sense.