Messages in this thread | | | Date | Fri, 30 Apr 2021 15:10:52 +0900 | From | Dominique Martinet <> | Subject | Re: [PATCH v1 1/2] caam: imx8m: fix the built-in caam driver cannot match soc_id |
| |
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
| |