Re: [PATCH v1 1/2] caam: imx8m: fix the built-in caam driver cannot match soc_id

[Dominique Martinet <dominique.martinet@atmark-techno.com>]

Alice Guo (OSS) wrote on Thu, Apr 29, 2021 at 10:02:49PM +0800:
> From: Alice Guo <alice.guo@nxp.com>
> 
> 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/



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@nxp.com>

And philosophical questions aside, this works for me:
Tested-by: Dominique Martinet <dominique.martinet@atmark-techno.com>

-- 
Dominique