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=-8.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,USER_AGENT_MUTT 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 0CF5BC43381 for ; Fri, 22 Feb 2019 17:27:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D2AFE2075C for ; Fri, 22 Feb 2019 17:27:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726427AbfBVR1S (ORCPT ); Fri, 22 Feb 2019 12:27:18 -0500 Received: from mx2.suse.de ([195.135.220.15]:52370 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726214AbfBVR1S (ORCPT ); Fri, 22 Feb 2019 12:27:18 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 383D1AE6B; Fri, 22 Feb 2019 17:27:16 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id 6DB1BE00A5; Fri, 22 Feb 2019 18:27:15 +0100 (CET) Date: Fri, 22 Feb 2019 18:27:15 +0100 From: Michal Kubecek To: Jakub Kicinski Cc: davem@davemloft.net, jiri@resnulli.us, andrew@lunn.ch, f.fainelli@gmail.com, netdev@vger.kernel.org, oss-drivers@netronome.com Subject: Re: [PATCH net-next 4/5] nfp: add .ndo_get_devlink Message-ID: <20190222172715.GT23151@unicorn.suse.cz> References: <20190221174620.12144-1-jakub.kicinski@netronome.com> <20190221174620.12144-5-jakub.kicinski@netronome.com> <20190222100450.GR23151@unicorn.suse.cz> <20190222090204.20c410e3@cakuba.netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190222090204.20c410e3@cakuba.netronome.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Feb 22, 2019 at 09:02:04AM -0800, Jakub Kicinski wrote: > On Fri, 22 Feb 2019 11:04:50 +0100, Michal Kubecek wrote: > > On Thu, Feb 21, 2019 at 09:46:19AM -0800, Jakub Kicinski wrote: > > > Support getting devlink instance from a new NDO. > > > > > > Signed-off-by: Jakub Kicinski > > > --- > > > drivers/net/ethernet/netronome/nfp/nfp_app.h | 2 ++ > > > drivers/net/ethernet/netronome/nfp/nfp_devlink.c | 11 +++++++++++ > > > drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 1 + > > > drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 1 + > > > 4 files changed, 15 insertions(+) > > > > > > diff --git a/drivers/net/ethernet/netronome/nfp/nfp_app.h b/drivers/net/ethernet/netronome/nfp/nfp_app.h > > > index d578d856a009..f8d422713705 100644 > > > --- a/drivers/net/ethernet/netronome/nfp/nfp_app.h > > > +++ b/drivers/net/ethernet/netronome/nfp/nfp_app.h > > > @@ -433,4 +433,6 @@ int nfp_app_nic_vnic_alloc(struct nfp_app *app, struct nfp_net *nn, > > > int nfp_app_nic_vnic_init_phy_port(struct nfp_pf *pf, struct nfp_app *app, > > > struct nfp_net *nn, unsigned int id); > > > > > > +struct devlink *nfp_devlink_get_devlink(struct net_device *netdev); > > > + > > > #endif > > > diff --git a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c > > > index db2da99f6aa7..e9eca99cf493 100644 > > > --- a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c > > > +++ b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c > > > @@ -376,3 +376,14 @@ void nfp_devlink_port_unregister(struct nfp_port *port) > > > { > > > devlink_port_unregister(&port->dl_port); > > > } > > > + > > > +struct devlink *nfp_devlink_get_devlink(struct net_device *netdev) > > > +{ > > > + struct nfp_app *app; > > > + > > > + app = nfp_app_from_netdev(netdev); > > > + if (!app) > > > + return NULL; > > > + > > > + return priv_to_devlink(app->pf); > > > +} > > > > AFAICS this would return a pointer to zero initialized struct devlink > > when built with CONFIG_DEVLINK=n. Then devlink_compat_running_version() > > would execute > > > > if (!dev->netdev_ops->ndo_get_devlink) > > return; > > > > devlink = dev->netdev_ops->ndo_get_devlink(dev); > > if (!devlink || !devlink->ops->info_get) > > return; > > > > with non-null devlink but null devlink->ops so that it dereferences null > > pointer (and so does devlink_compat_flash_update()). > > devlink_compat_flash_update() is this if CONFIG_DEVLINK=n: > > static inline int > devlink_compat_flash_update(struct net_device *dev, const char *file_name) > { > return -EOPNOTSUPP; > } > > No? You are right, I missed that devlink_compat_running_version() and devlink_compat_flash_update() also have alternative versions when devlink is disabled. So there is no problem. > > Maybe it would be safer not to call ndo_get_devlink directly and have > > an inline wrapper like > > > > #if IS_ENABLED(CONFIG_NET_DEVLINK) > > static inline struct devlink *dev_get_devlink(struct net_device *dev) > > { > > if (dev->netdev_ops->ndo_get_devlink) > > return dev->netdev_ops->ndo_get_devlink(); > > else > > retrurn NULL; > > } > > #else > > static inline struct devlink *dev_get_devlink(struct net_device *dev) > > { > > return NULL; > > } > > #endif > > > > so that one can simply call the wrapper and check return value for NULL. > > Only devlink code can call this ndo, and it doesn't exist with > DEVLINK=n. I don't dislike wrappers for NDOs, but I'll defer to Jiri > to decide if we want a wrapper here (without the #if/#else, just the > first part for code clarity) :) If the NDO is only supposed to be called from devlink code (or, more precisely, code built only with CONFIG_DEVLINK=y), it should be IMHO mentioned in its description. Another option would be enforcing it by adding #ifdef around the ndo_get_devlink entry in struct net_device_ops but that would require using ifdefs also in each driver providing the NDO which seems inconvenient. Michal