Re: [PATCH v8 05/12] clk: zte: Add Clock registration infrastructure
Stefan Dösinger <[email protected]> Wed, 29 Jul 2026 00:25:34 +0300
| Newsgroups | dev.linux.lists.mfd,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-phy,org.kernel.vger.linux-clk,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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
signature.asc
(application/pgp-signature, 870 B)
-----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-----