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 X-Spam-Level: X-Spam-Status: No, score=-11.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16402C4320A for ; Tue, 10 Aug 2021 13:45:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E8E556108C for ; Tue, 10 Aug 2021 13:45:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241811AbhHJNpr (ORCPT ); Tue, 10 Aug 2021 09:45:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:51782 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240192AbhHJNpq (ORCPT ); Tue, 10 Aug 2021 09:45:46 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0AEC561075; Tue, 10 Aug 2021 13:45:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1628603124; bh=Glql89CKaEO2bKO5D0IqlIuTd5q4oxJ9Hn2ZSRZr+6k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W3pWCgta7DCxFxMKzABYUZSAlENjwlFpfuHFoXXv2Eit9eMl2Z+UCcO5Dc43YQQMt WTVNyQ8MROBG3w8rJQO0Vcp2otFrz65A5789N/iQ/b/3s13ylFpmZfF1fcAyaedt3N ovC4qeJXiHZ331CjANyr3NzVzEvoZfFX9lJQHWfWjQT7fe/rRrKM6xabrSL4pAwcGO WAsrZtoEL2msoqVQ9ZFYcuNKnb/5PkDkqbuYEJEXJF/iG5535KgIcyS7mmOTgv7IMD CA0tzZ8OzXMMcuEEsgbziGo3jbol8i+tLifnzLmNjQRUT3CMMibJPFoNQ8K7rON1B/ /tR/laAwFJygA== Date: Tue, 10 Aug 2021 16:45:20 +0300 From: Leon Romanovsky To: Prabhakar Kushwaha Cc: "David S . Miller" , Jakub Kicinski , Alexandre Belloni , Andrew Lunn , Ariel Elior , Bin Luo , Claudiu Manoil , Coiby Xu , Derek Chickles , drivers@pensando.io, Felix Manlunas , Florian Fainelli , Geetha sowjanya , Greg Kroah-Hartman , GR-everest-linux-l2@marvell.com, GR-Linux-NIC-Dev@marvell.com, hariprasad , Ido Schimmel , intel-wired-lan@lists.osuosl.org, Ioana Ciornei , Jerin Jacob , Jesse Brandeburg , Jiri Pirko , Linu Cherian , Linux Kernel Mailing List , linux-omap@vger.kernel.org, linux-staging@lists.linux.dev, Manish Chopra , Michael Chan , netdev@vger.kernel.org, oss-drivers@corigine.com, Richard Cochran , Saeed Mahameed , Salil Mehta , Satanand Burla , Shannon Nelson , Simon Horman , Subbaraya Sundeep , Sunil Goutham , Taras Chornyi , Tariq Toukan , Tony Nguyen , UNGLinuxDriver@microchip.com, Vadym Kochan , Vivien Didelot , Vladimir Oltean , Yisen Zhuang , Prabhakar Kushwaha , Shai Malin , Shai Malin , rtoshniwal@marvell.com, Omkar Kulkarni Subject: Re: [PATCH net-next] devlink: Set device as early as possible Message-ID: References: <6859503f7e3e6cd706bf01ef06f1cae8c0b0970b.1628449004.git.leonro@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Aug 10, 2021 at 06:08:51PM +0530, Prabhakar Kushwaha wrote: > Hi Leon, <...> > > struct devlink *devlink_alloc_ns(const struct devlink_ops *ops, > > - size_t priv_size, struct net *net) > > + size_t priv_size, struct net *net, > > + struct device *dev) > > { > > struct devlink *devlink; > > > > - if (WARN_ON(!ops)) > > - return NULL; > > - > > + WARN_ON(!ops || !dev); > > if (!devlink_reload_actions_valid(ops)) > > return NULL; > > > > devlink = kzalloc(sizeof(*devlink) + priv_size, GFP_KERNEL); > > if (!devlink) > > return NULL; > > + > > + devlink->dev = dev; > > devlink->ops = ops; > > xa_init_flags(&devlink->snapshot_ids, XA_FLAGS_ALLOC); > > write_pnet(&devlink->_net, net); > > @@ -8810,12 +8812,9 @@ EXPORT_SYMBOL_GPL(devlink_alloc_ns); > > * devlink_register - Register devlink instance > > * > > * @devlink: devlink > > - * @dev: parent device > > */ > > This patch is converting devlink_alloc() to devlink_alloc_register(). > > There are 2 APIs: devlink_alloc() and devlink_register(). > Both APIs can be used in a scenario, > Where devlink_alloc() can be done by code written around > one struct dev and used by another struct dev. > or > This scenario is not even a valid scenario? devlink_alloc() is used to allocated netdev structures for newly initialized device, it is not possible to share same devlink instance between different devices. > > > -int devlink_register(struct devlink *devlink, struct device *dev) > > +int devlink_register(struct devlink *devlink) > > { > > - WARN_ON(devlink->dev); > > - devlink->dev = dev; > > mutex_lock(&devlink_mutex); > > list_add_tail(&devlink->list, &devlink_list); > > devlink_notify(devlink, DEVLINK_CMD_NEW); > > Considering device registration has been moved to devlink_alloc(). > Can the remaining code of devlink_register() be also moved in devlink_alloc()? The line "list_add_tail(&devlink->list, &devlink_list);" makes the devlink instance visible to the devlink netlink users. We need to be sure that it is happening when the device is already initialized, while devlink_alloc() is performed usually as first line in .probe() routine. This means that we can't combine alloc an register and devlink_alloc_register() can't be valid scenario. Thanks > > --pk