netdev - Re: DSA and Marvell Switch Drivers

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: <Yg1E9dxdzZDrqmtN@lunn.ch>
Date:   Wed, 16 Feb 2022 19:39:49 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     "Moltmann, Tobias" <Tobias.Moltmann@...mens.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: DSA and Marvell Switch Drivers

On Wed, Feb 16, 2022 at 08:55:17AM +0000, Moltmann, Tobias wrote:
> Hello,
> 
> I would first rewrite my questions and provide some information's and add some of Andrews answer to it as well.
> As I learned it would be helpful to address the "netdev list" to get (hopefully) even more help. 
> So please feel free to provide some feedback, thank you!
> 
> The issue we face comes along with an Kernel upgrade from 4.4.xxx to now 5.10.xx. It is all industrial-based hardware, so 
> no classical PC or something. On the hardware we have an x86 CPU, an IGB -> Marvell Switch (Marvell 88E6176) ->
> and two PHY's connected there.
> 
> Very roughly the way it worked/run with the 4.4 Kernel:
> 
> - mv88e6xxx_init() called - registered the driver
> - IGB driver loaded, started probing
> - within the probing we set up an MDIO bus (name: igb MDIO, id: 0000:01:00.0_mii)

So you have some out of tree patches for this? As far as i remember,
IGB does not make use of the MDIO framework.

> - the libphy does a first scan with no result due to some other missing stuff - at this point it is ok
> - also within the igb probing we set up an dsa_platform_data struct and run a platform_device_register()
> - this triggers the DSA driver
> - mv88e6352_probe() is called our Marvell switch is detected
> - a new DSA slave MDIO bus is been brought up automatically
> - mdiobus_scan() there register our two PHY devices 
> - everything is working :)

You can find a full example here, for a slights out of date kernel,

https://github.com/lunn/linux/blob/v5.15.5-zii-rap/drivers/platform/x86/zii-rap.c

This board also uses the igb, since the Ethernet is an i210. However,
it does not hack the driver to export the MDIO bus, it makes use of a
couple of GPIOs, and the bit banging MDIO bus driver. But that should
not make too big a difference.

The basic flow is, that once this platform driver loads, it calls
zii_rap_marvell_switch(). That tries to get the 'eth0' device. There
are some not so nice assumptions here, that this platform driver loads
after the igb.

It then adds a GPIO lookup table so you can find the GPIO being used
for the switch interrupt. The IRQ GPIO is then got, and converted into
an interrupt number. The switch actually uses level interrupts, but on
this platform only edge interrupts are supported. So we setup falling
edge and hope for the best.

The IRQ number is then added to the switch platform data.

The switch platform data is then registered to the MDIO core, via
bdinfo, against a bus name we know the MDIO bus will be given,
"gpio-0".

The bit banging MDIO bus is then setup and added.

When the MDIO bus is registered with the MDIO core, it will look at
the name, find the bdinfo structure uses the same name, and use that
to instantiate a device on the MDIO bus. That device will cause the
mv88e6xxx driver to probe, and setup a switch on the bus.

You should be able to follow the same basic scheme. Just don't add the
big banging MDIO bus, use the name you know your hacked igb driver
will use when it registers its MDIO bus. This board uses a 6390, which
needs a different compatible string to what you need. You need
"marvell,mv88e6085" for your switch.

	  Andrew