Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp41671imp; Wed, 20 Feb 2019 13:51:04 -0800 (PST) X-Google-Smtp-Source: AHgI3IYTExmb9czTeyDJ0XQL2g0pgqvmhfWFnc1lbHEjNq+4mXEHu4hxtkgNFNR0FdFqYMxOhMM/ X-Received: by 2002:a17:902:bd0a:: with SMTP id p10mr37968423pls.322.1550699464166; Wed, 20 Feb 2019 13:51:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550699464; cv=none; d=google.com; s=arc-20160816; b=aLLEoeZLkNlwjTVEni99bFgM4GqbsIjHlm40iwDjt9meUj3br50clnCwKvZtRleuyr PYe2ONruPrdFDFVyWnLFZvyw6eTkHbW3Lbz/Usd3m6/B4uAwbYJNW3U/Cs70VlIjSNM+ 53UTKUwZzzR/SaBZV8bzA3EzAyTQDowfe+KqODiB65prWkcd0c+supIJpqjVmg5YYqIX HREyuwX1SnGLFjHEBrWLkxPqHhZCeaNmY56vEdad/WkXkW4oqIk699c2DhAWUG8uauj4 jD9Y3URdsLFuSKPbwDpbsL6A7ChrxbBsZAarDS4pJGkSvMeLipWZ7WGq/pvhAWtRtsnP TSEg== 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=swm+z3gC0u60slwPeHSUMQ873yrgcaFctOgaFmrQ9hI=; b=cgg6hq/E2Npd+Sr8xYrLDtqy69qfEN8CmarSSlVtnn7VPcJz5dHJKXmeDbygVE1O60 vs9gkLANn6JNScIcTnzSqkuMk/dxQEAaGNpmASSFeyzqcW3DgGpOvErSX5UuqBkwUN1s 3lHsjsab1KnqPPq/N6KwLhgaxiJF39U5cyqCl7FOo7qC5M/NX+m4xPBYJs0f0yoR1IFm 8Cj4wPQ5z8UBdxK4uVDrjWL33ALhZC7D0BXt14Ba03bkZKFALT/S7pz/q1m3WiLPTbTV u7JudsDN5+8uWne7d0ICmIZvicwrPe2trxNEA++iiuX5FJo56VIXtB/HiYftOcswo0pC D/tw== 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 y24si17100213pgf.555.2019.02.20.13.50.48; Wed, 20 Feb 2019 13:51:04 -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 S1726363AbfBTVuM convert rfc822-to-8bit (ORCPT + 99 others); Wed, 20 Feb 2019 16:50:12 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:43206 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725869AbfBTVuM (ORCPT ); Wed, 20 Feb 2019 16:50:12 -0500 Received: by mail-ot1-f68.google.com with SMTP id n71so42824571ota.10 for ; Wed, 20 Feb 2019 13:50:11 -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=Qt/JjFPGTIgip7nwHCwFSU4hARZBSGfjL/+6z7+lSC4=; b=BMLOzd152GeivXtWWIxvT07w0jmp5DfUSu+sTob/YaEXBPe+itPaK0O7MNKEfbSrXs i+0A446ZFMSkLqoCxTShBJp/WEEWBBIo7j7g6AWpy3XteiykK3zBZWQbTxyhuYmp0lrA MvkWS39+QYOXEyZcf0h2nc9npEcIc/EdU5gaHJfy2fxrJzE+qhmczYqqRoLMoFsn21Up Ua2J9PRFelNbYNogRExtSmdUCPFh2ZfQkeruAMOWPGIfHwocNHmtjJcw8xGWh3cihWVF daSjJDJcse3PUpjJGUd8SKkTbkrh8TSEgx60ajCiogp+0cSqvKDZdJlxBc7FAvOlcf8Y GIFQ== X-Gm-Message-State: AHQUAuYUDL6aHHgL2GkPJ6FlXT0409bbl1ZcPBuswplGj2iuPyc9NqDi NmVhmbyN35PSz9QMZ0BQN9gPdDtDRii15S64zcU= X-Received: by 2002:a9d:5a0b:: with SMTP id v11mr21097092oth.124.1550699411168; Wed, 20 Feb 2019 13:50:11 -0800 (PST) MIME-Version: 1.0 References: <20190216164512.9525-1-mans@mansr.com> <20190220113506.11009-1-mans@mansr.com> <20190220115117.GK4072@localhost> In-Reply-To: From: "Rafael J. Wysocki" Date: Wed, 20 Feb 2019 22:50:00 +0100 Message-ID: Subject: Re: [PATCH] platform: set of_node in platform_device_register_full() To: =?UTF-8?B?TcOlbnMgUnVsbGfDpXJk?= Cc: "Rafael J. Wysocki" , Johan Hovold , 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 1:26 PM Måns Rullgård wrote: > > "Rafael J. Wysocki" writes: > > > On Wed, Feb 20, 2019 at 1:12 PM Måns Rullgård wrote: > >> > >> Johan Hovold writes: > >> > >> > On Wed, Feb 20, 2019 at 11:35:06AM +0000, Mans Rullgard wrote: > >> >> If the provided fwnode is an OF node, set dev.of_node as well. > >> >> > >> >> 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 these > >> >> cases, the glue device needs to get a reference to the original DT node > >> >> in order for the main driver to access properties and child nodes. > >> >> > >> >> For example, the sunxi-musb driver creates such a glue device using > >> >> platform_device_register_full(). Consequently, devices attached to > >> >> this USB interface don't get associated with DT nodes, if present, > >> >> the way they do with EHCI. > >> >> > >> >> This change will allow sunxi-musb and similar driver to easily > >> >> propagate the DT node to child devices as required. > >> > > >> > Just a drive-by comment, didn't look to closely at this patch, but this > >> > all sounds familiar. > >> > > >> > Note that if both platform devices are bound to drivers you may end up > >> > with some resources like pinctrl which are handled automatically by > >> > driver core at probe time to be requested twice (and failing the second > >> > time). > >> > > >> > Take a look at 4e75e1d7dac9 ("driver core: add helper to reuse a > >> > device-tree node"), which provides a means to avoid this, and > >> > 49484abd93ab ("USB: musb: dsps: propagate device-tree node"). > >> > >> Thanks, and ugh. So we should be setting the of_node_reused flag when > >> this is the case. It's easy for the musb-dsps driver since it doesn't > >> use platform_device_register_full() and can do this before the > >> device_add() call. How can we convey that this flag needs to be set? > > > > Through pdevinfo I guess? > > Not without adding another field to it. The most direct is of course to > simply add an of_node_reused flag there too and copy it over. Would > that be OK, or is there a better way? That's what I meant. :-)