linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Cc: linux-staging@lists.linux.dev, John Crispin <john@phrozen.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>, NeilBrown <neil@brown.name>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] dt: bindings: add ralink RT2880 resets device tree binding documentation
Date: Tue, 5 Oct 2021 08:27:25 -0500	[thread overview]
Message-ID: <CAL_Jsq+U_0JnCoJVaHH0T+kdmxX_OosD9=OT0dWyNdwbe=CLoQ@mail.gmail.com> (raw)
In-Reply-To: <CAMhs-H9TDEWEffDn7hBQxT127RNU4eUtPxaSciuiis0fPqTN_w@mail.gmail.com>

On Mon, Oct 4, 2021 at 1:23 PM Sergio Paracuellos
<sergio.paracuellos@gmail.com> wrote:
>
> Hi Rob,
>
> On Mon, Oct 4, 2021 at 8:06 PM Rob Herring <robh@kernel.org> 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 <sergio.paracuellos@gmail.com>
> > > ---
> > >  .../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 <sergio.paracuellos@gmail.com>
> > > +
> > > +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 <dt-bindings/reset/ralink-rt2880.h>
> > > +    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

  reply	other threads:[~2021-10-05 13:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-26 14:59 [PATCH 0/3] staging: mt7621-dts: complete reset missing stuff Sergio Paracuellos
2021-09-26 14:59 ` [PATCH 1/3] dt-bindings: reset: add dt binding header for ralink RT2880 resets Sergio Paracuellos
2021-10-04 18:02   ` Rob Herring
2021-10-04 18:26     ` Sergio Paracuellos
2021-10-05 13:29       ` Rob Herring
2021-10-05 14:28         ` Sergio Paracuellos
2021-09-26 14:59 ` [PATCH 2/3] dt: bindings: add ralink RT2880 resets device tree binding documentation Sergio Paracuellos
2021-10-04 18:06   ` Rob Herring
2021-10-04 18:23     ` Sergio Paracuellos
2021-10-05 13:27       ` Rob Herring [this message]
2021-10-05 14:24         ` Sergio Paracuellos
2021-09-26 14:59 ` [PATCH 3/3] staging: mt7621-dts: align resets with " Sergio Paracuellos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAL_Jsq+U_0JnCoJVaHH0T+kdmxX_OosD9=OT0dWyNdwbe=CLoQ@mail.gmail.com' \
    --to=robh@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=john@phrozen.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=neil@brown.name \
    --cc=sergio.paracuellos@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).