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 20CB21E47B7; Mon, 4 Aug 2025 16:23:02 +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=1754324583; cv=none; b=fQRQO0tN58PPxvNlfAJAnloeDk65VwZTW7Dxe5L13gYH5kc1+2MxOu9DIjHwlj/XesKLDqpVz3IqELZmTXZn+/Xwduh8BpHeo90U+fhUO2XCAxdLZM/9/uo5sSigPJE24cI3BYsDdmqYBrDVa46pADgOoDtvMjzSkLikYkgvXgI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754324583; c=relaxed/simple; bh=pyi3WTqynredpH+/oouhiz4DXT7XbOBYQrKL8dXYwvk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HXrHPPqurmSbpGV9EruGldxx2yXCFhQ3cwZlqjztAHlMOb7biT74OVExWcGUOOYIU+isLQFOfH21zftAVaVPOfAFCj5XCg6QrlJdbNhMCr+vUCWXx5nKx6NSYIF9YR/r714Pvz0HMUK8CMtY2t274Tpzc7T2sEivIQZM2Z0k2eE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oCvaLeHp; 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="oCvaLeHp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46125C4CEE7; Mon, 4 Aug 2025 16:23:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754324582; bh=pyi3WTqynredpH+/oouhiz4DXT7XbOBYQrKL8dXYwvk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oCvaLeHppq3GFNrqaQ6sQMa83jMh0jdCzPgWD1zWGcDVoaVu7OP6Bk/CnCtYojWC6 KiUfvkN8CKhRMUdeLNKJlMcssccOX8s1rZHgaPgsZDyts/dfr/Ru4RQrttbax9Qp/C eoGbHjwj5n8sH5d4aodA+7RJ8sBk5OGLDdCiJPy5hK4ufvXB82gLKPQUy3QyIkqAMm 8Si36B0ucDhVy2X5AgDG0Yi2L/AL2Q4N/+fmArReC1XqfitwxDFGZyj61EqKxFZVdb Ej+IrwCS4uS9/MU1zKQV8Oi5EbDknImKEphRUzd/eK6XflOeTaH7ZMNqZ6lAnmq7EY FaKqT/iceob5A== Date: Mon, 4 Aug 2025 09:23:00 -0700 From: Drew Fustini To: Yao Zi Cc: Rob Herring , Guo Ren , Fu Wei , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Krzysztof Kozlowski , Conor Dooley , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Emil Renner Berthing , Jisheng Zhang , linux-riscv@lists.infradead.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net v2 2/3] net: stmmac: thead: Get and enable APB clock on initialization Message-ID: References: <20250801091240.46114-1-ziyao@disroot.org> <20250801091240.46114-3-ziyao@disroot.org> <20250803170206.GA525144-robh@kernel.org> Precedence: bulk X-Mailing-List: devicetree@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 Mon, Aug 04, 2025 at 05:12:26AM +0000, Yao Zi wrote: > On Sun, Aug 03, 2025 at 12:02:06PM -0500, Rob Herring wrote: > > On Fri, Aug 01, 2025 at 09:12:39AM +0000, Yao Zi wrote: > > > It's necessary to adjust the MAC TX clock when the linkspeed changes, > > > but it's noted such adjustment always fails on TH1520 SoC, and reading > > > back from APB glue registers that control clock generation results in > > > garbage, causing broken link. > > > > > > With some testing, it's found a clock must be ungated for access to APB > > > glue registers. Without any consumer, the clock is automatically > > > disabled during late kernel startup. Let's get and enable it if it's > > > described in devicetree. > > > > > > Fixes: 33a1a01e3afa ("net: stmmac: Add glue layer for T-HEAD TH1520 SoC") > > > Signed-off-by: Yao Zi > > > Reviewed-by: Drew Fustini > > > Tested-by: Drew Fustini > > > --- > > > drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c > > > index c72ee759aae5..95096244a846 100644 > > > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c > > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c > > > @@ -211,6 +211,7 @@ static int thead_dwmac_probe(struct platform_device *pdev) > > > struct stmmac_resources stmmac_res; > > > struct plat_stmmacenet_data *plat; > > > struct thead_dwmac *dwmac; > > > + struct clk *apb_clk; > > > void __iomem *apb; > > > int ret; > > > > > > @@ -224,6 +225,11 @@ static int thead_dwmac_probe(struct platform_device *pdev) > > > return dev_err_probe(&pdev->dev, PTR_ERR(plat), > > > "dt configuration failed\n"); > > > > > > + apb_clk = devm_clk_get_optional_enabled(&pdev->dev, "apb"); > > > > The description sounds like this should not be optional. The binding > > change also makes it not optional. > > Yes, it shouldn't be. But using the non-optional API will cause the > driver fails to probe with the old (problematic) devicetree, IOW, it > breaks the ABI. Comparing to unusable ethernet, failing to adjust the > link speed sounds a minor point to me. I've just read Conor's comment in the v1 again: Nah, introduce the warnings. If the clock is required for operation, it should be marked as such. You've made it optional in the driver, which is the important part (backwards compatible) and you've got the dts patch in the series. Thus I think the argument I made in my reply to this thread is incorrect and the driver should remain backwards compatible. > Maybe we could add a comment to explain why optional API is used, or > just use the non-optional one if such ABI breakages are acceptable -- > for which I'd like to wait for more opinions. I think a comment in the code about why it uses the optional variant of the function is a good idea. Thanks, Drew