Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2174228yba; Thu, 25 Apr 2019 11:52:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqxRmLEm58P08Ys+oceJ+uGjARrqypd2ojJpVvd37jFy2cpQc8X9lW6wFRNPV2Zd591LTvs1 X-Received: by 2002:a63:fd06:: with SMTP id d6mr39146990pgh.183.1556218320896; Thu, 25 Apr 2019 11:52:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556218320; cv=none; d=google.com; s=arc-20160816; b=By4ldGJX6D3StIVboFo4R6webMvNvTwXwh6xMHVWlxl7Cmy6Bg9EaAF1wqC/4eDGpC 8ICilAYnllkT0QuOlZskJ0iwAAodSO8rxjCibRZIPpd2CktvgscdZHZLEshO86TvL8kz jttaVHMP9xQmuQz+RNxSLMiCvmRcAoZEXOdm98q6bgSmnGb0A+4tqM0xQu818tipbloy y2S4nHH9cOuKeKgQE25dwXO5mq24YfaQyiJ5EjGvTJEkeuy1VZ+pgKUise4NlN3J9ZAB wSZRHEq7gSl8EtbRiG0cvCI7iBtCw/QeVihqIVfuq8FRtOkSIgWWJWfAPPFL7QqYUDZi /l8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=mM2waGQCnGKBXmQ+1Cz9C2QAtfI3HncCalnxazu97d8=; b=RIhygqHUK3hb+k4uRZO6Mawm0UICT2lLNmx0NY60qLibtuulCCuFSdFJz1XSchlwKR UzVgbPBq+cTpaYcM6huaVmwEB3L3xT9lUxINo00mf7ublOVQrF+BFi6KqiUWGQdmZkwn XxqJKNRDQcfLciAekEvH1iZYCQrh1Pg98OlWrAhhUAUkiqYEdqERZOjEGPzLFdjxD2du qY3IgWsGep68VclT4cmhaXWZ6NvTS3/RrMHIFN6kacs6TMEpAw0pSYe2R1ysCU2GnMi0 aQ/NXxe33XOQB1FrFBFByKf0M+2twfKbze+M8hDncPmJw9EDx+kjxG8arpmjJLBky1ot pq/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=kNAddwW8; 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=pass (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 g4si22446675plp.196.2019.04.25.11.51.45; Thu, 25 Apr 2019 11:52:00 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=kNAddwW8; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728859AbfDYSIH (ORCPT + 99 others); Thu, 25 Apr 2019 14:08:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:34728 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726006AbfDYSIH (ORCPT ); Thu, 25 Apr 2019 14:08:07 -0400 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 03D5420878; Thu, 25 Apr 2019 18:08:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556215687; bh=mM2waGQCnGKBXmQ+1Cz9C2QAtfI3HncCalnxazu97d8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kNAddwW8q1Zo4qmWmTXMdzjB9qVQamI2E83mvnEkMz6U386rFcbnhefIoqC1RQzFE gCLa5fxpuDiy6WUIuLdva+bLzSpM4K4zlyYBrGMPUlyx25gA7gxYBatTh31unCD9YL lh83aG/+N6qIikGY462bStfU5o7Pf8JEJE9EQrWI= Received: by mail-qt1-f177.google.com with SMTP id g4so1114553qtq.10; Thu, 25 Apr 2019 11:08:06 -0700 (PDT) X-Gm-Message-State: APjAAAVj0iNJYZLfT8VkQXu9O9dQt5JhKrP3lHIewxw6gYiv46UdxCiL D9/sI7pvX9lohgjbYTFONuqJ+rgFln2ZmlNV6w== X-Received: by 2002:ac8:7647:: with SMTP id i7mr31438312qtr.38.1556215685478; Thu, 25 Apr 2019 11:08:05 -0700 (PDT) MIME-Version: 1.0 References: <20190424101913.1534-1-benjamin.gaignard@st.com> In-Reply-To: <20190424101913.1534-1-benjamin.gaignard@st.com> From: Rob Herring Date: Thu, 25 Apr 2019 13:07:53 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/5] Add of_ functions for device_link_add() To: Benjamin Gaignard Cc: "Wysocki, Rafael J" , Dmitry Torokhov , Mark Rutland , Bastien Nocera , Frank Rowand , Marco Felsch , =?UTF-8?Q?Guido_G=C3=BCnther?= , Yannick Fertre , Arnd Bergmann , Linux Input , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , linux-stm32@st-md-mailman.stormreply.com, Mark Brown Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 24, 2019 at 5:19 AM Benjamin Gaignard wrote: > > It could happen that we need to control suspend/resume ordering between > devices without obvious consumer/supplier link. For example when touchscreens > and DSI panels share the same reset line, in this case we need to be sure > of pm_runtime operations ordering between those two devices to correctly > perform reset. > DSI panel and touchscreen aren't sharing any heriachical relationship (unlike > I2C client and I2C bus or regulator client and regulator provider) so we need > to describe this in device-tree. Needing to know which touchscreen is attached to a panel could be important to describe if you have multiple displays. Doesn't the reset subsystem already have some support for shared resets? Seems like it could provide clients with struct device or device_node ptrs to other devices sharing a reset. > > This series introduce of_device_links_{add,remove} and devm_of_device_links_add() > helpers to find and parse 'links-add' property in a device-tree node. Going to document that property somewhere? :) I think this is too generic and coupled to Linux. It doesn't have any information as to what is the dependency or connection nor what the direction of the dependency is. I'm not convinced we need to solve this generically vs. defining something for this specific example. Rob