Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp5393382rwd; Mon, 12 Jun 2023 04:38:56 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ51jZt6Tw533vRDPTEdntTxQ7rwahiAtbM5mLhmi0B4z5eu0bIu/H3kGbTP4OWHGAITfr7t X-Received: by 2002:a05:6a20:394f:b0:100:6f8f:7793 with SMTP id r15-20020a056a20394f00b001006f8f7793mr10213882pzg.3.1686569935910; Mon, 12 Jun 2023 04:38:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686569935; cv=none; d=google.com; s=arc-20160816; b=SJC5PnP8m1iS8++WL3d03cnbWtMf4LIanCfQuMJ7+AZGtoTboESmVxEqMov+ASakZE EJ63J/VM/VXsgS2ulnIyxf6/CZkhifLddIw9jI84C3mWrzjds/f3J2hzD809b6q90aJL FcAnfEHiR1WSeeGiHAqI+4UrsMP9f/mfpVFiI+EJzH8rMhe1DrIEhKYZ29GWdPHDupw4 h6lBsQryZUTbYiimtoM7Ik34Bl+gsRq6rSK0Mj0mD8KLDcdHERb2A8sAFI7JPGIlX0xR LlM3DMT6J7P0R1qF+Jek5uHL8R7bPV4zQB06BZmxxdopPxvss+bm/kTEW5eIk6Ks15ZY SjBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=+yjKKzdnGV2UUsk+B6shVDCi3BDA94ELYFsM4QUhQB0=; b=R1sRClrn+65L7B6iUgTHWl0G7eme9D2ioY2QjAoDlfG/PR05x4IBEcXMGJiS0btv5L /y/JzTebR4wuR84X/k1ElfuUWGAsaHes2ErFm4a4fBc4WClcc7Gv6N5kHMRCF0IjPU8b Gp/82n7lQq5onl3aTRRfwkEoXChsHCcPAxnyHrYNrA551qQyoIVyAeKuZcRUaERS7nPi ZW0BAQzn2eYdUGH2yeq2+e0KExvd8uC4qveMk2psScndXkWiL+ALtpnxVqUtENcujtP8 +2yjcgOyf0+y1G8h75FI0QYhMAfVBR3aNo6a2KTXU4M6jcMIrqQQFFbaGQ52tg+0S83C LcGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=Q9gFFEqB; 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=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 71-20020a63004a000000b00535f192827bsi7114696pga.542.2023.06.12.04.38.43; Mon, 12 Jun 2023 04:38:55 -0700 (PDT) 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=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=Q9gFFEqB; 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=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233889AbjFLKaS (ORCPT + 99 others); Mon, 12 Jun 2023 06:30:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235495AbjFLK3w (ORCPT ); Mon, 12 Jun 2023 06:29:52 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B50A5F7DE; Mon, 12 Jun 2023 03:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+yjKKzdnGV2UUsk+B6shVDCi3BDA94ELYFsM4QUhQB0=; b=Q9gFFEqBJOoqsKLY+1HuM+QoVW esIoL5PNJsyp5o0kQ7sCIo6rBNpWJA0C4ZR6IssVf8AGR1cmTzDj3yUus70hPty1PuVkq2Yo4iccw oNvlotm6b5P62z4/jwNxaIc+hIgCUE6hRyozSs/QJiMiNr+9w0cc9oDGH0p30pnCHlU/utsD352bs cswMCUjp3aE0AGGUiBh4Du0xu5460W9Q+q44WDlxsFsXDM/49r977+cct8GQ2M/U0UZ1s0RII75WL YAXGsjMJFN/dyxpgnsjuMQWUFGNxOtrJmpZg3Pt91fwwpiDJODPPMohE4EluptIL9uH7fSv251BvW 1C1wTYrQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:43862) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q8eU9-0005V0-P3; Mon, 12 Jun 2023 11:09:17 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1q8eU2-0004rh-NT; Mon, 12 Jun 2023 11:09:10 +0100 Date: Mon, 12 Jun 2023 11:09:10 +0100 From: "Russell King (Oracle)" To: =?utf-8?B?QXLEsW7DpyDDnE5BTA==?= Cc: Daniel Golle , Landen Chao , DENG Qingfang , Sean Wang , Andrew Lunn , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Matthias Brugger , AngeloGioacchino Del Regno , Frank Wunderlich , Bartel Eerdekens , mithat.guner@xeront.com, erkin.bozoglu@xeront.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH net v2 1/7] net: dsa: mt7530: fix trapping frames with multiple CPU ports on MT7531 Message-ID: References: <20230611081547.26747-1-arinc.unal@arinc9.com> <9d571682-7271-2a5e-8079-900d14a5d7cd@arinc9.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9d571682-7271-2a5e-8079-900d14a5d7cd@arinc9.com> Sender: Russell King (Oracle) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 12, 2023 at 09:40:45AM +0300, Arınç ÜNAL wrote: > On 11.06.2023 19:04, Russell King (Oracle) wrote: > > On Sun, Jun 11, 2023 at 11:15:41AM +0300, Arınç ÜNAL wrote: > > > Every bit of the CPU port bitmap for MT7531 and the switch on the MT7988 > > > SoC represents a CPU port to trap frames to. These switches trap frames to > > > the CPU port the user port, which the frames are received from, is affine > > > to. > > > > I think you need to reword that, because at least I went "err what" - > > especially the second sentence! > > Sure, how does this sound: > > These switches trap frames to the CPU port that is affine to the user port > from which the frames are received. "... to the inbound user port." I think that's a better way to describe "user port from which the frames are received." However, I'm still struggling to understand what the overall message for this entire commit log actually is. The actual affinity of the user ports seems to be not relevant, but this commit is more about telling the switch which of its ports are CPU ports. So, if the problem is that we only end up with a single port set as a CPU port when there are multiple, isn't it going to be better to say something like: "For MT7531 and the switch on MT7988, we are not correctly indicating which ports are CPU ports when we have more than one CPU port. In order to solve this, we need to set multiple bits in the XYZ register so the switch will trap frames to the appropriate CPU port for frames received on the inbound user port. > > > Currently, only the bit that corresponds to the first found CPU port is set > > > on the bitmap. > > > > Ok. > > > > > When multiple CPU ports are being used, frames from the user > > > ports affine to the other CPU port which are set to be trapped will be > > > dropped as the affine CPU port is not set on the bitmap. > > > > Hmm. I think this is trying to say: > > > > "When multiple CPU ports are being used, trapped frames from user ports > > not affine to the first CPU port will be dropped we do not set these > > ports as being affine to the second CPU port." > > Yes but it's not the affinity we set here. It's to enable the CPU port for > trapping. In light of that, is the problem that we only enable one CPU port to receive trapped frames from their affine user ports? > > > Only the MT7531 > > > switch is affected as there's only one port to be used as a CPU port on the > > > switch on the MT7988 SoC. > > > > Erm, hang on. The previous bit indicated there was a problem when there > > are multiple CPU ports, but here you're saying that only one switch is > > affected - and that switch has only one CPU port. This at the very least > > raises eyebrows, because it's just contradicted the first part > > explaining when there's a problem. > > I meant to say, since I already explained at the start of the patch log that > this patch changes the bits of the CPU port bitmap for MT7531 and the switch > on the MT7988 SoC, only MT7531 is affected as there's only a single CPU port > on the switch on the MT7988 SoC. So the switch on the MT7988 SoC cannot be > affected. > > > > > > diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c > > > index 9bc54e1348cb..8ab4718abb06 100644 > > > --- a/drivers/net/dsa/mt7530.c > > > +++ b/drivers/net/dsa/mt7530.c > > > @@ -1010,6 +1010,14 @@ mt753x_cpu_port_enable(struct dsa_switch *ds, int port) > > > if (priv->id == ID_MT7621) > > > mt7530_rmw(priv, MT7530_MFC, CPU_MASK, CPU_EN | CPU_PORT(port)); > > > + /* Add the CPU port to the CPU port bitmap for MT7531 and the switch on > > > + * the MT7988 SoC. Any frames set for trapping to CPU port will be > > > + * trapped to the CPU port the user port, which the frames are received > > > + * from, is affine to. > > > > Please reword the second sentence. > > Any frames set for trapping to CPU port will be trapped to the CPU port that > is affine to the user port from which the frames are received. Too many "port"s. Would: "Add this port to the CPU port bitmap for the MT7531 and switch on the MT7988. Trapped frames will be sent to the CPU port that is affine to the inbound user port." explain it better? Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!