[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221102212645.GA459441-robh@kernel.org>
Date: Wed, 2 Nov 2022 16:26:45 -0500
From: Rob Herring <robh@...nel.org>
To: Andrew Davis <afd@...com>
Cc: Lee Jones <lee@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
Linus Walleij <linus.walleij@...aro.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Daniel Tang <dt.tangr@...il.com>,
Fabian Vogt <fabian@...ter-vogt.de>,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/9] dt-bindings: mfd: Add TI-Nspire misc registers
On Wed, Nov 02, 2022 at 02:05:28PM -0500, Andrew Davis wrote:
> On 11/2/22 12:35 PM, Rob Herring wrote:
> > On Tue, Nov 01, 2022 at 04:57:56PM -0500, Andrew Davis wrote:
> > > The TI Nspire devices contain a set of registers with a seemingly
> > > miscellaneous set of functionality. This area is known simply as the
> > > "misc" region.
> > >
> > > Signed-off-by: Andrew Davis <afd@...com>
> > > ---
> > > .../bindings/mfd/ti,nspire-misc.yaml | 55 +++++++++++++++++++
> > > 1 file changed, 55 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml b/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml
> > > new file mode 100644
> > > index 0000000000000..d409eae7537bd
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml
> > > @@ -0,0 +1,55 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/mfd/ti,nspire-misc.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: TI Nspire MISC hardware block
> > > +
> > > +maintainers:
> > > + - Andrew Davis <afd@...com>
> > > +
> > > +description: |
> > > + System controller node represents a register region containing a set
> > > + of miscellaneous registers. The registers are not cohesive enough to
> > > + represent as any specific type of device. The typical use-case is
> > > + for some other node's driver, or platform-specific code, to acquire
> > > + a reference to the syscon node (e.g. by phandle, node path, or
> > > + search using a specific compatible value), interrogate the node (or
> > > + associated OS driver) to determine the location of the registers,
> > > + and access the registers directly.
> >
> > Looks like you copied the generic description? Describe what MISC
> > contains.
> >
>
> I don't know what all MISC contains (or maybe I do, but it is not
> publicly available so I'm not going to add anything that hasn't
> already been found by clean-room reverse engineering [0]).
Put whatever you are comfortable with, but not a duplicate generic
description. You know it at least it has reboot registers...
> This is the point I was trying to make in that thread on v3. The
> node's content *is* the hardware description. Every time a new
> register is found it could have just been added to the DT. But now
> we also have to go back here and add the exact same information
> to the binding, every time. We don't require that for simple-bus,
> should simple-mfd be given the same flexibility?
The thing with any MFD is it makes up a device even if it's 'simple', so
it's important to get a full picture of the device. It could evolve to
not being 'simple'.
For example, if you came along and wanted to make it a clock provider,
you'd probably create a clock child node that's just a compatible and
'#clock-cells'. The feedback would be just add '#clock-cells' to the
'ti,nspire-misc' node. So yes, I want to see additions.
Rob
Powered by blists - more mailing lists