[<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