Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752175AbbGWGJv (ORCPT ); Thu, 23 Jul 2015 02:09:51 -0400 Received: from mail-pd0-f177.google.com ([209.85.192.177]:36165 "EHLO mail-pd0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751698AbbGWGJn (ORCPT ); Thu, 23 Jul 2015 02:09:43 -0400 Date: Thu, 23 Jul 2015 11:39:38 +0530 From: Viresh Kumar To: "Rafael J. Wysocki" Cc: Russell King - ARM Linux , Rafael Wysocki , Lists linaro-kernel , "linux-pm@vger.kernel.org" , open list Subject: Re: [PATCH V2] cpufreq: Fix double addition of sysfs links Message-ID: <20150723060938.GD5322@linux> References: <20150718163149.GP7557@n2100.arm.linux.org.uk> <35d0bb6829c6c8a5fec7c55e45d9293946c0221b.1437566548.git.viresh.kumar@linaro.org> <20150722131539.GU7557@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2088 Lines: 49 On 22-07-15, 18:42, Rafael J. Wysocki wrote: > > 3. what happens when 'policy' is NULL at the point when the first (few) CPUs > > are added - how do the symlinks get created later if/when policy becomes > > non-NULL (can it?) > > Yes, it can, and we have a design issue here that bothers me a bit. I replied to Russell with a NO here as the first CPU should have created the policy. BUT... > Namley, we need a driver's ->init callback to populate policy->cpus > for us, but this is not the only thing it is doing, so the concern is > that it may not be able to deal with CPUs that aren't online. ... the first few CPUs could have been offline and so we might not have tried to add the policy at all.. Need to fix that for sure. > I was thinking about an additional driver callback that would *only* > populate a mask of CPUs that should use the same policy as the given > one. Why so ? Drivers today are required to set policy->cpus with all CPUs that should be managed by that policy. i.e. all online+offline. So, actually ->init() fills policy->cpus with the value of policy->related_cpus. Yes, I thought earlier to change that by setting policy->related_cpus from drivers, instead of policy->cpus and wasn't sure if I should do that :) > We'd be able to call that from cpufreq_add_dev() for offline > CPUs too and this way the policy object could be created for the first > CPU using the policy that is registered instead of being added for the > first CPU using that policy that becomes online (which happens today). Creating policy for offline CPUs doesn't look that great to me. What we can do to fix the problem in hand, is to update a global mask of CPUs (with policy == NULL) which were offline when cpufreq_add_dev() was called for them. And when we create the policy, we can add links for all such CPUs. -- viresh -- 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/