From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH v1 1/4] i2c: mux: Add i2c-arbitrator 'mux' driver Date: Thu, 14 Feb 2013 16:35:57 -0700 Message-ID: <511D74DD.9070600@wwwdotorg.org> References: <1360778532-7480-1-git-send-email-dianders@chromium.org> <511BFF77.2090202@wwwdotorg.org> <511C32B5.20600@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Doug Anderson Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Daniel Kurtz , "linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Stephen Warren , Wolfram Sang , Ben Dooks , u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org, Guenter Roeck , Grant Grundler , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, Rob Herring , Jean Delvare , Alexandre Courbot , "Ben Dooks (embedded platforms)" , Girish Shivananjappa , "bhushan.r" , Naveen Krishna Chatradhi , "sreekumar.c" , Mark Brown , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Peter Korsgaard List-Id: linux-i2c@vger.kernel.org On 02/14/2013 02:40 PM, Doug Anderson wrote: > On Wed, Feb 13, 2013 at 4:54 PM, Doug Anderson wrote: >>>>> You should be able to replace all that with: >>>>> >>>>> module_platform_driver(&i2c_arbitrator_driver); ... > OK, so I dug into my problems here a little bit. All of the problems > are with a private branch that includes stuff not fully upstream, > but... > > The problem is that we've got a regulator (tps65090) on this bus. > Right now the first code that wants to use tps65090 runs from the > set_power() callback of "platform-lcd". It looks like: > lcd_fet = regulator_get(NULL, "lcd_vdd"); > > ...and "platform-lcd" is instantiated really early via > platform_device_register() for some reason. > > I tried to fix it by moving platform-lcd to actually be instantiated > via the device tree (with platform data populated through > of_platform_populate). I then hooked up regulators through the device > tree: It shouldn't matter when the platform-lcd device is instantiated, so doing it via a board file vs. a device tree shouldn't make much difference. ... > ...but when I moved to module_platform_driver() then things still broke. > > [ 1.510000] platform-lcd supply lcd_vdd not found, using dummy regulator What prints that? I assume that's some error-handling logic in the platform-lcd driver. It's probably not detecting an -EPROBE_DEFFERED return from regulator_get() correctly, and hence proceeding with the probe() when it should simply return and let the kernel retry the probe() later. > I was sorta hoping that there would be some magic where > regulator_get() would find the device tree node for the regulator and > then resolve the chain. ...but maybe that's a pipe dream. regulator_get() won't forcibly probe() the whole dependency chain. The idea is that if a driver tries to get a resource, and it fails with -EPROBE_DEFER, the requesting driver should fail its own probe() with that same error code, and the driver core will retry the failed probe() later when the resource is hopefully available. > Is there some better way I should be expressing dependencies? Do I > need to try to hack something together with -EAGAIN (ick!)? Yes, basically. -EPROBE_DEFER specifically, although that might be an alias for -EGAIN; I can't remember which way that went.