Re: [PATCH v1 1/2] driver core: fw_devlink: Add support for FWNODE_FLAG_BROKEN_PARENT

Saravana Kannan
2021-09-30T17:31:44Z

On Thu, Sep 30, 2021 at 7:00 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > 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.
>
> >
> > +-----------------------------+
> > | 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.
>
>
> > | 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.
>
>
> > | 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