From: Jiri Pirko <jiri@resnulli.us> To: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com> Cc: Jakub Kicinski <kuba@kernel.org>, 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-arm-kernel@lists.infradead.org>, "linux-clk@vger.kernel.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: Wed, 14 Dec 2022 08:32:19 +0100 [thread overview] Message-ID: <Y5l8A+n5Vy5wRHXj@nanopsycho> (raw) In-Reply-To: <DM6PR11MB46577F9AB422103140778D529BE39@DM6PR11MB4657.namprd11.prod.outlook.com> Tue, Dec 13, 2022 at 07:08:13PM CET, arkadiusz.kubalewski@intel.com wrote: >>From: Jiri Pirko <jiri@resnulli.us> >>Sent: Monday, December 12, 2022 2:37 PM >>To: Jakub Kicinski <kuba@kernel.org> >> >>Fri, Dec 09, 2022 at 05:19:42PM CET, kuba@kernel.org wrote: >>>On Fri, 9 Dec 2022 10:29:53 +0100 Jiri Pirko wrote: >>>> Thu, Dec 08, 2022 at 06:05:17PM CET, kuba@kernel.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? >>> >>>That's a larger question, IDK if broadening the scope of the discussion >>>will help us reach a conclusion. >>> >>>The patchset as is uses network namespaces for permissions: >>> >>>+ .flags = GENL_UNS_ADMIN_PERM, >> >>Yeah, I wonder if just GENL_ADMIN_PERM wuldn't be more suitable here... >> >> >>> >>>so that's what I'm commenting on - aligning visibility of objects with >>>already used permissions. >>> >>>> >> 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 :/ >>> >>>Sorry I was replying to both paragraphs here, sorry. >>>What I thought you suggested is we scope the DPLL to whatever the >>>linked netdevs are scoped to? If netns has any of the netdevs attached >>>to the DPLL then it can see the DPLL and control it as well. >> >>Okay, that would make sense. >>GENL_UNS_ADMIN_PERM | GENL_UNS_ADMIN_PERM then. >> > >I guess a typo here? Shall be: 'GENL_UNS_ADMIN_PERM | GENL_ADMIN_PERM'? Yes, sure. >Going to: >- apply those bits for all the dpll netlink commands, >- remove DPLLA_NETIFINDEX, >- leave pin DPLLA_PIN_NETIFINDEX as is. > >Or I have missed something? I believe it is ok. > >Thanks, >Arkadiusz > >>> >>>What I was saying is some DPLL have no netdevs. So we can do the same >>>thing with devlinks. Let the driver link the DPLL to one or more >>>devlink instances, and if any of the devlink instances is in current >>>netns then you can see the DPLL. >> >>I don't think that would be needed to pull devlink into the picture. >>If not netdev is linked to dpll, GENL_ADMIN_PERM would apply. >
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Pirko <jiri@resnulli.us> To: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com> Cc: Jakub Kicinski <kuba@kernel.org>, 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-arm-kernel@lists.infradead.org>, "linux-clk@vger.kernel.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: Wed, 14 Dec 2022 08:32:19 +0100 [thread overview] Message-ID: <Y5l8A+n5Vy5wRHXj@nanopsycho> (raw) In-Reply-To: <DM6PR11MB46577F9AB422103140778D529BE39@DM6PR11MB4657.namprd11.prod.outlook.com> Tue, Dec 13, 2022 at 07:08:13PM CET, arkadiusz.kubalewski@intel.com wrote: >>From: Jiri Pirko <jiri@resnulli.us> >>Sent: Monday, December 12, 2022 2:37 PM >>To: Jakub Kicinski <kuba@kernel.org> >> >>Fri, Dec 09, 2022 at 05:19:42PM CET, kuba@kernel.org wrote: >>>On Fri, 9 Dec 2022 10:29:53 +0100 Jiri Pirko wrote: >>>> Thu, Dec 08, 2022 at 06:05:17PM CET, kuba@kernel.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? >>> >>>That's a larger question, IDK if broadening the scope of the discussion >>>will help us reach a conclusion. >>> >>>The patchset as is uses network namespaces for permissions: >>> >>>+ .flags = GENL_UNS_ADMIN_PERM, >> >>Yeah, I wonder if just GENL_ADMIN_PERM wuldn't be more suitable here... >> >> >>> >>>so that's what I'm commenting on - aligning visibility of objects with >>>already used permissions. >>> >>>> >> 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 :/ >>> >>>Sorry I was replying to both paragraphs here, sorry. >>>What I thought you suggested is we scope the DPLL to whatever the >>>linked netdevs are scoped to? If netns has any of the netdevs attached >>>to the DPLL then it can see the DPLL and control it as well. >> >>Okay, that would make sense. >>GENL_UNS_ADMIN_PERM | GENL_UNS_ADMIN_PERM then. >> > >I guess a typo here? Shall be: 'GENL_UNS_ADMIN_PERM | GENL_ADMIN_PERM'? Yes, sure. >Going to: >- apply those bits for all the dpll netlink commands, >- remove DPLLA_NETIFINDEX, >- leave pin DPLLA_PIN_NETIFINDEX as is. > >Or I have missed something? I believe it is ok. > >Thanks, >Arkadiusz > >>> >>>What I was saying is some DPLL have no netdevs. So we can do the same >>>thing with devlinks. Let the driver link the DPLL to one or more >>>devlink instances, and if any of the devlink instances is in current >>>netns then you can see the DPLL. >> >>I don't think that would be needed to pull devlink into the picture. >>If not netdev is linked to dpll, GENL_ADMIN_PERM would apply. > _______________________________________________ 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-14 7:32 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 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 [this message] 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=Y5l8A+n5Vy5wRHXj@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: linkBe 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.