linux-kernel - Re: linux-next: Tree for Jul 7 (scsi/lpfc/lpfc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 8 Jul 2020 08:16:00 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     James Smart <james.smart@...adcom.com>
Cc:     Randy Dunlap <rdunlap@...radead.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-scsi <linux-scsi@...r.kernel.org>,
        dick kennedy <dick.kennedy@...adcom.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: linux-next: Tree for Jul 7 (scsi/lpfc/lpfc_init.c)

Hi James,

On Tue, Jul 7, 2020 at 11:43 PM James Smart <james.smart@...adcom.com> wrote:
>
> On 7/7/2020 10:09 AM, Randy Dunlap wrote:
> > On 7/7/20 1:08 AM, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Changes since 20200706:
> >>
> > on i386:
> >
> > when CONFIG_ACPI is not set/enabled:
> >
> >
> > ../drivers/scsi/lpfc/lpfc_init.c:1265:15: error: implicit declaration of function 'get_cpu_idle_time'; did you mean 'get_cpu_device'? [-Werror=implicit-function-declaration]
> >
> >
> > The cpufreq people want justification for using

I am one of cpufreq people :)

> > get_cpu_idle_time().  Please see
> > https://lore.kernel.org/linux-scsi/20200707030943.xkocccy6qy2c3hrx@vireshk-i7/
> >
>
> 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 understand that you need to use this functionality, what I was
rather asking was
why do you need to use a routine that is for cpufreq related stuff only.

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

What I would suggest is that, if required, we should add/move a
generic implementation
of this to another file (which is available to all) and then let
everyone use it.

--
viresh