On Thu, Sep 30, 2021 at 7:00 AM Andrew Lunn [off-list ref] wrote:

quoted

Andrew is testing with arch/arm/boot/dts/vf610-zii-dev-rev-b.dts.

Graphically it looks like this:

Nice ASCII art :-)

Thanks for the awesome diagram Vladimir!

This shows the flow of Ethernet frames thought the switch
cluster. What is missing, and causing fw_devlink problems is the MDIO
bus master for the PHYs, and the interrupt control where PHY
interrupts are stored, and the linking from the PHY to the interrupt
controller. Physically all these parts are inside the Ethernet switch
package. But Linux models them as separate blocks. This is because in
the general case, they are all discrete blocks. You have a MAC chip,
and a PHY chip, and the PHY interrupt output it connected to a SoC
GPIO.

quoted

 +-----------------------------+
 |          VF610 SoC          |
 |          +--------+         |
 |          |  fec1  |         |
 +----------+--------+---------+
                | DSA master
                |
                | ethernet = <&fec1>;
 +--------+----------+---------------------------+
 |        |  port@6  |                           |
 |        +----------+                           |
 |        | CPU port |     dsa,member = <0 0>;   |
 |        +----------+      -> tree 0, switch 0  |
 |        |   cpu    |                           |
 |        +----------+                           |
 |                                               |
 |            switch0                            |
 |                                               |
 +-----------+-----------+-----------+-----------+

Inside the block above, is the interrupt controller and the MDIO bus
master.

quoted

 |   port@0  |   port@1  |   port@2  |   port@5  |
 +-----------+-----------+-----------+-----------+
 |switch0phy0|switch0phy1|switch0phy2|   no PHY  |
 +-----------+-----------+-----------+-----------+

The control path for these PHYs is over the MDIO bus. They are probed
via the control path bus. These PHYs also have an interrupt output,
which is wired to the interrupt controller above.

quoted

 | user port | user port | user port | DSA port  |
 +-----------+-----------+-----------+-----------+
 |    lan0   |    lan1   |    lan2   |    dsa    |
 +-----------+-----------+-----------+-----------+

Thanks for the dts paths and the additional details Andrew.

I think this gives me enough info for now to make sure whatever I'm
coding isn't completely stupid. I'm trying to make the generic PHY
driver less greedy (taking it a bit further than what Vladimir was
attempting) and also delay the use of generic PHY driver as late as
possible (so that we give as much time as possible for the specific
driver to be registered/loaded before we give up and use generic PHY
driver). This would also need some changes to the DSA code and hence
these questions.

Btw, do we have non-DSA networking devices where fw_devlink=on
delaying PHY probes is causing an issue?

-Saravana