Quoting Sai Prakash Ranjan (2019-09-19 11:54:27) > On 2019-09-19 08:48, Sai Prakash Ranjan wrote: > > On 2019-09-19 05:55, Bjorn Andersson wrote: > >> In the transition to this new design we lost the ability to > >> enable/disable the safe toggle per board, which according to Vivek > >> would result in some issue with Cheza. > >> > >> Can you confirm that this is okay? (Or introduce the DT property for > >> enabling the safe_toggle logic?) > >> > > > > Hmm, I don't remember Vivek telling about any issue on Cheza because > > of this logic. > > But I will test this on Cheza and let you know. > > > > I tested this on Cheza and no perf degradation nor any other issue is > seen > atleast openly, although I see this below stack dump always with > cant_sleep change added. The usage of cant_sleep() here is wrong then, and the comment should be removed from the scm API as well because it looks like it's perfectly OK to call the function from a context that can sleep. > > [ 5.048860] BUG: assuming atomic context at > /mnt/host/source/src/third_party/kernel/v5.3/drivers/firmware/qcom_scm-64.c:206 > [ 5.060303] in_atomic(): 0, irqs_disabled(): 0, pid: 1, name: > swapper/0 > [ 5.067118] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.3.0 #102 > [ 5.073299] Hardware name: Google Cheza (rev3+) (DT) > [ 5.078416] Call trace: > [ 5.080953] dump_backtrace+0x0/0x16c > [ 5.084727] show_stack+0x20/0x2c > [ 5.088156] dump_stack+0x90/0xcc > [ 5.091585] __cant_sleep+0xb4/0xc4 > [ 5.095192] __qcom_scm_qsmmu500_wait_safe_toggle+0x5c/0xa0 > [ 5.100929] qcom_scm_qsmmu500_wait_safe_toggle+0x28/0x34 > [ 5.106491] qcom_sdm845_smmu500_reset+0x24/0x50 > [ 5.111249] arm_smmu_device_reset+0x1a4/0x25c > [ 5.115827] arm_smmu_device_probe+0x418/0x50c > [ 5.120406] platform_drv_probe+0x90/0xb0
