mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Davis <afd@ti.com>
To: Rob Herring <robh@kernel.org>
Cc: Lee Jones <lee@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Linus Walleij <linus.walleij@linaro.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Daniel Tang <dt.tangr@gmail.com>,
	Fabian Vogt <fabian@ritter-vogt.de>, <devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/9] dt-bindings: mfd: Add TI-Nspire misc registers
Date: Wed, 2 Nov 2022 20:13:44 -0500	[thread overview]
Message-ID: <904b42ea-0655-2fae-98d6-17429533de2e@ti.com> (raw)
In-Reply-To: <20221102212645.GA459441-robh@kernel.org>

On 11/2/22 4:26 PM, Rob Herring wrote:
> 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@ti.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@ti.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'.
> 

It would not evolve as a generic simple-mfd binding would not allow
any extra non-node properties.

'^.*$':
   type: object
additionalProperties: false

Maybe I'm thinking about this group of registers wrong, maybe it
is a simple-bus not a simple-mfd. I mean from software what else
is a bus but a space of addressable registers.. The issue would
be each child node of a simple-bus needs a unit-address and 'reg'.
Which we *could* do here if not for all this syscon weirdness :(

> 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.
> 

And then that would still fail the dtbs_check, since the simple-mfd binding
would only allow for child nodes, nothing else, that's what makes them "simple".
Each child node would need a compatible and therefor a binding. You would
still see everything and could prevent malformed nodes just the same.

Andrew

  reply	other threads:[~2022-11-03  1:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-01 21:57 [PATCH v4 0/9] TI-Nspire cleanups Andrew Davis
2022-11-01 21:57 ` [PATCH v4 1/9] dt-bindings: mfd: Add TI-Nspire misc registers Andrew Davis
2022-11-02 17:35   ` Rob Herring
2022-11-02 19:05     ` Andrew Davis
2022-11-02 21:26       ` Rob Herring
2022-11-03  1:13         ` Andrew Davis [this message]
2022-11-01 21:57 ` [PATCH v4 2/9] ARM: dts: nspire: Use syscon-reboot to handle restart Andrew Davis
2022-11-01 21:57 ` [PATCH v4 3/9] ARM: dts: nspire: Fix cpu node to conform with DT binding Andrew Davis
2022-11-01 21:57 ` [PATCH v4 4/9] ARM: dts: nspire: Fix sram " Andrew Davis
2022-11-01 21:58 ` [PATCH v4 5/9] ARM: dts: nspire: Fix vbus_reg " Andrew Davis
2022-11-01 21:58 ` [PATCH v4 6/9] ARM: dts: nspire: Fix uart " Andrew Davis
2022-11-01 21:58 ` [PATCH v4 7/9] ARM: dts: nspire: Use MATRIX_KEY macro for linux,keymap Andrew Davis
2022-11-03  4:07   ` Dmitry Torokhov
2022-11-03 16:29     ` Andrew Davis
2022-11-01 21:58 ` [PATCH v4 8/9] ARM: nspire: Use syscon-reboot to handle restart Andrew Davis
2022-11-01 21:58 ` [PATCH v4 9/9] ARM: nspire: Remove unused header file mmio.h Andrew Davis
2022-11-02 12:42 ` [PATCH v4 0/9] TI-Nspire cleanups Arnd Bergmann

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=904b42ea-0655-2fae-98d6-17429533de2e@ti.com \
    --to=afd@ti.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dt.tangr@gmail.com \
    --cc=fabian@ritter-vogt.de \
    --cc=geert+renesas@glider.be \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    /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

all inboxes | Powered by JetHome®