From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from trager.us (trager.us [52.5.81.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D7001C2324 for ; Mon, 22 Jun 2026 19:06:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=52.5.81.116 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782155195; cv=none; b=p6UoP4B6swTWnzH0AU9MsxcR99M93Q2JEzckmErGs8IbewfSOhdzn4KVj/+4PLpOiEUHeQA+YaBfATfNnAK1c34TSG8m8cAdhbKiomVcuWjeV5PXONTO1wDsjoT5IYGVaOmn9c1qcJqXkhyAuRN569JfMgpatE4qay4+3Ngx1gQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782155195; c=relaxed/simple; bh=jg+J7Z05s/OxCLHQHKhL8Q8/aSgcFvwJWjp91o97TcY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=sAwbhwuTyKeYEDpL9gh/VH6lMlKkNce6tw3DGvPJRmZ6zkvYqBY2q5dTGtRfIwDuLBGAetmxjZirvTcfr/3RCTYeaY36v3URG0a6HNTToA/fXxdNRDuFg8d3kUF6jq/2w8+xW121tVGca+IcYo9FmAgc4Mpm9Yt7LwCF1x6q+JY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=trager.us; spf=pass smtp.mailfrom=trager.us; arc=none smtp.client-ip=52.5.81.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=trager.us Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=trager.us Received: from c-76-104-255-50.hsd1.wa.comcast.net ([76.104.255.50] helo=[192.168.1.225]) by trager.us with esmtpsa (TLSv1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.92.3) (envelope-from ) id 1wbj76-0006Ku-Mm; Mon, 22 Jun 2026 18:11:16 +0000 Message-ID: Date: Mon, 22 Jun 2026 11:11:09 -0700 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Ethtool : PRBS feature To: "Das, Shubham" , Maxime Chevallier , Andrew Lunn Cc: Alexander H Duyck , "netdev@vger.kernel.org" , "mkubecek@suse.cz" , "D H, Siddaraju" , "Chintalapalle, Balaji" , "Lindberg, Magnus" , "niklas.damberg@ericsson.com" References: <06d8c98da24e80d148ede4e933bb621c5515a7a2.camel@gmail.com> <26971635-b13a-4ed3-b2cb-ce35da9b63d3@lunn.ch> Content-Language: en-US From: Lee Trager In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/22/26 8:38 AM, Das, Shubham wrote: > Hi Maxime, > >> Can you elaborate on what you have in mind for now ? what would the "ethtool -- >> phy-test" command look like in terms of its behaviour and parameters ? > We are trying to converge on a userspace uAPI for PRBS/BERT functionality that can work across > different hardware models (PHY-managed, MAC/NIC-offloaded, or firmware-based implementations), > without exposing those differences to userspace. This was my original thought as well. Create a well defined uAPI for PRBS testing/TX FIR tuning and allow the driver to implement support however it sees fit. Since our target is for ethernet devices ethtool was a natural spot for the uAPI. I presented this at netdev last year and received strong push back against associating PRBS testing/TX FIR tuning with ethtool. The argument being any new uAPI added to the kernel should be generic enough to handle future use cases so duplicate uAPIs don't have to be added. Since PRBS testing/TX FIR tuning can be done on many phys(Ethernet, PCIE, USB, etc) the uAPI does not belong in ethtool and needs to be structured to support other use cases. As drivers/phy is the base phy library the thought was support should be added in drivers/phy and a new phytool should be created to interact with a uAPI. This would be generic enough to support all use cases, with the downside being existing drivers would have to onboard to drivers/phy. I do wonder if the best path forward would be to create phytool in a way that allows the driver to implement PRBS testing/TX FIR tuning as it sees fit instead of being strictly tied to drivers/phy. > > Based on the functionality we currently have, we proposed below commands in first email : > > PRBS Transmitter/Checker Pattern Configuration: > ethtool --phy-test eth1 tx-prbs prbs7 > ethtool --phy-test eth2 rx-prbs prbs7 > > BERT Test: > ethtool --phy-test eth2 bert start > ethtool --phy-test eth2 bert stop > > BERT Test Counter Read/ PRBS Lock Status: > ethtool --phy-test eth2 stats > > BERT Clear stats - Symbol and Error counter: > ethtool --phy-test eth2 clear-stats > > TX Error Injection: > ethtool --phy-test eth1 inject-error 1 > ethtool --phy-test eth1 inject-error 1e-3 > > Disable PRBS Pattern : TX/RX > ethtool --phy-test eth1 tx-prbs off > ethtool --phy-test eth2 rx-prbs off The goal of running testing is to validate TX FIR values. If testing fails we need a uAPI to change those values. Also the uAPI need to support testing per lane. One thing hardware engineers at Meta did was test each lane with a different set of TX FIR values which allowed them to quickly determine the best set of values. > > Approach would be to add a generic ethtool netlink API for PHY/SerDes and allow drivers to implement the operations directly. > Conceptually: > ethtool ⇒ ethtool netlink ⇒ driver-specific implementation > > We would appreciate your input on whether a command-based model is suitable for a uAPI, and how we should design > it to accommodate different implementation models, such as PHY-based, phylib-based, and MAC/firmware-offloaded PRBS. > > - Shubham D > >> -----Original Message----- >> From: Maxime Chevallier >> Sent: 20 June 2026 20:09 >> To: Das, Shubham ; Andrew Lunn >> Cc: Alexander H Duyck ; lee@trager.us; >> netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju >> ; Chintalapalle, Balaji >> ; Lindberg, Magnus >> ; niklas.damberg@ericsson.com >> Subject: Re: Ethtool : PRBS feature >> >> Hi, >> >> On 6/20/26 15:48, Das, Shubham wrote: >>>> Can you change the firmware to expose the 802.3 registers for PRBS? >>>> You can then write a library which both plylib and your driver can use. >>> Andrew, >>> >>> No, exposing the PRBS registers to drivers is not possible in our design (the >> registers are buried deep within the Accelerator/NIC/PHY/Analog IP hierarchy). >>> Additionally, the PHY PRBS registers are not in accordance with the IEEE Clause >> 45 definitions. For instance, the PRBS registers are paged and 32-bit wide. >>> Given these constraints, we think ethtool --phy-test is a reasonable starting >> point for exposing the long-established Ethernet PRBS functionality to Linux >> userspace, as it aligns well with the driver-owned NIC architecture model. If you >> think a more generic layered approach would be preferable, we would appreciate >> guidance on the expected architecture. That would help us better understand the >> implementation complexity, required effort, and delivery timelines. >> >> Can you elaborate on what you have in mind for now ? what would the "ethtool -- >> phy-test" command look like in terms of its behaviour and parameters ? >> >> This feature is interesting for multiple people, each having different hardware >> designs and constraints. It's good to consider an iterative approach to build this, >> however we need to have in mind that this is uAPI, so once we commit to a design >> choice, we have to live with it. >> >> We do have flexibility on the kernel side of the API. We can implement PRBS in >> generic PHY, phylib, some MAC driver that talks to a firmware, etc. and hide away >> these implementation details to userspace, but we need to make sure the uAPI >> we come up with allows us to support all of that. >> >> Let's figure this out together, if you already have some ideas in mind we can use >> that as a starting point for the discussion :) >> >> Maxime >> >>> Thanks, >>> Shubham D >>> >>>> -----Original Message----- >>>> From: Andrew Lunn >>>> Sent: 20 June 2026 00:07 >>>> To: Das, Shubham >>>> Cc: Alexander H Duyck ; lee@trager.us; >>>> netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju >>>> ; Chintalapalle, Balaji >>>> ; Lindberg, Magnus >>>> ; niklas.damberg@ericsson.com >>>> Subject: Re: Ethtool : PRBS feature >>>> >>>>> The host driver does not directly access any registers but requests >>>>> the PHY FW to manage PRBS on behalf of it. >>>> Maybe a dumb question. Why? >>>> >>>> Can you change the firmware to expose the 802.3 registers for PRBS? >>>> You can then write a library which both plylib and your driver can use. >>>> >>>> Andrew