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=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 5BEFDC43381 for ; Thu, 21 Feb 2019 03:20:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1EAD12086C for ; Thu, 21 Feb 2019 03:20:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="tMk7RJ+4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726697AbfBUDUL (ORCPT ); Wed, 20 Feb 2019 22:20:11 -0500 Received: from mail-qt1-f196.google.com ([209.85.160.196]:43024 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725989AbfBUDUK (ORCPT ); Wed, 20 Feb 2019 22:20:10 -0500 Received: by mail-qt1-f196.google.com with SMTP id y4so29909050qtc.10 for ; Wed, 20 Feb 2019 19:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=MVRmEz42Lq0C5MJIS5UVSFp/RvtyEduAbMN4qMsJo3M=; b=tMk7RJ+4sTW/lyg0ulIf+ezpdGgXFs7HBiUcMyxQOBv4KGSN9OI+gCWEOCItOeKKin x9pwvHCob/lKP1kpJNExGI6JQgYCuIm/ouy4CoVA2z/cgp6B0ip8plATEApZCa5WZQin XPNNq3KXnoDQuwVCbUeDrvezFkiMfVn0Q05HZnPrsqLPopgIeBp2uhwScaYyQsvsWMFP KSJxKN2sDihVeA4chNKDbmxWsXjd1rWnerjvZTkI8eAMVeBVASa12dnAKTYBqsRqxgy2 O+h3pSOJLJpB/x8G0cBfvlNMmffnhOt0bnP4mA3egkH6dPknPc5RSBRY4ofBUloISagN 0e0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=MVRmEz42Lq0C5MJIS5UVSFp/RvtyEduAbMN4qMsJo3M=; b=q74YEivGsc7tJZjaU3mOzUYQc1mKALzs+J2A15bRRRMjyn3SsdsNMx31C9bWvH2NPC 4p8Pmd08dLyMH61oJT/2qZC0jOO9ynAs7PfTrqcMkuPDmZDJkG1HPNP/w7GiMFarv88F /Vbd78nw14uh8hY6HsUWWXOWHFPawDciKPAqbpsXreG695XQr7VqrFJyLp/57FOm/h3E hiDSJFTtFCqdJ9uqncstEcupMk5I2A7A35uEFfBGB4ZlnXiovYwWPeum2GSH1WciiRZE Kr+UGhIHjZBCDAeYo9L8mlljC65qSuIbWDjT6hD6i5+/m/tSN1jhH4HUwvfkWiXCc8YF xEGg== X-Gm-Message-State: AHQUAuafRzYebv1j+5rUf/EK5O/S0JAlctoGDbx57hrEynlJ0oq1OFbX qORl6RI3+oCz+lMaKszSmmjETg== X-Google-Smtp-Source: AHgI3IbO3EMkik02xqgIDOJkvQXPjba0bYWsvvrFYHLBI0SoFfmmYJEhSCJm6KHFj7DJgDvoR3tM9Q== X-Received: by 2002:a0c:ae6f:: with SMTP id z44mr10802245qvc.130.1550719209388; Wed, 20 Feb 2019 19:20:09 -0800 (PST) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id v131sm11840442qka.95.2019.02.20.19.20.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Feb 2019 19:20:09 -0800 (PST) Date: Wed, 20 Feb 2019 19:20:02 -0800 From: Jakub Kicinski To: Florian Fainelli Cc: Jiri Pirko , davem@davemloft.net, netdev@vger.kernel.org, oss-drivers@netronome.com, mkubecek@suse.cz, andrew@lunn.ch Subject: Re: [PATCH net-next 3/3] nfp: devlink: allow flashing the device via devlink Message-ID: <20190220192002.0b77f74f@cakuba.netronome.com> In-Reply-To: References: <20190214214046.19182-1-jakub.kicinski@netronome.com> <20190214214046.19182-4-jakub.kicinski@netronome.com> <20190215101514.GD2343@nanopsycho> <20190215074429.6890e47e@cakuba.netronome.com> <20190219091942.GA3080@nanopsycho> <20190219164926.23981359@cakuba.netronome.com> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 20 Feb 2019 18:59:05 -0800, Florian Fainelli wrote: > On 2/19/2019 4:49 PM, Jakub Kicinski wrote: > > On Tue, 19 Feb 2019 10:19:42 +0100, Jiri Pirko wrote: > >> Fri, Feb 15, 2019 at 04:44:29PM CET, jakub.kicinski@netronome.com wrote: > >>> On Fri, 15 Feb 2019 11:15:14 +0100, Jiri Pirko wrote: > >>>>> static const struct ethtool_ops nfp_net_ethtool_ops = { > >>>> > >>>> Why don't you use the compat fallback? I think you should. > >>> > >>> You and Michal both asked the same so let me answer the first to ask :) > >>> - if devlink is built as a module the fallback is not reachable. > >> > >> So the fallback is not really good as you can't use it for real drivers > >> anyway. Odd. Maybe we should compile devlink in without possibility to > >> have it as module. > > > > Ack, I'll make devlink a bool. > > Meh how about those poor and memory constrained embedded systems? > Ideally ethtool should/could have been modular as well, but that ship > has now sailed. To be clear - I'm not going to add a dependency. You'll still be able to use ethtool without devlink (granted, you won't be able to flash the device). It's not immediately clear to me how devlink being modular saves memory. The way I see it you either: (a) not have networking or need any devlink related functionality, and therefore do DEVLINK=n; or: (b) have a networking device driver built and loaded which will depend on devlink, so devlink will practically speaking always be loaded, even if its =m. > > I need a little extra time, I forgot that nfp's flower offload still > > doesn't register all ports (using your port flavour infrastructure). > > We have had similar issues with PHYLIB before where we wanted > net/core/ethtool.c to be able to call into generic PHYLIB functions to > obtain PHY statistics, an inline helper that de-references the PHY > device's driver function pointers solved that (look for > phy_ethtool_get_{strings,sset,stats}) while letting PHYLIB remain modular. > > devlink_compat_flash_update() is a bit big to be inlined, but why not? > > If we make sure we always provide a devlink_mutex and devlink_list that > symbols such that this builds wheter CONFIG_DEVLINK=y|m then everything > else can be determined at runtime whether devlink.ko is loaded or not. > > Does that make sense? I think so, we'd have to have a little object that would always be built-in when DEVLINK=m, and therefore accessible?