From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752326AbaEFRza (ORCPT ); Tue, 6 May 2014 13:55:30 -0400 Received: from sema.semaphore.gr ([78.46.194.137]:50897 "EHLO sema.semaphore.gr" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752121AbaEFRz2 (ORCPT ); Tue, 6 May 2014 13:55:28 -0400 Message-ID: <5369220A.3030207@semaphore.gr> Date: Tue, 06 May 2014 20:55:22 +0300 From: Stratos Karafotis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Geert Uytterhoeven , "Rafael J. Wysocki" CC: Viresh Kumar , Jesper Nilsson , Hans-Christian Egtvedt , Dirk Brandewie , "linux-doc@vger.kernel.org" , "cpufreq@vger.kernel.org" , "linux-pm@vger.kernel.org" , LKML , Randy Dunlap , "David S. Miller" , Linus Walleij , Simon Horman , Sekhar Nori , Samuel Ortiz , Linux-sh list Subject: Re: [PATCH v5 0/8] Introduce new cpufreq helper macros References: <535AC247.3070907@semaphore.gr> <535FCDBD.6080500@semaphore.gr> <1621123.rMC9JtD3Mo@vostro.rjw.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, On 06/05/2014 06:24 μμ, Geert Uytterhoeven wrote: > Hi Stratos, > > On Wed, Apr 30, 2014 at 12:26 AM, Rafael J. Wysocki wrote: >> On Tuesday, April 29, 2014 07:05:17 PM Stratos Karafotis wrote: >>> On 29/04/2014 07:17 πμ, Viresh Kumar wrote: >>>> On 26 April 2014 01:45, Stratos Karafotis wrote: >>>>> This patch set introduces two freq_table helper macros which >>>>> can be used for iteration over cpufreq_frequency_table and >>>>> makes the necessary changes to cpufreq core and drivers that >>>>> use such an iteration procedure. >>>>> >>>>> The motivation was a usage of common procedure to iterate over >>>>> cpufreq_frequency_table across all drivers and cpufreq core. >>>>> >>>>> This was tested on a x86_64 platform. >>>>> Most files compiled successfully but unfortunately I was not >>>>> able to compile sh_sir.c pasemi_cpufreq.c and ppc_cbe_cpufreq.c >>>>> due to lack of cross compiler. >>>>> >>>>> Changelog >>>>> >>>>> v4 -> v5 >>>>> - Fix warnings in printk format specifier for 32 bit >>>>> architectures in freq_table.c, longhaul, pasemi, ppc_cbe >>>> >>>> Doesn't look much has changed and so it stays as is: >>>> >>>> Acked-by: Viresh Kumar >>>> >>> >>> Thank you very much! >> >> I've applied the series to my bleeding-edge branch, will move it to linux-next >> after build testing later this week. > > This breaks if CONFIG_CPU_FREQ=n, e.g. ARM/shmobile/koelsch/ > non-multiplatform: > > drivers/built-in.o: In function `clk_round_parent': > clkdev.c:(.text+0xcf168): undefined reference to `cpufreq_next_valid' > drivers/built-in.o: In function `clk_rate_table_find': > clkdev.c:(.text+0xcf820): undefined reference to `cpufreq_next_valid' > make[3]: *** [vmlinux] Error 1 > > drivers/sh/clk/core.c (pre-CCF shmobile clock core) calls > cpufreq_for_each_valid_entry(): > > #define cpufreq_for_each_valid_entry(pos, table) \ > for (pos = table; cpufreq_next_valid(&pos); pos++) > > but cpufreq_next_valid() in drivers/cpufreq/cpufreq.c is not > compiled in. My bad. I'm sorry for this. :( Rafael, A solution could be to make cpufreq_next_valid an inline function in cpufreq.h, but as Viresh mentioned this would be very inefficient because of multiple copies. So, maybe it's better to revert the 2 patches that don't depend on CONFIG_CPU_FREQ: 4229e1c61a4a ("sh: clk: Use cpufreq_for_each_valid_entry macro for iteration") and 04ae58645afa ("irda: sh_sir: Use cpufreq_for_each_valid_entry macro for iteration"). Do I need to send revert patches for the above? Thanks, Stratos