On 6/19/2024 10:12 PM, Bjorn Andersson wrote:
On Wed, Jun 19, 2024 at 05:40:42PM +0530, Mukesh Ojha wrote:
On Wed, Jun 19, 2024 at 01:08:48PM +0200, Krzysztof Kozlowski wrote:
On 19/06/2024 12:56, Komal Bajaj wrote:
Enable the secure QFPROM driver which is used by QDU1000
Qualcomm QDU1000. You are changing kernel-wide defconfig, not some
Qualcomm downstream stuff.
platform for reading the secure qfprom region to get the
DDR channel configuration.
Signed-off-by: Komal Bajaj <quic_kbajaj@xxxxxxxxxxx>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 838b4466d6f6..c940437ae1b3 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1575,6 +1575,7 @@ CONFIG_NVMEM_LAYERSCAPE_SFP=m
CONFIG_NVMEM_MESON_EFUSE=m
CONFIG_NVMEM_MTK_EFUSE=y
CONFIG_NVMEM_QCOM_QFPROM=y
+CONFIG_NVMEM_QCOM_SEC_QFPROM=y
Module
Should not this be inline with what CONFIG_NVMEM_QCOM_QFPROM is having ?
Either both CONFIG_NVMEM_QCOM_QFPROM and CONFIG_NVMEM_QCOM_SEC_QFPROM
should be m or both y
While that would be a convenient guideline, you're adding runtime
overhead to all other targets (Qualcomm and non-Qualcomm) so the desire
to keep anything that can module outweigh such convenience.
Based on the recent addition of llcc and qfprom nodes I'm _guessing_
that LLCC is the one user of this today, and it is =m, so therefore
SEC_QFPROM can be =m as well.
By expanding the commit message slightly, we could have avoided the
"why?" questions and the need for me to "guess" the actual dependency.
Thanks Bjorn for the suggestion.
I will incorporate the suggested changes in the next patch.
Thanks
Komal
Regards,
Bjorn
-Mukesh
CONFIG_NVMEM_RMEM=m
CONFIG_NVMEM_ROCKCHIP_EFUSE=y
CONFIG_NVMEM_ROCKCHIP_OTP=y
--
2.42.0
Best regards,
Krzysztof
