From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BAD7A34E755 for ; Thu, 26 Mar 2026 09:42:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774518139; cv=none; b=cEPVocaM2ujJizICOMhtJnPUXF2V1B59AAjQ8dHNgdimh/yJ55JK94PEP/CHxqNCLvIg2zSl40TkdU5szOTn+8PmXtHx8R7lM0xnZNFwCjBb0TlIReordrOjhwCKr8MTpZAj9WEw8TV10JN2uDCAEdII70lMR4+GvQUY3hj7Lvk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774518139; c=relaxed/simple; bh=zWYr+qztsci4xUDGsyVLLiu2KnsGt694wGsFHwa6Opg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qiQoROqzFo9HSK8M6kwUnJ+6anQc68MYGvGtyn4FeU8I9BrCW/CbQ+RmMjz1Sd+0rSX+YPxOJZU7hy3fKBfvU3fIUolQxCUAHdJuln2ZFNRAsZV2yAFFs/dUVNeRq5rZjzPUUcS/32UriGPwLZ/xFnhzjG/b1HzkcF7EsMxxdoA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=piMiAPR+; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="piMiAPR+" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4836fc075d2so1102365e9.0 for ; Thu, 26 Mar 2026 02:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774518136; x=1775122936; darn=vger.kernel.org; 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=Z9S62wraGGWuFLRViippcyE9BcofvCghK7ZcArgqLNk=; b=piMiAPR+i/MtUreI5lcRQhNR1sxSQxR0s8BunWlNE63YHIzodoGBtYe8Cq+uGkHciE 81ZIp37W461krMciGMN7KKy3cSsyEBYmR+7rjziPzpv0lBp2HulPjrBNEh7LzNtrvtv1 h/OR3EREDU1r1NzvpG2571WyLQsR9q1QCAuHymvF2JwR4/dkzrF6WXhyzYWMwR9H1L4V eoiv+n1krHcKb6AJ+1K4RO+gWQQbH3ONFL5PPfzJrgb7wZO7wsGnZoQk+5cd8/tg8uIo w2+8B/+41FTYXzV8dtK4siu1rI2OCSFOABe5t9DiOZKHaC6/XWvdaJvYW4WX0iK+8DSq YLGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774518136; x=1775122936; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Z9S62wraGGWuFLRViippcyE9BcofvCghK7ZcArgqLNk=; b=Q7AgGtB2ZoR6vwtx8EQYRxHIsARM8bOiw0sluJhF3EX2jKaAis4lzQq7i4t+p0FR60 SWdKJLypXONCh7yjgICu5uzdVXcFIiQJoQAc/OZyMc4xgZlFPZbrj2IP5jZUbvz4SPG6 VgobavdWGzFdiN+c5jScu6DFPep2H23dNM5aDA1qm3wk8D8tydcuXr4YT2RRhktWrlaj sClXN4TFPCbyxE2Wtir+9IFBuhbow6S1XZaod9GwOYxcOm2jAeMOtnxN+65r+0ydZ/2m EHD3dTiFqwdZNV/sgvKRNUkE+euyyuCVfrUa9hQYmffqoEJ71I9sCgj0Y6elZ1iS+cI2 H1xA== X-Forwarded-Encrypted: i=1; AJvYcCWqaSn53LCB9vpYCbehrE2i8i5R+qHQB0EjpOxzbkJC9efND3RjFQb7rPZsPX5LZ17D9sNoFmtHCd2zU60=@vger.kernel.org X-Gm-Message-State: AOJu0YzXjHMhiKzpRfneDjK2Nn/YxEjvYTBa03EHaDnfbNhqfegaWsXc aOnmsgtX03b/YnzUMhqh/67VIoxWuKC56+3BlCj2XVI1r5y1Y/QpSnnb X-Gm-Gg: ATEYQzzq4MM3P0kPeDkR2UZyuY7Vxh4VcSDEKhmh5BYYuorBk9AU8aIqxkPY/lzlr8t 2sgY6IlxC9pBFbFqD+ushfgB2mOOWT+0RK2JQw3vk9gDmGl/yVMFIZkVvqZ/fcfNeeRzgUeogSK qOsxGOUPHmyhN49Zhenlo7vwicFR6PNrL19siufRS/kWIFQv7hq6nvkozbM4/8UFqOZyvYEogzH QYP/fo/x0zx0w5oKoro58DbmfZAkuPbc+iIS7KbrXHtPes+9ew0AR8ZXD0fPBqf/o12LT9pXTDV XAoqa1Q0ZR4f+HpsaDba29XedFzOyej5FGM8NbdjSLBmJbuP/2m6C1YnoDbn4WT2NJHed62QkVL xk9hllxWeAaeMRU33zKl9wMsySmwHKOT8JnFEhwk295411JsF/4CHWQraP5nzNsO1X6roTIBPk7 n/y6YwHyph6hhSYG4= X-Received: by 2002:a05:600c:4f95:b0:486:fcf9:5ba with SMTP id 5b1f17b1804b1-4871609da81mr58564565e9.7.1774518135734; Thu, 26 Mar 2026 02:42:15 -0700 (PDT) Received: from skbuf ([2a02:2f04:d50a:b400:cf79:b8bb:14ce:d80f]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48722c9f0afsm33134005e9.10.2026.03.26.02.42.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Mar 2026 02:42:14 -0700 (PDT) Date: Thu, 26 Mar 2026 11:42:11 +0200 From: Vladimir Oltean To: Fidelio Lawson , Bastien Curutchet Cc: Woojung Huh , UNGLinuxDriver@microchip.com, Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Marek Vasut , Maxime Chevallier , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Fidelio Lawson Subject: Re: [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata Message-ID: <20260326094211.hdaf4tz7lbjyjznn@skbuf> References: <20260326-ksz87xx_errata_low_loss_connections-v1-0-79a698f43626@exotec.com> <20260326-ksz87xx_errata_low_loss_connections-v1-0-79a698f43626@exotec.com> <20260326-ksz87xx_errata_low_loss_connections-v1-3-79a698f43626@exotec.com> <20260326-ksz87xx_errata_low_loss_connections-v1-3-79a698f43626@exotec.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260326-ksz87xx_errata_low_loss_connections-v1-3-79a698f43626@exotec.com> <20260326-ksz87xx_errata_low_loss_connections-v1-3-79a698f43626@exotec.com> On Thu, Mar 26, 2026 at 10:10:23AM +0100, Fidelio Lawson wrote: > Implement the "Module 3: Equalizer fix for short cables" erratum from > Microchip document DS80000687C for KSZ87xx switches. > > The issue affects short or low-loss cable links (e.g. CAT5e/CAT6), > where the PHY receiver equalizer may amplify high-amplitude signals > excessively, resulting in internal distortion and link establishment > failures. > > Depending on the selected workaround (1 or 2), the driver writes a > specific value to the indirect PHY register > using the 6E/6F/A0 indirect access mechanism. > > The errata fix is applied during global switch initialization when > enabled via device tree. > > Signed-off-by: Fidelio Lawson > --- > drivers/net/dsa/microchip/ksz8.c | 46 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 46 insertions(+) > > diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c > index 78b42cf50ce2..b6f3a1ce85fc 100644 > --- a/drivers/net/dsa/microchip/ksz8.c > +++ b/drivers/net/dsa/microchip/ksz8.c > @@ -1901,6 +1901,41 @@ void ksz8_phylink_mac_link_up(struct phylink_config *config, > ksz8_phy_port_link_up(dev, port, duplex, tx_pause, rx_pause); > } > > +static int ksz8_handle_module3_errata(struct ksz_device *dev) > +{ > + int ret = 0; "ret" does not need to be zero-initialized. It is unconditionally overwritten by ksz_write8(). And please sort lines with variable declarations in decreasing line length order. Netdev calls this "reverse Christmas tree" ordering and is the preferred coding style. > + const u16 *regs = dev->info->regs; > + u16 indir_reg = 0x0000; > + u8 indir_val = 0x00; > + > + switch (dev->low_loss_wa_mode) { > + case KSZ_LOW_LOSS_WA_1: > + indir_reg = 0x3C; > + indir_val = 0x15; > + break; > + case KSZ_LOW_LOSS_WA_2: > + indir_reg = 0x4C; > + indir_val = 0x40; Do the 3c and 4c registers have any associated documentation? Do we know what they are or what they do? We should have some macros for them, instead of magic numbers. > + break; > + default: > + break; Is it expected that in the default case (no workaround), the code flow writes indir_val = 0x00 to indir_reg = 0x0000? Or would it be better to just exit early without making any change? > + } > + > + mutex_lock(&dev->alu_mutex); > + > + ret = ksz_write8(dev, regs[REG_IND_CTRL_0], 0xA0); > + > + if (!ret) > + ret = ksz_write8(dev, 0x6F, indir_reg); > + > + if (!ret) > + ret = ksz_write8(dev, regs[REG_IND_BYTE], indir_val); Is this sequence better suited for ksz8_ind_write8()? Perhaps wrapped in another layer similar to ksz8_pme_write8(), once we know what the magic numbers represent in terms of indirect table? > + > + mutex_unlock(&dev->alu_mutex); > + > + return ret; > +} > + > static int ksz8_handle_global_errata(struct dsa_switch *ds) > { > struct ksz_device *dev = ds->priv; > @@ -1915,6 +1950,17 @@ static int ksz8_handle_global_errata(struct dsa_switch *ds) > if (dev->info->ksz87xx_eee_link_erratum) > ret = ksz8_ind_write8(dev, TABLE_EEE, REG_IND_EEE_GLOB2_HI, 0); > > + /* KSZ87xx Errata DS80000687C. > + * Module 3: Equalizer fix for short cables > + * The receiver of the embedded PHYs is tuned by default > + * to support long cable length applications. > + * Because of this, the equalizer in the PHY may amplify > + * high amplitude receiver signals to the point that > + * the signal is distorted internally > + */ > + if (!ret && dev->low_loss_wa_enable && ksz_is_ksz87xx(dev)) > + ret = ksz8_handle_module3_errata(dev); > + > return ret; > } > > > -- > 2.53.0 > FYI, the driver is in a restructuring process. The ksz88xx_switch_ops will be split out of the common ksz_switch_ops. This will conflict with your series, so you should rebase on top of that much larger set. You can coordinate with Bastien Curutchet to see what is the status: https://lore.kernel.org/netdev/20260313153849.qkfzv5c2u6fepjku@skbuf