Re: [PATCH] dmatest: properly handle duplicate DMA channels

[Dan Williams]

On Fri, Sep 19, 2008 at 4:31 PM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 18 Sep 2008 10:21:19 -0500
> Timur Tabi <timur@xxxxxxxxxxxxx> wrote:
>
>> --- a/drivers/dma/dmatest.c
>> +++ b/drivers/dma/dmatest.c
>> @@ -321,10 +321,15 @@ static void dmatest_cleanup_channel(struct dmatest_chan *dtc)
>>
>>  static enum dma_state_client dmatest_add_channel(struct dma_chan *chan)
>>  {
>> -     struct dmatest_chan     *dtc;
>> +     struct dmatest_chan     *dtc, *_dtc;
>>       struct dmatest_thread   *thread;
>>       unsigned int            i;
>>
>> +     /* Have we already been told about this channel? */
>> +     list_for_each_entry_safe(dtc, _dtc, &dmatest_channels, node)
>> +             if (dtc->chan == chan)
>> +                     return DMA_DUP;
>> +
>>       dtc = kmalloc(sizeof(struct dmatest_chan), GFP_ATOMIC);
>>       if (!dtc) {
>>               pr_warning("dmatest: No memory for %s\n", chan->dev.bus_id);
>
> hm.  A few lines after that GFP_ATOMIC the driver does a GFP_KERNEL
> allocation.
>
> One of them is incorrect.  The interface is undocumented (natch), but I
> assume that GFP_KERNEL is the one to use here.
>

The interface is documented, although not the locking (natch), at
include/linux/dmaengine.h:229.  When I fix this up is there a
canonical location to document a callback interface rather than at the
callback's typedef?

Thanks,
Dan
--
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/