re: gpio-ml-ioh: Support interrupt function

re: gpio-ml-ioh: Support interrupt function

[Dan Carpenter]

Hi,

The linux-next patch 54be566317b6 "gpio-ml-ioh: Support interrupt
function" generates a Sparse warning.

+               irq_base = irq_alloc_descs(-1, IOH_IRQ_BASE, num_ports[j],
+                                          GFP_KERNEL);
                                           ^^^^^^^^^^

The last argument should be a NUMA node, not a GFP_ flag.  I'm not
sure what the right fix is.  There are currently 5 callers in my
cscope for this function in linux-next.

2 pass GFP_KERNEL which is wrong.
2 pass 0 which maybe should be cpu_to_node(0)?
1 passes -1 which maybe could be NUMA_NO_NODE?

I'm probably embarrassing myself with my ignorance here, but I do
know that GFP_KERNEL isn't right.

regards,
dan carpenter

Re: gpio-ml-ioh: Support interrupt function

[Tomoya MORINAGA]

Hi,

(2011/10/18 5:10), Dan Carpenter wrote:
> The linux-next patch 54be566317b6 "gpio-ml-ioh: Support interrupt
> function" generates a Sparse warning.
>
> +               irq_base = irq_alloc_descs(-1, IOH_IRQ_BASE, num_ports[j],
> +                                          GFP_KERNEL);
>                                             ^^^^^^^^^^
>
> The last argument should be a NUMA node, not a GFP_ flag.  I'm not
> sure what the right fix is.  There are currently 5 callers in my
> cscope for this function in linux-next.
>
> 2 pass GFP_KERNEL which is wrong.
> 2 pass 0 which maybe should be cpu_to_node(0)?
> 1 passes -1 which maybe could be NUMA_NO_NODE?
>
I can understand your saying.
Seeing accepted other drivers, '0' or '-1' is used.
Focusing on GPIO driver, gpio-pca953x.c uses '-1'.

Though I tried to understand source code of irq_alloc_descs,
I can't understand which value we should use.

 > Grant,
Could you help me ?

-- 
tomoya
ROHM Co., Ltd.

Re: gpio-ml-ioh: Support interrupt function

[David Rientjes]

On Tue, 18 Oct 2011, Tomoya MORINAGA wrote:

> > The linux-next patch 54be566317b6 "gpio-ml-ioh: Support interrupt
> > function" generates a Sparse warning.
> > 
> > +               irq_base = irq_alloc_descs(-1, IOH_IRQ_BASE, num_ports[j],
> > +                                          GFP_KERNEL);
> >                                             ^^^^^^^^^^
> > 
> > The last argument should be a NUMA node, not a GFP_ flag.  I'm not
> > sure what the right fix is.  There are currently 5 callers in my
> > cscope for this function in linux-next.
> > 
> > 2 pass GFP_KERNEL which is wrong.

Right, all irq_alloc_descs() allocations are already implicitly 
GFP_KERNEL.

> > 2 pass 0 which maybe should be cpu_to_node(0)?
> > 1 passes -1 which maybe could be NUMA_NO_NODE?
> > 
> I can understand your saying.
> Seeing accepted other drivers, '0' or '-1' is used.

There's actually no guarantee in the kernel that node 0 has memory, so 
unless that is assured in the context then passing 0 would be wrong.

> Focusing on GPIO driver, gpio-pca953x.c uses '-1'.
> 

The slab layer guarantees that passing -1 will allocate on the node that 
is local to the cpu that the code is running on.  Unless there's a 
compelling reason to allocate on a different node, then this is what you 
want to use.

We try not to pass -1 directly, though, we try to use NUMA_NO_NODE 
wherever possible.

Re: gpio-ml-ioh: Support interrupt function

[Tomoya MORINAGA]

(2011/10/18 14:56), David Rientjes wrote:
> On Tue, 18 Oct 2011, Tomoya MORINAGA wrote:
>
>>> The linux-next patch 54be566317b6 "gpio-ml-ioh: Support interrupt
>>> function" generates a Sparse warning.
>>>
>>> +               irq_base = irq_alloc_descs(-1, IOH_IRQ_BASE, num_ports[j],
>>> +                                          GFP_KERNEL);
>>>                                              ^^^^^^^^^^
>>>
>>> The last argument should be a NUMA node, not a GFP_ flag.  I'm not
>>> sure what the right fix is.  There are currently 5 callers in my
>>> cscope for this function in linux-next.
>>>
>>> 2 pass GFP_KERNEL which is wrong.
>
> Right, all irq_alloc_descs() allocations are already implicitly
> GFP_KERNEL.
>
>>> 2 pass 0 which maybe should be cpu_to_node(0)?
>>> 1 passes -1 which maybe could be NUMA_NO_NODE?
>>>
>> I can understand your saying.
>> Seeing accepted other drivers, '0' or '-1' is used.
>
> There's actually no guarantee in the kernel that node 0 has memory, so
> unless that is assured in the context then passing 0 would be wrong.
>
>> Focusing on GPIO driver, gpio-pca953x.c uses '-1'.
>>
>
> The slab layer guarantees that passing -1 will allocate on the node that
> is local to the cpu that the code is running on.  Unless there's a
> compelling reason to allocate on a different node, then this is what you
> want to use.
>
> We try not to pass -1 directly, though, we try to use NUMA_NO_NODE
> wherever possible.
 >

Hi, David
Thank you for your information.
I will try to test with '-1'.

After testing with '-1',
I will post the patch for this.

Thanks,
-- 
tomoya
ROHM Co., Ltd.

Re: gpio-ml-ioh: Support interrupt function

[David Rientjes]

On Tue, 18 Oct 2011, Tomoya MORINAGA wrote:

> Hi, David
> Thank you for your information.
> I will try to test with '-1'.
> 
> After testing with '-1',
> I will post the patch for this.
> 

Please try with NUMA_NO_NODE, that's what the slab allocators use and will 
be the ones consuming this.  It's available in include/linux/numa.h.

Re: gpio-ml-ioh: Support interrupt function

[Tomoya MORINAGA]

(2011/10/18 15:52), David Rientjes wrote:
> On Tue, 18 Oct 2011, Tomoya MORINAGA wrote:
>
>> Hi, David
>> Thank you for your information.
>> I will try to test with '-1'.
>>
>> After testing with '-1',
>> I will post the patch for this.
>>
>
> Please try with NUMA_NO_NODE, that's what the slab allocators use and will
> be the ones consuming this.  It's available in include/linux/numa.h.

OK, I'll use NUMA_NO_NODE instead '-1'.

thanks,
-- 
tomoya
ROHM Co., Ltd.

Re: gpio-ml-ioh: Support interrupt function

[Tomoya MORINAGA]

(2011/10/18 14:56), David Rientjes wrote:
> On Tue, 18 Oct 2011, Tomoya MORINAGA wrote:
>
>>> The linux-next patch 54be566317b6 "gpio-ml-ioh: Support interrupt
>>> function" generates a Sparse warning.
>>>
>>> +               irq_base = irq_alloc_descs(-1, IOH_IRQ_BASE, num_ports[j],
>>> +                                          GFP_KERNEL);
>>>                                              ^^^^^^^^^^
>>>
>>> The last argument should be a NUMA node, not a GFP_ flag.  I'm not
>>> sure what the right fix is.  There are currently 5 callers in my
>>> cscope for this function in linux-next.
>>>
>>> 2 pass GFP_KERNEL which is wrong.
>
> Right, all irq_alloc_descs() allocations are already implicitly
> GFP_KERNEL.
>
>>> 2 pass 0 which maybe should be cpu_to_node(0)?
>>> 1 passes -1 which maybe could be NUMA_NO_NODE?
>>>
>> I can understand your saying.
>> Seeing accepted other drivers, '0' or '-1' is used.
>
> There's actually no guarantee in the kernel that node 0 has memory, so
> unless that is assured in the context then passing 0 would be wrong.
>
>> Focusing on GPIO driver, gpio-pca953x.c uses '-1'.
>>
>
> The slab layer guarantees that passing -1 will allocate on the node that
> is local to the cpu that the code is running on.  Unless there's a
> compelling reason to allocate on a different node, then this is what you
> want to use.
>
> We try not to pass -1 directly, though, we try to use NUMA_NO_NODE
> wherever possible.
> --

Using NUMA_NO_NODE, I confirmed our gpio(gpio-pch) works well.
I will submit the patch both gpio-pch and gpio-ml-ioh soon.

thanks,
-- 
tomoya
ROHM Co., Ltd.