From patchwork Tue Oct 22 17:32:15 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sudeep Holla X-Patchwork-Id: 177209 Delivered-To: patch@linaro.org Received: by 2002:a92:409a:0:0:0:0:0 with SMTP id d26csp5174436ill; Tue, 22 Oct 2019 10:32:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqwGIhMQBhY0YL34G8NQ+kvJehmaa01rNxzmDtHW+h5KDRR/6F2LUOeUrbcoFY2viuLFCZg2 X-Received: by 2002:a50:e71a:: with SMTP id a26mr32149526edn.265.1571765564916; Tue, 22 Oct 2019 10:32:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571765564; cv=none; d=google.com; s=arc-20160816; b=Ckmv51u74zX6IT/l3Huep8mo8pUghn+exWy9ghJmg/HRlGMWhPjfigULZViycdl3pB fznK7kBOL74QSi/Q8tQ2qJpk7haakAB67qnpn/wkAEd096rFqCM2LTMZwYQD/tznhul6 gDaAQQh9jZ/VtsPvTDCI5BRxWLh4Pb77zJ4QkXdQh1cNlqOftvFgvb6Sbst+zOIFGA7+ 1ZKIn8aoUg0BXTljDoP+zuuAPTimN/dCnGdNkMRXtEW2xd0/T8avQDf/liCV/ijdYrII dzyK8OSwv9EHrs21bM3cSUhdCBTBkTqHTtufpZ1g4KhZsQubmu2UI5BEclHuIo9gLV0k 16Pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=7R2DU8+K+wZzTGJaCrefRkCeQh3ZlVjf0jazSBzErec=; b=ExlDL26xX5IWyNVSdEOGL/TrUdwTf5VI/d3BIUZh1zIUtLKIvLiHkEzuIoXU5SLr+4 D8h+Qznt3pBK0z3T0nwdr1UUbQoGIFP5D0sO7l6STZMImEdlNHPXQLr3rL9Dhg0kxrjG k+2gOvO8dh0azlU3rvDLI6xzyhYpl1RDtJ53dsLbNjE/+0sb0OQDW+u+NU+fVN0+uCQk UmDAz9NRvxD2iTvRaCcthqEF+spSBdn8GOH7vN+rxqp5jc99bBVIIsFee5EHii1nSchI jVkpvngtBdvifFo6Ju1E7n5V8j1OEo0F4TKYody88g6bgxd2x/XBrfQhwTIbiYbLEQzL iGrg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c19si13922300ede.360.2019.10.22.10.32.44; Tue, 22 Oct 2019 10:32:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727531AbfJVRco (ORCPT + 10 others); Tue, 22 Oct 2019 13:32:44 -0400 Received: from [217.140.110.172] ([217.140.110.172]:58550 "EHLO foss.arm.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1726024AbfJVRcn (ORCPT ); Tue, 22 Oct 2019 13:32:43 -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 D1DD331F; Tue, 22 Oct 2019 10:32:22 -0700 (PDT) Received: from usa.arm.com (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 0FBE43F71A; Tue, 22 Oct 2019 10:32:21 -0700 (PDT) From: Sudeep Holla To: Viresh Kumar , "Rafael J . Wysocki" Cc: Sudeep Holla , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH] cpufreq: mark duplicate frequencies as invalid and continue as normal Date: Tue, 22 Oct 2019 18:32:15 +0100 Message-Id: <20191022173215.13350-1-sudeep.holla@arm.com> X-Mailer: git-send-email 2.17.1 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Currently if we encounter duplicate frequency table entries, we abort the validation and return error immediately. Instead of failing, we can mark the entry as invalid and continue to function normal. Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Signed-off-by: Sudeep Holla --- drivers/cpufreq/freq_table.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Hi Viresh, Since commit da0c6dc00c69 ("cpufreq: Handle sorted frequency tables more efficiently"), I seem to have modified the firmware entry on my TC2 to drop 500MHz and had not seen the issue with duplicate entries and had totally forgotten about it. Recently I reverted back to original setting as I corrupted it and started seeing this issues. I don't know the background for raising duplicates as fatal error but we did allow it when we add arm_big_little.c and hence this RFC. If there are known issues with this approach, I can continue with changed firmware config. With switcher, we have: (little cluster) Virt: 175 MHz, 200 MHz, 250 MHz, 300 MHz, 350 MHz, 400 MHz, 450 MHz, 500 MHz Actu: 350 MHz, 400 MHz, 500 MHz, 600 MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz (big cluster) 500 MHz, 600 MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz with 500 MHz duplicate in merged table. Regards, Sudeep -- 2.17.1 diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c index ded427e0a488..e9bf287846d6 100644 --- a/drivers/cpufreq/freq_table.c +++ b/drivers/cpufreq/freq_table.c @@ -305,9 +305,10 @@ static int set_freq_table_sorted(struct cpufreq_policy *policy) } if (pos->frequency == prev->frequency) { - pr_warn("Duplicate freq-table entries: %u\n", + pr_warn("Duplicate freq-table entries: %u marking it invalid\n,", pos->frequency); - return -EINVAL; + pos->frequency = CPUFREQ_ENTRY_INVALID; + continue; } /* Frequency increased from prev to pos */