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]
Date:   Mon, 1 Aug 2022 08:26:30 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     netdev <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Oleksij Rempel <linux@...pel-privat.de>,
        Christian Marangi <ansuelsmth@...il.com>,
        John Crispin <john@...ozen.org>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Mans Rullgard <mans@...sr.com>,
        Arun Ramadoss <arun.ramadoss@...rochip.com>,
        Woojung Huh <woojung.huh@...rochip.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        George McCollister <george.mccollister@...il.com>,
        DENG Qingfang <dqfext@...il.com>,
        Sean Wang <sean.wang@...iatek.com>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Aleksander Jan Bajkowski <olek2@...pl>,
        Alvin Šipraga <alsi@...g-olufsen.dk>,
        Luiz Angelo Daros de Luca <luizluca@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Pawel Dembicki <paweldembicki@...il.com>,
        Clément Léger <clement.leger@...tlin.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Marek Behún <kabel@...nel.org>,
        Marcin Wojtas <mw@...ihalf.com>,
        Frank Rowand <frowand.list@...il.com>
Subject: Re: [PATCH v2 net-next 4/4] net: dsa: validate that DT nodes of
 shared ports have the properties they need

On Mon, Aug 1, 2022 at 8:11 AM Vladimir Oltean <vladimir.oltean@....com> wrote:
>
> On Mon, Aug 01, 2022 at 08:02:56AM -0600, Rob Herring wrote:
> > > +if:
> > > +  oneOf:
> > > +    - properties:
> > > +        ethernet:
> > > +          items:
> > > +            $ref: /schemas/types.yaml#/definitions/phandle
> > > +    - properties:
> > > +        link:
> > > +          items:
> > > +            $ref: /schemas/types.yaml#/definitions/phandle-array
> >
> > 'items' here is wrong. 'required' is needed because the property not
> > present will be true otherwise.
> >
> > Checking the type is redundant given the top-level schema already does that.
>
> Excuse me, but I don't understand. I verified this and it works as
> expected - if the property is present, the 'items' evaluates to true,
> otherwise to false.

The main schema has:

link:
  $ref: /schemas/types.yaml#/definitions/phandle-array

Both with and without 'items' can't be correct.

> Could you suggest an alternative way of checking whether the 'ethernet'
> or 'link' properties are present, as part of a conditional?

if:
  oneOf:
    - required: [ ethernet ]
    - required: [ link ]

'required' here doesn't mean the property is required, but is simply
true if the property is present and false if not present.


> > > I have deliberately made this part of dsa-port.yaml and not depend on
> > > any compatible string. The reason is the code - we'll warn about missing
> > > properties regardless of whether we have fallback logic for some older
> > > switches. Essentially the fact that some switches have the fallback to
> > > not use phylink will remain an undocumented easter egg as far as the
> > > dt-schema is concerned.
> >
> > dsa-port.yaml is only applied when some other schema references it
> > which is probably based on some compatible. If you want to apply this
> > under some other condition, then you need a custom 'select' schema to
> > define when.
>
> No, this is good, I think. I got a "build warning" from your bot which
> found the DSA examples which had missing required properties, so I think
> it works the way I indended it.

Okay, I was thinking you wanted to check cases that didn't yet have a
schema for the specific device.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ