Quoting rishabhb@xxxxxxxxxxxxxx (2018-05-04 15:00:55) > > 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. I seem to recall that we went with this #2 option for the smp boot APIs. See __qcom_scm_set_cold_boot_addr() for one example. -- 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
