From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 2BB6D1B808 for ; Fri, 23 Jan 2026 13:09:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769173749; cv=none; b=pvI+lWxB8AbaPxW08kPuCkOqopcJCRfKupRNHBCtYS3GI02I/3zGTb/MGJUhfRmu6SqXeoiOefZ1kqE5S0gtHfjMC8Llxdiy4+QKqGLz5WkC536B0vAinnpALGBzGX8rYVsNJW6fY1mXInpxmUhp1NkNxl/lZKWJD5c5MNwwXh8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769173749; c=relaxed/simple; bh=cFpC7v3e2f1s5QcKqpbbp+MFq/K0luTpU66taNYWdOU=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OFAgF4e8zsYpbUdze8DwndKpbIz9rDQ8XOkuV/SOGRjCPt9XgIOcqZoHZldwg9M+h0abPuRIq9pFXm6Enq/B6L+LzlJPk03kmm9OqiUdNmmeN8ZrLwPVhbIp2mow2A4J//XnBtQwT06GpF5o9vgK4I7fbAqz3v+dcd+XyNa7XWY= 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=iR38wHq2; arc=none smtp.client-ip=209.85.128.52 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="iR38wHq2" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-47ee76e8656so30052985e9.0 for ; Fri, 23 Jan 2026 05:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769173746; x=1769778546; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=0mZ7cxT9Oc18zXyi3CSpw+MXg+25jVdopAgJLZF8Ols=; b=iR38wHq2FEItCU6W71zVW44xzhAYS6eRUF31IsomzvlHGKv8nwPsoB9b93LRLE15Ye u/r4QyI/4HvD51VifPawjsUecXF4QSfmOPtos6sRivPtSSPQQRNJCmyNJv/eNqwVtUvD 1BzeKjSIzo6MoXrO8SebpfPk1wN7FpXFxtIGX/OjrnnAkrOEZAFYMiEZL74/WbMeXU+H Zst/8X2l/DEGwPFLyPYdzN3YnE917cOl0a3VaFipiiS/FLc76Po7zJwNvtqLu4KeFXEt mvi9e28BR8irowMxc0z4Wlb9jBOeZeQIsUdfQM6tYL/VPaXmTgk9sncOaDRKLXEtG6Dw DTMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769173746; x=1769778546; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0mZ7cxT9Oc18zXyi3CSpw+MXg+25jVdopAgJLZF8Ols=; b=GgXvFjcnKBFx12OZKG1RzdB4LneB87Fbv8oHiKZ0urNPt469Ynd6OKCNFM224Idh+d mIdkvdu777JlYSdVf8kzoa2DnKuBJp0cIKRQyfZo3lsZSmHJf6ktluhcKCrugXvUIS8R 10RNW/jYNAhMTWXn5U/5t4a1Jk6i/SrssXYdRKbICwyVoU9ac561p5R6lyW84RrhSbr1 uB/Ada0/nyH2QVm4empJqa2s5hc9zNHgE5tYGuAvKzeSKV3/t4SBlLO/cDmXh09f6D09 HIH6k9hHaDrAOuqI0ZcU7fk/MS37sy49SBXgpBeNZofQivba4IMfTrqvFLTMdUHqWTFp fSKg== X-Forwarded-Encrypted: i=1; AJvYcCWdV2sQSRuPdNgwxBYXQZvawudGKuEDYhJBKZV86kj4eiUWo2G1iP+e6Jv4AuLgr/aZp15lfNY3NWX/Trk=@vger.kernel.org X-Gm-Message-State: AOJu0Yyc2D9Djm51CojMEDUj8Zp/XPmM+Zh2SKvBE7/li1na01EGLg/5 kh1O9RIUetwomkCcdvlrVFeUmZf04aP1J1LgMh6R/YjsXNrYW662NZdm X-Gm-Gg: AZuq6aLrX++Vj0jQH7xZjgcavwYvgl9QyVnzwRFKmh0ZQdNgTUqzMiilh7/jhZOmS6C V9DviNWJxVTzNhJZmNuTBOyMHI9DzIUZf4rNCDYPZ+IhEO/298NeNo63VUkEReA9SVAumlRPmPu KTtyYiIbx2ePPMQl3fJ6VHQVJ39jAlipgQoNN9epFMgQ93ZfOj3EDdgSbhQOOUgAwUebFuhi3ij Okj69a8PTBqcKMK8/OG3NJ5UVqRrSadWpAzFx+zawEs9XTtYUOxNkyB/pY/9H6cDwAtz81qm1zg ZhvpvxEikpWfWfcFhzKTvF3LLKgRQJ06jx1pcYd7+4rXAvwHcu8olz/O6az4CpFgI6onTPkN13T +pMNuxghE9UbOFLmxRJto29Go6f2o+YIPfZfvnXhh4oh457PaKwsFlFk7FSKrRZE8fmVT110tCj omgtnpU9m0+rX2oBbBYhaTN39Qg73nMVdJNa89fG4= X-Received: by 2002:a05:600c:46c5:b0:477:6374:6347 with SMTP id 5b1f17b1804b1-4804f8235f5mr33189985e9.22.1769173746248; Fri, 23 Jan 2026 05:09:06 -0800 (PST) Received: from Ansuel-XPS. (93-34-88-81.ip49.fastwebnet.it. [93.34.88.81]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1e71730sm7008672f8f.26.2026.01.23.05.09.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Jan 2026 05:09:05 -0800 (PST) Message-ID: <697372f1.df0a0220.291d22.85ee@mx.google.com> X-Google-Original-Message-ID: Date: Fri, 23 Jan 2026 14:09:01 +0100 From: Christian Marangi To: "Russell King (Oracle)" Cc: Andrew Lunn , Heiner Kallweit , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [net-next PATCH v2 0/3] net: phy: as21xxx: toggle In Band feature support References: <20260123120117.10883-1-ansuelsmth@gmail.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: On Fri, Jan 23, 2026 at 12:16:45PM +0000, Russell King (Oracle) wrote: > [Please note: gmail.com has become unreliable for email delivery, > google has too much power to decide what is spam and what isn't, with > no route for appeal. please consider switching to a different email > provider.] > Thanks for reporting this. I'm also noticing for a while some legit email from mailing list going to spam. I have a new mail from a long time but never took the time to actually made the switch for kernel submission. Also it's mostly new so I guess it needs to earn some cretis as it will get directly rejected by some service. Chicken Egg problem... > On Fri, Jan 23, 2026 at 01:00:28PM +0100, Christian Marangi wrote: > > This is a new variant of the previous submitted patch adding a similar > > feature. > > > > Old Aeonsemi Firmware permitted only to enable or disable In Band > > support and it couldn't be disabled after (or there wasn't a > > way to detect the current state of it) > > > > As suggested by Russell this was bad Implementation. Some talk > > with Aeonsemi permitted to release a new firmware with correct > > implementation. > > > > This series adds support for this if new firmware (1.9.1+) is > > used. On the new firmware, 2 new IPC command are introduced > > to GET the current state of DPC RA (Rate Adaption) or SET it. > > (DPC RA is effectively In Band mode) > > > > It was verified on the same scenario and can confirm it works > > as expected. (Airoha AN7581/AN7583 with and without In Band > > mode) (If PCS is set to In Band and PHY isn't then no > > connection, so it's easy to verify correct functionality of > > this) > > > > The new firmware is currently submitted to linux-firmware > > awaiting it to be merged. > > > > For old firmware to save on compatibility we still enable > > In Band by default (this is what the current driver do) > > > > This was discovered to be needed in some scenario as is effectively > > the most compatible featureset. > > > > On a BananaPi R4 Pro, one of the 2 AS21xxx PHY is connected to > > one of the Switch port and such switch supports only In Band when > > set to USXGMII (assuming the Switch expect an SFP module to be > > attached where in absence of i2c or MDIO line In Band is always > > required) > > Coupling the PHY's rate adaption with inband support, but not setting > phydev->rate_matching anywhere in this driver seems wrong, and highly > suspicious. I'm not sure what to think given what you've said above, > it just seems completely wrong what has happened here. > Honestly speaking the Rate Adaption thing is what I found in some strange API c code on the downstream driver where they say that in DPC_RA RA is Rate Adaption. My personal idea is that, that thing toggle also other stuff and not only Rate Adaption. On the Airoha PCS In Band is controlled by enabling and disabling AN register (and this also apply to Mediatek PCS) With AN enabled, DPC RA needs to be enabled or no traffic. With AN disabled, DPC RA needs to be disabled or not traffic. This both apply to Airoha and Mediatek PCS. For the Switch, it's a different story. Everything is controlled by a Firmware blob and it's only possible to send command to setup the Serdes mode (USXGMII in this case) I made lots of test with forcing speed or trying to find a way to make it work but the only combo I found working was USXGMII + DPC_RA enabled. For the lack of .get_rate_matching should be set to RATE_MATCH_NONE AFAIK for this PHY. To give more info comments in the downstream driver at dpc_ra_enable have "Set USXGMII mode.". But I verified that PCS at USXGMII (but no In Band) and DPC_RA off I have correct link up and traffic. So it's not dropping to 10g base-r somehow with DPC_RA disabled and if it was the case the PCS should be configured for that mode (there are specific register for that). > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! -- Ansuel