public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
To: David Rientjes <rientjes@google.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>,
	linux-kernel@vger.kernel.org
Subject: Re: gpio-ml-ioh: Support interrupt function
Date: Tue, 18 Oct 2011 15:38:16 +0900	[thread overview]
Message-ID: <4E9D1ED8.3070106@dsn.lapis-semi.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1110172251590.4880@chino.kir.corp.google.com>

(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.

  reply	other threads:[~2011-10-18  6:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-17 20:10 gpio-ml-ioh: Support interrupt function Dan Carpenter
2011-10-18  0:32 ` Tomoya MORINAGA
2011-10-18  5:56   ` David Rientjes
2011-10-18  6:38     ` Tomoya MORINAGA [this message]
2011-10-18  6:52       ` David Rientjes
2011-10-18  7:03         ` Tomoya MORINAGA
2011-10-18 12:12     ` Tomoya MORINAGA

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E9D1ED8.3070106@dsn.lapis-semi.com \
    --to=tomoya-linux@dsn.lapis-semi.com \
    --cc=dan.carpenter@oracle.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=tomoya-linux@dsn.okisemi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox