Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp505999pxb; Thu, 5 Nov 2020 06:04:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJwhbcqzZvYlXG4U9iGt7PjPCAOq9UtWthfOM7AQZUWegTsynYCy4BPMYOV80nuFbujxtbva X-Received: by 2002:a17:906:868b:: with SMTP id g11mr2467671ejx.263.1604585064588; Thu, 05 Nov 2020 06:04:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604585064; cv=none; d=google.com; s=arc-20160816; b=WzbWs0cNgdLAhh1bK1Copu222oEBPTVcFxMDkxZqez9ZBbUhBVleuk39l8vLlG6+tV HwCmlpCCRJEiYRW2kE/NDlTT1cKzI5fDwmMOAwDFpDdUl4c6+m6o5OKtbDWoZQquoDBP /T6rnTZpXP0pKE58ekITWC95zaiUDhR5vn7Unan6taQOMTisNCNhbU/9sD4YxOAhczpg k50BK/oc3k42a8RwUvFeb4sxz+BmA5eBlD+y0QPI+FlAMpfh9zqzUPh0eR/FXnUhpqX4 wVfy79iy4x0/spPdWpfnRUcbyYv/1SA6DRzjyd8/yrDg+5g/IItTtBNUJ5ERTApyqekj zmkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=g2Mcwnv7uwehn27RSXSTkQBYOagYPNKYES5mvtR3+yU=; b=fUzC+bkndEfFDeL3GouptybTcKDXA+9tcJZgKcbmSqRusbf69c8Akr2LoYkX8Es54H paS3H1bgXHLb3PKK9RVbkEillFv+QX6GtapFKNmUX+MaGGbhypSLoAC+HnQ3ffsPVWo9 Dv8oc3hzYXh5y73lTpuekXCFzLVj52pv5QKSylyV5o4OuDx+QW6i44/SY++DdVglMDqh XiwJFreXBOF6FKXgR7pwH7DnUYT5ZHxyYMe8N5DueZzjS5G0Vo00UrGfuM5WqZRLp537 loNg4pNhsQbsuLKYmr3LbwrSdXCl4TcAREdJXvosyTdEJF6BVVmwj0FP9KmBujyXtNXL 6dVg== 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 o6si1625873edi.560.2020.11.05.06.03.59; Thu, 05 Nov 2020 06:04:24 -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 S1730935AbgKEOCH (ORCPT + 99 others); Thu, 5 Nov 2020 09:02:07 -0500 Received: from foss.arm.com ([217.140.110.172]:33318 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730929AbgKEOCH (ORCPT ); Thu, 5 Nov 2020 09:02:07 -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 2C43714BF; Thu, 5 Nov 2020 06:02:06 -0800 (PST) Received: from localhost (e108754-lin.cambridge.arm.com [10.1.198.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B70DD3F719; Thu, 5 Nov 2020 06:02:05 -0800 (PST) Date: Thu, 5 Nov 2020 14:02:02 +0000 From: Ionela Voinescu To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , Viresh Kumar , Len Brown , Sudeep Holla , Morten Rasmussen , Jeremy Linton , Linux PM , Linux Kernel Mailing List Subject: Re: [PATCH 8/8] acpi: fix NONE coordination for domain mapping failure Message-ID: <20201105140202.GA16751@arm.com> References: <20201105125524.4409-1-ionela.voinescu@arm.com> <20201105125524.4409-9-ionela.voinescu@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rafael, On Thursday 05 Nov 2020 at 14:05:55 (+0100), Rafael J. Wysocki wrote: > On Thu, Nov 5, 2020 at 1:57 PM Ionela Voinescu wrote: > > > > For errors parsing the _PSD domains, a separate domain is returned for > > each CPU in the failed _PSD domain with no coordination (as per previous > > comment). But contrary to the intention, the code was setting > > CPUFREQ_SHARED_TYPE_ALL as coordination type. > > > > Change shared_type to CPUFREQ_SHARED_TYPE_NONE in case of errors parsing > > the domain information. The function still return the error and the caller > > is free to bail out the domain initialisation altogether in that case. > > > > Given that both functions return domains with a single CPU, this change > > does not affect the functionality, but clarifies the intention. > > Is this related to any other patches in the series? > It does not depend on any of the other patches. I first noticed this in acpi_get_psd_map() which is solely used by cppc_cpufreq.c, but looking some more into it showed processor_perflib.c's acpi_processor_preregister_performance() had the same inconsistency. I can submit this separately, if that works better. Thanks, Ionela. > > Signed-off-by: Ionela Voinescu > > Cc: Rafael J. Wysocki > > Cc: Len Brown > > Cc: Viresh Kumar > > --- > > drivers/acpi/cppc_acpi.c | 2 +- > > drivers/acpi/processor_perflib.c | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c > > index 75e36b909ae6..e1e46cc66eeb 100644 > > --- a/drivers/acpi/cppc_acpi.c > > +++ b/drivers/acpi/cppc_acpi.c > > @@ -477,7 +477,7 @@ int acpi_get_psd_map(unsigned int cpu, struct psd_data *domain) > > /* Assume no coordination on any error parsing domain info */ > > cpumask_clear(domain->shared_cpu_map); > > cpumask_set_cpu(cpu, domain->shared_cpu_map); > > - domain->shared_type = CPUFREQ_SHARED_TYPE_ALL; > > + domain->shared_type = CPUFREQ_SHARED_TYPE_NONE; > > > > return -EFAULT; > > } > > diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c > > index 5909e8fa4013..5ce638537791 100644 > > --- a/drivers/acpi/processor_perflib.c > > +++ b/drivers/acpi/processor_perflib.c > > @@ -710,7 +710,7 @@ int acpi_processor_preregister_performance( > > if (retval) { > > cpumask_clear(pr->performance->shared_cpu_map); > > cpumask_set_cpu(i, pr->performance->shared_cpu_map); > > - pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL; > > + pr->performance->shared_type = CPUFREQ_SHARED_TYPE_NONE; > > } > > pr->performance = NULL; /* Will be set for real in register */ > > } > > -- > > 2.17.1 > >