On Sat, 7 Sept 2024 at 11:57, Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > > On Sat, Sep 07, 2024 at 01:49:02AM GMT, Rudraksha Gupta wrote: > > > Looks like qcom_scm_get_tzmem_pool() returns NULL. Not sure how this > > > happens. Can you confirm that the QCom SCM driver probed correctly? > > > > Thanks for looking into this! Please let me know how I can help! > > > > > > I've been building the driver into the kernel I believe. Here's the relevant > > line in the config: > > > > $ rg -i "scm" > > samsung/expressatt/linux.defconfig > > 1615:# CONFIG_ARM_SCMI_PROTOCOL is not set > > 1627:CONFIG_QCOM_SCM=y > > 1628:# CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT is not set > > > > > > It seems like the scm driver is being probed: > > > > ~ # dmesg | grep scm > > [ 0.066438] qcom_scm: convention: smc legacy > > [ 0.362543] bus: 'platform': add driver qcom_scm > > The scm driver is added, but it is not probed as there is no SCM node in > DT. I'll send and RFT patch to add it. However the issue still persists: > the driver should not crash if there is no SCM device on a system. > qcom_scm_*_alloc should fall back if there is no SCM. > Ugh, so some SCM calls seem to expect that they can get called without the SCM driver. It's not very intuitive, I would expect that the driver must be up for SCM to work at all. I think we should fall back to using kzalloc() in such cases as there's no struct device to use with the DMA alloc APIs. I'll prepare a patch. Bart
