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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdb-4GPnVegc+OqyPaZN2rNCkgmNL4qjf-LGnnz27+EBbg@mail.gmail.com>
Date:   Wed, 25 Oct 2023 21:48:18 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Pali Rohár <pali@...nel.org>,
        Enrico Mioso <mrkiko.rs@...il.com>,
        Robert Marko <robert.marko@...tura.hr>,
        Russell King <linux@...linux.org.uk>,
        Chris Packham <chris.packham@...iedtelesis.co.nz>,
        Andrew Lunn <andrew@...n.ch>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Marek Behún <kabel@...nel.org>,
        Christian Marangi <ansuelsmth@...il.com>,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v7 5/7] ARM64: dts: marvell: Fix some common
 switch mistakes

Hi Vladimir,

thanks for paging in the right maintainers to look at the respective boards,
much appreciated!

On Tue, Oct 24, 2023 at 8:28 PM Vladimir Oltean <olteanv@...il.com> wrote:

> I looked at U-Boot's ft_board_setup() from board/Marvell/mvebu_armada-37xx/board.c
> and it doesn't appear to do anything with the switch. But after the MOX precedent
> (which is _still_ problematic, more below), I still think we are way too
> trigger-happy with this, and it would be good to ask someone who has the
> Espressobin to test.

Yeah that would be great.

> > -     /* switch nodes are enabled by U-Boot if modules are present */
> > +     /*
> > +      * NOTE: switch nodes are enabled by U-Boot if modules are present
> > +      * DO NOT change this node name (switch0@10) even if it is not following
> > +      * conventions! Deployed U-Boot binaries are explicitly looking for
> > +      * this node in order to augment the device tree!
> > +      */
>
> Not "this node", but all switch nodes!
(...)
> It's funny that you add a comment TO NOT rename switch nodes, then you
> proceed to do just that.

Yeah it's a stupid mistake on my behalf. :( too sleepy or something.

I fixed it up, and put a small comment above each of them not
to change the node name.

> > -             ports {
> > +             ethernet-ports {
>
> U-Boot code does this, so you can't rename "ports":
>
>         /*
>          * now if there are more switches or a SFP module coming after,
>          * enable corresponding ports
>          */
>         if (id < peridot + topaz - 1) {
>                 res = fdt_status_okay_by_pathf(blob,
>                                                "%s/switch%i@...ports/port@a",
>                                                mdio_path, id, addr);
>         } else if (id == peridot - 1 && !topaz && sfp) {
>                 res = fdt_status_okay_by_pathf(blob,
>                                                "%s/switch%i@...ports/port-sfp@a",
>                                                mdio_path, id, addr);
>         } else {
>                 res = 0;
>         }
>
> >                       #address-cells = <1>;
> >                       #size-cells = <0>;
> >
> > -                     port@1 {
> > +                     ethernet-port@1 {
>
> or "port@.*", or "port-sfp@a", for the same reason. Here and everywhere
> in this device tree. Basically only the ethernet-phy rename seems safe.

Fair, reverted it all.

> Having that said, we need to suppress these warnings for the Marvell
> schema only:
>
> arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dtb: switch0@10: $nodename:0: 'switch0@10' does not match '^(ethernet-)?switch(@.*)?$'
>         from schema $id: http://devicetree.org/schemas/net/dsa/marvell,mv88e6xxx.yaml#
> arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dtb: ethernet-switch@12: ethernet-ports: 'port-sfp@a' does not match any of the regexes: '^(ethernet-)?port@[0-9]+$', 'pinctrl-[0-9]+'
>         from schema $id: http://devicetree.org/schemas/net/dsa/marvell,mv88e6xxx.yaml#
>
> because someone _will_ fix them and break the boot in the process.

Really? I think you will stop them from doing that every single time ;)

Jokes aside, we certainly need a way to suppress this warning.

> Rob, Krzysztof, Conor, do you have any suggestion on how to achieve that?

What we can do easily is to override the $nodename requirement for
a certain compatible with one of those - if: constructions, but that would
unfortunately make us be lax on every other board as well.

What we want to achieve is:

1. Match on the top level compatible (under '/') with contains: const:
cznic,turris-mox

2. Then relax requirements on the switch nodes if that is true.

I assume I would have to go into
Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
and put hard requirement on node names from there. I'm not sure
this would work or that it's even possible, or desireable.

But...

We  *COULD* add a second over-specified compatible to the switch
node. Such as:

      switch0@10 {
                compatible = "marvell,turris-mox-mv88e6190-switch",
"marvell,mv88e6190";

(and the same for the 6085 version)

And use that to relax the requirement for that variant with an - if:
statemement.

This should work fine since U-Boot is only looking for nodenames, not
compatible strings. I think I will try this approach.

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ