Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp541895pxb; Thu, 5 Nov 2020 06:51:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJygxG+S4JohFseAG3BbNiwvEYUEChyShV8ICFbIKI/zhSUQe9Ksn/9rUqSQHrEpwXD6gTe2 X-Received: by 2002:a05:6402:b8e:: with SMTP id cf14mr2819338edb.86.1604587870253; Thu, 05 Nov 2020 06:51:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604587870; cv=none; d=google.com; s=arc-20160816; b=PkENLpJzYr3vl/bfJEkrTu/y1orzzh5L5ShQu/doNyCsh/G6WW2wXz2EwAOVw26ctv FSm3MrS3c/v8vnf6LVDe8tJSjH1ZrVx3Vlk+4piQj+M36s2GN7r6/dKRDcFSNEZpmXIV 0kIDNhxyfX9TNWGkcqASqwKUdHLjDSbMO+ytos6VFKjf0iH9jLsdkdLTHFocSJjvQ8kb BSXeHW5EhBQzZHBZpONWr0/WqyO83pw6+YKT9zl1F0oFjaDfFdUGGsQRftDIVUYPOFCo EzDaNCuWXfRrX8VCWsAYwQWnTV0nPdphoenKSlqr+HBMEdK047lqX/sIsH48wTv8tzvc mKGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=c6N0gMQmd4ELBNOhLJPWNgO6ni1qE04kRKcnlI4ROaU=; b=P2mU8OvOxBIdLqBcsPA1SyZPcJW3EChpdt7h9IeZgrPIIcVcz+cGIj+H/2NJ2w2vUk +pj1tZcLsvAFlcvfFj2csQPERNXtjhrECY5TNBYgP5yN2ImRZVwUrIVDmQj300lYtsWK SDPEohtHG1+cG21mq5kp6U91ket0rDxbjAYIaKG1ffV0BLHwQzAviv7wPl9Mc32TG1dg JpFscXG59zWXMpsq8hi0jWV7L8r538VXOL8tPtpjupmjiY1JA1E3IWdND0odcMWR0Dhj MC5Y3u8snB0WZ9hTsnrBNkKDQwKnBfG/t8iMsdqvMgQsk2PqT/1fkio8riTi4+iavS0c 8tmQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g11si1385549edn.315.2020.11.05.06.50.47; Thu, 05 Nov 2020 06:51:10 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730669AbgKEOrP (ORCPT + 99 others); Thu, 5 Nov 2020 09:47:15 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:52836 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730465AbgKEOrO (ORCPT ); Thu, 5 Nov 2020 09:47:14 -0500 Received: from 89-64-88-191.dynamic.chello.pl (89.64.88.191) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.514) id 18280cb34b1dfbb5; Thu, 5 Nov 2020 15:47:12 +0100 From: "Rafael J. Wysocki" To: Ionela Voinescu 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 Date: Thu, 05 Nov 2020 15:47:11 +0100 Message-ID: <2133387.cqCEZmzLhk@kreacher> In-Reply-To: <20201105140202.GA16751@arm.com> References: <20201105125524.4409-1-ionela.voinescu@arm.com> <20201105140202.GA16751@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, November 5, 2020 3:02:02 PM CET Ionela Voinescu wrote: > 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. No need this time, but in general sending unrelated changes separately is less confusing. Thanks!