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 4F689C48BF6 for ; Thu, 29 Feb 2024 10:52:34 +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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1/b7H00xhRQYMWUbgaRXN+h+pWML52jJ5sjvts1Wwl0=; b=g2qa7Z5OLnLzBU MCOrqxppsznGKGvZY4oNCcLH7ZVCxfFeTV91TfRPI6iCBvBpdMhmsoZ9b9mpcRwbbA49t9ppdC2z5 VLiRVtjjAHrKT+w4w9yUMt+2vyQ139CKbnffXFwXM4WZMkwFkN0NrMErvMbOV1LKk78VYbsvjH90h ehIfu/Os5LeJIwJVFxABhB/1vUlSwlFfbh9T7L4UlLudiXzGgeGVC7E4uVbc0RITSZyVKN21tJoUo jS7mS4SFncr58KuuyxeMparGR85QjrJPpHCUZzTmDq9oUBUIdsOuuAv3ioLOF6H8OiyIkaup0YfZM /RTyxv8hvS/wn7ZeoKpw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfe1T-0000000DEqO-2cjD; Thu, 29 Feb 2024 10:52:19 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfe1Q-0000000DEob-253p for linux-arm-kernel@lists.infradead.org; Thu, 29 Feb 2024 10:52:18 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id C2A95CE2482; Thu, 29 Feb 2024 10:52:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40C61C433C7; Thu, 29 Feb 2024 10:52:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709203934; bh=tFIRN6AD7OJmcls33kRXGPl2Q5cmwc4WEirIvdGkHzU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qvy2HkJjQRFvy49WbBPN6hh/2n2KJejdturTF3m9Zr0Zr6A9utMib5ESLThImKW0F 9aonzpE+JIwUkl2pEbtSDK2hoiWbWKMF3dReGzkeM1B2bFt+o/Xd1DzUwiJ2Dnpf+n fobSTAdyYYl5i/4tCEzAH7ZDj8GMU3RpF7SkqDtKt08KKfzF5YD1rbQh0GFhYP5R4C Fqug2EHJQydIhLS8hYUv57Zxx/iWIn6ALQNXrLAIw7vqy9G1NZ0TjiuzCq0sNE9i65 ZI4qoMYGEFm0tesRCAtTC4eMu3Xsxn7z7xR0y6MmKnZEjMdaKKRRa8956NqvhLveQN yuD7qtUtBuZuA== Message-ID: <0106ce78-c83f-4552-a234-1bf7a33f1ed1@kernel.org> Date: Thu, 29 Feb 2024 12:52:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next] net: ethernet: ti: am65-cpsw: Add priv-flag for Switch VLAN Aware mode Content-Language: en-US To: Siddharth Vadapalli , Andrew Lunn Cc: Jiri Pirko , davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, vladimir.oltean@nxp.com, hkallweit1@gmail.com, dan.carpenter@linaro.org, horms@kernel.org, yuehaibing@huawei.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, srk@ti.com, Pekka Varis References: <20240227082815.2073826-1-s-vadapalli@ti.com> <7d1496da-100a-4336-b744-33e843eba930@ti.com> <49e531f7-9465-40ea-b604-22a3a7f13d62@ti.com> <10287788-614a-4eef-9c9c-a0ef4039b78f@lunn.ch> <0004e3d5-0f62-49dc-b51f-5a302006c303@ti.com> From: Roger Quadros In-Reply-To: <0004e3d5-0f62-49dc-b51f-5a302006c303@ti.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240229_025216_925799_DD3F0B18 X-CRM114-Status: GOOD ( 21.35 ) 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 29/02/2024 11:27, Siddharth Vadapalli wrote: > On Wed, Feb 28, 2024 at 02:36:55PM +0100, Andrew Lunn wrote: >>> What if there is no kernel behavior associated with it? How can it be mimicked >>> then? >> >> Simple. Implement the feature in software in the kernel for >> everybody. Then offload it to your hardware. >> >> Your hardware is an accelerator. You use it to accelerate what linux >> can already do. If Linux does not have the feature your accelerator >> has, that accelerator feature goes unused. > > Is it acceptable to have a macro in the Ethernet Driver to conditionally > disable/enable the feature (via setting the corresponding bit in the > register)? > > The current implementation is: > > /* Control register */ > writel(AM65_CPSW_CTL_P0_ENABLE | AM65_CPSW_CTL_P0_TX_CRC_REMOVE | > AM65_CPSW_CTL_VLAN_AWARE | AM65_CPSW_CTL_P0_RX_PAD, > common->cpsw_base + AM65_CPSW_REG_CTL); > > which sets the "AM65_CPSW_CTL_VLAN_AWARE" bit by default. > > Could it be changed to: > > #define TI_K3_CPSW_VLAN_AWARE 1 > > .... > > /* Control register */ > val = AM65_CPSW_CTL_P0_ENABLE | AM65_CPSW_CTL_P0_TX_CRC_REMOVE | > AM65_CPSW_CTL_P0_RX_PAD; > > #ifdef TI_K3_CPSW_VLAN_AWARE > val |= AM65_CPSW_CTL_VLAN_AWARE; > #endif > > writel(val, common->cpsw_base + AM65_CPSW_REG_CTL); > > Since no additional configuration is necessary to disable/enable the > functionality except clearing/setting a bit in a register, I am unsure of > the implementation for the offloading part being suggested. Please let me > know if the above implementation is an acceptable alternative. This doesn't really solve the problem as it leaves the question open as to who will set TI_K3_CPSW_VLAN_AWARE. And the configuration is then fixed at build. Can you please explain in which scenario the default case does not work for you? Why would end user want to disable VLAN_AWARE mode? TRM states "Transmit packets are NOT modified during switch egress when the VLAN_AWARE bit in the CPSW_CONTROL_REG register is cleared to 0h. This means that the switch is not in VLAN-aware mode." The same problem would also apply to cpsw.c and cpsw_new.c correct? A bit later the driver does this /* switch to vlan unaware mode */ cpsw_ale_control_set(common->ale, HOST_PORT_NUM, ALE_VLAN_AWARE, 1); cpsw_ale_control_set(common->ale, HOST_PORT_NUM, ALE_PORT_STATE, ALE_PORT_STATE_FORWARD); The comment says vlan unaware but code is setting ALE_VLAN_AWARE to 1. Is the comment wrong? -- cheers, -roger _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel