linux-kernel - Re: [PATCH] regulator: mt6397: convert to arch

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:	Tue, 5 Jan 2016 13:44:52 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Yingjoe Chen <yingjoe.chen@...iatek.com>
Cc:	Daniel Kurtz <djkurtz@...omium.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Henry Chen <henryc.chen@...iatek.com>,
	Mark Rutland <mark.rutland@....com>,
	Liam Girdwood <lgirdwood@...il.com>,
	linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org,
	Sascha Hauer <kernel@...gutronix.de>, eddie.huang@...iatek.com,
	linux-arm-kernel@...ts.infradead.org,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH] regulator: mt6397: convert to arch_initcall

On Thu, Dec 24, 2015 at 04:10:43PM +0800, Yingjoe Chen wrote:

> These changes are related to pinctrl init order patch. The related
> discussion is here:
> http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003298.html

So this is just to cut down on probe deferrals?  Sorry but as you'll see
from the discussion in that thread I'm really not enthusiastic about
taking such patches.  Trying to use initcall ordering is a hack we're
moving towards removing, isn't very robust and makes it harder to
convince people that it's worth doing anything to really improve things.

> I think Henry use arch_initcall because that's what pinctrl patch was
> using. In this case, we should use subsys_initcall for all these.

But why?  This sort of random unexplained level picking is part of the
problem...

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)