devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Saravana Kannan <saravanak@google.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Lee Jones <lee@kernel.org>,
	Colin Foster <colin.foster@in-advantage.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: Advice on MFD-style probing of DSA switch SoCs
Date: Sat, 11 Feb 2023 16:50:39 +0100	[thread overview]
Message-ID: <Y+e5TzNRckDADd5d@lunn.ch> (raw)
In-Reply-To: <20230211012755.wh4unmkzibdyo4ln@skbuf>

> 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

  reply	other threads:[~2023-02-11 15:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-22 13:48 Advice on MFD-style probing of DSA switch SoCs Vladimir Oltean
2022-12-22 14:34 ` Andrew Lunn
2022-12-22 16:18   ` Vladimir Oltean
2022-12-22 16:36     ` Andrew Lunn
2022-12-23  8:44 ` Krzysztof Kozlowski
2022-12-23 13:44   ` Vladimir Oltean
2023-02-07  6:49     ` Saravana Kannan
2023-02-11  1:27       ` Vladimir Oltean
2023-02-11 15:50         ` Andrew Lunn [this message]
2023-02-11 21:36           ` Vladimir Oltean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+e5TzNRckDADd5d@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=alexandre.belloni@bootlin.com \
    --cc=colin.foster@in-advantage.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=saravanak@google.com \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).