From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 7D6F93E49C6 for ; Tue, 28 Jul 2026 21:25:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785273950; cv=none; b=MBi4FhCNAvJvODvKVRRrTNer0R7Qdfo9KjRS25bmXN81EDGJStn3zGc3g+gsIeDRvhe5sWIXBSIVU5NLwCwX3xqbn9omZQzP6YCubyHqlLTej3ffpd28n/96+TTgAk6yxZrvjMhYHEX7s/Rd0vK2TG6mOW2p89iQ3cIbT9v3mKE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785273950; c=relaxed/simple; bh=APWk0uOj8/6LVjgqEtJk1b6uSGlDci9M7cPzBIGfdF8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=c18S4rNYd28qPdgtiArhq9YZnU5adIA/PIS9FPlhr8ND+1uoaL7JTERa11UINzlMqX8/BAPphgV+rGICqnHKYmwHYYW5MSQEj3SZnxBpX11joIt7JegwiYjz9/HZH+wYxhlG/lSbY0etv670VIseepyTfjvXbOHTer28B9tnvUA= 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=arhJvCiW; arc=none smtp.client-ip=209.85.128.42 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="arhJvCiW" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4954c0833b4so1947675e9.1 for ; Tue, 28 Jul 2026 14:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785273947; x=1785878747; darn=vger.kernel.org; h=content-type: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=1dUKZYq5xkF+c+j8L2UCzb9nPYl48cxNMgRgY7fYgmE=; b=arhJvCiWsnMDShQuKi1qEpuiBNzclxRrA8COReiRG7NMiZgP02HqV4F5qmeeLr+Ivm STSv0UwU1RrxnHzaheLqxL0OR1C35VXJ2TqtmoDxjXls0jj6SXwFj0jyWzHPe1t99kKj WVYizW/FAREUzRqBgixpM5w1P9sK6TwjxEDFRMKDvbj2AKCrNmhU6gtpnLUmSr9N6ugV caRWujc6G4+6C//2ZTPtny8liIRtUtMEKxrGuIUfAJl+2jEstOvhD5yClHdqG25+9CLW aODyveF0zAqsvwzHi01LHUukSin1FbG8R8EHOZlPxhxmTQpiT5+rFEILKUJEPg7wGWGF sB3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785273947; x=1785878747; h=content-type: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=1dUKZYq5xkF+c+j8L2UCzb9nPYl48cxNMgRgY7fYgmE=; b=Cv7D7dbWOecfhpkoRENq9a+PvlmCMr2MtWj8sk+x02TEBxXu8mjLs4+kD2Q8PJz4/p r+aKA49fRGzS0KOedLcr21UoTJbD6dHGa3EEFf/9V4ivfcXjwWWC8n2r3wdVH7kYyYCp cUDKxD6+hqNqg4gcDt4w3V/Ssvq25nM78rJKbgoFaBPvgezSrz+I3hTDiCi7PHaWVfuW 6ac3oHCET2TVWXgJrtwU/liFzKotKs2inu8hH3z8Vi57X+9GohJY4lpX65E18Qnrc6bl QhumOU6MDj1XdxRPCyWpSixKq1UO6l8EKan2zlnflA4ouENU4vlI6cilNPWnY9/rxzGQ i3bA== X-Forwarded-Encrypted: i=1; AHgh+Rr+TD45ahQ5+QZ2+6nR8vgiAUxONPsK97bj0Wzat4jRhoA85OaR9yXfrifDf6iIm/jbh/nfp9CJC4jK4lI=@vger.kernel.org X-Gm-Message-State: AOJu0YyMgpzytbqK6BMV2CVvOorMA9XRPO+00d4WqE5hC9SHP1Ya1bWL PvzmCr2G+T/X/xPtbE9/DAcL+0bRXLXRXHLoSv/2AxhYRfcnU0C9tujT X-Gm-Gg: AR+sD11hhkVXLi1V8fni0NvkMhvrpyngbSSuRZZEaWVo7+bmOaUuXXhwHjlpiTRPvxD /Ii9hh9V0n/FMbJ0GmLgBK31GmniaXfAbgDajva/cyi4T1iRWWWyNxX3uisRj4xwKxCwqea4mai f5Sy0QuaLm8E/8eSaNEaR58hjomRWp7dIRRuXpAmO/BD9fKraCDsIeyKYlTf/+SYdqWHozBPVBJ JGSK5UPPb+UmU6sYupSkamf+4zM/xDAv5tMf8wMPAyUzZamPFKJB0sU89ia1xMpKlJ2mvXVEvyO ICYcKCU91MIw8w7TApgLK0o+im0ntYVnkW7FUUcg7fxfX+k15JOxAwvsDgntJoy39Fz9/c3roKy pLMkUFnITaGopaiE3svCsnf/jjAYo+6VT+hdTc2TtDS0bwvRvP+qZxD2LzE2wylCJnmRw1lZZM8 9rwbBU+7buQ8B9cygIstpu31jGHoqFvlKMC8Y2o4ys0ZsmX7FhWrZlSP6Krg09KJPDL2V/ANY= X-Received: by 2002:a05:600d:844e:20b0:495:5375:2510 with SMTP id 5b1f17b1804b1-496c6568a37mr33118015e9.24.1785273946598; Tue, 28 Jul 2026 14:25:46 -0700 (PDT) Received: from grey.localnet ([197.250.51.166]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-496c45c297dsm103054375e9.7.2026.07.28.14.25.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jul 2026 14:25:45 -0700 (PDT) From: Stefan =?UTF-8?B?RMO2c2luZ2Vy?= To: Brian Masney Cc: Michael Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Philipp Zabel , Vinod Koul , Neil Armstrong , Russell King , Lee Jones , linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-phy@lists.infradead.org, mfd@lists.linux.dev Subject: Re: [PATCH v8 05/12] clk: zte: Add Clock registration infrastructure Date: Wed, 29 Jul 2026 00:25:34 +0300 Message-ID: In-Reply-To: References: <20260727-zx29clk-v8-0-7a107b00f1dd@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPartYxrm5NhARqO7C27MMFWz9g"; micalg="pgp-sha256"; protocol="application/pgp-signature" --nextPartYxrm5NhARqO7C27MMFWz9g Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Stefan =?UTF-8?B?RMO2c2luZ2Vy?= To: Brian Masney Subject: Re: [PATCH v8 05/12] clk: zte: Add Clock registration infrastructure Date: Wed, 29 Jul 2026 00:25:34 +0300 Message-ID: In-Reply-To: MIME-Version: 1.0 Hi Brian, Thanks for the review! Am Dienstag, 28. Juli 2026, 16:53:17 Ostafrikanische Zeit schrieben Sie: > Looking into the other patches. There's more mixing of the clk provider > calling the clk consumer APIs here. It looks like this just takes a > reference and holds them. Would moving to parent_data address this? I think so. parent_data::fw_name is indeed something I have been looking for and didn't stumble across myself. And I suspect when you say "use parent_data", you don't mean "use parent_data.name everywhere". But it raises the question of how to handle internal clocks, e.g. foo_gate- >foo_div->foo_mux->clock-26m. Only "clock-26m" is passed through the DT and found via fw_name, and only foo_gate is exported. For the other clocks I currently rely on the string matching to resolve the parent named in the static init data to an actual registered clk_hw. The alternative I see is storing the struct clk_hw * in a table by index and pass it in parent_data.hw, but that'd require managing the extra indices. Or build a clock-local name->clk_hw lookup, but then I am just reinventing the old name matching. Am I missing something obvious? Is there a canonical implementation somewhere that implements modern best practices? I learned that looking at existing drivers isn't always a reliable guide. Cheers, Stefan --nextPartYxrm5NhARqO7C27MMFWz9g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQJPBAABCAA5FiEEQxb0tqoFWyeVMl1sPRO8yFRPGiIFAmppHk4bFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMiwyAAoJED0TvMhUTxoirHYQAJP3CdwusoH3pkXKfPo4 IsHXR5HpSkcfs8UCWKbXUiLjzTOXi23M6YRSjmwFG3d1x7/tF3zuRiRB7UoTbPxi Dpcjy4P38mBhhj5ViTMPZEDb1+yGlH/55A3Q13yyGUZAYrWBvjlF1+CeyejwGj3i MVs7cQGfnjS5eKxnSlMeu6YES3/GMT1FEr87RSiK1tIR7l5Ly+ZlVUeFL6j/QR5c 0fRWrLVaRuf40Z+Br0mTqVYameqPi3Y2txNe/WB5/6G3h+Pwgr8fa18n7kss1CR4 PLy4xOCkdwBhFr3V1XAwmLR903mrts0OzyiU2WEgelU4aIvO0g+IY/QpVCb4Tc28 sIFnx1o9RB82nrHOGyZ+tE3Td9Z8jdagf7NCcynDF9OBNO8d2p2VHrytuTO05BU0 6WTcRZf3HNTRavdGicG0D+UZLTrVSeATG7Gn84xOtEcqnNQgqGw+7FFrbYL3uvnB zJpQ0g3TxhaSjw9l5WYghaypuxgBUI3vsXsNBCFUi9/LHutvv7c2UFoB9pGMO+0F agh+s3+qnrEIuyCa6gMNO0ARQMjjfVWPCMn+QO0W6LDHLm9V862PI8/fSAHIJtBw 8YniFVm03EcJNgSelHRlZO20sDNBbjjcJdMzKez23UwFsD+debYrdpQOo4Z1MVqr o4X7ofieFY9lg1CnhuLk+OK+ =e+iT -----END PGP SIGNATURE----- --nextPartYxrm5NhARqO7C27MMFWz9g--