From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Andrew Lunn <andrew@lunn.ch>
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 23:36:43 +0200 [thread overview]
Message-ID: <20230211213643.talp76wceyc7mypp@skbuf> (raw)
In-Reply-To: <Y+e5TzNRckDADd5d@lunn.ch>
On Sat, Feb 11, 2023 at 04:50:39PM +0100, Andrew Lunn wrote:
> 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.
I was thinking it wouldn't work because the PTP timer sub-driver would
first have to request the clock input from the CCF, before registering
its own clock output with the CCF. So the driver writer would be forced
to request a clock from the CCF in the probe() phase, if it wanted to
also register as a clock provider in the probe() phase.
I.o.w., switch #1 would get an -EPROBE_DEFER waiting for the clock from
switch #2, before it would get to call dsa_register_switch().
TLDR: the rule "provide all you have in stage 1, request all you need
in stage 2" would only work if you don't need anything to register your
providers.
prev parent reply other threads:[~2023-02-11 21:36 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
2023-02-11 21:36 ` Vladimir Oltean [this message]
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=20230211213643.talp76wceyc7mypp@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andrew@lunn.ch \
--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 \
/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