[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200713144421.GA149051@bogus>
Date: Mon, 13 Jul 2020 08:44:21 -0600
From: Rob Herring <robh@...nel.org>
To: Kurt Kanzenbach <kurt@...utronix.de>
Cc: Florian Fainelli <f.fainelli@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
devicetree@...r.kernel.org,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Richard Cochran <richardcochran@...il.com>,
Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
ilias.apalodimas@...aro.org, Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH v1 8/8] dt-bindings: net: dsa: Add documentation for
Hellcreek switches
On Mon, Jul 13, 2020 at 08:45:33AM +0200, Kurt Kanzenbach wrote:
> On Sat Jul 11 2020, Florian Fainelli wrote:
> > On 7/10/2020 4:36 AM, Kurt Kanzenbach wrote:
> >> Add basic documentation and example.
> >>
> >> Signed-off-by: Kurt Kanzenbach <kurt@...utronix.de>
> >> ---
> >> .../bindings/net/dsa/hellcreek.yaml | 132 ++++++++++++++++++
> >> 1 file changed, 132 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/net/dsa/hellcreek.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/dsa/hellcreek.yaml b/Documentation/devicetree/bindings/net/dsa/hellcreek.yaml
> >> new file mode 100644
> >> index 000000000000..bb8ccc1762c8
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/net/dsa/hellcreek.yaml
> >> @@ -0,0 +1,132 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/net/dsa/hellcreek.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Hirschmann Hellcreek TSN Switch Device Tree Bindings
> >> +
> >> +allOf:
> >> + - $ref: dsa.yaml#
> >> +
> >> +maintainers:
> >> + - Andrew Lunn <andrew@...n.ch>
> >> + - Florian Fainelli <f.fainelli@...il.com>
> >> + - Vivien Didelot <vivien.didelot@...il.com>
> >
> > Don't you want to add yourself here as well?
>
> Sure.
>
> >
> >> +
> >> +description:
> >> + The Hellcreek TSN Switch IP is a 802.1Q Ethernet compliant switch. It supports
> >> + the Pricision Time Protocol, Hardware Timestamping as well the Time Aware
>
> s/Pricision/Precision/g;
>
> >> + Shaper.
> >> +
> >> +properties:
> >> + compatible:
> >> + oneOf:
> >> + - const: hirschmann,hellcreek
> >> +
> >> + reg:
> >> + description:
> >> + The physical base address and size of TSN and PTP memory base
> >
> > You need to indicate how many of these cells are required.
>
> Yes.
>
> >
> >> +
> >> + reg-names:
> >> + description:
> >> + Names of the physical base addresses
> >
> > Likewise.
> >
> >> +
> >> + '#address-cells':
> >> + const: 1
> >> +
> >> + '#size-cells':
> >> + const: 1
> >
> > Humm, not sure about those, you do not expose a memory mapped interface
> > bus from this switch to another sub node.
>
> True. That might be even different for other SoCs.
>
> >
> >> +
> >> + leds:
> >> + type: object
> >> + properties:
> >> + '#address-cells':
> >> + const: 1
> >> + '#size-cells':
> >> + const: 0
> >> +
> >> + patternProperties:
> >> + "^led@[0-9]+$":
> >> + type: object
> >> + description: Hellcreek leds
> >> +
> >> + properties:
> >> + reg:
> >> + items:
> >> + - enum: [0, 1]
> >> + description: Led number
> >> +
> >> + label:
> >> + description: Label associated with this led
> >> + $ref: /schemas/types.yaml#/definitions/string
> >> +
> >> + default-state:
> >> + items:
> >> + enum: ["on", "off", "keep"]
> >> + description: Default state for the led
> >> + $ref: /schemas/types.yaml#/definitions/string
> >> +
> >> + required:
> >> + - reg
> >
> > Can you reference an existing LED binding by any chance?
>
> Yes, we should reference leds/common.yaml somehow. Looking at
> leds-gpio.yaml for example, it should be possible like this:
>
> patternProperties:
> "^led@[0-9]+$":
> type: object
> description: Hellcreek leds
>
> $ref: ../../leds/common.yaml#
>
> [...]
>
> But, how to express that only label and default-state should be used?
properties:
label: true
default-state: true
additionalProperties: false
Powered by blists - more mailing lists