lkml.org 
[lkml]   [2016]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 2/3] of: Support hashtable lookups for phandles
On Tue, May 10, 2016 at 8:45 AM, Pantelis Antoniou
<pantelis.antoniou@konsulko.com> wrote:
> Hi Rob,
>
>> On May 10, 2016, at 00:11 , Rob Herring <robherring2@gmail.com> wrote:
>>
>> On Mon, May 9, 2016 at 3:38 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> Hi Pantelis,
>>>
>>> On Mon, May 9, 2016 at 8:11 PM, Pantelis Antoniou
>>> <pantelis.antoniou@konsulko.com> wrote:
>>>> --- a/drivers/of/base.c
>>>> +++ b/drivers/of/base.c
>>>
>>>> @@ -1073,9 +1097,14 @@ struct device_node *of_find_node_by_phandle(phandle handle)
>>>> return NULL;
>>>>
>>>> raw_spin_lock_irqsave(&devtree_lock, flags);
>>>> - for_each_of_allnodes(np)
>>>> - if (np->phandle == handle)
>>>> - break;
>>>> + /* when we're ready use the hash table */
>>>> + if (of_phandle_ht_available() && !in_interrupt())
>>>
>>> I guess the !in_interrupt() test is because of the locking inside
>>> rhashtable_lookup_fast()?
>>
>> Not a use we should support. Just warn for anyone parsing DT in
>> interrupt context.
>>
>
> That’s not about users calling in interrupt context. It’s when we’re
> very early in the boot sequence we’re under interrupt context and
> calls to the hash methods cannot be made.

I don't understand. When exactly are we in interrupt context?

Rob

\
 
 \ /
  Last update: 2016-05-10 16:41    [W:0.067 / U:3.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site