From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stratos Karafotis Subject: Re: [PATCH v5 0/8] Introduce new cpufreq helper macros Date: Wed, 07 May 2014 16:34:12 +0300 Message-ID: <536A3654.20201@semaphore.gr> References: <535AC247.3070907@semaphore.gr> <5369220A.3030207@semaphore.gr> <4469396.zveA7sC36d@vostro.rjw.lan> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <4469396.zveA7sC36d@vostro.rjw.lan> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8" To: "Rafael J. Wysocki" , Viresh Kumar Cc: Geert Uytterhoeven , 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 Hi Rafael, On 07/05/2014 04:13 =CE=BC=CE=BC, Rafael J. Wysocki wrote: > On Wednesday, May 07, 2014 10:53:16 AM Viresh Kumar wrote: >> On 6 May 2014 23:25, Stratos Karafotis wrote= : >>> My bad. I'm sorry for this. :( >>> >>> Rafael, >>> A solution could be to make cpufreq_next_valid an inline function i= n cpufreq.h, >>> but as Viresh mentioned this would be very inefficient because of m= ultiple copies. >> >> That statement was true when we didn't had this problem.. >> >>> 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"). >> >> This doesn't look right. It can happen to some other drivers as well= in future. >> So, there are two solutions I can think of: >> 1. move cpufreq_next_valid and rename it to __cpufreq_next_valid(). = Also make it >> inline. Then create two versions of cpufreq_next_valid(), one inline= d (only when >> CONFIG_CPU_FREQ=3Dn) and other one in cpufreq.c (non- inlined).. >> >> But probably that would be called ugly by some people :) >> >> 2. Make cpufreq_next_valid() inline and forget about extra space it = takes :) >> >> @Rafel: Let me know which one you like :) >=20 > 2. >=20 >=20 Do you want me to resend the entire patch set or only patch 1/8? Thanks, Stratos From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stratos Karafotis Date: Wed, 07 May 2014 13:34:12 +0000 Subject: Re: [PATCH v5 0/8] Introduce new cpufreq helper macros Message-Id: <536A3654.20201@semaphore.gr> List-Id: References: <535AC247.3070907@semaphore.gr> <5369220A.3030207@semaphore.gr> <4469396.zveA7sC36d@vostro.rjw.lan> In-Reply-To: <4469396.zveA7sC36d@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: "Rafael J. Wysocki" , Viresh Kumar Cc: Geert Uytterhoeven , 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 Hi Rafael, On 07/05/2014 04:13 μμ, Rafael J. Wysocki wrote: > On Wednesday, May 07, 2014 10:53:16 AM Viresh Kumar wrote: >> On 6 May 2014 23:25, Stratos Karafotis wrote: >>> 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. >> >> That statement was true when we didn't had this problem.. >> >>> 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"). >> >> This doesn't look right. It can happen to some other drivers as well in future. >> So, there are two solutions I can think of: >> 1. move cpufreq_next_valid and rename it to __cpufreq_next_valid(). Also make it >> inline. Then create two versions of cpufreq_next_valid(), one inlined (only when >> CONFIG_CPU_FREQ=n) and other one in cpufreq.c (non- inlined).. >> >> But probably that would be called ugly by some people :) >> >> 2. Make cpufreq_next_valid() inline and forget about extra space it takes :) >> >> @Rafel: Let me know which one you like :) > > 2. > > Do you want me to resend the entire patch set or only patch 1/8? Thanks, Stratos