Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754397AbbEZN0f (ORCPT ); Tue, 26 May 2015 09:26:35 -0400 Received: from foss.arm.com ([217.140.101.70]:49748 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754341AbbEZN0N (ORCPT ); Tue, 26 May 2015 09:26:13 -0400 Message-ID: <55647454.50401@arm.com> Date: Tue, 26 May 2015 14:25:40 +0100 From: Sudeep Holla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Boyd CC: Sudeep Holla , "linux-kernel@vger.kernel.org" , Liviu Dudau , Lorenzo Pieralisi , "Jon Medhurst (Tixy)" , Mike Turquette , "linux-clk@vger.kernel.org" Subject: Re: [PATCH 3/4] clk: scpi: add support for cpufreq virtual device References: <1430134846-24320-1-git-send-email-sudeep.holla@arm.com> <1430134846-24320-4-git-send-email-sudeep.holla@arm.com> <20150520234558.GB31753@codeaurora.org> In-Reply-To: <20150520234558.GB31753@codeaurora.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1261 Lines: 33 On 21/05/15 00:45, Stephen Boyd wrote: > On 04/27, Sudeep Holla wrote: >> The clocks for the CPUs are provided by SCP and are managed by this >> clock driver. So the cpufreq device needs to be added only after the >> clock get registered and removed when this driver is unloaded. >> >> This patch manages the cpufreq virtual device based on the clock >> availability. >> >> Signed-off-by: Sudeep Holla > > The cpufreq device can't handle probe defer? I suppose we do it > this way because we need to create a platform device somewhere > and this is the best place to do so? > Correct, unless the communication with the SCP firmware is established and the CPU clocks are registered, it makes no sense to register CPUFreq virtual device. This seems to be best place IMO. And yes, thanks to the absence of platform code on ARM64, where such code was traditionally stashed away and got away with such scenarios. Let me if you disagree with this or have any other suggestions. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/