[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230211213643.talp76wceyc7mypp@skbuf>
Date: Sat, 11 Feb 2023 23:36:43 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Andrew Lunn <andrew@...n.ch>
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
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.
Powered by blists - more mailing lists