[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y5MAEQ74trsNFQQc@nanopsycho>
Date: Fri, 9 Dec 2022 10:29:53 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
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
Thu, Dec 08, 2022 at 06:05:17PM CET, kuba@...nel.org wrote:
>On Thu, 8 Dec 2022 17:33:28 +0100 Jiri Pirko wrote:
>> For any synce pin manipulation over dpll netlink, we can use the netns
>> check of the linked netdev. This is the netns aware leg of the dpll,
>> it should be checked for.
>
>The OCP card is an atomic clock, it does not have any networking.
Sure, so why it has to be netns aware if it has nothing to do with
networking?
>
>> I can't imagine practically havind the whole dpll instance netns aware.
>> Omitting the fact that it really has no meaning for non-synce pins, what
>> would be the behaviour when for example pin 1 is in netns a, pin 2 in
>> netns b and dpll itself in netns c?
>
>To be clear I don't think it's a bad idea in general, I've done
>the same thing for my WIP PSP patches. But we already have one
>device without netdevs, hence I thought maybe devlink. So maybe
>we do the same thing with devlink? I mean - allow multiple devlink
>instances to be linked and require caps on any of them?
I read this 5 times, I'm lost, don't understand what you mean :/
Powered by blists - more mailing lists