On 12/26/2015 11:07 PM, Julia Lawall wrote:
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index 3409e80..6a76992 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -2448,8 +2448,10 @@ static int cpsw_probe(struct platform_device *pdev) /* RX IRQ */ irq = platform_get_irq(pdev, 1); - if (irq < 0) + if (irq < 0) { + ret = -ENOENT;Why not just propagate an error returned by that function?OK, I did what was done a few lines before in the same function: ndev->irq = platform_get_irq(pdev, 1); if (ndev->irq < 0) { dev_err(priv->dev, "error getting irq resource\n"); ret = -ENOENT; goto clean_ale_ret; } Maybe they should all be changed?Yeah, I'd vote for it. I'm seeing no sense in overriding an actual error.Hm, I decided to check drivers/base/dd.c and I think I maybe know the reason now: -ENXIO, usually returned by platform_get_irq(), is silently "swallowed" by really_probe(); to be precise, -ENODEV and -ENXIO are only reported with pr_debug(), while -ENOENT causes printk(KERN_WARNING, ...)...
Sorry, I'm confused... What should it be? v1 or v2? Here are the counts of the different constants returned on failure of platform_get_irq:
I was somewhat confused myself but then I remembered about the deferred probing -- overriding error code basically just disables it in this case.
ENODEV: 84 ENXIO: 67
Those 2 totally make no sense. :-)
EINVAL: 61 ENOENT: 29 EBUSY: 11
Hm...
EIO: 2 EPROBE_DEFER: 1
Hm, and that last one is unconditional?
julia
MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
