From: Jiri Pirko <jiri@resnulli.us>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>,
Vadim Fedorenko <vfedorenko@novek.ru>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
Paolo Abeni <pabeni@redhat.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Vadim Fedorenko <vadfed@fb.com>,
linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
"Olech, Milena" <milena.olech@intel.com>,
"Michalik, Michal" <michal.michalik@intel.com>
Subject: Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions
Date: Tue, 6 Dec 2022 09:50:19 +0100 [thread overview]
Message-ID: <Y48CS98KYCMJS9uM@nanopsycho> (raw)
In-Reply-To: <20221205161933.663ea611@kernel.org>
Tue, Dec 06, 2022 at 01:19:33AM CET, kuba@kernel.org wrote:
>On Mon, 5 Dec 2022 11:32:04 +0100 Jiri Pirko wrote:
>> >> I believe we should do it only the other way around. Assign
>> >> dpll_pin pointer to struct net_device and expose this over new attr
>> >> IFLA_DPLL_PIN over RT netlink.
>> >
>> >The ID table is global, what's the relationship between DPLLs
>> >and net namespaces? We tie DPLLs to a devlink instance which
>> >has a namespace? We pretend namespaces don't exist? :S
>>
>> Well, if would be odd to put dpll itself into a namespace. It might not
>> have anything to do with networking, for example in case of ptp_ocp.
>> What would mean for a dpll to be in a net namespace?
>
>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?
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Pirko <jiri@resnulli.us>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>,
Vadim Fedorenko <vfedorenko@novek.ru>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
Paolo Abeni <pabeni@redhat.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Vadim Fedorenko <vadfed@fb.com>,
linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
"Olech, Milena" <milena.olech@intel.com>,
"Michalik, Michal" <michal.michalik@intel.com>
Subject: Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions
Date: Tue, 6 Dec 2022 09:50:19 +0100 [thread overview]
Message-ID: <Y48CS98KYCMJS9uM@nanopsycho> (raw)
In-Reply-To: <20221205161933.663ea611@kernel.org>
Tue, Dec 06, 2022 at 01:19:33AM CET, kuba@kernel.org wrote:
>On Mon, 5 Dec 2022 11:32:04 +0100 Jiri Pirko wrote:
>> >> I believe we should do it only the other way around. Assign
>> >> dpll_pin pointer to struct net_device and expose this over new attr
>> >> IFLA_DPLL_PIN over RT netlink.
>> >
>> >The ID table is global, what's the relationship between DPLLs
>> >and net namespaces? We tie DPLLs to a devlink instance which
>> >has a namespace? We pretend namespaces don't exist? :S
>>
>> Well, if would be odd to put dpll itself into a namespace. It might not
>> have anything to do with networking, for example in case of ptp_ocp.
>> What would mean for a dpll to be in a net namespace?
>
>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?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-12-06 8:50 UTC|newest]
Thread overview: 172+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 21:37 [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Vadim Fedorenko
2022-11-29 21:37 ` Vadim Fedorenko
2022-11-29 21:37 ` [RFC PATCH v4 1/4] dpll: add dpll_attr/dpll_pin_attr helper classes Vadim Fedorenko
2022-11-29 21:37 ` Vadim Fedorenko
2022-11-29 21:37 ` [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Vadim Fedorenko
2022-11-29 21:37 ` Vadim Fedorenko
2022-11-30 15:21 ` Jiri Pirko
2022-11-30 15:21 ` Jiri Pirko
2022-11-30 16:23 ` Jiri Pirko
2022-11-30 16:23 ` Jiri Pirko
2022-12-23 16:45 ` Kubalewski, Arkadiusz
2022-12-23 16:45 ` Kubalewski, Arkadiusz
2023-01-02 12:28 ` Jiri Pirko
2023-01-02 12:28 ` Jiri Pirko
2022-11-30 16:37 ` Jiri Pirko
2022-11-30 16:37 ` Jiri Pirko
2022-12-02 11:27 ` Kubalewski, Arkadiusz
2022-12-02 11:27 ` Kubalewski, Arkadiusz
2022-12-02 12:39 ` Jiri Pirko
2022-12-02 12:39 ` Jiri Pirko
2022-12-02 14:54 ` Kubalewski, Arkadiusz
2022-12-02 14:54 ` Kubalewski, Arkadiusz
2022-12-02 16:15 ` Jiri Pirko
2022-12-02 16:15 ` Jiri Pirko
[not found] ` <20221202212206.3619bd5f@kernel.org>
2022-12-05 10:32 ` Jiri Pirko
2022-12-05 10:32 ` Jiri Pirko
2022-12-06 0:19 ` Jakub Kicinski
2022-12-06 0:19 ` Jakub Kicinski
2022-12-06 8:50 ` Jiri Pirko [this message]
2022-12-06 8:50 ` Jiri Pirko
2022-12-06 17:27 ` Jakub Kicinski
2022-12-06 17:27 ` Jakub Kicinski
2022-12-07 13:10 ` Jiri Pirko
2022-12-07 13:10 ` Jiri Pirko
2022-12-07 16:59 ` Jakub Kicinski
2022-12-07 16:59 ` Jakub Kicinski
2022-12-08 8:14 ` Jiri Pirko
2022-12-08 8:14 ` Jiri Pirko
2022-12-08 16:19 ` Jakub Kicinski
2022-12-08 16:19 ` Jakub Kicinski
2022-12-08 16:33 ` Jiri Pirko
2022-12-08 16:33 ` Jiri Pirko
2022-12-08 17:05 ` Jakub Kicinski
2022-12-08 17:05 ` Jakub Kicinski
2022-12-09 9:29 ` Jiri Pirko
2022-12-09 9:29 ` Jiri Pirko
2022-12-09 16:19 ` Jakub Kicinski
2022-12-09 16:19 ` Jakub Kicinski
2022-12-12 13:36 ` Jiri Pirko
2022-12-12 13:36 ` Jiri Pirko
2022-12-13 18:08 ` Kubalewski, Arkadiusz
2022-12-13 18:08 ` Kubalewski, Arkadiusz
2022-12-14 7:32 ` Jiri Pirko
2022-12-14 7:32 ` Jiri Pirko
2022-11-29 21:37 ` [RFC PATCH v4 3/4] dpll: documentation on DPLL subsystem interface Vadim Fedorenko
2022-11-29 21:37 ` Vadim Fedorenko
2022-12-02 12:43 ` kernel test robot
2022-12-19 9:13 ` Paolo Abeni
2022-12-19 9:13 ` Paolo Abeni
2023-01-12 13:45 ` Kubalewski, Arkadiusz
2023-01-12 13:45 ` Kubalewski, Arkadiusz
2022-11-29 21:37 ` [RFC PATCH v4 4/4] ptp_ocp: implement DPLL ops Vadim Fedorenko
2022-11-29 21:37 ` Vadim Fedorenko
2022-11-30 8:30 ` kernel test robot
2022-11-30 12:41 ` Jiri Pirko
2022-11-30 12:41 ` Jiri Pirko
2022-12-02 11:27 ` Kubalewski, Arkadiusz
2022-12-02 11:27 ` Kubalewski, Arkadiusz
2022-12-02 12:48 ` Jiri Pirko
2022-12-02 12:48 ` Jiri Pirko
2022-12-02 14:39 ` Kubalewski, Arkadiusz
2022-12-02 14:39 ` Kubalewski, Arkadiusz
2022-12-02 16:20 ` Jiri Pirko
2022-12-02 16:20 ` Jiri Pirko
2022-12-08 0:35 ` Kubalewski, Arkadiusz
2022-12-08 0:35 ` Kubalewski, Arkadiusz
2022-12-08 8:19 ` Jiri Pirko
2022-12-08 8:19 ` Jiri Pirko
2022-12-07 2:33 ` Jakub Kicinski
2022-12-07 2:33 ` Jakub Kicinski
2022-12-07 13:19 ` Jiri Pirko
2022-12-07 13:19 ` Jiri Pirko
[not found] ` <20221207090524.3f562eeb@kernel.org>
2022-12-08 11:22 ` Jiri Pirko
2022-12-09 0:36 ` Jakub Kicinski
2022-12-09 9:32 ` Jiri Pirko
2022-11-30 12:32 ` [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Jiri Pirko
2022-11-30 12:32 ` Jiri Pirko
2022-12-02 11:27 ` Kubalewski, Arkadiusz
2022-12-02 11:27 ` Kubalewski, Arkadiusz
2022-12-02 16:12 ` Jiri Pirko
2022-12-02 16:12 ` Jiri Pirko
2022-12-07 2:47 ` Jakub Kicinski
2022-12-07 2:47 ` Jakub Kicinski
2022-12-07 14:09 ` netdev.dump
2022-12-07 14:09 ` netdev.dump
2022-12-07 23:21 ` Jakub Kicinski
2022-12-07 23:21 ` Jakub Kicinski
2022-12-08 11:28 ` Jiri Pirko
2022-12-08 11:28 ` Jiri Pirko
2022-12-09 0:39 ` Jakub Kicinski
2022-12-09 0:39 ` Jakub Kicinski
2022-12-09 0:56 ` Kubalewski, Arkadiusz
2022-12-09 0:56 ` Kubalewski, Arkadiusz
2022-12-08 18:08 ` Maciek Machnikowski
2022-12-08 18:08 ` Maciek Machnikowski
2022-12-09 11:07 ` Jiri Pirko
2022-12-09 11:07 ` Jiri Pirko
2022-12-09 14:09 ` Maciek Machnikowski
2022-12-09 14:09 ` Maciek Machnikowski
2022-12-09 16:31 ` Jakub Kicinski
2022-12-09 16:31 ` Jakub Kicinski
2022-12-09 17:11 ` Maciek Machnikowski
2022-12-09 17:11 ` Maciek Machnikowski
2022-12-12 13:58 ` Jiri Pirko
2022-12-12 13:58 ` Jiri Pirko
2023-01-09 14:43 ` Kubalewski, Arkadiusz
2023-01-09 14:43 ` Kubalewski, Arkadiusz
2023-01-09 16:30 ` Jiri Pirko
2023-01-09 16:30 ` Jiri Pirko
2023-01-10 10:54 ` Kubalewski, Arkadiusz
2023-01-10 10:54 ` Kubalewski, Arkadiusz
2023-01-10 14:28 ` Jiri Pirko
2023-01-10 14:28 ` Jiri Pirko
[not found] ` <645a5bfd-0092-2f39-0ff2-3ffb27ccf8fe@machnikowski.net>
2023-01-11 14:17 ` Kubalewski, Arkadiusz
2023-01-11 14:17 ` Kubalewski, Arkadiusz
2023-01-11 14:40 ` Maciek Machnikowski
2023-01-11 14:40 ` Maciek Machnikowski
2023-01-11 15:30 ` Kubalewski, Arkadiusz
2023-01-11 15:30 ` Kubalewski, Arkadiusz
2023-01-11 15:54 ` Maciek Machnikowski
2023-01-11 15:54 ` Maciek Machnikowski
2023-01-11 16:27 ` Kubalewski, Arkadiusz
2023-01-11 16:27 ` Kubalewski, Arkadiusz
2023-01-10 20:05 ` Jakub Kicinski
2023-01-10 20:05 ` Jakub Kicinski
2023-01-11 8:19 ` Jiri Pirko
2023-01-11 8:19 ` Jiri Pirko
2023-01-11 14:16 ` Kubalewski, Arkadiusz
2023-01-11 14:16 ` Kubalewski, Arkadiusz
2023-01-11 15:04 ` Jiri Pirko
2023-01-11 15:04 ` Jiri Pirko
2023-01-11 15:30 ` Kubalewski, Arkadiusz
2023-01-11 15:30 ` Kubalewski, Arkadiusz
2023-01-11 16:14 ` Jiri Pirko
2023-01-11 16:14 ` Jiri Pirko
2023-01-12 12:15 ` Kubalewski, Arkadiusz
2023-01-12 12:15 ` Kubalewski, Arkadiusz
2023-01-12 14:43 ` Jiri Pirko
2023-01-12 14:43 ` Jiri Pirko
2022-12-09 0:46 ` Kubalewski, Arkadiusz
2022-12-09 0:46 ` Kubalewski, Arkadiusz
2022-12-07 14:51 ` Jiri Pirko
2022-12-07 14:51 ` Jiri Pirko
[not found] ` <20221207091946.3115742f@kernel.org>
2022-12-08 12:02 ` Jiri Pirko
2022-12-08 12:02 ` Jiri Pirko
2022-12-09 0:54 ` Jakub Kicinski
2022-12-08 18:23 ` Kubalewski, Arkadiusz
2022-12-08 18:23 ` Kubalewski, Arkadiusz
2022-12-08 0:27 ` Kubalewski, Arkadiusz
2022-12-08 0:27 ` Kubalewski, Arkadiusz
2022-12-08 11:58 ` Jiri Pirko
2022-12-08 11:58 ` Jiri Pirko
2022-12-08 23:05 ` Kubalewski, Arkadiusz
2022-12-08 23:05 ` Kubalewski, Arkadiusz
2022-12-09 10:01 ` Jiri Pirko
2022-12-09 10:01 ` Jiri Pirko
2023-01-12 12:23 ` Kubalewski, Arkadiusz
2023-01-12 12:23 ` Kubalewski, Arkadiusz
2023-01-12 14:50 ` Jiri Pirko
2023-01-12 14:50 ` Jiri Pirko
2023-01-12 19:09 ` Jakub Kicinski
2023-01-12 19:09 ` Jakub Kicinski
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=Y48CS98KYCMJS9uM@nanopsycho \
--to=jiri@resnulli.us \
--cc=arkadiusz.kubalewski@intel.com \
--cc=jonathan.lemon@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=michal.michalik@intel.com \
--cc=milena.olech@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vadfed@fb.com \
--cc=vfedorenko@novek.ru \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.