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 56724C433FE for ; Fri, 26 Nov 2021 21:58:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242357AbhKZWCC (ORCPT ); Fri, 26 Nov 2021 17:02:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241820AbhKZWAB (ORCPT ); Fri, 26 Nov 2021 17:00:01 -0500 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50A52C06173E for ; Fri, 26 Nov 2021 13:56:48 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id u3so27265983lfl.2 for ; Fri, 26 Nov 2021 13:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telus.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QWWtOidMzsjvAKxeAS7b8lTc05KdXZeQanVTUq2qbEo=; b=GcKt20lEaAogQDEQAun3vb0IjBQ/H18zsvVKCJZqsvuBjlberwkcwifN0FAXHA/FW9 OU5IBLKi3cAIYY4KK8COo0liUi6zUZT9bQ1OzcQQil3rBIUqH2ZQAbOQXqdWOmAilEpH kHaOL5rA6bZi68A7rjeR8h4wqrMKVAT3kAak/RFxeVuFCuMaztinDbRJ4h3B2UZk9/oG WRMZ4nRta2hrIboaZLndKvO9IfokMLreyKCeFytQUyXC4jbG1t6jKTxRuGwlgD38ZkQz usGUgTBH7IV6Qc2gs39BNO0MM2wi0x6JTulxLdUQjuRkrZ7RFVAmgytZO9Rn9QDQAoiE 7Jfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QWWtOidMzsjvAKxeAS7b8lTc05KdXZeQanVTUq2qbEo=; b=Omcxci4g06Gm/kNBtNFneEYvMWBYTUaUiiYnHuSBzZ2igPhU/hPUyc+e4lPLdvY17O cZBcF/RidrvepUROjgWEagCj8yex9aXA12lQyJkzXuxgS57g2Fx6ImmpU4b6WFH/0PJm Z/u3tKXbG2UyvSxVU7LUZz37eYHRGVr/6YQIxeWZ9x7i41ZwKBqum+njGSRCOenDUnxG MFyNkRF01RpCTHwqDXobex4+mDbvxHHAUOFV+4o79GbTJwJBB7e39PsqDTb9GnPjIdsS MvM2TbwmqIVzobVRyHUU5czU+cUkp9+rO9qNzlySFH3X0Rro6cFvh+90owZeQhz1HD+t KrNw== X-Gm-Message-State: AOAM533uPY/M237ulIIKZKlDIGoHrR9XGwekbuuTK7fgdu3nZzUWE39M Ap1lk3guud0By3T25vXQ2xOrnafBQeYrKa5BN7rcnQ== X-Google-Smtp-Source: ABdhPJwtljwAmkD/NkmAfbPf/8CARqBuGrgIww0VlMYRN8503DRr8KdefbcChfI+9TFiMZaHNLBVnkFwJMtNsautp2g= X-Received: by 2002:a05:6512:3a87:: with SMTP id q7mr31614406lfu.515.1637963806464; Fri, 26 Nov 2021 13:56:46 -0800 (PST) MIME-Version: 1.0 References: <20210401183654.27214-1-daniel.lezcano@linaro.org> <20210401183654.27214-3-daniel.lezcano@linaro.org> In-Reply-To: From: Doug Smythies Date: Fri, 26 Nov 2021 13:56:36 -0800 Message-ID: Subject: Re: [PATCH v6 3/7] powercap/drivers/dtpm: Simplify the dtpm table To: Daniel Lezcano Cc: "Rafael J. Wysocki" , Linux PM list , Linux Kernel Mailing List , Lukasz Luba , Greg Kroah-Hartman , dsmythies Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 26, 2021 at 9:43 AM Daniel Lezcano wrote: > > On 26/11/2021 18:21, Rafael J. Wysocki wrote: > > Hi Doug, > > > > On Fri, Nov 26, 2021 at 6:08 PM Doug Smythies wro= te: > >> > >> Hi Daniel, > >> > >> This patch introduces a regression, at least on my test system. > >> I can no longer change CPU frequency scaling drivers, for example > >> from intel_cpufreq (A.K.A intel_pstate in passive mode) to intel_pstat= e > >> (A.K.A. active mode). The task just hangs forever. > >> > >> I bisected the kernel and got this commit as the result. > >> As a double check, I reverted this commit: > >> 7a89d7eacf8e84f2afb94db5ae9d9f9faa93f01c > >> on kernel 5.16-rc2 and the issue was resolved. > >> > >> While your email is fairly old, I observe that it was only included as= of > >> kernel 5.16-rc1. > >> > >> Command Example that never completes: > >> > >> $ echo passive | sudo tee /sys/devices/system/cpu/intel_pstate/status > >> > >> syslog excerpt attached. > > > > This looks like it may be problematic: > > > > diff --git a/drivers/powercap/dtpm_cpu.c b/drivers/powercap/dtpm_cpu.c > > index f6076de39540..98841524a782 100644 > > --- a/drivers/powercap/dtpm_cpu.c > > +++ b/drivers/powercap/dtpm_cpu.c > > @@ -204,7 +204,7 @@ static int cpuhp_dtpm_cpu_online(unsigned int cpu) > > return ret; > > } > > > > -int dtpm_register_cpu(struct dtpm *parent) > > +static int __init dtpm_cpu_init(void) > > { > > int ret; > > > > so please try to remove the __init annotation from dtpm_cpu_init() and > > see if that helps. > > Yes, actually that should be called only if it is configured properly. > The dtpm_cpu just initializes itself unconditionally, I did not figured > out there is the usually allyesconfig used by default by the distros. > > That should be fixed with a proper DT configuration [1] I added your 5 patch set on top of 5.16-rc2 and confirm it fixes the issue. I tested both ways, with CONFIG_OF not set, forcing the CONFIG_DTPM stuff off, and with CONFIG_OF=3Dy. Oh, I used V2 of the patch set from earlier today. ... Doug > > [1] > https://lore.kernel.org/all/20211124125506.2971069-3-daniel.lezcano@linar= o.org/ > > -- > Linaro.org =E2=94=82 Open source software for AR= M SoCs > > Follow Linaro: Facebook | > Twitter | > Blog