Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2386962ybl; Sun, 26 Jan 2020 01:22:02 -0800 (PST) X-Google-Smtp-Source: APXvYqw9e/xLDe8nFc1lzorAbuMa99DB4mV2CIDQ8fg4mzEeeJNz8rLsD670NpRfiD6V/aFnfC5H X-Received: by 2002:a9d:760e:: with SMTP id k14mr8346408otl.344.1580030521977; Sun, 26 Jan 2020 01:22:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580030521; cv=none; d=google.com; s=arc-20160816; b=wrNh3zTbJfR2boI8QBDZIKvHEXFdJSLoH1Jk0lRqyP43NsPraJJhukzT/eagJLbpmR LYsXNGo3X2MRhUYruhNtpg2DVejapT1gN4c6MMiY77lp33z17jXjEKTItDswtgmySQvQ pcOzZY+pY1J4FNwiIywErDL/rpitmvbS22INroG90z/A45alnAHNHgDomWY8rxV4ngvB cq/g3Vzus/WnJxhspHP6yyDVv86U/76QY1+x9lmG4QJxkOz6zvyT2+4afQ34YbaEv2yU egOokvRku3oMXzOn4l/vy7o/w+IfCe9IEf1hFrZFQPoIkKR5L2ET71x1w6Ut0Fdd+h7A VmCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=CRmMnV5Uy79zjtX3sisn5ZZX6auwskylrIq+dOTxweY=; b=Gqfwy/pmzdujyeEOze1auUwOW8eyxrMHtvxaXY7qg56a9rNFMQEVIT6uCuUzHZN0wb lh/kJr+t8rCpwTjCOTM63IRSoY9E2aZj/nAjfmOK+bW5QUWHNjrnMEszImYamSty/XSv Yd/LhLJjiv4Y6ApoA3n7+lgIxLILGl2bjfUf9xsTEhgLD/vQv2hIQMOLfzt7uEC+y8Qg 8o5exRD0w1VxTww6UI12kRPIhhedd3oQqJ+cwwzu+j7V6oujJ/U5TePzwqj2NFj8jQUP QdBLr2/tTYXmbUlIHHGXvSyX2aayRA7vS8XlP/KBfchNELm/RnR4uG5czF51Yw16p3Rs p5dw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n9si5179596ota.103.2020.01.26.01.21.50; Sun, 26 Jan 2020 01:22:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726443AbgAZJU4 (ORCPT + 99 others); Sun, 26 Jan 2020 04:20:56 -0500 Received: from smtp04.smtpout.orange.fr ([80.12.242.126]:25021 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726518AbgAZJU4 (ORCPT ); Sun, 26 Jan 2020 04:20:56 -0500 Received: from localhost.localdomain ([93.23.15.185]) by mwinf5d07 with ME id uxLl2100n3zZxD103xLmMA; Sun, 26 Jan 2020 10:20:54 +0100 X-ME-Helo: localhost.localdomain X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Sun, 26 Jan 2020 10:20:54 +0100 X-ME-IP: 93.23.15.185 From: Christophe JAILLET To: claudiu.manoil@nxp.com, davem@davemloft.net Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Christophe JAILLET Subject: [PATCH] gianfar: Allocate the correct number of rx queues in 'gfar_of_init()' Date: Sun, 26 Jan 2020 10:20:28 +0100 Message-Id: <20200126092028.14246-1-christophe.jaillet@wanadoo.fr> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We can get values for rx and tx queues from "fsl,num_rx_queues" and "fsl,num_tx_queues". However, when 'alloc_etherdev_mq()' is called, the value for "tx" is used for both. Use 'alloc_etherdev_mqs()' instead. Signed-off-by: Christophe JAILLET --- WARNING: This patch is purely speculative! I don't fully understand the code, and tx and rx queues seem to be allocated by 'gfar_alloc_[rt]x_queues()' and handled with priv-> fields. I don't know the relationship between queues provided by the core, and the ones specificly handled in this driver. 'netif_set_real_num_rx_queues()' a few lines below is also spurious to me. If "fsl,num_rx_queues" > "fsl,num_tx_queues" it will return an error and things then look out of synch (i.e. 'priv->num_rx_queues' is set to a value bigger than what is allocated by core, that is to say the one from 'priv->num_tx_queues') If my assumptions are correct, I guess that the call to 'netif_set_real_num_rx_queues()' is useless Sorry for the noise if I'm completly wrong. In such a case, some explanation would be appreciated. --- drivers/net/ethernet/freescale/gianfar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c index 72868a28b621..5e934069682e 100644 --- a/drivers/net/ethernet/freescale/gianfar.c +++ b/drivers/net/ethernet/freescale/gianfar.c @@ -708,7 +708,7 @@ static int gfar_of_init(struct platform_device *ofdev, struct net_device **pdev) return -EINVAL; } - *pdev = alloc_etherdev_mq(sizeof(*priv), num_tx_qs); + *pdev = alloc_etherdev_mqs(sizeof(*priv), num_tx_qs, num_rx_qs); dev = *pdev; if (NULL == dev) return -ENOMEM; -- 2.20.1