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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqLyCJE2c4ORx-kK1iUMR08iMUMDi0FMb9WeTyfyzO3GKw@mail.gmail.com>
Date:   Mon, 1 Aug 2022 08:02:56 -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 Sat, Jul 30, 2022 at 10:24 AM Vladimir Oltean
<vladimir.oltean@....com> wrote:
>
> Hi Rob,
>
> On Fri, Jul 29, 2022 at 12:39:06PM -0600, Rob Herring wrote:
> > All valid points. At least for the sea of warnings, you can limit
> > checking to only a subset of schemas you care about. Setting
> > 'DT_SCHEMA_FILES=net/' will only check networking schemas for example.
> > Just need folks to care about those subsets.
> >
> > I'm not saying don't put warnings in the kernel for this. Just don't
> > make it the only source of warnings. Given you are tightening the
> > requirements, it makes sense to have a warning. If it was something
> > entirely new, then I'd be more inclined to say only the schema should
> > check.
>
> How does this look like? It says that if the 'ethernet' property exists
> and is a phandle (i.e. this is a CPU port), or if the 'link' property
> exists and is a phandle-array (i.e. this is a DSA port), then the
> phylink-related properties are mandatory, in the combinations that they
> may appear in.
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
> index 09317e16cb5d..ed828cec90fd 100644
> --- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
> +++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
> @@ -76,6 +76,31 @@ properties:
>  required:
>    - reg
>
> +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.

> +then:
> +  allOf:
> +  - required:
> +    - phy-mode
> +  - oneOf:
> +    - required:
> +      - fixed-link
> +    - required:
> +      - phy-handle
> +    - required:
> +      - managed
> +    - required:
> +      - phy-handle
> +      - managed
> +
>  additionalProperties: true
>
>
> 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.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ