Thread (15 messages) read the whole thread 15 messages, 3 authors, 2022-12-14

Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions

From: Jiri Pirko <jiri@resnulli.us>
Date: 2022-12-07 13:10:49
Also in: linux-arm-kernel, linux-clk

Tue, Dec 06, 2022 at 06:27:05PM CET, kuba@kernel.org wrote:
On Tue, 6 Dec 2022 09:50:19 +0100 Jiri Pirko wrote:
quoted
quoted
Yeah, that's a slightly tricky one. We'd probably need some form 
of second order association. Easiest if we link it to a devlink
instance, I reckon. The OCP clock card does not have netdevs so we
can't follow the namespace of netdevs (which would be the second
option).  
Why do we need this association at all?
Someone someday may want netns delegation and if we don't have the
support from the start we may break backward compat introducing it.
Hmm. Can you imagine a usecase?

Link to devlink instance btw might be a problem. In case of mlx5, one
dpll instance is going to be created for 2 (or more) PFs. 1 per ConnectX
ASIC as there is only 1 clock there. And PF devlinks can come and go,
does not make sense to link it to any of them.

Thinking about it a bit more, DPLL itself has no network notion. The
special case is SyncE pin, which is linked to netdevice. Just a small
part of dpll device. And the netdevice already has notion of netns.
Isn't that enough?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help