Re: [PATCH 7/7] arch/unicore32/kernel/dma.c: ensure arguments torequest_irq and free_irq are compatible

From: Julia Lawall
Date: Thu Mar 15 2012 - 02:10:40 EST




On Thu, 15 Mar 2012, Guan Xuetao wrote:

On Wed, 2012-03-14 at 10:23 +0100, Julia Lawall wrote:

On Wed, 14 Mar 2012, Guan Xuetao wrote:

On Wed, 2012-03-14 at 11:19 +0300, Dan Carpenter wrote:
On Wed, Mar 14, 2012 at 04:07:24PM +0800, Guan Xuetao wrote:
puv3_init_dma() is called ONCE when initializing.
In logical, if request_irq(IRQ_DMAERR, *) failed, free_irq(IRQ_DMA, *)
is unnecessary, and dma device/driver can keep on working.
The patch could be:
ret = request_irq(IRQ_DMAERR, dma_err_handler, 0, "DMAERR", NULL);
if (ret) {
printk(KERN_CRIT "Can't register IRQ for DMAERR\n");
- free_irq(IRQ_DMA, "DMA");
return ret;
}

It seems like you should remove the error return as well?

regards,
dan carpenter

The error return value will only generate an extra warning message, and
have no side-effect.

The whole thing seems a little strange. I guess your point is that the
call site never looks at the return value? Wouldn't it be better to make
there be no return value in that case? If there is a return value, some
calling context in the future might take that into account and then the
lack of a free_irq would be a memory leak. Also if the first request_irq
can never fail, perhaps that should be made explicit by not testing the
return value?

julia
This function is an init_call, not a probe function, and it is only
called ONCE.
The dma device here has two interrupts, one IRQ_DMA, another IRQ_DMAERR.
And the device could work without IRQ_DMAERR.
The return value should indicate whether there is something wrong during
initialization, so the function needs return errno when any request_irq
is failed.
For the first request_irq, some code has prepared its resources before
this call, so I suppose it successful. However, the return value must be
tested.

OK, thank you for the explanation. I will change the patch.

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/