Date:   Sat, 11 Feb 2023 03:27:55 +0200
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Lee Jones <lee@...nel.org>,
        Colin Foster <colin.foster@...advantage.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: Advice on MFD-style probing of DSA switch SoCs

Hi Saravana,

This has nothing to do with the topic of the thread, right? (probing a
DSA switch SoC as a MFD parent for its sub-blocks).

On Mon, Feb 06, 2023 at 10:49:03PM -0800, Saravana Kannan wrote:
> IMHO, the DSA is a logical device that's made up of many different
> pieces of real hardware IP. IMHO an ideal solution would be something
> like a dsa_bus type where we add a dsa_device.

So in DSA terminology, what you call a dsa_device would be a DSA switch tree
(a group of interconnected DSA chips forming an Ethernet switching fabric),
and what you call the dsa_bus would be the bus on which the switch trees live?

> The dsa_device will list all the necessary devices (IRQ, PHY, MDIO,
> etc -- they can be wherever they want in DT) as its suppliers and when
> the dsa_device is probed, it can assume all its suppliers are present
> and then do the DSA initialization.

How would the dsa_device (the DSA switch tree) know what are its suppliers?
DSA is library code used by multiple drivers from multiple vendors.
It's just that this library code has a built-in mechanism for serializing
probing, in case those switches form a tree. The dependencies are not fixed.
Would fw_devlink be involved in determining these? Up to what degree can
the dependencies be "wherever they want in DT"?

> This would also solve the PHYs problem you stated earlier.

How would it solve it?

> So, basically you'd move some of the dsa initialization code into the
> dsa_probe() function of the dsa_bus.

Not clear what makes this solution better than what currently exists.

> Hope I'm making some sense. Let me know if you want to discuss this
> further and I can try and provide more context and details.
> 
> Also, there's already a driver core feature that does just this --
> component devices -- but the implementation is old and not so great
> IMHO. Component device model can be done better using device links. I
> want to refactor the component device framework to use device links,
> but that's a problem for another time.

Ok, in my mind the problem is the way in which each individual DSA
switch driver, written by $vendor, organizes the resources/peripherals
pertaining to a single chip. Not the way in which the DSA framework
coordinates the probing of multiple chips in an arbitrarily-defined
topology, and defers some initialization to a dsa_switch_ops :: setup()
function. The latter part doesn't have a good justification to be
changed IMO; it doesn't do any harm. I.o.w., I never gave an example
of cross-chip fw_devlink dependencies that would need to be satisfied,
only ones local to a chip.

But since your email seems to be about cross-chip, let me try to
entertain the idea and ask you to explain what you're proposing.

Let's take an absolutely extreme (and hypothetical) example:

    +--------------------------------+
    |                                |
    |     Host SoC running Linux     |
    |                                |
    |  +----------+   +----------+   |
    |  |   MDIO   |   |   ETH    |   |
    |  |controller|   |controller|   |
    |  |          |   |  (DSA    |   |
    |  |          |   | master)  |   |
    +--+----------+---+----------+---+
            |              |
            |              |
       MDIO |              | ETH
            |              |
            v              v
    +--------------------------------+
    |                    CPU port    |-------
    |                                |-------
    |               MDIO-controller  |-------
    |  +----------+  DSA switch #1   |------- External
    |  |   MDIO   |                  |------- ETH
    |  |controller|                  |------- ports
    |  |          |                  |-------
    |  |          |   cascade port   |-------
    +--+----------+------------------+
            |       ^      |
            |       |      |
       MDIO |   CLK |      | ETH
            |       |      |
            v       |      v
    +--------------------------------+
    |                 cascade port   |-------
    |                                |-------
    |                                |-------
    |         MDIO-controlled        |------- External
    |            switch #2           |------- ETH
    |                                |------- ports
    |                                |-------
    |                                |-------
    +--------------------------------+

where we have a DSA switch tree with 2 chips, both have their registers
accessible over MDIO. But chip #1 is accessed through the host's MDIO
controller, and chip #2 through chip #1's MDIO controller.

These chips are also going to be used with PTP, and the PTP timers of
the 2 switches don't feed off of individual oscillators as would be
usual, but instead, there is a single oscillator feeding into one
switch, and that switch forwards this as a clock to the other switch
(because board designers heard it's more trendy this way). So switch #2
provides a clock to switch #1.


With the current mainline DSA code structure, assuming a monolithically
written $vendor driver (as basically N-1 of them are), the above would
not work under any circumstance.


In the alternative in which we implement what you hinted at and nothing
more (a dsa_device composed of switches 1 and 2), how would this ever
come any closer to the conclusion that the 2 monolithic blocks above are
able to probe linearly, and finally bind the aggregate device?


In the alternative in which we implement what I proposed in this email
thread and nothing more, the drivers for the chips would have to not be
monolithically written. First to probe would be the SoC driver for switch
chip #1. That would probe its children: the MDIO controller, the PTP timer,
the Ethernet switching IP with its ports (the DSA driver proper).
Perhaps the DSA driver has some unmet dependencies, so it defers probe.
Doesn't affect the rest.

After chip #1 probes its MDIO controller, that MDIO bus probes its own
children. On that bus is the switch chip #2, which can probe its own SoC
driver. Same story: PTP timer, MDIO bus, Ethernet switching IP (DSA proper).
Let's say that this DSA driver had no dependencies and can probe
straight away. It enters dsa_tree_setup_routing_table(), the infamous
function which determines "hey, you have a cascade port towards another
DSA switching IP which hasn't probed yet, I can't fully initialize you
either" and basically finishes probing "early".

Then finally, the dependency for the DSA switching IP of chip #1 gets
resolved and it retries probing. It enters dsa_tree_setup_routing_table(),
and this figures out "ah, you're the last switch, the tree is complete,
we've been waiting for you!" and initializes the entire Ethernet fabric
from the probing context of this switch. So this ad-hoc mechanism only
affects the probing of the switching fabric and Ethernet ports, the rest
can go on with its business.


So I gave you an example in which I don't really understand what would
an aggregate device representing the entire switching fabric bring new
to the table.

Also, PCBs with more than 1 switch on them are relatively rare. Usually,
when you need more Ethernet ports, you just buy a larger switching chip.
DSA has no problem working with a single chip, and many chip vendors
don't actually support cascading. I think that for the volume of users
of the multi-chip feature, it actually works very well and with very
little code. I think that the problems of multi-chip setups are the same
as the problem of single-chip setups.

Powered by blists - more mailing lists