netdev - Re: [PATCH net-next v4 5/7] ARM64: dts: marvell: Fix some common switch mistakes

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]

Date: Thu, 19 Oct 2023 17:26:49 +0200
From: Marek Behún <kabel@...nel.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, 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>, Russell King <linux@...linux.org.uk>, 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>, 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 v4 5/7] ARM64: dts: marvell: Fix some common
 switch mistakes

On Thu, 19 Oct 2023 17:49:35 +0300
Vladimir Oltean <olteanv@...il.com> wrote:

> On Thu, Oct 19, 2023 at 05:40:22PM +0300, Vladimir Oltean wrote:
> > +Marek
> > 
> > On Wed, Oct 18, 2023 at 11:03:44AM +0200, Linus Walleij wrote:  
> > > Fix some errors in the Marvell MV88E6xxx switch descriptions:
> > > - The top node had no address size or cells.
> > > - switch0@0 is not OK, should be switch@0.
> > > 
> > > Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
> > > ---
> > > diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
> > > index 9eab2bb22134..c69cb4e191e5 100644
> > > --- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
> > > +++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
> > > @@ -305,7 +305,7 @@ phy1: ethernet-phy@1 {
> > >  	};
> > >  
> > >  	/* switch nodes are enabled by U-Boot if modules are present */
> > > -	switch0@10 {
> > > +	switch@10 {  
> > 
> > As the comment says: U-Boot
> > (https://elixir.bootlin.com/u-boot/latest/source/board/CZ.NIC/turris_mox/turris_mox.c#L728)
> > sets up status = "okay" for these nodes depending on the MOXTET
> > configuration. It doesn't look as if it's doing that by alias, just by
> > path ("%s/switch%i@%x").
> > 
> > I have a Turris MOX, please allow me some time to test if the node name
> > change is going to be significant and cause regressions. I expect the
> > answer to be yes (sadly).  
> 
> Yeah, it's bad.
> 
> U-Boot 2018.11 (Dec 16 2018 - 12:50:19 +0000), Build: jenkins-turris-os-packages-kittens-mox-90
> 
> DRAM:  1 GiB
> Enabling Armada 3720 wComphy-0: SGMII1        3.125 Gbps
> Comphy-1: PEX0          5 Gbps
> Comphy-2: USB3_HOST0    5 Gbps
> MMC:   sdhci@...00: 0
> Loading Environment from SPI Flash... SF: Detected w25q64dw with page size 256 Bytes, erase size 4 KiB, total 8 MiB
> OK
> Model: CZ.NIC Turris Mox Board
> Net:   eth0: neta@...00
> Turris Mox:
>   Board version: 22
>   RAM size: 1024 MiB
>   SD/eMMC version: SD
> Module Topology:
>    1: Peridot Switch Module (8-port)
>    2: Peridot Switch Module (8-port)
>    3: Peridot Switch Module (8-port)
>    4: SFP Module
> 
> Hit any key to stop autoboot:  0
> => run sd_tftp_boot  
> neta@...00 Waiting for PHY auto negotiation to complete....... done
> BOOTP broadcast 1
> BOOTP broadcast 2
> DHCP client bound to address 10.0.0.117 (254 ms)
> Using neta@...00 device
> TFTP from server 10.0.0.1; our IP address is 10.0.0.117
> Filename 'mox/armada-3720-turris-mox.dtb'.
> Load address: 0x4f00000
> Loading: ####
>          1.5 MiB/s
> done
> Bytes transferred = 19479 (4c17 hex)
> Using neta@...00 device
> TFTP from server 10.0.0.1; our IP address is 10.0.0.117
> Filename 'mox/Image'.
> Load address: 0x5000000
> Loading: #################################################################
>          ##########################################
>          6 MiB/s
> done
> Bytes transferred = 54069760 (3390a00 hex)
> ## Flattened Device Tree blob at 04f00000
>    Booting using the fdt blob at 0x4f00000
>    Loading Device Tree to 000000003bf16000, end 000000003bf1dc16 ... OK
> ERROR: board-specific fdt fixup failed: FDT_ERR_NOTFOUND
>  - must RESET the board to recover.
> 
> FDT creation failed! hanging...### ERROR ### Please RESET the board ###

Yes, unfortunately changing that node name will break booting.

Maybe we could add a comment into the DTS to describe this unfortunate
state of things? :)

Marek