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 smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.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 72834C4332F for ; Fri, 10 Nov 2023 08:10:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id EB71C40182; Fri, 10 Nov 2023 08:10:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EB71C40182 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1699603841; bh=vpCtbjOQYB7CbGmDZeC8zhL9z85yZ9rjhQgjRnIMeNA=; h=Date:To:References:From:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=LEdtYIglreFhDzqtbO03WVK8mrVptsa9NWCEZY5Jgs7IcfXGUZyPJfO7KSD4YMlPG aooWMgs1Hjv5RKqkL5bRIpdyskYsdboHe76dkUl+6HVEdejPqE9TkrlFrlVleo0ORA fB9G70WN4ollBDzzfWFVl9s90U42YHo/eP1rBT4YedGqxvST9Y+lULnfzYMdp2CMpG 1Qy2Uc7BJ9TaRX6iXC3lZvdmPCejoIZbzshnoLYuU9bpvUJTKbCc09tTyD1P0CFBeD hpsbucK/tiqBn673QGKgNVQLPjkBxtK9XakUv9n+PCQ83j93e1vVfYWpGGwX2M1rJF HZ73MhtOD75+A== X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBhze9496vdH; Fri, 10 Nov 2023 08:10:39 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp2.osuosl.org (Postfix) with ESMTP id 0F8A740424; Fri, 10 Nov 2023 08:10:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0F8A740424 Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by ash.osuosl.org (Postfix) with ESMTP id 883A61BF2FF for ; Fri, 10 Nov 2023 08:10:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5BDD260E22 for ; Fri, 10 Nov 2023 08:10:37 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5BDD260E22 X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK-3C7mMyxAM for ; Fri, 10 Nov 2023 08:10:36 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by smtp3.osuosl.org (Postfix) with ESMTPS id 7905E60E03 for ; Fri, 10 Nov 2023 08:10:36 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7905E60E03 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-185-v6VMaS5TP3inGFLqfefYRg-1; Fri, 10 Nov 2023 03:10:33 -0500 X-MC-Unique: v6VMaS5TP3inGFLqfefYRg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 67A0085A5B5; Fri, 10 Nov 2023 08:10:33 +0000 (UTC) Received: from [10.45.225.136] (unknown [10.45.225.136]) by smtp.corp.redhat.com (Postfix) with ESMTP id E98BFC1290F; Fri, 10 Nov 2023 08:10:31 +0000 (UTC) Message-ID: Date: Fri, 10 Nov 2023 09:10:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Jesse Brandeburg , intel-wired-lan@lists.osuosl.org References: <20231108151018.72670-1-ivecera@redhat.com> Content-Language: en-US From: Ivan Vecera In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699603835; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4GQjFWahYGq4tfrY4kZ+Y1bC9y7ReN8MIM0FcjIcMww=; b=gjFanukJG4ebPRZvoMRFxdupnfTMLG5IsOeoFiw3mgKkffGFYyepRTcbXNJukMFdNQG6/s MQ8w2INMXWocbflUFpxY3Hzpmm3G/B1mwY+wfeG919xelGtBMDVMe9p5Xx0Xb6bSNPrRjO puW17N0JiEXaEjwA1aA+rsd0y+bSKNk= X-Mailman-Original-Authentication-Results: smtp3.osuosl.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=gjFanukJ Subject: Re: [Intel-wired-lan] [PATCH iwl-net] i40e: Fix max frame size check X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Wojciech Drewek , "open list:NETWORKING DRIVERS" , Eric Dumazet , Tony Nguyen , Jacob Keller , Jakub Kicinski , Paolo Abeni , "David S. Miller" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On 08. 11. 23 21:38, Jesse Brandeburg wrote: > On 11/8/2023 7:10 AM, Ivan Vecera wrote: >> Commit 3a2c6ced90e1 ("i40e: Add a check to see if MFS is set") added >> a check for port's MFS (max frame size) value. The value is stored >> in PRTGL_SAH register for each physical port. According datasheet this >> register is defined as: >> >> PRTGL_SAH[PRT]: (0x001E2140 + 0x4*PRT, PRT=0...3) >> >> where PRT is physical port number. > > > > Was there an actual problem here? I suspect if you read all the > registers for each PF's BAR, you'll find that all 4 report the same, > correct value, for the perspective of the BAR they're being read from. > > The i40e hardware does this (somewhat non-obvious) for *lots* of port > specific registers, and what happens is no matter which of the 4 you > read the value from, you'll get the right "port specific" value. This is > because the hardware designers decided to make a different "view" on the > register set depending on which PF you access it from. The only time > these offsets matter is when the part is in debug mode or when the > firmware is reading the internal registers (from the internal firmware > register space - which has no aliasing) that rely on the correct offset. > > In this case, I think your change won't make any functional difference, > but I can see why you want to make the change as the code doesn't match > the datasheet's definition of the register. > > That all said, unless you can prove a problem, I'm relatively sure that > nothing is wrong here in functionality or code. And if you go this > route, there might be a lot of other registers to fix that have the same > aliasing. > > I apologize for the confusing manuals and header file, it's complicated > but in practice works really well. Effectively you can't read other > port's registers by accident. > > Here was my experiment showing the aliasing on X722. You'll note that > the lower 16 bits are a MAC address that doesn't change no matter which > register you read. > > device 20:0.0 > 0x1e2140 == 0x26008245 > 0x1e2144 == 0x26008245 > 0x1e2148 == 0x26008245 > 0x1e214c == 0x26008245 > device 20:0.1 > 0x1e2140 == 0x26008345 > 0x1e2144 == 0x26008345 > 0x1e2148 == 0x26008345 > 0x1e214c == 0x26008345 > device 20:0.2 > 0x1e2140 == 0x26008445 > 0x1e2144 == 0x26008445 > 0x1e2148 == 0x26008445 > 0x1e214c == 0x26008445 > device 20:0.3 > 0x1e2140 == 0x26008545 > 0x1e2144 == 0x26008545 > 0x1e2148 == 0x26008545 > 0x1e214c == 0x26008545 > > lspci -d ::0200 > 20:00.0 Ethernet controller: Intel Corporation Ethernet Connection X722 > for 10GBASE-T (rev 04) > 20:00.1 Ethernet controller: Intel Corporation Ethernet Connection X722 > for 10GBASE-T (rev 04) > 20:00.2 Ethernet controller: Intel Corporation Ethernet Connection X722 > for 10GbE SFP+ (rev 04) > 20:00.3 Ethernet controller: Intel Corporation Ethernet Connection X722 > for 10GbE SFP+ (rev 04) > > Hope this helps! Hi Jesse, thanks a lot for the explanation. I found this during preparation of my iwl-next stuff and found that variable 'i' is used inappropriately so I checked also the datasheet and found the definition of PRTGL_SAH register that is defined per port but I didn't know there is such aliasing for registers in PF BAR space. I will send a new patch that at least fix the wrong usage of 'i' variable. Thanks, Ivan _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan