linux-kernel - Re: [PATCH 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC

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]

Message-ID: <CAF7HswMRrs9hwKo_uHCLMtx7+h46-DPEJRcEqu0-zEG4CVvvjg@mail.gmail.com>
Date: Tue, 30 Dec 2025 09:02:02 +0800
From: Kyle Hsieh <kylehsieh1995@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Joel Stanley <joel@....id.au>, 
	Andrew Jeffery <andrew@...econstruct.com.au>, devicetree@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-aspeed@...ts.ozlabs.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC

On Wed, Dec 24, 2025 at 5:20 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> On Wed, Dec 24, 2025 at 02:40:39PM +0800, Kyle Hsieh wrote:
> > On Tue, Dec 23, 2025 at 6:35 PM Andrew Lunn <andrew@...n.ch> wrote:
> > >
> > > > > What make/model of switch is it? Is it unmanaged, or does it use SPI
> > > > > or I2C for management?
> > >
> > > > The switch is connected via RMII to the MAC and is managed over MDIO.
> > >
> > > O.K. What make/model?
> > >
> > The device is a Marvell 88E6393X switch. In our design, the BMC connects
>
> Which Linux does have a driver for.
>
> > to the device via RMII with fixed link parameters to retrieve ethernet.
> > > > On our board, MDIO is not wired directly to the processor; instead, we
> > > > use a USB-to-MPSSE bridge (FT2232) to toggle the MDIO signals for
> > > > switch management.
> > >
> > > I have to push back on you using a closed source user space driver,
> > > given that i help maintain the Ethernet switch drivers...
> > >
> > > I know there have been attempts to get GPIO support added for FT2232,
> > > but i don't think any got as far as mainline. That is probably the
> > > only part you are missing. You can describe USB devices in DT. So you
> > > should be able to describe such a GPIO controller. You can then
> > > instantiate an virtual,mdio-gpio driver to give you an MDIO bus. And
> > > then add nodes for the switch using DSA.
>
> > Apologies for the confusion in my previous reply.
> > The BMC connects to the peer via an RMII fixed-link.
> > The link parameters are fixed at design time and there is no runtime
> > MDIO-managed PHY or switch control from the BMC.
>
> So you use the USB-MDIO to program the EEPROM? The switch boots using
> the settings in the EEPROM? It is then an unmanaged hub? You are not
> using UMSD in userspace? That code looks terrible.
>
> So if you connect multiple of these unmanaged hubs together in a loop,
> your network disappears in a broadcast storm? Yes, you can use these
> switches in a dumb mode, but it has consequences. If you let Linux
> manage it, you gain a lot of functionality, such as STP, to break
> loops.
>
> But you seem to be opposed to this. At least add in a comment
> explaining the purpose of the fixed link. DT describes hardware, so
> there is no harm in describing the hardware, even if it is a comment
> and not real properties.
Thanks for the comments.
I understand the concern about the DTS. I will add a clear comment in the
device tree explaining why a fixed-link is used and that the switch is
initialized via hardware straps and EEPROM, with no runtime management
from Linux.
>
>         Andrew