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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 16 Feb 2022 09:22:26 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     "Moltmann, Tobias" <Tobias.Moltmann@...mens.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: DSA and Marvell Switch Drivers

On 2/16/22 12:55 AM, 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)
> - 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 :)
> 
> 
> Now in the 5.10 Kernel, as there are the rewritten DSA/Marvell drivers included, the upper "stuff" is not working anymore.
> So far so good... Due to the fact, that the DSA/Marvell drivers aren't platform driver anymore the trigger with the platform_device_register()
> has no effect any more. I suggest we need to end up in the new mv88e6xxx_probe() function in drivers/net/dsa/mv88e6xxx/chip.c.
> As there is all the probing, register of DSA stuff included. 
> I added some "printf" in the module init parts in the chip.c file as well as in the /net/dsa/dsa.c - and I do see them in the
> Kernel logfile after startup. Everything else I added as output, does not show up.
> 
> Andrew already pointed out, that you now have to set up (as example) the following:
> 
> static struct dsa_mv88e6xxx_pdata dsa_mv88e6xxx_pdata = {
>         .cd = {
>                 .port_names[0] = NULL,
>                 .port_names[1] = "cpu",
>                 .port_names[2] = "red",
>                 .port_names[3] = "blue",
>                 .port_names[4] = "green",
>                 .port_names[5] = NULL,
>                 .port_names[6] = NULL,
>                 .port_names[7] = NULL,
>                 .port_names[8] = "waic0",
>         },
>         .compatible = "marvell,mv88e6190",
>         .enabled_ports = BIT(1) | BIT(2) | BIT(3) | BIT(4) | BIT(8),
>         .eeprom_len = 65536,
> };
> 
> static const struct mdio_board_info bdinfo = {
>         .bus_id = "gpio-0",
>         .modalias = "mv88e6085",
>         .mdio_addr = 0,
>         .platform_data = &dsa_mv88e6xxx_pdata, };
> 
>         dsa_mv88e6xxx_pdata.netdev = dev_get_by_name(&init_net, "eth0");
>         if (!dsa_mv88e6xxx_pdata.netdev) {
>                 dev_err(dev, "Error finding Ethernet device\n");
>                 return -ENODEV;
>         }
> 
>         err = mdiobus_register_board_info(&bdinfo, 1);
>         if (err) {
>                 dev_err(dev, "Error setting up MDIO board info\n");
>                 goto out;
>         }
> 
> I did a bunch of tries with this information's, put in our .bus_id, changed the port_names accordingly, switched the board register up and down etc. 
> but it still does not succeed ☹ 
> As Andrew also mentioned there is no mainline example and I'm also a bit confused that I haven't found (might be limitated to my person)
> any example somewhere out there which will put some light in our darkness...
> 
> So I would appreciate any help from you guys.
> You can also contact me directly - feel free if you think it a more optimized way. 
> I'll share my solution/information's if it works someday ...

There is a working example of registering a dsa platform data based
switch under drivers/net/dsa/dsa_loop_bdinfo.c can you try to get
inspiration from that one and see where the registration fails?
-- 
Florian