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: <32ff7ca8-9cb0-4889-adb0-a6dae735630b@lunn.ch>
Date: Wed, 24 Dec 2025 10:20:19 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Kyle Hsieh <kylehsieh1995@...il.com>
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 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.

	Andrew