lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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