Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2209391yba; Thu, 25 Apr 2019 12:26:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqzxuBkbPUutFflxqd7zDz0/r0GIB+6zqsY7IJhOyDy2eR+QK0hMafNzcHAdW4uN1/AdeqJl X-Received: by 2002:aa7:9151:: with SMTP id 17mr40714168pfi.192.1556220397812; Thu, 25 Apr 2019 12:26:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556220397; cv=none; d=google.com; s=arc-20160816; b=beY2wJ5NiqppCm3e6uYusvl2bl1H/eQ6L99oK8gBeElkVuyNAQRS/CnQUYleZAk9X0 7nfuIZNu/4K0F+WUneNxd0u2FffsPRj3muRif/RnTBc1yAE3Uc4w55IIeYtgmcQpvIpc CbYh9stwwdy8Mefh76UAAPEXe0xR+vvDTN4eJ39LgvCM5tG9MId7UqCTFalnapvDTh+T FLoWJ58MHDpRAru/5bQJCj1tIqahpU5rJDfRWBYQRTUyl+/JyTI/3PXDGGBZjGvFjJcc s7zP4nvZidqOTovq00VsaFla2RaalhrsECJp+MQjZZFxYxT1DpM0nLmsHtJ2xPzv7vYR apxQ== 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=WlxvnPPRAeB6QKDQcuJCsKMtXSMLWsbJIXPOVAwtVVo=; b=ky+R/OrY2EW6V0zcO3ld8wNfxOMIK78+W3ij0eGF4YEp+VJKzL6y/TTQD6DSMN58mI RHMA5VNJorYn+7rtvOAnSAYQMxq2TKG8pns7oCxITg9aJ2BvACjDaQfG2QFjF9dxv/kt RSz98N27oAjr39tGlUcmAdYA0LzAupmgsbvb0iVXyDjXcIJydk29JL60Ak8t3ttcL+1a Y/y1bNNQbuHZc1fYJ0xTk5Blh7xzDJ1e1M+bWQMKpgklWpJ5aE1NMaA3erE/0CAAYqj0 g1CUKnQ9CJDVrJGl8IuDtPt2ZLKWNyNu1kUAHHBpkgxo0ThI9De48dMdUWonCOo30CLD PqwQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Q3bYmxTJ; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j5si23456928pfa.63.2019.04.25.12.26.22; Thu, 25 Apr 2019 12:26:37 -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=@gmail.com header.s=20161025 header.b=Q3bYmxTJ; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730098AbfDYTZQ (ORCPT + 99 others); Thu, 25 Apr 2019 15:25:16 -0400 Received: from mail-it1-f196.google.com ([209.85.166.196]:52459 "EHLO mail-it1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729084AbfDYTY6 (ORCPT ); Thu, 25 Apr 2019 15:24:58 -0400 Received: by mail-it1-f196.google.com with SMTP id x132so2003630itf.2; Thu, 25 Apr 2019 12:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WlxvnPPRAeB6QKDQcuJCsKMtXSMLWsbJIXPOVAwtVVo=; b=Q3bYmxTJ1QnevyIWZD1OHcmDMFAUEh/YHqhTN5q9JJe1zidGKauuA4/sUWzEdcaJWL 9VB5/l3c8Al0KTWLbwJ7jfP+ihGWoxgkDiv2HsxCHBJKRfjVY/ZVR9wh75exP28XUBqN MDAvYEJiXda3D+UCve8t+eXRZXLPjVd7LOdzQ8rtLFAdTF7GI8OVSH/zYzLJTSMA9L1n PnzlBOp+pojYjTeqC9IDDQ99U09WHtkMP/DoEAH+9RCEb8YwBkR7yCffzbndL0NNS/xH GhNf1/L46C4R6GMhcfU84mQJU+KRmlh4QuzQ8lQ9Cu8aD0FMEzZ6ztDi+SAQKLNXqiHK gvMA== 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; bh=WlxvnPPRAeB6QKDQcuJCsKMtXSMLWsbJIXPOVAwtVVo=; b=q7+FZzxsWjuZCvESaruA0Pwt9/mR1fgptIqnePig3DK1Ly8gjyKNB+ublFpsXXWS1z r7twW8GkNm4wfXThUrHWA5F42t63gkxq8mVhvvCWkr7XN+Nrr3d+5+hBhqgn9x/m3CRC NDjBbkQJP8zcrJBRmmcmAj7dxShqiTbXIn+T7d3L0A+WvZ1cymhS4Bei68taPrtmMFqv bwzU/rDPd3a9GtzXcc6e7mISQlLf5oAFXUuY2Rih0koavTAIMx05GHxblaUHJZcffNks e3Kk9Y+d/+5ABTeRo33pBwCakmAZ6Lzsl77FIjFkkZ7FwSGZI90gBq5K48aJEkTkGzvf rL2g== X-Gm-Message-State: APjAAAXm6HeCcmAv6eD9uBfo9V2NrMC7kbxRoSrRM3WEZYzcAQYKZJWf Owm+ZpwUv0DZyGzyzEMydJsNqIpgocmyQjn2Jxw= X-Received: by 2002:a24:e97:: with SMTP id 145mr5131387ite.141.1556220297415; Thu, 25 Apr 2019 12:24:57 -0700 (PDT) MIME-Version: 1.0 References: <20190424101913.1534-1-benjamin.gaignard@st.com> In-Reply-To: From: Dmitry Torokhov Date: Thu, 25 Apr 2019 12:24:46 -0700 Message-ID: Subject: Re: [PATCH 0/5] Add of_ functions for device_link_add() To: Rob Herring Cc: Benjamin Gaignard , "Wysocki, Rafael J" , Mark Rutland , Bastien Nocera , Frank Rowand , Marco Felsch , =?UTF-8?Q?Guido_G=C3=BCnther?= , Yannick Fertre , Arnd Bergmann , Linux Input , DTML , "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 Thu, Apr 25, 2019 at 11:08 AM Rob Herring wrote: > > 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. I am pretty sure there will be more drivers needing complex dependencies. Doesn't ACPI allow defining relationship between devices that goes beyond the tree structure? Thanks. -- Dmitry