Hi Vignesh, Vignesh Raghavendra <vigneshr@xxxxxx> writes: > Hi Nicolas, > > On 08/11/22 11:41 pm, Nicolas Frayer wrote: >> When the k3 socinfo driver is built as a module, there is a possibility >> that it will probe after the davinci mdio driver. By deferring the mdio >> probe we allow the k3 socinfo to probe and register the >> soc_device_attribute structure needed by the mdio driver. >> >> Signed-off-by: Nicolas Frayer <nfrayer@xxxxxxxxxxxx> >> --- >> drivers/net/ethernet/ti/davinci_mdio.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c >> index 946b9753ccfb..095198b6b7be 100644 >> --- a/drivers/net/ethernet/ti/davinci_mdio.c >> +++ b/drivers/net/ethernet/ti/davinci_mdio.c >> @@ -533,6 +533,10 @@ static int davinci_mdio_probe(struct platform_device *pdev) >> const struct soc_device_attribute *soc_match_data; >> >> soc_match_data = soc_device_match(k3_mdio_socinfo); >> + >> + if (!soc_match_data) >> + return -EPROBE_DEFER; > > I dont think this is right way to detect if socinfo driver is probed. > Per documentation of soc_device_match() , function will return NULL if > it does not match any of the entries in k3_mdio_socinfo (ie if we are > running on any platforms other that ones in the list) > > Note that this driver is used on TI's 32 bit SoCs too that dont even > have a k3-socinfo driver equivalent. In such case, this code will end up > probe deferring indefinitely. Yes, you're right. This is not the right solution and this patch should be dropped. We'll need to have a deeper look at socinfo to figure out if/how it could be configured to support a fully modular kernel. Kevin
