From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DE8EC43381 for ; Wed, 20 Feb 2019 11:03:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0555020685 for ; Wed, 20 Feb 2019 11:02:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727662AbfBTLC6 convert rfc822-to-8bit (ORCPT ); Wed, 20 Feb 2019 06:02:58 -0500 Received: from unicorn.mansr.com ([81.2.72.234]:44296 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726370AbfBTLC5 (ORCPT ); Wed, 20 Feb 2019 06:02:57 -0500 Received: by unicorn.mansr.com (Postfix, from userid 51770) id CA65415632; Wed, 20 Feb 2019 11:02:56 +0000 (GMT) From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: "Rafael J. Wysocki" Cc: Greg Kroah-Hartman , Linux Kernel Mailing List Subject: Re: [PATCH] platform: set of_node in platform_device_register_full() References: <20190216164512.9525-1-mans@mansr.com> Date: Wed, 20 Feb 2019 11:02:56 +0000 In-Reply-To: (Rafael J. Wysocki's message of "Wed, 20 Feb 2019 11:51:01 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Rafael J. Wysocki" writes: > On Wed, Feb 20, 2019 at 11:41 AM Måns Rullgård wrote: >> >> "Rafael J. Wysocki" writes: >> >> > On Mon, Feb 18, 2019 at 12:10 PM Måns Rullgård wrote: >> >> >> >> "Rafael J. Wysocki" writes: >> >> >> >> > On Sat, Feb 16, 2019 at 5:50 PM Mans Rullgard wrote: >> >> >> >> >> >> If the provided fwnode is an OF node, set dev.of_node as well. >> >> >> >> >> >> Signed-off-by: Mans Rullgard >> >> >> --- >> >> >> drivers/base/platform.c | 1 + >> >> >> 1 file changed, 1 insertion(+) >> >> >> >> >> >> diff --git a/drivers/base/platform.c b/drivers/base/platform.c >> >> >> index dff82a3c2caa..853a1d0e5845 100644 >> >> >> --- a/drivers/base/platform.c >> >> >> +++ b/drivers/base/platform.c >> >> >> @@ -512,6 +512,7 @@ struct platform_device *platform_device_register_full( >> >> >> >> >> >> pdev->dev.parent = pdevinfo->parent; >> >> >> pdev->dev.fwnode = pdevinfo->fwnode; >> >> >> + pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode)); >> >> > >> >> > of_node_get() generally does a kobject_get() on the node's kobject, so >> >> > when is that reference dropped? Or if it doesn't need to be dropped >> >> > at all, why is this the case? >> >> >> >> platform_device_release() calls of_device_node_put(). >> > >> > Yes, it does, but this is the reference that's already acquired for >> > devices added while parsing DT, isn't it? >> > >> > Your change adds an extra reference AFAICS. >> > >> > Also, why is this patch needed? >> >> Some drivers are just shims that create extra "glue" devices with the DT >> device as parent and have the real driver bind to these. In other >> cases, the same real driver matches the DT node directly. When a glue >> device is used, it needs to get a reference to the original DT node in >> order for the main driver to access properties and child nodes. >> >> Right now, my problem is that the suxi-musb driver creates such a glue >> device for the musb core driver to bind to without setting of_node. >> This means devices attached to this USB interface don't get associated >> with DT nodes, if present, the way they do with EHCI. > > You really should describe problems that you want to address in patch > changelogs. This helps a lot to understand the motivation for the > changes. Do you want me to send a new patch with the above explanation in the commit message? >> The sunxi-musb driver uses platform_device_register_full(), so this >> seemed like the easiest way to let it set of_node of the new device. >> Since this creates a second reference to the same node, of_node_get() >> is required. > > But what about devices that already have of_node set at this point? > > Maybe check if of_node is NULL before trying to set it? It's a brand new device allocated a few lines above. of_node has to be null here. -- Måns Rullgård