Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752504AbbFKIPU (ORCPT ); Thu, 11 Jun 2015 04:15:20 -0400 Received: from mail-oi0-f50.google.com ([209.85.218.50]:36075 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751868AbbFKIPG (ORCPT ); Thu, 11 Jun 2015 04:15:06 -0400 MIME-Version: 1.0 In-Reply-To: References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> Date: Thu, 11 Jun 2015 10:15:04 +0200 Message-ID: Subject: Re: [PATCH 00/21] On-demand device registration From: Linus Walleij To: Tomeu Vizoso Cc: Mark Rutland , "devicetree@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , linux-samsung-soc , dmaengine@vger.kernel.org, "linux-gpio@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pwm@vger.kernel.org" , linux-clk@vger.kernel.org, "linux-tegra@vger.kernel.org" , Rob Herring , "open list:DRM PANEL DRIVERS" , Grant Likely , Alexander Holler , Dan Williams , Dmitry Torokhov , "linux-usb@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-i2c@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2462 Lines: 59 On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso wrote: > On 10 June 2015 at 09:30, Linus Walleij wrote: >> regulator_get(...) -> not available, so: >> - identify target regulator provider - this will need instrumentation >> - probe it >> >> It then turns out the regulator driver is on the i2c bus, so we >> need to probe the i2c driver: >> - identify target i2c host for the regulator driver - this will need >> instrumentation >> - probe the i2c host driver >> >> i2c host comes out, probes the regulator driver, regulator driver >> probes and then the regulator_get() call returns. > > Hmm, if I understand correctly what you say, this is exactly what this > particular series does: > > regulator_get -> of_platform_device_ensure -> probe() on the platform > device that encloses the requested device node (i2c host) -> i2c slave > gets probed and the regulator registered -> regulator_get returns the > requested resource Yes. But only for device tree. > The downside I'm currently looking at is that an explicit dependency > graph would be useful to have for other purposes. For example to print > a neat warning when a dependency cannot be fulfilled. Or to refuse to > unbind a device which other devices depend on, or to automatically > unbind the devices that depend on it, or to print a warning if a > device is hotplugged off and other devices depend on it. Unbind/remove() calls are the inverse usually yes. But also the [runtime] power up/down sequences for the devices tend to depend on a similar ordering or mostly the same. (Mentioned this before I think.) >> This requires instrumentation on anything providing a resource >> to another driver like those I mentioned and a lot of overhead >> infrastructure, but I think it's the right approach. However I don't >> know if I would ever be able to pull that off myself, I know talk >> is cheap and I should show the code instead. > > Yeah, if you can give it a second look and say if it matches what you > wrote above, it would be very much appreciated. Yes you are right. But what about ACPI, board files, Simple Firmware and future hardware description languages... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/