Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp4062977pxb; Tue, 10 Nov 2020 07:07:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJzB5pTy0SA3alaCo9izO1trnUWEAfYwxNGz399uQixdyHaEYnwxRRsivuA0yCqyyRYFAT6v X-Received: by 2002:a17:906:bce6:: with SMTP id op6mr20236340ejb.2.1605020825731; Tue, 10 Nov 2020 07:07:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605020825; cv=none; d=google.com; s=arc-20160816; b=lhzTWtcvq/LcOUDRKFAGK6p2L207sxZQhcbblHI2Q5iyWJipRrqhLhEU8Ws/RoCF0a zJLOiEB0BjpXHBfN8zvdhQJfuY81PBur1mvzpLqzzpBfZMzG9XzKeLqIhxf9pHHfgh0r hmnyj2rVar8ok9fyQNOa6dTbc/krIzWeZzXtRSGxVO7mXMwFWbPaOIDEzq+uIT4u5uVn QASH+M+rCZiUH7tzA1dyLzd2lRkU6kGa9OhPSno/1rxKsnRQqjmbbBe/Hr+CIbRUZMaX UB7Ha21akOmSSxdtWlgeoEwg2fnGVaBAYewS3j2ckmSRMlWq7BYqKWlnNZZfKa6fVJni Raow== 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=Oyhz32EQsfdWM7w0mcexhRBjBez7J5s3gPCEPVsmgm0=; b=cHQagPeucA3yYSsJLiLuugb2IViJSiCYf/MuGqm114hXqp2IAjcmW1lg1YnETpK3pU KzP2njGQXNYTal3V2nCVk4T5P8a43Jyp9Xx/If2mMxajn6W1cNYnoehmM83Fln3o7DYm HKzYIIk5e9M5S2ojrdYpISXVLmrxYlv3iVqhnCzsR6awghUYk1JiN20dz47BzSmZRBMU wrSLXkauBVXwUNHwk1sEIFz4tyVQ6nO6HRMouRYaa3KjxZ+tL8ReY+GvfODEK1mvRV+Q lYnauo149xRRnaqAuvjnt4K5vi0zVDp6coqFWNo4mv0sSP0Sc4LNEiIs0HeVQ3E1JUR9 SuyQ== 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 m22si2523265ejo.281.2020.11.10.07.06.30; Tue, 10 Nov 2020 07:07:05 -0800 (PST) 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 S1731139AbgKJPEi (ORCPT + 99 others); Tue, 10 Nov 2020 10:04:38 -0500 Received: from foss.arm.com ([217.140.110.172]:57230 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726721AbgKJPEh (ORCPT ); Tue, 10 Nov 2020 10:04:37 -0500 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 49EE412FC; Tue, 10 Nov 2020 07:04:37 -0800 (PST) Received: from [10.57.21.178] (unknown [10.57.21.178]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3A1FE3F718; Tue, 10 Nov 2020 07:04:35 -0800 (PST) Subject: Re: [PATCH 3/4] powercap/drivers/dtpm: Add API for dynamic thermal power management To: Daniel Lezcano Cc: rafael@kernel.org, srinivas.pandruvada@linux.intel.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rui.zhang@intel.com, "Rafael J. Wysocki" , Arnd Bergmann , "open list:GENERIC INCLUDE/ASM HEADER FILES" References: <20201006122024.14539-1-daniel.lezcano@linaro.org> <20201006122024.14539-4-daniel.lezcano@linaro.org> <8fea0109-30d4-7d67-ffeb-8e588a4dadc3@arm.com> <313a92c5-3c45-616f-1fe8-9837721f9889@arm.com> <2495f9b8-327d-bf92-a159-ac3202d30ee0@linaro.org> From: Lukasz Luba Message-ID: Date: Tue, 10 Nov 2020 15:04:33 +0000 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: <2495f9b8-327d-bf92-a159-ac3202d30ee0@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 11/10/20 2:59 PM, Daniel Lezcano wrote: > On 10/11/2020 12:05, Lukasz Luba wrote: >> >> Actually I've found one issue when I have been trying to clean >> my testing branch with modified scmi-cpufreq.c. > > IMO, those errors are not the dtpm framework fault but the scmi-cpufreq. True, I have added this proposed macro directly into driver, but it's not strictly the framework. > > You should add a component in the drivers/powercap which does the glue > between the scmi-cpufreq and the dtpm. No stub will be needed in this > case as the component will depend on CONFIG_DTPM. > > > > Make sense, the glue stick should take care in this scenario. In this case, please keep the Reviewed-by and Tested-by and ignore the previous email.