From patchwork Fri Jul 31 10:32:45 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tomeu Vizoso X-Patchwork-Id: 6910231 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 4F446C05AC for ; Fri, 31 Jul 2015 10:35:34 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4B4AA205D1 for ; Fri, 31 Jul 2015 10:35:33 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3EBF1203B4 for ; Fri, 31 Jul 2015 10:35:32 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZL7d8-0005nR-G1; Fri, 31 Jul 2015 10:33:34 +0000 Received: from merlin.infradead.org ([2001:4978:20e::2]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZL7d5-0005m7-Ge for linux-arm-kernel@bombadil.infradead.org; Fri, 31 Jul 2015 10:33:31 +0000 Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]) by merlin.infradead.org with esmtps (Exim 4.85 #2 (Red Hat Linux)) id 1ZL7d3-0003m4-Gw for linux-arm-kernel@lists.infradead.org; Fri, 31 Jul 2015 10:33:30 +0000 Received: by wicmv11 with SMTP id mv11so52750957wic.0 for ; Fri, 31 Jul 2015 03:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=nZZAJ1nFSjlyuBchQsdaDUkj2+MfWZO2oCmpffY5ZPM=; b=VgGI5MSuMHZ2tW5JoTzicBBqC0ILekPoPDzOvTYAzw49Afjd0L1907TmZvEcR/BsjI 0SbO8y1GGerRbdcLXJB6kfYsZqwwDrJ7LDF+h6q+rFhDu3rJiZrVnsENrR4hdijdQQ6G Ouie/un/EvpJcDCBspMm/b5njKaU7DGojJWLG1UvuE8SjFQ5B5MIAR4txcbLwkq5Cx3g oHtw2rOvBuR3cChcZGge81TVe453ZBHIj2lzQvE9wcpAG81kx3jc4nyLHyvJ23UHgDhG /hOUISnj7d+XJztWynkCZerbHBSbMIsHYDDESCFrFXnl39KZLmU2mU49s2UYpACLtUYL zEYg== X-Received: by 10.180.99.196 with SMTP id es4mr5355362wib.57.1438338784853; Fri, 31 Jul 2015 03:33:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.0.38 with HTTP; Fri, 31 Jul 2015 03:32:45 -0700 (PDT) In-Reply-To: References: <1438089593-7696-1-git-send-email-tomeu.vizoso@collabora.com> <1438089593-7696-5-git-send-email-tomeu.vizoso@collabora.com> From: Tomeu Vizoso Date: Fri, 31 Jul 2015 12:32:45 +0200 X-Google-Sender-Auth: ybG0VepFQifV3Xp6d4cMUc4TZVg Message-ID: Subject: Re: [PATCH v2 04/22] of/platform: add of_platform_device_find() To: Rob Herring X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150731_063329_804900_6E4AE1AD X-CRM114-Status: GOOD ( 33.80 ) X-Spam-Score: -2.4 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "devicetree@vger.kernel.org" , "linux-acpi@vger.kernel.org" , Arnd Bergmann , Stephen Warren , Linus Walleij , Dmitry Torokhov , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Rob Herring , Javier Martinez Canillas , Mark Brown , Thierry Reding , Grant Likely , "linux-arm-kernel@lists.infradead.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 29 July 2015 at 17:27, Rob Herring wrote: > On Wed, Jul 29, 2015 at 6:20 AM, Tomeu Vizoso > wrote: >> On 29 July 2015 at 08:14, Tomeu Vizoso wrote: >>> On 28 July 2015 at 17:31, Rob Herring wrote: >>>> On Tue, Jul 28, 2015 at 8:54 AM, Tomeu Vizoso >>>> wrote: >>>>> On 28 July 2015 at 15:39, Rob Herring wrote: >>>>>> On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso >>>>>> wrote: >>>>>>> From an arbitrary node in the tree, find the enclosing node that >>>>>>> corresponds to a platform device, as registered by >>>>>>> of_platform_populate(). > > [...] > >>>>> If I had a way to get, say, a i2c device from its fwnode then I would >>>>> just need to make sure that a device's parent is probed before probing >>>>> it and everything would be cleaner in the OF case. >>>> >>>> If you have the struct device from the device_node, then you should be >>>> able to do this, right? >>> >>> Yes, if I could go back from the device_node to the struct device that >>> was registered from it, for all buses, then all this would be much >>> simpler and more robust. It would basically work like in the ACPI >>> case. >>> >>> I will play with this idea. >>> >>>>>> That is probably not the >>>>>> most efficient search, but we could fix that. We could add struct >>>>>> device ptr to struct device_node and check without searching for >>>>>> example. >>>>> >>>>> That would be great, but I thought there was an issue with a OF node >>>>> being able to be related to more than one struct device (but I haven't >>>>> found this myself yet). >>>> >>>> I think it pretty much should be one to one. I'm not aware of any >>>> examples where that is not the case. This function would already be >>>> broken if you could have more than one struct device. >>> >>> Well, for platform devices we currently know that there can only be >>> one struct device for a given device_node, but that's not so clear for >>> other devices. >> >> Just found this case: >> >> http://lxr.free-electrons.com/source/drivers/spi/spi-tegra114.c#L1124 >> >> Looks like SPI master devices point to the same device_node as the >> platform device that registers them. > > I don't think this is a problem. The device ptr would only point to > the platform device. Nothing else is going to know about the ptr, > modify it nor expect that it points to the same struct device that > contains the of_node ptr. > > So I think any instances of struct device like this are ones you don't > care about for purposes of probe dependencies. Ok, I think I got it now. This is what I came up with and works fine on all the boards I'm testing with: err_clear_flag: @@ -501,59 +503,29 @@ void of_platform_depopulate(struct device *parent) } EXPORT_SYMBOL_GPL(of_platform_depopulate); /** * of_platform_device_find() - Find nearest ancestor that is a platform device * @np: node to find platform device for * - * Walks the tree up and finds the closest ancestor that has match data and - * either is at the root of the tree or is a child of a simple memory mapped - * bus. + * Walks the OF tree up and finds the closest ancestor that has a platform + * device associated with it. * * Returns such a device, or NULL if none could be found. */ struct device *of_platform_device_find(struct device_node *np) { struct device_node *target; - struct platform_device *pdev; + struct platform_device *pdev = NULL; of_node_get(np); for (target = np; !of_node_is_root(target); target = of_get_next_parent(target)) - if (of_is_platform(target)) + if (target->platform_dev) { + pdev = target->platform_dev; break; - - pdev = of_find_device_by_node(target); + } of_node_put(target); Thanks, Tomeu > Rob > -- > 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/ diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 89c5cd513027..e14518b5e1ce 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -192,6 +192,8 @@ static struct platform_device *of_platform_device_create_pdata( goto err_clear_flag; } + np->platform_dev = dev; + return dev;