On Thu, 30 Aug 2018 at 13:12, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > > > > On 2018-08-30 12:45, Krzysztof Kozlowski wrote: > > Ah I missed that point and I see you fixed that case in "mmc: > > dw_mmc-exynos: fix potential external abort in resume_noirq()". The > > true reasoning for this patch is that soc clk driver should suspend > > after every other suspend callback which is using clocks... It would > > be nice to explain this particular scenario in commit msg. > > > > However both dw-mmc and clk will be now in suspend noirq phase so do > > you have any guarantees that dw-mmc will be suspended after clk? > > Frankly speaking this works now, because the devices are populated in > the order of their presence in device-tree. When the order would be > reverse, dw-mmc driver will defer probe until clocks are registered. > This would be enough to ensure proper suspend/resume order, because all > deferred devices are moved to the end of dpm_list (the list of device > used for system suspend/resume calls), see deferred_probe_work_func() > and comments there. Looks quite fragile... but I understand now that your patch is a logical solution for existing infrastructure with existing dw-mmc behavior during suspend. I wonder whether the device links should be used here (in case of dw-mmc and clk drivers) and in all clk consumers in general. Something similar to regulators_get(). Can you extend the commit msg with this clk--dw_mmc scenario? With that change: Reviewed-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx> Best regards, Krzysztof
