[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221206092705.108ded86@kernel.org>
Date: Tue, 6 Dec 2022 09:27:05 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>,
Vadim Fedorenko <vfedorenko@...ek.ru>,
Jonathan Lemon <jonathan.lemon@...il.com>,
Paolo Abeni <pabeni@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Vadim Fedorenko <vadfed@...com>,
linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
"Olech, Milena" <milena.olech@...el.com>,
"Michalik, Michal" <michal.michalik@...el.com>
Subject: Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions
On Tue, 6 Dec 2022 09:50:19 +0100 Jiri Pirko wrote:
>> 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.
Powered by blists - more mailing lists