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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 B4A5DC33C9E for ; Tue, 7 Jan 2020 09:58:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8B7232081E for ; Tue, 7 Jan 2020 09:58:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=rere.qmqm.pl header.i=@rere.qmqm.pl header.b="lJeppMG3" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727799AbgAGJ6i (ORCPT ); Tue, 7 Jan 2020 04:58:38 -0500 Received: from rere.qmqm.pl ([91.227.64.183]:10498 "EHLO rere.qmqm.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726565AbgAGJ6i (ORCPT ); Tue, 7 Jan 2020 04:58:38 -0500 Received: from remote.user (localhost [127.0.0.1]) by rere.qmqm.pl (Postfix) with ESMTPSA id 47sSWJ1fDMz39; Tue, 7 Jan 2020 10:58:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rere.qmqm.pl; s=1; t=1578391116; bh=DckSMbQGrkJkV8SZ/4frgGzn8td5s/q5GcUzXT57kyY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lJeppMG3SUpGR5br0nhNkmnKIgDju2w8v19ouX6n++Z69ayPmOEWktUDLFSWR9CIq 5esfs1SnAADmKeFLnQinJ2YWTZBadWESl8oIxMsR3WC/AJE4Cuqs3K3D8FGs1KmKTK Z1OVX15oefUaopnJrqEiXze0Rddmrnm7FzaupnUlOq5xFGYKjMXnK5RfdkWoBmaPeC pLCOK+WiCjAjYKgtu2iwwEAOE8rpbGj35aDecOq9Y4sQ9owY6T2/RYkJNDyi3xjU/F k4tKmA2AaeFcjyQ0TC0a8WY6EKESfztt3js7UbdZqXNoAmHwEmt7s+4mc43T8FjkBm aqO7uQx6rs/sA== X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.101.4 at mail Date: Tue, 7 Jan 2020 10:58:35 +0100 From: =?iso-8859-2?Q?Micha=B3_Miros=B3aw?= To: Viresh Kumar Cc: Nishanth Menon , Stephen Boyd , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] opp: quiet down WARN when no valid OPPs remain Message-ID: <20200107095834.GB3515@qmqm.qmqm.pl> References: <5c2d6548aef35c690535fd8c985b980316745e91.1578077228.git.mirq-linux@rere.qmqm.pl> <20200107064128.gkeq2ejtvx4bmyhj@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200107064128.gkeq2ejtvx4bmyhj@vireshk-i7> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 07, 2020 at 12:11:29PM +0530, Viresh Kumar wrote: > On 03-01-20, 20:36, Michał Mirosław wrote: > > Per CPU screenful of backtraces is not really that useful. Replace > > WARN with a diagnostic discriminating common causes of empty OPP table. > But why should a platform have an OPP table in DT where none of them works for > it ? I added the warn intentionally here just for that case. Hmm. I guess we can make it WARN_ON_ONCE instead of removing it, but I don't think the backtrace is ever useful in this case. Empty table can be because eg. you run old DT on newer hardware version. This is why it's still communicated via dev_err(). Best Regards, Michał Mirosław