From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (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 1E2B1249E5 for ; Tue, 4 Aug 2026 05:03:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785819842; cv=none; b=jhCNnyUnEiqUXHm24UmCRbzRd5Fnx7IqWVbATJF2ZtXq8SYfvcDi4ERFMW3wRWOC9jBtfI2QVtWNz3MF0xdJHWL8j4YcNgX++hJA0/OcE749LiTjapp8q74dXlJ35kdNQ10kfSfc33R2zyc1Ozaw49kz2EbMKOyDc0gsNXjRMcU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785819842; c=relaxed/simple; bh=FSJlrY3I3aNh7f4zmDrsNnt6kg6s2wYYb9KmntktFLA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WBwsPNhX0Y88pG6wdogamW0xSZG+zhh4x3ZQBz/xkBr5CFzkuIwCC4IaeIqU3EFexDfxWBQRHrLhYD/FOSQ+nRcdRs1Mz93MLTjpxDpeyX+P3Kc+/20gPgqdNSU4FvsaEC9sHUIoBk/U5rUTCqurnxYCONgvsNdesrUb1FKoV/Y= 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=crj1fG+J; arc=none smtp.client-ip=209.85.208.43 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="crj1fG+J" Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-69c20ba892eso867125a12.1 for ; Mon, 03 Aug 2026 22:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785819838; x=1786424638; darn=vger.kernel.org; h=content-type:content-transfer-encoding:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=m0K5uL+ffxmjOwUEwo70igju+6SeZRlmphKolSxYy0o=; b=crj1fG+J5oDM9i1p4hnCN9tAlKW4Wzr7aa36BqSYBUrbVvnDr0hEQTPkY7KYKjcQSk uSyrLVOjDvoF6tBgydwGHjjANKajC4p/09c1zkcRAnMKVzhp1BQOGFKZxMMjMJjhI2MO 5qVbGeBoBoNXx7dfYEcj8NVEikkHcy7/y1UC5SS9jg6f7bfaDfFCr44mJuo1Ix2XFgYx hlHtWWk8TeFUtj83fLgyVQ7HQ3qXYyAeuygzU84vYM2w4jU/TSXQqqrfiC4yxOlzMXh1 oXuzoL8d8j2IiGlEBoLvGFfbklhbJwIU4++kgCJlRuaayBCeOUOlzvdiajMV/7K2fIHQ srow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785819838; x=1786424638; h=content-type:content-transfer-encoding:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=m0K5uL+ffxmjOwUEwo70igju+6SeZRlmphKolSxYy0o=; b=Wreol7fEeMylA8qzhOErIF6+zKFpfOgbAQa0vjaEA+NOXhuBwp5fIIlEJZ1w3Plr9/ evYvCp/0SuZZ9RAOwhsf23HwmgPLA7ANKs6DNzKja3F/uEJmNIGARSgAYy5La/BQlHR8 3IOXIep+5qd9OgzibuwEh87x0qtVpiLoETFiG1v/dgzfHOHiODljZ89w52y4+jhX8WSK 7OqYKz8bqNwo2AsbkpizyZ8nbZOT+O3+GgQTuI0qh4+kgcBHMgwAC0CbUqGFiraj7EKg kxJYBYVVpnBWXWNAEH9VF5xY84++tWazvMPDfke97VkX2HwdQDgDRfDx/1QdUO/4lwAJ NmjQ== X-Forwarded-Encrypted: i=1; AHgh+RobG2hHeMfuyYNzTbU63PlNqLnY5tLzIq18nXUCedJjL7OSHsoaNb6pGtjSPSRwlRuPmjBfPf7VMoXo5tI=@vger.kernel.org X-Gm-Message-State: AOJu0YwQDrp9imZjGLIiRnYb0hon6yGos29tihj2erKX4lvS2AK5xWtz 8Z3HGQG0eXyl3rNCO+FH6V0KmPUBGpDwPcLhknKrl/9TvCcAm2lYTBxB X-Gm-Gg: AR+sD13vpxdysl4ZhzEWOsRRKrpFo1bcHdCDTRVTlf2IgVGdR86au3x+vjuFIXcJ2CR v893/MdFdrg2opyZhm8LsxPUlaGr5cFf0bdEUYIdqQX5hlpO1A/PH/YzPWY6/tzckRx5bvePtLp MIvNoS8yXWnO6dNniwJB+Nr7dR01OSVI0vDdEvSarkHLlCKQoW/5/NvZ6taMPdcyw4iEpnDZ+5Z WpG44377x1L4XSkf8/QT+UWe4vG0ndqcrNvSFLqUZ4h1ejJ/yIcaTOkcvyAm9bVOXecvl2EuKOE eyWpSG1apqtrp9fv30UjFTm6zYEt94vOM4CM2dPjbjg+OM1fXONCdfD6ecL3ssEcZDx3Y6TGnV2 kG7/MOAyAmA3COXFvVfHgUriZnw/Jjq4eirfoIXnvKE8HpFO+fjdyDeES54MM/IhiSYB4lEkA4B IMDjLckeM9jgjkLa/G1bXwVC84nIKtdktRHafVnj6XFzetAXsCLw7SiBSALvf6MdlGNZ8UzAUXx vQrLpCUGTpTuy6FcgZX5ORKu7okAMYxiQeQf+ruOy/yCmQHvIh48VzQYQ9DJ6JiFFPRE3IVDr6c satVPCwspKXMiHUvb8KxLXUIj/dds3iee9zsaNF1mOTYtLt7HlAx3Z1Fe8PfbRDupo6kLmbfA96 9eIMsrg1ziepu47WdWSj1DhEkTbx2r1bQXZWFyn65aazOu/MQZpZxrkitnOKvXIiECSnK6fk6dR WJP0/qfkngqVG/IZZz/Zg= X-Received: by 2002:a17:907:3e07:b0:c12:3cbf:9f6d with SMTP id a640c23a62f3a-c20244fb9a5mr217102666b.1.1785819838130; Mon, 03 Aug 2026 22:03:58 -0700 (PDT) Received: from jernej-laptop.localnet (APN-122-65-17-gprs.simobil.net. [46.122.65.17]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1fd3c90739sm627034766b.14.2026.08.03.22.03.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2026 22:03:57 -0700 (PDT) From: Jernej =?UTF-8?B?xaBrcmFiZWM=?= To: Andre Przywara , James Hilliard Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Chen-Yu Tsai , Samuel Holland , Richard Genoud , Maxime Ripard , Alexandre Torgue , Giuseppe Cavallaro , Jose Abreu , Maxime Chevallier , Maxime Coquelin , Andrew Lunn , Heiner Kallweit , Russell King , Saravana Kannan , Lee Jones , Heiko Stuebner , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, mfd@lists.linux.dev, linux-rockchip@lists.infradead.org Subject: Re: [PATCH 00/21] net: phy: add X-Powers AC200/AC300 EPHY support Date: Tue, 04 Aug 2026 07:03:49 +0200 Message-ID: In-Reply-To: References: <20260802-submit-acx00-of-dynamic-v1-v1-0-0a53cd9e21cc@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Dne ponedeljek, 3. avgust 2026 ob 17:57:15 Srednjeevropski poletni =C4=8Das= je James Hilliard napisal(a): > On Mon, Aug 3, 2026 at 7:26=E2=80=AFAM Andre Przywara wrote: > > > > Hi James, > > > > thanks for sending this to the list, but as Andrew already mentioned: > > this is quite a beast, and would need to be broken down. > > Jernej and I created some patches just for the AC200 PHY on the H6, > > which Jernej recently revived, and IIUC, wanted to send to the list. > > This would probably be a more workable route: start easy, then add > > support for more SoCs (H616 depends on the WIP PWM driver) and more > > variants (AC300) later. >=20 > Well, I wanted to validate that the overall driver design is suitable for > the H616 which has to support both PHY variants at runtime effectively > since that is the most complex use case, I also don't have a H6 board > to test with myself at the moment. I think being able to see a more > complete implementation like this is helpful as it can better inform how > we can tie the different control interfaces to the link PHY in a way that > works for the more complex H616 case. No. AC200 and AC300 are separate chips. Just making some artificial connection in DT, because H616 wafer is once copackaged with AC200 die and at other time with AC300 is not correct. Let just have bootloader properly identify copackaged chip, enable it and be done with it. I'm working on proper AC200 series as Andre mentioned. I researched all functionality because I don't want to miss anything in DT and to have good arguments why I did thing the way I did. This series doesn't care of anything else than AC200 EPHY, which isn't correct. Some things are even not properly modeled and it was already discussed in previous reviews. For example, MDIO PHY node should reference both, clock and resets. I plan to post AC200 patches with at least audio codec included, alongside EPHY. TVE is also working but it has more open questions, so it won't be part of next submission. >=20 > > Which also brings me to some attribution questions: If I understand > > correctly, this has been written mostly by some LLM? I think you would > > need at least to disclose that, if not even add an official tag? >=20 > Some patches were, sure, my understanding is that it's not required to > explicitly call that out but I can add more info if that helps, this was > tested/validated using a heavily automated hardware in the loop > testbench setup on an AC200 and AC300 variant H616 board. Yes, you have to reveal AI involvement. >=20 > > Also I wonder how this relates to the patches floating around for a > > while already: https://github.com/jernejsk/linux-1/commits/ac200-v4. > > This branch is relatively new, but the ac200-v3 branch for instance is > > much older. >=20 > Yeah, parts of this are loosely based off of some existing patches that > were floating around like those, although it has diverged quite a bit as > well since this series is designed to handle both phy variants. >=20 > I guess I should link to some of the earlier work in the cover letter? However, what bother me more, is that obviously a lot of AC200 things were copied (even if only by LLM) from my WIP AC200 branch without any atribution to either Andre or me. As Andre mentioned in other response, let do it separately for AC200, AC300 and detection between them (best in bootloader). Best regards, Jernej >=20 > > On 8/3/26 07:14, James Hilliard wrote: > > > The Allwinner H616/H618 secondary EMAC is commonly connected to a Fast > > > Ethernet PHY in an X-Powers AC200 or AC300 companion package. The two > > > packages expose the same link PHY ID and largely compatible link-side > > > registers, but require different control paths before those registers= can > > > be accessed: AC200 is initialized through its I2C MFD, while AC300 us= es a > > > non-PHY Clause 22 control endpoint. > > > > > > Some H616-family products were shipped with either package under the = same > > > board identity. For those systems, this series uses a SID NVMEM fiel= d to > > > select the control provider at run time. With CONFIG_OF_DYNAMIC, the= link > > > PHY enables only the selected fail-needs-probe provider, so an AC300 = board > > > > Just to bring that shallow discussion we had on IRC to the list: I > > wonder if this is the right solution? Alternatively I was wondering if > > just patching the DT in U-Boot would simplify things, and also help > > other DT users like *BSD or U-Boot (proper) itself, to not boil the > > ocean, but just allowing them to follow a standard DT description. >=20 > This can be used either way, CONFIG_OF_DYNAMIC isn't a hard > dependency with this design, aside from adding CONFIG_OF_DYNAMIC > support for mdio the dynamic enablement of the correct phy control > drivers is relatively simple with this architecture. >=20