Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4594464pxb; Tue, 5 Oct 2021 06:29:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIKBVDFDkYRhy4rxOYxE0Bk0tXSrj4wWF0jmDJtSierlbLVBKxj+wexZiuMynFkNZ8l1BI X-Received: by 2002:a17:90a:bd18:: with SMTP id y24mr3893096pjr.83.1633440544020; Tue, 05 Oct 2021 06:29:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633440544; cv=none; d=google.com; s=arc-20160816; b=dCObAn84BiwaJMYLn6EPXr8HF/gjwstuI7NMyBwRxSb8zfgPwMMn+kI8OANKvrFgsY qFQTiwYZHj8LAVhz/M/r5kV0J20u6R98g/XD6ZM26hMY3huZB3o1GHQCWQQHGVynqMJi vH4GOXlT4kRRty6uvgaLb5wy49qMtL4QWkvRLNvfzfaujy6Zz7igCq0GQ1gun+ks3zWU 51vwgZqj0RQL+llFC5WuAZwPbTqzjLEV71OUO7vwPaHanM3iqI0lXEVx1/iYkFyWppBb jFff8LOafzGUyQ2b/2lCwiqQEFtly2DtBeWp9D8ovXrz0mchAaNr4ioxfweKtRPwcJ32 OLeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=LXlRqcN3gs7VJvVDJOIexOqIGX+OiCx/sN+A1VmXpJw=; b=So7OPowbLn3/gKblfNFyt+jTzgPquzZs0X/d9kLzu3bytkrPfkec1yG4rgS0hy/uRZ YKRNI9t+DpUgJiEXLJNMWDMl2qsr9Nk3o+Nja54qca59mxgnyg2KlgSpzls8DizTSJyK d4x2XamGyqLN4YSpAPmWHGkn0f1bzcaiG2n8yDexlnmWa9FkCuHmyIEpuycgdJyoYBCT 4freqgfoGUcpckZ5+5ImRrH51ZFxScqBEp9K1Ri7czN/lh6oRIIRvuztbYAqkICnf8wE zM8gJfSNAlJcewop0Qf0qq1t1vnDseXU2oupBs1uCq2nbOvpTi/UIh5Ec0zqlyGZPFYh /S/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OSXc2LRU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id e3si4651299plj.442.2021.10.05.06.28.48; Tue, 05 Oct 2021 06:29:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OSXc2LRU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S234959AbhJEN3c (ORCPT + 99 others); Tue, 5 Oct 2021 09:29:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:49240 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234950AbhJEN3c (ORCPT ); Tue, 5 Oct 2021 09:29:32 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5EE5E61251; Tue, 5 Oct 2021 13:27:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633440461; bh=MOH/wIgGZg6o0CoLkFJQmfzWGtCwlnQSYLFTb25uQlE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=OSXc2LRUI4jwymWNkorUMTx3IFqUVd8nGbunxnV4tDHJIzKX/UmPIEKW1LZC+dqhg fj4xIOWMU+FrFQnf8liB/iuwu8aPd7Ebrrqu/+/2D/tbDLdnBGDQ/iLWqGIAIoGQAj dhBY9itF4VbZYAQV87Cj+YGui9E4aYT6LvtQz6cibckn3yYskVxxMsYwLpKQR/WjQc 540JNRJwmIx/zi16917RkiXb4UjmQs9RGD25YrwBNJNfICyVjI6Ft639964CpbVSWz bVZ1dR7Px+wZgFhhrlNWlWiWIfgXYUpOMu2wzqtoHCp+OF7MmyAhxPBvxmLK2ItSIe 8awC367gFY1fA== Received: by mail-qt1-f182.google.com with SMTP id r16so19001491qtw.11; Tue, 05 Oct 2021 06:27:41 -0700 (PDT) X-Gm-Message-State: AOAM533VO+z33Rj879OrOmE79gktQMMahsUdD6RlY6hQ+e+QHcvzNwAI Yt5ceVXUkdh88ILyETbdjevklsaVtnXakY5bfw== X-Received: by 2002:ac8:1090:: with SMTP id a16mr19819375qtj.297.1633440459286; Tue, 05 Oct 2021 06:27:39 -0700 (PDT) MIME-Version: 1.0 References: <20210926145931.14603-1-sergio.paracuellos@gmail.com> <20210926145931.14603-3-sergio.paracuellos@gmail.com> In-Reply-To: From: Rob Herring Date: Tue, 5 Oct 2021 08:27:25 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/3] dt: bindings: add ralink RT2880 resets device tree binding documentation To: Sergio Paracuellos Cc: linux-staging@lists.linux.dev, John Crispin , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Greg KH , NeilBrown , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 4, 2021 at 1:23 PM Sergio Paracuellos wrote: > > Hi Rob, > > On Mon, Oct 4, 2021 at 8:06 PM Rob Herring wrote: > > > > On Sun, Sep 26, 2021 at 04:59:30PM +0200, Sergio Paracuellos wrote: > > > Adds device tree binding documentation for resets in the ralink RT2880 SoCs. > > > > > > Signed-off-by: Sergio Paracuellos > > > --- > > > .../bindings/reset/ralink,rt2880-reset.yaml | 39 +++++++++++++++++++ > > > 1 file changed, 39 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/reset/ralink,rt2880-reset.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/reset/ralink,rt2880-reset.yaml b/Documentation/devicetree/bindings/reset/ralink,rt2880-reset.yaml > > > new file mode 100644 > > > index 000000000000..88eddeb4ee45 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/reset/ralink,rt2880-reset.yaml > > > @@ -0,0 +1,39 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/reset/ralink,rt2880-reset.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Ralink RT2880 Reset Controller Device Tree Bindings > > > + > > > +maintainers: > > > + - Sergio Paracuellos > > > + > > > +description: | > > > + Ralink RT2880 reset controller driver which supports the SoC > > > + system controller supplied reset registers for the various peripherals > > > + of the SoC. > > > + > > > + See also: > > > + - dt-bindings/reset/ralink-rt2880.h > > > + > > > +properties: > > > + compatible: > > > + const: ralink,rt2880-reset > > > + > > > + '#reset-cells': > > > + const: 1 > > > + > > > +required: > > > + - '#reset-cells' > > > + - compatible > > > + > > > +additionalProperties: false > > > + > > > +examples: > > > + - | > > > + #include > > > + rstctrl: reset-controller { > > > + compatible = "ralink,rt2880-reset"; > > > + #reset-cells = <1>; > > > > How is this h/w controlled? If this is part of a system controller, then > > it needs to be documented as such. IOW, you need to document the binding > > for the whole block. > > > > Do you really need a child node here? All you need to make a system > > controller a reset provider is add '#reset-cells' to it. > > I am just documenting what is already mainlined (see [0]) in order to > get mt7621-dts out of staging at some point of my life. What am I > supposed to do? Should I rewrite all already mainlined code? Because > if that is the case we need to rewrite tons of things from the ralink > platform... On the flip side, am I not supposed to review bindings because the dts is already in staging? Code dependent on DT bindings shouldn't have been mainlined without any documented binding. Looks like the resets are part of "mediatek,mt7621-sysc" to answer my question. Add a #reset-cell to that node (and binding) and then change this line to "mediatek,mt7621-sysc": reset_dev.of_node = of_find_compatible_node(NULL, NULL, "ralink,rt2880-reset"); That's the minimal change, but really I would move the reset code to the clock driver as that is what handles the sysc node. > I'd also like to know what we should do with those nodes already added > to the dtsi file that have not got associated compatible driver > mainlined. Can we just get rid of them? Yes. Typically dts files start with minimal support. A dts file in staging is odd. We shouldn't be adding them there. Rob