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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CF802EB64D7 for ; Tue, 13 Jun 2023 20:47:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To: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-Owner; bh=SVCZnQoW7rlY6qxCkF2Dd0LZ8voxnR5I3RQjPdbpr3s=; b=LeGD6iJ0M9YALc qYvb4QxEZq5MNcij2z4b9KE5sk2p9/tuD/0mqh4lLofbtciIiNMRQZCUMrHA7NNVItwsIrvkCpFDU RO3zSM/PG1gECaDjGge7s+5sBusJSMLfmwRYhWZ7ypw4HcdkIlF2FY6wXdL39kS98PFBhJQl7pPVi gM51uvoveOOp1R9/RuK5RYR9nmvVpbA5yMY5wZuYIN1Sr7W+vU+g4ogJ6eLdcoyBE1gYhReLP1gz+ LF2boOIFFZeTIuWb7eoM6cZTpFmMSmYdaatoBKisuSPK4JU0Ext29x167Tq20a3Le0wptN8tF5mdm 6gNq574fVn1mWkXc4xEA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q9Av0-0098Ji-04; Tue, 13 Jun 2023 20:47:10 +0000 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q9Auv-0098Hq-2r; Tue, 13 Jun 2023 20:47:08 +0000 Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-51879487e18so1544402a12.3; Tue, 13 Jun 2023 13:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686689219; x=1689281219; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=fSNOwltAQrxAVV68XPYGPjq5L/bIYHyNYEji3sovMB8=; b=Ls9NCRlivmPC49auVyJHDRF+h04dMXwMGmh110SKXer2GYxSqLJ9P1EGp0FjvkdV5Y ZT59hga7BfF3nhKADgA++VIjISbHOXjbarrE22ZfAE111jgQ3jK7jtShuQEjePBTdLis yciak/fmFmqGLf0kPVtaE83SgyEUNf4EYJ8t+BcD70N9SeDplDhhnv21ndbgohUjIo3Q qoIFrDRIjD3zlcF+yzNquVLT03HQips/sNO/bgOKLbcYVEkAQUc21wT7i4P3CHKfFH3E JBqhJVUG2DsUf/DTTO0WW993S6gOxx5pmwiBMHSV5JbAOZ/Gt2Ydgt6O9rNJJ0aBuvZC X8tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686689219; x=1689281219; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fSNOwltAQrxAVV68XPYGPjq5L/bIYHyNYEji3sovMB8=; b=cknaz6aBnAnq5wwVAIC77GgOAKEnrTInPxxtiVCpS7LvGZhi/KG6BfPmIm7gQ//yae 8zHadk0MAHoqubPH0JrR641HZOJVQQFhR+2O8S1Tg+/2I069v1ZrgFwTZ7PA76vUQ6Zc AwwW7xt3zaVvr2AqRRWZwTQSvNF9vHQNcaSYI67qUlhhe1dTwzFNIVckt0ADX4y1SW18 6dZEUvePeTUCNgRalSNWvANbeOyYl0YgHz9n/h9RdrPK88GQddEFMWaAUmMiaZ3MqMVz 3gYrym82eYa4sI/sovkIPmA2VyVPYgRj5+6JG8jxwDZXZU5rGzHGMgZHRGu0XHHULgb2 qPvw== X-Gm-Message-State: AC+VfDxuhHXzoyAZe0qGepuA1a8UJJ5Is4p/sEdwUl1l7C8E9CxEjjD6 Ke3QwME7P2ZhzE7G7k8OcJ0= X-Google-Smtp-Source: ACHHUZ5x08A9ldgu+vaqcgdfWvL3xxuzZM1dqATv5NQNkKaCgRk/Z49H2tvIClpjTgNoxcUIajTGMw== X-Received: by 2002:a05:6402:2055:b0:514:9df0:e3f3 with SMTP id bc21-20020a056402205500b005149df0e3f3mr9203260edb.0.1686689219118; Tue, 13 Jun 2023 13:46:59 -0700 (PDT) Received: from skbuf ([188.27.184.189]) by smtp.gmail.com with ESMTPSA id b14-20020aa7c6ce000000b00506987c5c71sm6802283eds.70.2023.06.13.13.46.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jun 2023 13:46:58 -0700 (PDT) Date: Tue, 13 Jun 2023 23:46:55 +0300 From: Vladimir Oltean To: "Russell King (Oracle)" Cc: =?utf-8?B?QXLEsW7DpyDDnE5BTA==?= , Daniel Golle , Landen Chao , DENG Qingfang , Sean Wang , Andrew Lunn , Florian Fainelli , "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 2/7] net: dsa: mt7530: fix trapping frames with multiple CPU ports on MT7530 Message-ID: <20230613204655.7dk5f5pbcyrquva5@skbuf> References: <20230611081547.26747-1-arinc.unal@arinc9.com> <20230611081547.26747-2-arinc.unal@arinc9.com> <20230613150815.67uoz3cvvwgmhdp2@skbuf> <20230613171858.ybhtlwxqwp7gyrfs@skbuf> <20230613172402.grdpgago6in4jogq@skbuf> <20230613173908.iuofbuvkanwyr7as@skbuf> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230613_134705_924610_88651BE9 X-CRM114-Status: GOOD ( 28.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 13, 2023 at 07:29:18PM +0100, Russell King (Oracle) wrote: > Maybe it's just me being dumb, but I keep finding things difficult to > understand, such as the above paragraph. > > It sounds like you're saying that _before_ this patch, port 5 is the > active CPU port, but the CPU_PORT *FIELD* NOT BITS are set such that > port 6 is the active CPU port. Therefore, things are broken, and this > patch fixes it. > > Or are you saying that after this patch is applied, port 5 is the > active CPU port, but the CPU_PORT *FIELD* is set to port 6. If that's > true, then I've no idea what the hell is going on here because it > seems to be senseless. There are 2 distinct patches at play. I'll be showing some tables below. Their legend is that patch (1) affects only the second column and patch (2) affects only the third column. Patch (1): net: dsa: mt7530: fix trapping frames with multiple CPU ports on MT7530 ---------------------------------------------------------------------------------- What you need to know looking at the current code in net-next is that mt753x_cpu_port_enable() always overwrites the CPU_MASK field of MT7530_MFC, because that contains a single port. So when operating on a device tree with multiple CPU ports defined, only the last CPU port will be recorded in that register, and this will affect the destination port for trapped-to-CPU frames. However, DSA, when operating on a DT with multiple CPU ports, makes the dp->cpu_dp pointer of all user ports equal to the first CPU port. That affects which DSA master is automatically brought up when user ports are brought up. Minor issue, TBH, because it is sufficient for the user to manually bring up the DSA master corresponding to the second CPU port, and then trapped frames would be processed just fine. Prior to ~2021/v5.12, that facility wasn't even a thing - the user always had to bring that interface up manually. That means that without patch (1) we have: CPU ports in the Trapping CPU port Default CPU port device tree (MT7530_MFC:CPU_MASK) (all dp->cpu_dp point to it) ------------------------------------------------------------------------- 5 5 5 6 6 6 5 and 6 6 5 The semi-problem is that the DSA master of the trapping port (6) is not automatically brought up by the dsa_slave_open() logic, because no slave has port 6 (the trapping port) as a master. All that this patch is doing is that it moves around the trapping CPU port towards one of the DSA masters that is up, so that the user doesn't really need to care. The table becomes: CPU ports in the Trapping CPU port Default CPU port device tree (MT7530_MFC:CPU_MASK) (all dp->cpu_dp point to it) -------------------------------------------------------------------------- 5 5 5 6 6 6 5 and 6 5 5 Patch (2) net: dsa: introduce preferred_default_local_cpu_port and use on MT7530 -------------------------------------------------------------------------------- This patch influences the choice that DSA makes when it comes to the dp->cpu_dp assignments of user ports, when fed a device tree with multiple CPU ports. The preference of the mt7530 driver is: if port 6 is defined in the DT as a CPU port, choose that. Otherwise don't care (which implicitly means: let DSA pick the first CPU port that is defined there, be it 5 or 6). The effect of this patch taken in isolation is (showing only "after", because "before" is the same as the "before" of patch 1): CPU ports in the Trapping CPU port Default CPU port device tree (MT7530_MFC:CPU_MASK) (all dp->cpu_dp point to it) ------------------------------------------------------------------------- 5 5 5 6 6 6 5 and 6 6 6 As you can see, patch (2) resolves the same semi-problem even in isolation because it makes the trapping port coincide with the default CPU port in a different way. > > I think at this point I just give up trying to understand what the > hell these patches are trying to do - in my opinion, the commit > messages are worded attrociously and incomprehensively. +1, could have been better.. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel