From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 35883388E41; Tue, 14 Apr 2026 21:58:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776203917; cv=none; b=GyvyGRW+0cF/gutbbmp2I9l0mnmzkr5PRG1wDoVyF6GQ6t9/4SVs+G08xeebeOUtqhYKU01QLOBSy2XeUhov7qk2mard1H3FiVIbvDRgW9olL9SFvb1GNZfFLtr7x2/zS/0Eo6iluoD8GyTJ8u7O6lHZUXWhrLRqHqTTG9fF4Tg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776203917; c=relaxed/simple; bh=eE/A1HY1Is/66jFX3FEuLDx0jM8WPULiynZwxPFdYuw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ArVJjjUFuDRt+eAId19CYkyBhrpNaSyorJPuvOubZF5To08L43ewIhhAh6e1kZ8e+HrynMKsmoSgBGHoM4DruTUimPLHdoGfRQUbwJqScMCuB7RCHNGQmsbLSivOE77Y26h529jGIVo41fPdFpXbITTgIQF9rwoETk4l4uztjcc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AaGycWMq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AaGycWMq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B5FAC19425; Tue, 14 Apr 2026 21:58:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776203917; bh=eE/A1HY1Is/66jFX3FEuLDx0jM8WPULiynZwxPFdYuw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AaGycWMqF2itECQyxqYFjUFW3dHR6GRwAx0BBqkWWwCe02RFgFaBe1KclsQWMKa6y 22FZim7vYwpx8mtvgYbtKC02RUcVaV7DdLzB/h6PDUFa+9SuZoiudP/1INUeO4AhNP XxUDuQI0hdpglQy+RgfZc+BuL+d04pLkwwo6BY38yNdN18r3Di2qAQQAqFZAh6dbpH iMDXLzQdVo0hERNhykRSphEZmx0p7gAo5a3A4iKFyydOnpTxTEEhMrRjmHDYhjQWmu fYrGupJZMCUlUmIT/ai6S4x4IlylDTGaXJNEdRoZ8JfCvqcOSXmG9FkX03uY+3yIYF moV/T4obwB7Mg== Date: Tue, 14 Apr 2026 14:58:35 -0700 From: Jakub Kicinski To: "Kubalewski, Arkadiusz" Cc: "Nitka, Grzegorz" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "intel-wired-lan@lists.osuosl.org" , "Oros, Petr" , "richardcochran@gmail.com" , "andrew+netdev@lunn.ch" , "Kitszel, Przemyslaw" , "Nguyen, Anthony L" , "Prathosh.Satish@microchip.com" , "Vecera, Ivan" , "jiri@resnulli.us" , "vadim.fedorenko@linux.dev" , "donald.hunter@gmail.com" , "horms@kernel.org" , "pabeni@redhat.com" , "davem@davemloft.net" , "edumazet@google.com" Subject: Re: [PATCH v5 net-next 0/8] dpll/ice: Add TXC DPLL type and full TX reference clock control for E825 Message-ID: <20260414145835.07fbe355@kernel.org> In-Reply-To: References: <20260402230626.3826719-1-grzegorz.nitka@intel.com> <20260406192312.0f7a2760@kernel.org> <20260409181041.395a0c37@kernel.org> <20260410133812.4cf9b090@kernel.org> 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-Transfer-Encoding: 7bit On Mon, 13 Apr 2026 08:19:30 +0000 Kubalewski, Arkadiusz wrote: >> My concern is that I think this is a pretty run of the mill SyncE >> design. If we need to pretend we have two DPLLs here if we really >> only have one and a mux - then our APIs are mis-designed :( > > Well, the true is that we did not anticipated per-port control of the > TX clock source, as a single DPLL device could drive multiple of such. > > This is not true, that we pretend there is a second PLL - there is a > PLL on each TX clock, maybe not a full DPLL, but still the loop with > a control over it's sources is there and it has the same 2 external > sources + default XO. Don't we put that MAC PLL into bypass mode if we feed a clock from the EEC DPLL? > A mentioned try of adding per port MUX-type pin, just to give some control > to the user, is where we wanted to simplify things, but in the end the API > would have to be modified in significant way, various paths related to pin > registration and keeping correct references, just to make working case > for the pin_on_pin_register and it's internals. We decided that the burden > and impact for existing design was to high. > > And that is why the TXC approach emerged, the change of DPLL is minimal, > The model is still correct from user perspective, SyncE SW controller shall > anticipate possibility that per-port TXC dpll is there We are starting to push into what was previously the domain of drivers/clk, tho. IIUC the "ASIC PLL"s are usually integrated with clock dividers. And cannot be "configured" after chip init / async reset (which is why I presume you whack a reset in patch 7?). > This particular device and driver doesn't implement any EEC-type DPLL > device, the one could think that we can just change the type here and use > EEC type instead of new one TXC - since we share pins from external dpll > driver, which is EEC type, and our DPLL device would have different clock_id > and module. But, further designs, where a single NIC is having control over > both a EEC DPLL and ability to control each source per-port this would be > problematic. At least one NIC Port driver would have to have 2 EEC-type DPLLs > leaving user with extra confusion. The distinction between TXC and EEC dpll is confusing. I thought EEC one _was_supposed_to_ drive the Tx clock? What PPS means is obvious, what EEC means if not driving Tx clock is unclear to me.. Let me summarize my concerns - we need to navigate the split between drivers/clk and dpll. We need a distinction on what goes where, because every ASIC has a bunch of PLLs which until now have been controlled by device tree (if at all). If the main question we want to answer is "which clock ref is used to drive internal clock" all we need is a MUX. If we want to make dpll cover also ASIC PLLs for platforms without device tree we need a more generic name than TXC, IMHO.