netdev - Re: Advice on MFD-style probing of DSA switch SoCs

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]

Message-ID: <Y+e5TzNRckDADd5d@lunn.ch>
Date:   Sat, 11 Feb 2023 16:50:39 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     Saravana Kannan <saravanak@...gle.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        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

> 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.

I'm not sure that is true. The switches probe method should register
with the driver core any resources a switch provides. So switch #1
MDIO bus driver is registered during its probe, allowing the probe of
switch #2 to happen. When switch #2 probes, it should register its
clock with the common clock framework, etc.

However, the linking of resources together, the PTP clock in your
example, should happen in the switches setup() call, which only
happens once all the switches in the cluster have probed, so all the
needed resources should be available.

Because we have these two phases, i think the above setup would work.

	Andrew