Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5867708pxj; Wed, 23 Jun 2021 10:35:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyFDPFfElGNA1GNbYIP22jg3Gn0heAXhRxWtepkPkzeOyY/rJ2+0TXKE7EXqb34k96tzGaX X-Received: by 2002:a50:ef12:: with SMTP id m18mr1231100eds.285.1624469712258; Wed, 23 Jun 2021 10:35:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624469712; cv=none; d=google.com; s=arc-20160816; b=yxOi7txHIqKJ0Wp80CL5o1LvqXkJSHmc401A+j30yh2nh96r4T73ji5kLEp5YnQIi8 mFspH9KAWCpNX/EF2VWp+sn3/QOMK3PcL1GrI+72DFJ12fGdJ4GEPVoH8Md4rlp7mSNn 1akV41S5DOHPYY9ni8uxAgjeSzWDTrnANfTxyPtUK2R+aG4bn82+sPanKYVO7GDYC6lg fpeyp926RXA2ML7smPRBzJvgIKbDNZj0wOYwbaYxJODAmp+corPbYgJ+S80Y+md3KMi0 F0lYgyV+mMM8aNZaFjZz8Pfjv/zwckb6djcBXX/Uh2Mq89GICdxt8OxwQmEuPN8ltxqf 4V+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=xsm/iuKc+04iGIrtanquxcEfKGm0/iHMtOF7c6r7Jqk=; b=ErkHipuPm+ejJ+oriO8icbujFNo4kuOnJx6ynZIIGoUryB0oEY1/qtjP2KLiBFi+8X 3hLDqSCwV2YPqfc0CqEGEd9Cy3lLlIrqxQ0RWWXJ9ksIRUQAF7UAluIKlixSJFvfnGF0 b/HWJWZns1aqFGwTWM4KQ7NWuzWLqr4DmSz7kQpQYqOM7CllAMCOaZ6IdZujrtzi4cV6 PmzwEixbSmNtWSYmI4lD3mjOyJ5KIINzQAU267zQUDO4MX/j13LUu2iGdjGVilZdzXfe VMGp2F3uU1BVjZc1RqPc6Iw+sGaA9B9/J/AUaws27w8AXV+dwQ3rIhq3oRLD5hDWf+aa oUzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kroah.com header.s=fm1 header.b=nrg5Vic+; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=Fo9q8bpZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z3si435203edx.106.2021.06.23.10.34.49; Wed, 23 Jun 2021 10:35:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kroah.com header.s=fm1 header.b=nrg5Vic+; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=Fo9q8bpZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229915AbhFWRdY (ORCPT + 99 others); Wed, 23 Jun 2021 13:33:24 -0400 Received: from new1-smtp.messagingengine.com ([66.111.4.221]:53895 "EHLO new1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229726AbhFWRdX (ORCPT ); Wed, 23 Jun 2021 13:33:23 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 43D69580661; Wed, 23 Jun 2021 13:31:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 23 Jun 2021 13:31:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=xsm/iuKc+04iGIrtanquxcEfKGm 0/iHMtOF7c6r7Jqk=; b=nrg5Vic+q3fYGWO54Ohj8Ja8nFHGwEHL15bQRUdaZQo UGdGD0d6oILejJ9507k2qhfYXJDztCBWHuNOWkMs2S/0AgNoK6dnZDc4IeI7quPo Tfd9m+lYAEbt6yVey5delOudOe0Mi7PhH5s23sbJ7UFCY42UqWttU8CyP4vUluH5 K8bohS21hlYfN4McqQZoiAeoi2UGiuoYJtXhDZT0KfQqxH8Z7hhm5GmYiCBYZJyw jpe8mrSiHV82GZjTBXb4GcIpOCu89hmzrJTZIONMwtEtz0vprOwy2IrgaeZEmsYi SWW3hSco8qNmVOSke6zdY0nXIEUZHIINVTcPdmobTTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=xsm/iu Kc+04iGIrtanquxcEfKGm0/iHMtOF7c6r7Jqk=; b=Fo9q8bpZzDgc7kErb09oXI L/ZU9KO7XyIILfJqtg43JCGiEPfeTMoiDq32drvTljvHqFARtCsnvYoiWGp7igI5 felWcOf7B2vZmkTjnY7VyvesdAiX2t95Wm7zHwze4zFwswr34gtzusL+toPXeOf0 t7TwQjj0LLa7KIe+9Cfrol6QOOh4GBlx+k0gvW7PgSDhrfg1/hNwv1540UMt8dLK bpQxCvYuOXCAEp3mQXe3xZfzoMeiqIwaQMwXvnLPCrVu9PgOCD+ygtHbohasvpZ5 x/3XQZUPhPGgULtcje2D1jym3agHl+NjR00sPd6ubpYToDt0aUvq8vTu+nkms4cQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeegfedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepifhrvghg ucfmjfcuoehgrhgvgheskhhrohgrhhdrtghomheqnecuggftrfgrthhtvghrnhepveeuhe ejgfffgfeivddukedvkedtleelleeghfeljeeiueeggeevueduudekvdetnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhrvghgsehkrhhorg hhrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 23 Jun 2021 13:31:03 -0400 (EDT) Date: Wed, 23 Jun 2021 19:31:00 +0200 From: Greg KH To: Rocco Yue Cc: "David S . Miller" , Jakub Kicinski , Jonathan Corbet , Hideaki YOSHIFUJI , David Ahern , Matthias Brugger , Felix Fietkau , John Crispin , Sean Wang , Mark Lee , netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, bpf@vger.kernel.org, wsd_upstream@mediatek.com, chao.song@mediatek.com, zhuoliang.zhang@mediatek.com, kuohong.wang@mediatek.com Subject: Re: [PATCH 4/4] drivers: net: mediatek: initial implementation of ccmni Message-ID: References: <20210623113452.5671-1-rocco.yue@mediatek.com> <20210623113452.5671-4-rocco.yue@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210623113452.5671-4-rocco.yue@mediatek.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 23, 2021 at 07:34:52PM +0800, Rocco Yue wrote: > +static int ccmni_open(struct net_device *ccmni_dev) > +{ > + struct ccmni_inst *ccmni = netdev_priv(ccmni_dev); > + > + netif_tx_start_all_queues(ccmni_dev); > + netif_carrier_on(ccmni_dev); > + > + if (atomic_inc_return(&ccmni->usage) > 1) { > + atomic_dec(&ccmni->usage); > + netdev_err(ccmni_dev, "dev already open\n"); > + return -EINVAL; You only check this _AFTER_ starting up? If so, why even check a count at all? Why does it matter as it's not keeping anything from working here. > + } > + > + return 0; > +} > + > +static int ccmni_close(struct net_device *ccmni_dev) > +{ > + struct ccmni_inst *ccmni = netdev_priv(ccmni_dev); > + > + atomic_dec(&ccmni->usage); > + netif_tx_disable(ccmni_dev); > + > + return 0; > +} > + > +static netdev_tx_t > +ccmni_start_xmit(struct sk_buff *skb, struct net_device *ccmni_dev) > +{ > + struct ccmni_inst *ccmni = NULL; > + > + if (unlikely(!ccmni_hook_ready)) > + goto tx_ok; > + > + if (!skb || !ccmni_dev) > + goto tx_ok; > + > + ccmni = netdev_priv(ccmni_dev); > + > + /* some process can modify ccmni_dev->mtu */ > + if (skb->len > ccmni_dev->mtu) { > + netdev_err(ccmni_dev, "xmit fail: len(0x%x) > MTU(0x%x, 0x%x)", > + skb->len, CCMNI_MTU, ccmni_dev->mtu); > + goto tx_ok; > + } > + > + /* hardware driver send packet will return a negative value > + * ask the Linux netdevice to stop the tx queue > + */ > + if ((s_ccmni_ctlb->xmit_pkt(ccmni->index, skb, 0)) < 0) > + return NETDEV_TX_BUSY; > + > + return NETDEV_TX_OK; > +tx_ok: > + dev_kfree_skb(skb); > + ccmni_dev->stats.tx_dropped++; > + return NETDEV_TX_OK; > +} > + > +static int ccmni_change_mtu(struct net_device *ccmni_dev, int new_mtu) > +{ > + if (new_mtu < 0 || new_mtu > CCMNI_MTU) > + return -EINVAL; > + > + if (unlikely(!ccmni_dev)) > + return -EINVAL; > + > + ccmni_dev->mtu = new_mtu; > + return 0; > +} > + > +static void ccmni_tx_timeout(struct net_device *ccmni_dev, unsigned int txqueue) > +{ > + struct ccmni_inst *ccmni = netdev_priv(ccmni_dev); > + > + ccmni_dev->stats.tx_errors++; > + if (atomic_read(&ccmni->usage) > 0) > + netif_tx_wake_all_queues(ccmni_dev); Why does it matter what the reference count is? What happens if it drops _RIGHT_ after testing for it? Anytime you do an atomic_read() call, it's almost always a sign that the logic is not correct. Again, why have this reference count at all? What is it protecting? > +/* exposed API > + * receive incoming datagrams from the Modem and push them to the > + * kernel networking system > + */ > +int ccmni_rx_push(unsigned int ccmni_idx, struct sk_buff *skb) Ah, so this driver doesn't really do anything on its own, as there is no modem driver for it. So without a modem driver, it will never be used? Please submit the modem driver at the same time, otherwise it's impossible to review this correctly. thanks, greg k-h