How do I know when the dsa_loop and dsa_loop_bdinfo linux kernel modules are working?

I am working on an embedded system that will connect a processor running Linux to an Ethernet switch via a "conduit" Ethernet link (e.g. eth0) using one of the port-based DSA frame tagging protocols, so that the Linux kernel will present the userspace with separate Ethernet links for each of the switch's user ports (e.g. lan1, lan2, lan3).

As I understand it this is usually done via a fixed phy-less conduit (e.g. xMII) and an MDIO link between the processor and the switch so that the processor can configure and control the physical user ports.

I want to do some software development ahead of receiving the hardware, so I want to "fake" the MDIO link, or in some other way configure the kernel, such that it uses port-based DSA frame tagging over an ordinary (PHY-equipped) Ethernet port.

The documentation of kernel modules dsa_loop and dsa_loop_bdinfo imply that these might be suitable, and the source code seems to link .netdev = "eth0" to some user ports ("lan1".."lan4") but I don't seem to be able to use these to create the desired port devices (relevant kernel modules with printk debug lines added):

root@machine:~/dsa_loop# modprobe dsa_core
root@machine:~/dsa_loop# modprobe tag_dsa
root@machine:~/dsa_loop# insmod dsa_loop_bdinfo.ko
[   64.258577] dsa_loop_bdinfo_init
root@machine:~/dsa_loop# insmod dsa_loop.ko
[   70.802119] dsa_loop_init

root@machine:~/dsa_loop# lsmod
Module                  Size  Used by
dsa_loop               16384  0
dsa_loop_bdinfo        16384  0
tag_dsa                16384  0
dsa_core              118784  2 tag_dsa,dsa_loop
...

I am using ifconfig -a to show net devices, but I don't see lan1..lan4, only eth0.

So I guess I have several questions:

1. Are the dsa_loop and dsa_loop_init modules intended to allow DSA tagging to be performed on a "normal" Ethernet link?

2. How are these modules intended to be used?

3. dsa_loop_bdinfo.ko appears to depend on a fixed PHY device - do I need to create an instance of this somehow?

4. Are there any other ways of configuring Linux to do this without access to the switch MDIO?

The problem I was running into is the result of an ordering problem between these loadable modules and the fixed-phy layer code which was being compiled as a built-in module.

When the kernel configuration was changed to compile them as build-in modules along with the fixed-phy code the problem went away and I could see calls to dsa_loop_drv_probe.