From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752807AbbGNHes (ORCPT ); Tue, 14 Jul 2015 03:34:48 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:34398 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752567AbbGNHep (ORCPT ); Tue, 14 Jul 2015 03:34:45 -0400 MIME-Version: 1.0 In-Reply-To: <20150713154254.GH11162@sirena.org.uk> References: <1435743667-11987-1-git-send-email-tomeu.vizoso@collabora.com> <1435743667-11987-12-git-send-email-tomeu.vizoso@collabora.com> <20150701173802.GW11162@sirena.org.uk> <20150713154254.GH11162@sirena.org.uk> From: Tomeu Vizoso Date: Tue, 14 Jul 2015 09:34:22 +0200 X-Google-Sender-Auth: VrqQBaR3uv3pjQAxouy2c9R4GGE Message-ID: Subject: Re: [alsa-devel] [PATCH v2 11/12] ASoC: tegra: register dependency parser for firmware nodes To: Mark Brown Cc: "devicetree@vger.kernel.org" , linux-fbdev@vger.kernel.org, linux-acpi@vger.kernel.org, alsa-devel@alsa-project.org, Stephen Warren , Takashi Iwai , "Rafael J. Wysocki" , Liam Girdwood , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , linux-gpio@vger.kernel.org, Thierry Reding , Linux PWM List , "linux-tegra@vger.kernel.org" , Alexandre Courbot Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13 July 2015 at 17:42, Mark Brown wrote: > On Mon, Jul 13, 2015 at 02:10:45PM +0200, Tomeu Vizoso wrote: >> On 1 July 2015 at 19:38, Mark Brown wrote: >> > On Wed, Jul 01, 2015 at 11:41:06AM +0200, Tomeu Vizoso wrote: > >> >> +static void tegra_max98090_get_dependencies(struct fwnode_handle *fwnode, >> >> + struct list_head *deps) >> >> +{ >> >> + add_dependency(fwnode, "nvidia,i2s-controller", deps); >> >> + add_dependency(fwnode, "nvidia,audio-codec", deps); >> >> +} > >> > Why is this all being open coded in an individual driver (we already >> > know about and manage all these dependencies in the core...)? If we're >> > going to do this I'd expect the interface for specifying DT nodes to the >> > core to be changed to support this. > >> Are you thinking of changing drivers to acquire their resources >> through Arnd's devm_probe (only that the resource table would have to >> be in struct device_driver)? > >> https://lkml.kernel.org/g/4742258.TBitC3hVuO@wuerfel > > No, I'm looking at how we already have all the "did all my dependencies > appear" logic in the core based on data provided by the drivers. Sorry, but I still don't get what you mean. Information about dependencies is currently available only after probe() starts executing, and used to decide whether we want to defer the probe. The goal of this series is to eliminate most or all of the deferred probes by checking that all dependencies are available before probe() is called. Because currently we only have dependency information after probe() starts executing, we have to make it available earlier. In this particular version, in callbacks that are registered from the initcalls that register subsystems, classes, drivers, etc. Whatever knows how these dependencies are expressed in the firmware data. I thought you were pointing out that the property names would be duplicated, once in the probe() implementation and also in the implementation of the get_dependencies callback. A way to consolidate the code and remove that duplication would be having a declarative API for expressing dependencies, which could be used for both fetching dependencies and for preventing deferred probes. That's why I mentioned devm_probe. Thanks, Tomeu