[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160105134452.GE16023@sirena.org.uk>
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)
Powered by blists - more mailing lists