Alice Guo (OSS) wrote on Thu, Apr 29, 2021 at 10:02:49PM +0800: > From: Alice Guo <alice.guo@xxxxxxx> > > drivers/soc/imx/soc-imx8m.c is probed later than the caam driver so that > return -EPROBE_DEFER is needed after calling soc_device_match() in > drivers/crypto/caam/ctrl.c. For i.MX8M, soc_device_match returning NULL > can be considered that the SoC device has not been probed yet, so it > returns -EPROBE_DEFER directly. So basically you're saying if the soc is imx8m then soc_device_match() has to find a match -- if for some reason there is rightfully no match the caam driver will forever loop on EPROBE_DEFER (not sure how that is handled by the driver stack?); but in this particular case we don't actually need soc_device_match() to work: it's just there to pick the appropriate clock data from caam_imx_soc_table[], and we already know we should use &caam_imx7_data if imx8m_machine_match got a hit. If we're going this way (making the caam driver only handle soc init being late as that was noticeable), then I'd tend to agree with arnd's comment[1] and not rely on soc_device_match at all in this case -- just keeping it as a fallback if direct of_match_node didn't work for compabitility with other devices. [1] https://lore.kernel.org/r/CAK8P3a1GjeHyMCworQYVtp5U0uu2B9VBHmf9y0hGn-o8aKSJZw@xxxxxxxxxxxxxx/ Note I haven't had time to play with device_link_add or other ways to make the soc init successfully early, but it's probably better to not wait for me on this so I'm quite happy with this for now. > Fixes: 7d981405d0fd ("soc: imx8m: change to use platform driver") > Signed-off-by: Alice Guo <alice.guo@xxxxxxx> And philosophical questions aside, this works for me: Tested-by: Dominique Martinet <dominique.martinet@xxxxxxxxxxxxxxxxx> -- Dominique
