[PATCH -next] cpufreq: add stub for get_cpu_idle_time() to fix scsi/lpfc driver build

[PATCH -next] cpufreq: add stub for get_cpu_idle_time() to fix scsi/lpfc driver build

[Randy Dunlap]

From: Randy Dunlap <rdunlap@infradead.org>

To fix a build error in drivers/scsi/lpfc/lpfc_sli.c when
CONFIG_CPU_FREQ is not set/enabled, add a stub function for
get_cpu_idle_time() in <linux/cpufreq.h>.

../drivers/scsi/lpfc/lpfc_sli.c: In function ‘lpfc_init_idle_stat_hb’:
../drivers/scsi/lpfc/lpfc_sli.c:7330:26: error: implicit declaration of function ‘get_cpu_idle_time’; did you mean ‘set_cpu_active’? [-Werror=implicit-function-declaration]
   idle_stat->prev_idle = get_cpu_idle_time(i, &wall, 1);

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-pm@vger.kernel.org
Cc: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Cc: linux-scsi@vger.kernel.org
---
 include/linux/cpufreq.h |    4 ++++
 1 file changed, 4 insertions(+)

--- linux-next-20200706.orig/include/linux/cpufreq.h
+++ linux-next-20200706/include/linux/cpufreq.h
@@ -237,6 +237,10 @@ static inline unsigned int cpufreq_get_h
 {
 	return 0;
 }
+static inline u64 get_cpu_idle_time(unsigned int cpu, u64 *wall, int io_busy)
+{
+	return 0;
+}
 static inline void disable_cpufreq(void) { }
 #endif
 

Re: [PATCH -next] cpufreq: add stub for get_cpu_idle_time() to fix scsi/lpfc driver build

[Viresh Kumar]

On 06-07-20, 09:44, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
> 
> To fix a build error in drivers/scsi/lpfc/lpfc_sli.c when
> CONFIG_CPU_FREQ is not set/enabled, add a stub function for
> get_cpu_idle_time() in <linux/cpufreq.h>.
> 
> ../drivers/scsi/lpfc/lpfc_sli.c: In function ‘lpfc_init_idle_stat_hb’:
> ../drivers/scsi/lpfc/lpfc_sli.c:7330:26: error: implicit declaration of function ‘get_cpu_idle_time’; did you mean ‘set_cpu_active’? [-Werror=implicit-function-declaration]

And why is lpfc_sli.c using a cpufreq (supposedly internal, i.e. for
cpufreq related parts) routine ? I think if you really need this, then
it should be moved to a better common place and let everyone use it.

I also see that drivers/macintosh/rack-meter.c has its own
implementation for this.

>    idle_stat->prev_idle = get_cpu_idle_time(i, &wall, 1);
> 
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: linux-pm@vger.kernel.org
> Cc: James Smart <james.smart@broadcom.com>
> Cc: Dick Kennedy <dick.kennedy@broadcom.com>
> Cc: linux-scsi@vger.kernel.org
> ---
>  include/linux/cpufreq.h |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> --- linux-next-20200706.orig/include/linux/cpufreq.h
> +++ linux-next-20200706/include/linux/cpufreq.h
> @@ -237,6 +237,10 @@ static inline unsigned int cpufreq_get_h
>  {
>  	return 0;
>  }
> +static inline u64 get_cpu_idle_time(unsigned int cpu, u64 *wall, int io_busy)
> +{
> +	return 0;
> +}
>  static inline void disable_cpufreq(void) { }
>  #endif
>  

-- 
viresh

Re: [PATCH -next] cpufreq: add stub for get_cpu_idle_time() to fix scsi/lpfc driver build

[Randy Dunlap]

On 7/6/20 8:09 PM, Viresh Kumar wrote:
> On 06-07-20, 09:44, Randy Dunlap wrote:
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> To fix a build error in drivers/scsi/lpfc/lpfc_sli.c when
>> CONFIG_CPU_FREQ is not set/enabled, add a stub function for
>> get_cpu_idle_time() in <linux/cpufreq.h>.
>>
>> ../drivers/scsi/lpfc/lpfc_sli.c: In function ‘lpfc_init_idle_stat_hb’:
>> ../drivers/scsi/lpfc/lpfc_sli.c:7330:26: error: implicit declaration of function ‘get_cpu_idle_time’; did you mean ‘set_cpu_active’? [-Werror=implicit-function-declaration]
> 
> And why is lpfc_sli.c using a cpufreq (supposedly internal, i.e. for
> cpufreq related parts) routine ? I think if you really need this, then
> it should be moved to a better common place and let everyone use it.

Viresh:

James Smart replied in another email thread with lpfc explanation for using
get_cpu_idle_time().  Please see
https://lore.kernel.org/linux-scsi/7ae1c7e3-ce8d-836b-1ae7-d4d00bd8f95c@broadcom.com/T/#md083717b1ff3a428c3b419dcc6d11cd03fee44c7

for this text:
""The driver is using cpu utilization in order to choose between softirq or work queues in handling an interrupt. Less-utilized, softirq is used. higher utilized, work queue is used.  The utilization is checked periodically via a heartbeat. ""


> I also see that drivers/macintosh/rack-meter.c has its own
> implementation for this.
> 
>>    idle_stat->prev_idle = get_cpu_idle_time(i, &wall, 1);
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>> Cc: Viresh Kumar <viresh.kumar@linaro.org>
>> Cc: linux-pm@vger.kernel.org
>> Cc: James Smart <james.smart@broadcom.com>
>> Cc: Dick Kennedy <dick.kennedy@broadcom.com>
>> Cc: linux-scsi@vger.kernel.org
>> ---
>>  include/linux/cpufreq.h |    4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> --- linux-next-20200706.orig/include/linux/cpufreq.h
>> +++ linux-next-20200706/include/linux/cpufreq.h
>> @@ -237,6 +237,10 @@ static inline unsigned int cpufreq_get_h
>>  {
>>  	return 0;
>>  }
>> +static inline u64 get_cpu_idle_time(unsigned int cpu, u64 *wall, int io_busy)
>> +{
>> +	return 0;
>> +}
>>  static inline void disable_cpufreq(void) { }
>>  #endif
>>  
> 


-- 
~Randy

Re: [PATCH -next] cpufreq: add stub for get_cpu_idle_time() to fix scsi/lpfc driver build

[Viresh Kumar]

On 07-07-20, 11:18, Randy Dunlap wrote:
> Viresh:
> 
> James Smart replied in another email thread with lpfc explanation for using
> get_cpu_idle_time().  Please see
> https://lore.kernel.org/linux-scsi/7ae1c7e3-ce8d-836b-1ae7-d4d00bd8f95c@broadcom.com/T/#md083717b1ff3a428c3b419dcc6d11cd03fee44c7
> 
> for this text:
> ""The driver is using cpu utilization in order to choose between softirq or work queues in handling an interrupt. Less-utilized, softirq is used. higher utilized, work queue is used.  The utilization is checked periodically via a heartbeat. ""

To avoid ping pong of messages, I have instead replied to that email
directly now. Lets follow it there.

-- 
viresh