From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751198Ab1IZOQq (ORCPT ); Mon, 26 Sep 2011 10:16:46 -0400 Received: from opensource.wolfsonmicro.com ([80.75.67.52]:36697 "EHLO opensource.wolfsonmicro.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750725Ab1IZOQp (ORCPT ); Mon, 26 Sep 2011 10:16:45 -0400 Date: Mon, 26 Sep 2011 15:16:43 +0100 From: Mark Brown To: Grant Likely Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Greg Kroah-Hartman , Dilan Lee , Manjunath GKondaiah , Arnd Bergmann Subject: Re: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism Message-ID: <20110926141643.GK2946@opensource.wolfsonmicro.com> References: <20110922184614.25419.84606.stgit@ponder> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110922184614.25419.84606.stgit@ponder> X-Cookie: You are always busy. User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote: > Allow drivers to report at probe time that they cannot get all the resources > required by the device, and should be retried at a later time. > This should completely solve the problem of getting devices > initialized in the right order. Right now this is mostly handled by > mucking about with initcall ordering which is a complete hack, and > doesn't even remotely handle the case where device drivers are in > modules. This approach completely sidesteps the issues by allowing > driver registration to occur in any order, and any driver can request > to be retried after a few more other drivers get probed. So, one issue I did think of the other day while putting some support in the regulator core for using this: what happens with devices which can optionally use a resource but don't rely on it? One example here is that a lot of the MMC drivers have an optional regulator to control some of the supplies for the cards. If the reglator isn't there it won't be used but it's not a blocker for anything. Devices doing this would need some way to figure out if they should -EBUSY or fail otherwise.