On Tue, May 10, 2016 at 8:45 AM, Pantelis Antoniou <pantelis.anton...@konsulko.com> wrote: > Hi Rob, > >> On May 10, 2016, at 00:11 , Rob Herring <robherri...@gmail.com> wrote: >> >> On Mon, May 9, 2016 at 3:38 PM, Geert Uytterhoeven <ge...@linux-m68k.org> >> wrote: >>> Hi Pantelis, >>> >>> On Mon, May 9, 2016 at 8:11 PM, Pantelis Antoniou >>> <pantelis.anton...@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
