Message ID | 20230202125930.271740-8-rakesh.sankaranarayanan@microchip.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp232558wrn; Thu, 2 Feb 2023 05:19:57 -0800 (PST) X-Google-Smtp-Source: AK7set9qEbhlDFlWewEgDEj5oS8OwirVvL0KlIjEGITkHvLSL8pimSQ3NVl4+zju0os/3tGrzG+t X-Received: by 2002:a05:6a20:1615:b0:bc:4d0c:ce45 with SMTP id l21-20020a056a20161500b000bc4d0cce45mr8012684pzj.53.1675343997614; Thu, 02 Feb 2023 05:19:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675343997; cv=none; d=google.com; s=arc-20160816; b=1JFe7KmyUEAIdV2unHGXLApTy415fU1Tme7ORsiHAjJra1CAMPnPd7+4qAHeLVJT7y 99vVLFdW39HycNsPXP0D/1vqBVWu0dGp8GHyxlyV0v/8AU5uV52zlkEkQLAImO4bo6ij NVq+wE9zLnotfcTOjCbj7YmqkAQIS62VESbsc2HoinWyU+pOCfKvY9dL1iadjkV7CBHM 3smeCmZc2Rcjc61mCoa/IkQTiO47U/Cp+RnlMUF5TA/E5iTHfbi+IJm5yNF4DfR3DbRb gtXQ1ryDv02aSR1UWIn/4sQwozlZPn+Dk7DOn+fMk1KBsHKB0GTmNL2mTOVq10rOa6/F RkJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=8vaB2nzg1NiGUwy3efKPMjZ6Dtjev1+EL0Clby/39LI=; b=lDLLhnAYZdEy+VAPbcIQf+3kCNfG0kFzhLYbxVJ+C3N176n2BBmwLPLDoZ2cXwhzFz GfmYKHeoNjSK0zWqyp/rxBJwlz4+vEFZR/Rov1N4GXSMunk9L/nktXb8xPci3pkzkT3L 0OdUTcv1ysVm4Y1C0izBBRX7dL2GIvTpZTGiPqH9WfWdfGF/UFIz4LE8o5ce6nNEdlwd YvDflXmg01kGmjXuzrHs4j8QlPRofM7T/OEfb1UfFHN8rzit/NJ28lWSQK7aty2AFqDu exe4bJBKkViHgMivja13caOkgLBK4l4HElNXGMNPozamHqVIWoxGv+YoRE84GJnacr1Z 9NEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b="wN/tie7P"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m4-20020a656a04000000b004cc3c59b5f0si26814956pgu.329.2023.02.02.05.19.44; Thu, 02 Feb 2023 05:19:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b="wN/tie7P"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232478AbjBBM7j (ORCPT <rfc822;il.mystafa@gmail.com> + 99 others); Thu, 2 Feb 2023 07:59:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232375AbjBBM7R (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 2 Feb 2023 07:59:17 -0500 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 477418F241; Thu, 2 Feb 2023 04:59:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1675342749; x=1706878749; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=gOPgGw0RohtMRFMCFrPybEvNkhUd8DRkAKdQTixdWLk=; b=wN/tie7PXKsvgyYPNfmOkfUVkYMGFhEVyLZK00FvOasaK7psHFcP1jOG 54bL5xl+kyEU/2UXRqycUh9pn00FcsjuzZ+aq07tzXPLBp1BxS1p/Y+J0 3UY5zfA0gERa6Iz005fxWOIGgb03JHt5EP2tPVFh6e/nGUCLUBxH3SKyU 9OECkTzbXzLpsB1BFr0ToLg981AJGmxlEA0l6NVQ1zrv7Xsoh2Y8rFXFm bBlp+ugzlhI8kRv1lvJ711piq+7XdOXOOA0GJsYD0whSWK8gecg+B8EPi f+02oK+rD3Ek7vot+EfFeWmGQSY+B9wMJn94Wd6FvnEbaLIOUBhx9GYV9 g==; X-IronPort-AV: E=Sophos;i="5.97,267,1669100400"; d="scan'208";a="135251855" Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 02 Feb 2023 05:59:08 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.85.151) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Thu, 2 Feb 2023 05:59:05 -0700 Received: from che-lt-i67786lx.microchip.com (10.10.115.15) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server id 15.1.2507.16 via Frontend Transport; Thu, 2 Feb 2023 05:59:01 -0700 From: Rakesh Sankaranarayanan <rakesh.sankaranarayanan@microchip.com> To: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org> CC: <andrew@lunn.ch>, <f.fainelli@gmail.com>, <olteanv@gmail.com>, <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>, <woojung.huh@microchip.com>, <UNGLinuxDriver@microchip.com>, <linux@armlinux.org.uk> Subject: [RFC PATCH net-next 07/11] net: dsa: microchip: lan937x: update switch register Date: Thu, 2 Feb 2023 18:29:26 +0530 Message-ID: <20230202125930.271740-8-rakesh.sankaranarayanan@microchip.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230202125930.271740-1-rakesh.sankaranarayanan@microchip.com> References: <20230202125930.271740-1-rakesh.sankaranarayanan@microchip.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756725507609476640?= X-GMAIL-MSGID: =?utf-8?q?1756725507609476640?= |
Series |
net: dsa: microchip: lan937x: add switch cascade support
|
|
Commit Message
Rakesh Sankaranarayanan
Feb. 2, 2023, 12:59 p.m. UTC
Second switch in cascaded connection doesn't have port with macb
interface. dsa_switch_register returns error if macb interface is
not up. Due to this reason, second switch in cascaded connection will
not report error during dsa_switch_register and mib thread work will be
invoked even if actual switch register is not done. This will lead to
kernel warning and it can be avoided by checking device tree setup
status. This will return true only after actual switch register is done.
Signed-off-by: Rakesh Sankaranarayanan <rakesh.sankaranarayanan@microchip.com>
---
drivers/net/dsa/microchip/ksz_common.c | 10 ++++++++++
1 file changed, 10 insertions(+)
Comments
On Thu, Feb 02, 2023 at 06:29:26PM +0530, Rakesh Sankaranarayanan wrote: > Second switch in cascaded connection doesn't have port with macb > interface. dsa_switch_register returns error if macb interface is > not up. Due to this reason, second switch in cascaded connection will > not report error during dsa_switch_register and mib thread work will be > invoked even if actual switch register is not done. This will lead to > kernel warning and it can be avoided by checking device tree setup > status. This will return true only after actual switch register is done. What i think you need to do is move the code into ksz_setup(). With a D in DSA setup, dsa_switch_register() adds the switch to the list of switches, and then a check is performed to see if all switches in the cluster have been registered. If not, it just returns. If all switches have been registered, it then iterates over all the switches can calls dsa_switch_ops.setup(). By moving the start of the MIB counter into setup(), it will only be started once all the switches are present, and it means you don't need to look at DSA core internal state. Andrew
Hi Andrew, Thanks for the comment, I will change and test the code as you explained and update the patch in next revision. Thanks, Rakesh S. On Thu, 2023-02-02 at 16:40 +0100, Andrew Lunn wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you > know the content is safe > > On Thu, Feb 02, 2023 at 06:29:26PM +0530, Rakesh Sankaranarayanan > wrote: > > Second switch in cascaded connection doesn't have port with macb > > interface. dsa_switch_register returns error if macb interface is > > not up. Due to this reason, second switch in cascaded connection > > will > > not report error during dsa_switch_register and mib thread work > > will be > > invoked even if actual switch register is not done. This will lead > > to > > kernel warning and it can be avoided by checking device tree setup > > status. This will return true only after actual switch register is > > done. > > What i think you need to do is move the code into ksz_setup(). > > With a D in DSA setup, dsa_switch_register() adds the switch to the > list of switches, and then a check is performed to see if all > switches > in the cluster have been registered. If not, it just returns. If all > switches have been registered, it then iterates over all the switches > can calls dsa_switch_ops.setup(). > > By moving the start of the MIB counter into setup(), it will only be > started once all the switches are present, and it means you don't > need > to look at DSA core internal state. > > Andrew
On Thu, Feb 02, 2023 at 04:40:36PM +0100, Andrew Lunn wrote: > On Thu, Feb 02, 2023 at 06:29:26PM +0530, Rakesh Sankaranarayanan wrote: > > Second switch in cascaded connection doesn't have port with macb > > interface. dsa_switch_register returns error if macb interface is > > not up. Due to this reason, second switch in cascaded connection will > > not report error during dsa_switch_register and mib thread work will be > > invoked even if actual switch register is not done. This will lead to > > kernel warning and it can be avoided by checking device tree setup > > status. This will return true only after actual switch register is done. > > What i think you need to do is move the code into ksz_setup(). > > With a D in DSA setup, dsa_switch_register() adds the switch to the > list of switches, and then a check is performed to see if all switches > in the cluster have been registered. If not, it just returns. If all > switches have been registered, it then iterates over all the switches > can calls dsa_switch_ops.setup(). > > By moving the start of the MIB counter into setup(), it will only be > started once all the switches are present, and it means you don't need > to look at DSA core internal state. +1 Also there's a bug in its own right in ksz_mib_read_work(), here: if (!netif_carrier_ok(dp->slave)) mib->cnt_ptr = dev->info->reg_mib_cnt; The code accesses dp->slave, so naturally it kicks the bucket for cascade ports. It doesn't crash with CPU ports because dp->slave is in a union with dp->master, which is also a struct net_device * with its own carrier: struct dsa_port { /* A CPU port is physically connected to a master device. * A user port exposed to userspace has a slave device. */ union { struct net_device *master; struct net_device *slave; }; This needs to be fixed, since accessing the DSA master through a dp->slave pointer is dangerous and unintended. Easiest thing to do would be to only check link state if (dsa_port_is_user(dp)). For other ports always read all MIB counters.
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c index 2160a3e61a5a..0df71156a540 100644 --- a/drivers/net/dsa/microchip/ksz_common.c +++ b/drivers/net/dsa/microchip/ksz_common.c @@ -3213,6 +3213,7 @@ int ksz_switch_register(struct ksz_device *dev) { const struct ksz_chip_data *info; struct device_node *port, *ports; + struct dsa_switch_tree *dst; phy_interface_t interface; unsigned int port_num; int ret; @@ -3330,6 +3331,15 @@ int ksz_switch_register(struct ksz_device *dev) return ret; } + /* Do not proceed further if device tree setup is not done. + * dsa_register_switch() will not report error in case of + * cascaded switch. This will lead to scheduling mib read + * work and kernel warning. + */ + dst = dev->ds->dst; + if (!dst->setup) + return 0; + /* Read MIB counters every 30 seconds to avoid overflow. */ dev->mib_read_interval = msecs_to_jiffies(5000);