Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp432703imp; Wed, 20 Feb 2019 02:51:52 -0800 (PST) X-Google-Smtp-Source: AHgI3Ia75ZQ5kTGjnwN8KrlbDqmmPdDuVzn7L0Mo1W2d4V0CPA4VT8uluDZ6gac0M8othd7gY2o7 X-Received: by 2002:a63:6605:: with SMTP id a5mr7457715pgc.372.1550659912259; Wed, 20 Feb 2019 02:51:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550659912; cv=none; d=google.com; s=arc-20160816; b=Loo5gNsL4vLJ7/+M2Ht+66N83gwhFg7SWtoI3+YC2g7BfQeOrNigtpGDTa3qtFN73S KcK7SARK74xVEvO5qmvPztDWCzrOl4vZlHtKgm6bmlm8bQtk53tfS4QWOleaEKYFtJ4c qSuJyLKnmJgdpIzGB3LNwuGEAVFB60Dy0Wfmk2F7OgIjuvSJlvzL0OBQERyUVcqVQvvK yv9Smd5fIJgwiW7uS6vLKe+G2/Tfu11F/EPvBINCNd8CCai4zNJ8rZWFv1ehmmie5RDZ 9dM1cINLKxUF9Gi7Yj7vOyRUYTVwLEHx3TyCw6L6u3h1xTFBSqOQgPfHoyF8jVr38fn+ uvVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=b6QZdvznIWnMBGMDmt9+1i51VNYIGhw6oLdG4fAJNRg=; b=VLrcm5+Y17PM/RrAYsPi7BhXgOqXVJVfFLpGeNJGA2L0GH958lK3tTE/Qnd68iSG9u lWOqsvmqXLG3MFOuOJxGdJyNUypkQywOPuvIwfF3XYAnMY7KRsOdFl2V2RRPBCASphkW rOpDhj+Gpb907Ly/diofZ01Ivr1pxbF2toqSbn1Ala4Fbx8QWNsaLI9nwliRZjxY99dX y8pjinEdorB52dJzD5KVJJqfspVx8yjtDrOHECabhHuGpHQskYaYgqgFj5Rv34ERjE29 pk/KYo7er8wkOP8RHiQ3GgIK1/8RAGjBQ9cm/h740xa+/J+V+x8tvfgB6zRjya9qMYfk AXGA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a13si16950688pls.101.2019.02.20.02.51.36; Wed, 20 Feb 2019 02:51:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727532AbfBTKvO convert rfc822-to-8bit (ORCPT + 99 others); Wed, 20 Feb 2019 05:51:14 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:38655 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726317AbfBTKvO (ORCPT ); Wed, 20 Feb 2019 05:51:14 -0500 Received: by mail-ot1-f68.google.com with SMTP id m1so39417833otf.5 for ; Wed, 20 Feb 2019 02:51:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qJs1KPGFFnjF6jdTus+S8DJENlhbz+RYILWqzFDWB2c=; b=eREINTYhWlwyoS95ltN8wWSU0h1fobSTM4puYkZgW+9Wqy7heubk0QbPYUqIWgSiXL Ex/R5V4viT0uRJ5gNjNMXGATBGjuxrj6wen51o/bYGML00HBCzNndVCIqjr+oebjiblX gu2MNIMOraWm0f9zjqh/w1pc/CFNHNWGkKkN8zJeeK/r3K3p9MV0o+ebrZq534h+osAV JM9UTDqI7RtYQyXq29sSsb4cP/v4H0cE0jriNPDHdnlERYS2RfTX9fSkxIEbNeu5qlXs 4ETHIs4BLZKKoZnWAmYabekm60PBtszk5WI7FhCbAgCTKVnJz4BD2S3e832AK+IkeGuc 08cg== X-Gm-Message-State: AHQUAuYZVHuZFz/5arxS/V0yS0aBjP35gxxvogWbAn57eOQ2v2s6MPen MVxvKFLxRKFmM/n7tSvMrW4rU4z4ft6fwm0j9ab4gQ== X-Received: by 2002:a9d:7cd3:: with SMTP id r19mr7641414otn.139.1550659872950; Wed, 20 Feb 2019 02:51:12 -0800 (PST) MIME-Version: 1.0 References: <20190216164512.9525-1-mans@mansr.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Wed, 20 Feb 2019 11:51:01 +0100 Message-ID: Subject: Re: [PATCH] platform: set of_node in platform_device_register_full() To: =?UTF-8?B?TcOlbnMgUnVsbGfDpXJk?= Cc: "Rafael J. Wysocki" , Greg Kroah-Hartman , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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?