Marek Vasut <[email protected]> writes: > On 2/27/26 1:07 PM, Kamlesh Gurudasani wrote: >> The SCMI clock protocol version was only being fetched when CLK_CCF >> was enabled. On non-CCF platforms, the probe function returned early >> without fetching the version, leaving priv->version as 0. >> >> This caused issues because code paths like scmi_clk_gate() and >> scmi_clk_get_permissions() depend on priv->version to determine >> which protocol message format to use, even in non-CCF mode. >> >> Fix this by moving the scmi_generic_protocol_version() call before >> the CLK_CCF check, ensuring the version is fetched for both CCF and >> non-CCF platforms. > Which platforms are these non-CCF platforms you refer to ? Which > platforms are broken right now ? Those details should be included in the > CM . We noticed this on am62lx_evm which is yet to be upstreamed.
It should fail for all "CONFIG_SCMI_FIRMWARE" "~CONFIG_CLK_CCF" But the failure case "0" is favoring the devices which are using scmi clock protocol version less than 0x20001 (or 0x30000). I can't really say if following devices use SCMI Server version greater than 0x20001 and are getting affected by this. As am62lx_evm is not upstreamed yet, not sure if I should add that in commit message. Let me know what you think. Devices with "CONFIG_SCMI_FIRMWARE" "~CONFIG_CLK_CCF": am62lx_evm cm3588-nas-rk3588 coolpi-4b-rk3588s coolpi-cm5-evb-rk3588 coolpi-cm5-genbook-rk3588 evb-rk3588 gameforce-ace-rk3588s generic-rk3588 jaguar-rk3588 khadas-edge2-rk3588s mnt-reform2-rk3588 nanopc-t6-rk3588 nanopi-r6c-rk3588s nanopi-r6s-rk3588s neu6a-io-rk3588 neu6b-io-rk3588 nova-rk3588s odroid-m2-rk3588s orangepi-5-max-rk3588 orangepi-5-plus-rk3588 orangepi-5-rk3588s orangepi-5-ultra-rk3588 quartzpro64-rk3588 rock-5-itx-rk3588 rock-5c-rk3588s rock5a-rk3588s rock5b-rk3588 sige7-rk3588 stm32mp15-odyssey stm32mp15 stm32mp15_trusted tiger-rk3588 toybrick-rk3588 turing-rk1-rk3588 Regards, Kamlesh
