netdev - Re: [PATCH net-next 1/3] dt-bindings: net: add dt bindings for marvell10g driver

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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL_JsqKPR7XpTZ=Sc=0OdD=b64xssE3F=QvpZs_NvQdBkuJLBQ@mail.gmail.com>
Date:   Thu, 27 Feb 2020 14:11:02 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        devicetree@...r.kernel.org, Jason Cooper <jason@...edaemon.net>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        Mark Rutland <mark.rutland@....com>,
        netdev <netdev@...r.kernel.org>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Subject: Re: [PATCH net-next 1/3] dt-bindings: net: add dt bindings for
 marvell10g driver

On Thu, Feb 27, 2020 at 11:36 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> > > > +    allOf:
> > > > +      - $ref: /schemas/types.yaml#/definitions/uint16-array
> > > > +      - minItems: 1
> > > > +        maxItems: 4
> > > > +
> > > > +examples:
> > > > +  - |
> > > > +    ethernet-phy@0 {
> > > > +        reg = <0>;
> > >
> > > This needs to be under an 'mdio' node with #address-cells and
> > > #size-cells set correctly.
> >
> > I wish these things were documented somewhere... I'm pretty sure this
> > passed validation when I wrote it.
>
> Documentation/devicetree/bindings/net/mdio.yaml
>
> Rob, is there a way to express the hierarchy between yaml files and
> properties? Can we say that a phy, as defined by ethernet-phy.yaml
> should always be inside an MDIO bus as defined in mdio.yaml?

We can link a child schema into a parent schema, but not the other way
around. So you can do something like this in mdio.yaml:

  "^ethernet-phy@[0-9a-f]+$":
    type: object
    allOf:
      - $ref: ethernet-phy.yaml#

That happens to work in this case since there's a common compatible
string for ethernet phys, but doesn't scale in the general case. Note
that ethernet-phy.yaml would need a couple of changes too. Also, this
should also be expanded to other possible node names like 'switch'.

I've had some thoughts of defining a pseudo property '$parent' or
something to be able to express constraints such as to what bus a
device has to be on. Currently, we rely on the overlap of the bus
schemas checking the bus specific aspects of the bus child nodes. I'm
also not really convinced that putting say an I2C device under a SPI
bus node is a problem we need to check for.

I'm not sure how any of this would help on examples compiling and
validating correctly. In example-schema.yaml, it mentions all the
problems I see: dtc fails, validation fails, bus node requirements,
and include file requirements:

  # Examples are now compiled with dtc and validated against the schemas
  #
  # Examples have a default #address-cells and #size-cells value of 1. This can
  # be overridden or an appropriate parent bus node should be shown (such as on
  # i2c buses).
  #
  # Any includes used have to be explicitly included.

Rob