linux-kernel - Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 18 Sep 2019 10:17:47 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Amit Kucheria <amit.kucheria@...aro.org>,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        bjorn.andersson@...aro.org, edubezval@...il.com, agross@...nel.org,
        tdas@...eaurora.org, swboyd@...omium.org, ilina@...eaurora.org,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Zhang Rui <rui.zhang@...el.com>, linux-pm@...r.kernel.org
Subject: Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier

On Wed, Sep 18, 2019 at 02:39:38PM +0530, Viresh Kumar wrote:
> On 17-09-19, 10:34, Sudeep Holla wrote:
> > On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote:
> > > -device_initcall(qcom_cpufreq_hw_init);
> > > +postcore_initcall(qcom_cpufreq_hw_init);
> >
> > I am fine with core framework initcall pushed to earlier initcall levels
> > if required, but for individual/platform specific drivers I am not so
> > happy to see that.
> >
> > This goes against the grand plan of single common kernel strategy by
> > Android moving all drivers as modules.
>
> Its been long that I got the opportunity to work on drivers directly, but as far
> as I remember (which should be incorrect based on your reply) we can still build
> a driver as module even if it has some postcore_initcall() declarations. They
> will execute at module insertion. Is that incorrect ? If not, then how is it
> going to affect android effort ?
>

Ah no, I am not referring to building as module. As you mention, that may
work just fine. I was referring to timing dependency during boot. The idea
is minimize the number of such initcall dependency. They should all work
fine even as modules and should have least dependency on initcall sequence.

--
Regards,
Sudeep