On Wed, Sep 23, 2026 at 11:08 PM Bryan O'Donoghue <[email protected]> wrote: > > On 14/09/2026 13:41, Albert Esteve wrote: > > static int spm_cpuidle_drv_probe(struct platform_device *pdev) > > { > > + struct qcom_scm *scm = qcom_scm_get(); > > int cpu, ret; > > > > - if (!qcom_scm_is_available()) > > + if (!scm) > > return -EPROBE_DEFER; > > Is this equivalent code ? > > Its also a bit confusing to me that the next patch adds a .available > field to the qcom_scm struct.
I can see how this can be confusing. The problem with qcom_scm_is_available(scm) is that callers did not have an SCM handle yet. So drivers needed to search for it beforehand. Once I had to repeat that a few times, I instead added qcom_scm_get(), which looks up the bound instance and returns NULL if it is not ready (and still uses qcom_scm_is_available() internally). So, !scm is the same check as before, while we obtain the pointer for the following calls. scm->available in the following patch replaces the __scm publication flag when the global is removed. Until then, readiness is still based on the static __scm validity. > > I see where you do get drvdata but I haven't managed to find in the > series where the data gets set - haven't asked an LLM either - I think > the logic to associate the scm pointer and get it should live together > in one patch so that the logic is easier to find and reason about. platform_set_drvdata() is already in qcom_scm_probe(); this series only adds the dev_get_drvdata() / qcom_scm_get() lookups. I can clarify this in the commit message so the set/get pairing is more obvious. BR, Albert > > --- > bod >
