From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 7B1AA26560B;
	Tue,  6 May 2025 10:12:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1746526334; cv=none; b=kCiZGDKGhwPUrg934ynAt586uQXY9MbzGqi6DukB/UWMaLQZWDmj8E/Ej5Snc3Hx1J9ELy4dIqnN/04RfDwu2evMvNfQ9IwOQ7QF2xEQ+A8jmC71EBd/CkomjCoj6tmfTwyS8xZBw1aD28jvoOXzLUAn68ebRGXXJ3oPiDGKha8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1746526334; c=relaxed/simple;
	bh=yCdfwrBsl/xCwXkqHogoX2iASKM3lEEo2PqiI8L3efA=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=aU7NYGYe8WrisCSDLn8aZM7WkofiEPIf7Yix7UbDXQd24co5ttscvdJ3pvOCNyM6IyY1WPl4ZT7oxTGe259FpNHJZS9cLdU+NL7j/iK8P+mv84xjy4xTlbdqwyKyCwSYl9rFrTmniGPC5376vFo/phz17cPZ2/NjRHtHsGm/C/o=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
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 2BD16113E;
	Tue,  6 May 2025 03:12:02 -0700 (PDT)
Received: from bogus (e133711.arm.com [10.1.196.55])
	by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1D3AF3F5A1;
	Tue,  6 May 2025 03:12:09 -0700 (PDT)
Date: Tue, 6 May 2025 11:12:07 +0100
From: Sudeep Holla <sudeep.holla@arm.com>
To: Mike Tipton <quic_mdtipton@quicinc.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>, <arm-scmi@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <linux-pm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, Peng Fan <peng.fan@oss.nxp.com>,
	Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH v3] cpufreq: scmi: Skip SCMI devices that aren't used by
 the CPUs
Message-ID: <20250506-stirring-competent-ladybug-9cadb5@sudeepholla>
References: <20250428144728.871404-1-quic_mdtipton@quicinc.com>
 <aBllHt7A2nP/9x3N@hu-mdtipton-lv.qualcomm.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aBllHt7A2nP/9x3N@hu-mdtipton-lv.qualcomm.com>

On Mon, May 05, 2025 at 06:25:50PM -0700, Mike Tipton wrote:
> On Mon, Apr 28, 2025 at 07:47:28AM -0700, Mike Tipton wrote:
> > Currently, all SCMI devices with performance domains attempt to register
> > a cpufreq driver, even if their performance domains aren't used to
> > control the CPUs. The cpufreq framework only supports registering a
> > single driver, so only the first device will succeed. And if that device
> > isn't used for the CPUs, then cpufreq will scale the wrong domains.
> > 
> > To avoid this, return early from scmi_cpufreq_probe() if the probing
> > SCMI device isn't referenced by the CPU device phandles.
> > 
> > This keeps the existing assumption that all CPUs are controlled by a
> > single SCMI device.
> > 
> > Signed-off-by: Mike Tipton <quic_mdtipton@quicinc.com>
> > Reviewed-by: Peng Fan <peng.fan@nxp.com>
> > ---
> 
> Hi Sudeep / Viresh,
> 
> Any thoughts on this?
> 

I have actually queued and forgot to respond. Though I realise the change
is not dependent on any other changes now.

Viresh, hope you are OK with me taking this change or do you prefer to take
it via your tree ? I am fine with that as well.

-- 
Regards,
Sudeep