Alice Guo (OSS) wrote on Thu, Apr 29, 2021 at 10:02:49PM +0800:

From: Alice Guo <redacted>

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@mail.gmail.com/ (local)



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 <redacted>

And philosophical questions aside, this works for me:
Tested-by: Dominique Martinet <redacted>

-- 
Dominique

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel