From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Holler Subject: Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT) Date: Thu, 21 Aug 2014 21:19:00 +0200 Message-ID: <53F64624.5000403@ahsoftware.de> References: <1399913280-6915-1-git-send-email-holler@ahsoftware.de> <20140514141914.446F7C4153D@trevor.secretlab.ca> <20140821140211.GD19293@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140821140211.GD19293-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Thierry Reding , Grant Likely Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jon Loeliger , Russell King , Greg Kroah-Hartman , Rob Herring , Arnd Bergmann , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org Am 21.08.2014 16:02, schrieb Thierry Reding: > Anyway, those are all fairly standard reasons for where deferred probe > triggers, and since I do like deferred probe for it's simplicity and > reliability I'd rather not try to work around it if boot time is all > that people are concerned about. It's neither simple nor reliable. It's non deterministic brutforcing while making it almost impossible to identify real errors. In my humble opinion the worst way to solve something. I'm pretty sure if I would have suggest such a solution, the maintainer crowd would have eaten me without cooking. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html