From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D4590C4332F for ; Wed, 14 Dec 2022 07:33:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hNmd1wgicAIRBVq9udKcI4evjS2Lcc0FHTflH0L2qKc=; b=Mu48U3IKZ7YX9d BOk8mrLliyNFl+KxTRcTEX1BvXEHEDwdDD4IOcndsBcyxKAqMBx6QWnajdvtGz2g981m5/2O3eopq Qokrbbyfh2jrSzJIc5FHXIDOvHmvwuThN1cDzbNHmEM7w1K4wNHRy2F0UiK/1upft8EwgMYkHJTfE tNMy3lAdl8ViUAPxX9cXvAJHKgVeXrDXmdT6Ff6Me+rmz0oGBlW6G2fk69O44MbUoa9Tilyxg65Rc NmJjTsaV0oKXWLhec4Ev5jnzdYXvxW3XvoGaLaUgLs3fmM7g5Cs1lpqAN0K4dH6Bd/xafo11dwPdT NbIkWwbldO5hzDvhagqQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5MFn-00E2SG-LC; Wed, 14 Dec 2022 07:32:35 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5MFj-00E2NB-JB for linux-arm-kernel@lists.infradead.org; Wed, 14 Dec 2022 07:32:34 +0000 Received: by mail-ed1-x52a.google.com with SMTP id e13so21277002edj.7 for ; Tue, 13 Dec 2022 23:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Y1iX53ofpqrzk0YZ6KNxGxfiNC7kqMLlKM8UTuzJUTY=; b=SqySALxQYMa1zWvs0VVjWBKFgrWM7hYJ6MjmSCsCJ0qS2z7Z5fL6KHXDZpKuD0TNd6 vSH8b9osSg0RdIBSRmszn9lNPxxF78sdkQjSMs3ySnWa7FBBlBzrHXOc7r+k7wVIllZ9 2MCRv/Hvy3qc6mKDv4bOPnAh3U0O5vispnqr4WYVuTaPlBAyRr+co+3DT82ca6m14wke rCsgnfs+TliA+eGtBqGVV8B4gLeSbaKzLLMTwXZnz+qLuwkI9QVZYwxfYGA3I49+ee9l rG7viLshSy8dbdy2whFJ+7mKkAHL2WW/EhZ5Q1nbUY0OwsRF2a3WTnsDt9brZwGhtRko qdpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Y1iX53ofpqrzk0YZ6KNxGxfiNC7kqMLlKM8UTuzJUTY=; b=4nMOd4TAMWA86qfx5dxQGo4TJPTLf4JRolaiPYjINYbN74ZUdmnQbefKGYJWG/kSXQ ZiPVrhkE29J9+43tzkpXw+ovmj73jYXNFDplh1z0T4e25kG3MaqgpqbjDcNe7K0JtS0h aq1Kul/sEJvvXCwEF2TisCSqZpUPSWnuwSI7HrqmgkEqsTpgs+xSiZTP0fV0XXsEFG3h 3TBBvx4eku6fa7y79ob86SExUgEzwbSLFTD+gfOJQGHi0bnrTC9WQdSFiTwon+caYguQ fuDYIvncj0VYmbDbLdj4tqFOLZY63QcKMDnfuSgWFSe9GAR4YEv0KVtDQoiYqRzOkbin jZ5Q== X-Gm-Message-State: ANoB5pm34sZ7y6CREqeP4OjgtmN2GNwV1Tkrbo3xyHQCD1x4FixNdn3D 8PtMpAqKC4+l7BI/d3dpSwfZMQ== X-Google-Smtp-Source: AA0mqf5E5OyQJdElpwGM8XN0xgmPjPP6McLdDoWBZvqHNWy+h8HvDmPxb/C3ceS4wUuqqDTX+FDZWw== X-Received: by 2002:a05:6402:43ce:b0:46c:a43d:5e23 with SMTP id p14-20020a05640243ce00b0046ca43d5e23mr24265030edc.28.1671003141902; Tue, 13 Dec 2022 23:32:21 -0800 (PST) Received: from localhost ([217.111.27.204]) by smtp.gmail.com with ESMTPSA id bf8-20020a0564021a4800b0045cf4f72b04sm5803587edb.94.2022.12.13.23.32.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Dec 2022 23:32:20 -0800 (PST) Date: Wed, 14 Dec 2022 08:32:19 +0100 From: Jiri Pirko To: "Kubalewski, Arkadiusz" Cc: Jakub Kicinski , Vadim Fedorenko , Jonathan Lemon , Paolo Abeni , "netdev@vger.kernel.org" , Vadim Fedorenko , "linux-arm-kernel@lists.infradead.org" , "linux-clk@vger.kernel.org" , "Olech, Milena" , "Michalik, Michal" Subject: Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Message-ID: References: <20221207085941.3b56bc8c@kernel.org> <20221208081955.335ca36c@kernel.org> <20221208090517.643277e8@kernel.org> <20221209081942.565bc422@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221213_233231_651648_F545F2BA X-CRM114-Status: GOOD ( 21.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Tue, Dec 13, 2022 at 07:08:13PM CET, arkadiusz.kubalewski@intel.com wrote: >>From: Jiri Pirko >>Sent: Monday, December 12, 2022 2:37 PM >>To: Jakub Kicinski >> >>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