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. Regards, Bjorn > -Mukesh > > > > > CONFIG_NVMEM_RMEM=m > > > CONFIG_NVMEM_ROCKCHIP_EFUSE=y > > > CONFIG_NVMEM_ROCKCHIP_OTP=y > > > -- > > > 2.42.0 > > > > > > > Best regards, > > Krzysztof > >
