On 2018-05-04 15:00, rishabhb@xxxxxxxxxxxxxx wrote:
The upstream qcom_scm driver is currently coded as a platform device driver. This approach introduces the following problem: The driver's init function is declared a subsys_initcall. There are initcalls before the subsys level that use the scm apis for example randomizing the stack canaries, etc. All scm apis use a struct device * as one of arguments(__scm->dev). At the early stages the scm driver is not initialized and if other initcalls use these apis, it causes a null pointer dereference, since __scm is NULL. Even if we try to make the scm_initcall as an early initcall, it won't workout as the platform driver code is not initialized at that stage. To avoid this problem which of the following approach is suggested: 1. In place of coding it as a platform device driver just export the apis and make the init function as an early initcall. Since we will no longer use platform apis this approach should work. 2. Wherever scm apis are used before the driver is initialized, change them to use arm_smccc_smc apis. This would avoid null pointer dereference. -Rishabh
This is one the usecases where scm call is being made before the scm driver is initialized: https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/arch/arm64/kernel/setup.c?h=LE.UM.2.3.2.r1#n339 (init_random_pool -- called in the setup_arch function) https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/soc/qcom/early_random.c?h=LE.UM.2.3.2.r1 (implementation of early random number -- makes an scm call) -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
