Date:   Mon, 6 Feb 2023 22:42:28 +0200
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     =?utf-8?B?QXLEsW7DpyDDnE5BTA==?= <arinc.unal@arinc9.com>
Cc:     netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Sean Wang <sean.wang@mediatek.com>,
        Landen Chao <Landen.Chao@mediatek.com>,
        DENG Qingfang <dqfext@gmail.com>, Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org,
        Frank Wunderlich <frank-w@public-files.de>,
        erkin.bozoglu@xeront.com, richard@routerhints.com
Subject: Re: [PATCH net] net: dsa: mt7530: don't change PVC_EG_TAG when CPU
 port becomes VLAN-aware
Message-ID: <20230206204228.sa45cvco6bltidwq@skbuf>
References: <20230205203906.i3jci4pxd6mw74in@skbuf>
 <b055e42f-ff0f-d05a-d462-961694b035c1@arinc9.com>
 <20230205235053.g5cttegcdsvh7uk3@skbuf>
 <116ff532-4ebc-4422-6599-1d5872ff9eb8@arinc9.com>
 <20230206174627.mv4ljr4gtkpr7w55@skbuf>
 <5e474cb7-446c-d44a-47f6-f679ae121335@arinc9.com>
 <f297c2c4-6e7c-57ac-2394-f6025d309b9d@arinc9.com>
 <f297c2c4-6e7c-57ac-2394-f6025d309b9d@arinc9.com>
 <20230206203335.6uxfiylftyktut5u@skbuf>
 <4ee5df8d-618b-db78-9c14-17a45e383b67@arinc9.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4ee5df8d-618b-db78-9c14-17a45e383b67@arinc9.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SkM2RVBjNDNmbENGaVdUZW5IQkR4U0JtNjlpei9OYVNEb3RQbEZCdlVEMU5U?=
 =?utf-8?B?VzRldm1vWDhCNGF5cWxDRUx2Um1vSysvL0JYdTlXUklnaC9vREhadVFBZlBT?=
 =?utf-8?B?d0dQNWR0RlNnVi9pV2JBemNJL2M3MGgvTFBiM0p2Y3ZnR2ZqYnRsWnlPZTNX?=
 =?utf-8?B?T3gvOTBJWkN6U0RYS3F1MkJOc2VHNS9ZcXBjblJVbUJEVE5QZkw3cWwyOWFr?=
 =?utf-8?B?c0ZVN1hCSVBzZGwxVjJqZ3VaTVAwZGFjT2szdzVqTlhxVWpvZHBmTlZPVG4z?=
 =?utf-8?B?WmRVZFpScHVNVFpuQTJadWIxclMxNmhHWmQrdnpBTEJwQmFZOW5RUEZQS1VR?=
 =?utf-8?B?ZkZMYlpseFNUZ1NnTlFyd1M3TDgreko3VmJPekJEcEp0dEQwaHUxamNDVFVz?=
 =?utf-8?B?MjJ3S2dFMm0vdi9seVVZdjNrRXhFMlp5UHNzdVlwWmp6L3NRbHB1aTcxa3Jv?=
 =?utf-8?B?TVR1VTJGSTFRck56cXk0RDRwcHZvam9QWXY2UjFsVDd5WVRieVBYSU02alN1?=
 =?utf-8?B?TFI4dUdPL2pWRVErWWxSczVFSlFCbmlmRXhvSmxNNk5yYzNSanRkTXg2UGpn?=
 =?utf-8?B?VjBSMmUzQVZxNC9waWFLMmtSVHFGUS8xWVVRVlphTk1TaUdnciszMncxQ3Uz?=
 =?utf-8?B?ZlhSOCtaYWFxNVZndGxtbncrN3JMZlRSampuNTFMQmxObmtNOGdwNVlSdkNW?=
 =?utf-8?B?L21HL2pPbDBTclN5elJXaDJaaWkwcWJjdmY4Q1B6MUoxZkFuZWtuSllRR3kw?=
 =?utf-8?B?TUcxNFpuMGFuYU1VU2RKVmFyaVAybXl4WUM5bi85bXg0UnRLU0tLTytpMG4y?=
 =?utf-8?B?WURYVnRMMWVJYUxQNC82K1ErUHhESzRSdmRKU1MzZUplQ0tDZDVQcm9aZFBw?=
 =?utf-8?B?VFpIbWgvek9MZS9NRGFLMytCV3BXaGptWUJpZU01bnEya203V3ZSVjRpL3BD?=
 =?utf-8?B?NXpyVk5LYWVBU1FGNVBLWnZvRkN5S040b3NvaGNkei9WWERoTFVaZVBNcjVr?=
 =?utf-8?B?d1JhZTN0K21JdE9FTTlXenNBaU02ejNBbmE2L1IzSHE0eTkxQUp3TmF0OFA5?=
 =?utf-8?B?Y1pLMjlvUFVKRU5EQUYrS29mRWxFWjFJNnl1OGtHVHQwNzhCckJWdFFhKy8v?=
 =?utf-8?B?eUk5YVJQQ3Vubk1pbzhDM3MzTzFTTXFENkFuaEhrVWZJellLcjkvTkFWVVhk?=
 =?utf-8?B?V2hoU2kyUzA4NXI3YTk3MHlJQkpQaTVtY0VjcEdqK01IeFlRbDJZcmdhZ2s3?=
 =?utf-8?B?b1FBYVNFdG5mdVVWRnMwaElrK1JSUWFUdE1HSFV1V1JPWnRJbWhqYTg2RHVJ?=
 =?utf-8?B?Mm9VSEk5Vms1ZkI0eW1pMldmckhtOTJVTTVBL3FxU2dCK2VGMEhGdFVDZ3kz?=
 =?utf-8?B?RFZERGRiZTU5TkZNV1NVNWxwUGxBM3NoTmdqU0w5czQ0VGhZWWZYVGJ4eVJp?=
 =?utf-8?B?Unl5ZzBSVUNBR0p1eXRreG9FejdxdGpTWmRhZjlTY3h1dmNNb0RZbG1DODIy?=
 =?utf-8?B?YTYvYnA0VzlQeENhYy9VbThhWjBSRlBCakNRVnlDakl3bzBDOFA1eGo2ekJJ?=
 =?utf-8?B?Tjg5WHRXS3VhS0FIVDArOW5EemdYL2dtd1hwNmJ0MXQwRUZ4b0dxQmJGbWVw?=
 =?utf-8?B?dkNMRVBlanRZczRuZmVKeXBJT2lTT0Vudm54YjRjdkZUZkhJZnFyL0J5a1lH?=
 =?utf-8?B?M2J0bTY4NXpoN1REUFRMVENpRElMWXNjZkw4VTQwcm0rQnpHU1lzWGRmWDA1?=
 =?utf-8?B?ZUdCeWtkSml5QVJqSjhDSEtIUU9PMmczQVhkOU9ReUNBdEZNM2RjQm0rbjNL?=
 =?utf-8?B?TUdJZkRrRmJhTnBWV1orUndtcFI0NzVsWks4QnJVS3llOHdWYSttaWZNdzhP?=
 =?utf-8?B?NW5PMXRoYS9TdnQvNW9xN043OGhZZWR0MzlyeWJGSXdvOU1tSHdBdnhmSkJS?=
 =?utf-8?B?TlpFdngxY2tjMTU5N294RlM3YjNkaFBjWkdxNEpkMllpdys3R3ZZWjdnL3dk?=
 =?utf-8?B?OGtmT1hjemFxcGFKb3ptYTkrZS9jQkdiOU5GamhuUHdpOG9PUHBmQzlxZGtP?=
 =?utf-8?B?ZVdvbVpYc1R3QVo0MHhIMnd5Q0twdkloenRuSk9tL2VqeEhCNTZTa0crNjVq?=
 =?utf-8?B?cEdubUNNaUN3dk5kNXhhWHVxYXFzY2ozUU5oakZPQjd5dkJ4NHdJMjhhWmFP?=
 =?utf-8?B?bXc9PQ==?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a3522f80-2881-40e4-bf0b-08db0882ac32
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2023 20:42:33.3334
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 6iFOw9dihZ7eaUJW2UhV2x7qsOyFgVx5ZxRjipOOP0OSzUm/pRIn8RoTMQB/j9rCNcceQ/yptDJTAoHNy3rhkA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR04MB9437
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 06, 2023 at 11:35:50PM +0300, Arınç ÜNAL wrote:
> On 06/02/2023 23:33, Vladimir Oltean wrote:
> > On Mon, Feb 06, 2023 at 10:41:47PM +0300, Arınç ÜNAL wrote:
> > > One last thing. Specific to MT7530 switch in MT7621 SoC, if port@5 is the
> > > only CPU port defined on the devicetree, frames sent from DSA master appears
> > > malformed on the user port. Packet capture on computer connected to the user
> > > port is attached.
> > > 
> > > The ARP frames on the pcapng file are received on the DSA master, I captured
> > > them with tcpdump, and put it in the attachments. Then I start pinging from
> > > the DSA master and the malformed frames appear on the pcapng file.
> > > 
> > > It'd be great if you could take a look this final issue.
> > 
> > What phy-mode does port@5 use when it doesn't work? What about the DSA master?
> 
> It's rgmii on port@5 and gmac1.

What kind of RGMII? Plain "rgmii" on both ends, with no internal delays?
With RGMII, somebody must add a skew to the clock signal relative to the
data signals, so that setup/hold times at the other end are not violated.
Either the transmitter or the receiver can add RGMII delays in each
direction of communication, but someone must do it, and no more than one
entity should do it.

So my question would be: could you retry after replacing phy-mode = "rgmii"
with phy-mode = "rgmii-id" on port@5? And if that doesn't change anything
(unlikely but possible), also try "rgmii-txid" and "rgmii-rxid" in port@5?
Don't change the phy-mode on gmac1.