Re: lockdep dump on devtree_lock (involving esdhc)

[Grant Likely <grant.likely@secretlab.ca>]

On Wed, Jun 12, 2013 at 8:49 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 11 Jun 2013, Scott Wood wrote:
>
>> I get the following lockdump output on p2020rdb using
>> v3.10-rc5-43-g34376a5.  While it's not particularly polite for the
>> esdhc driver to be calling OF functions while holding another lock which
>> can be acquired from interrupt context, why is devtree_lock usually
>> acquired in an irqsafe manner but sometimes not?
>>
>> Both types of usage were added by the same commit:
>>
>> commit d6d3c4e656513dcea61ce900f0ecb9ca820ee7cd
>> Author: Thomas Gleixner <tglx@linutronix.de>
>> Date:   Wed Feb 6 15:30:56 2013 -0500
>>
>>     OF: convert devtree lock from rw_lock to raw spinlock
>>
>> Stephen, you asked about this here:
>> http://lkml.indiana.edu/hypermail/linux/kernel/1302.1/01383.html
>>
>> Did you ever get an answer?
>
> https://patchwork.kernel.org/patch/2470731/
>
>> I'm also curious why devtree_lock was made raw to begin with...
>> Iterating over a device tree doesn't seem like something you'd want to
>> trust to be low-latency.
>
> The reason is that it's taken in low level cpu bringup code and I did
> not find a different solution. :(

Hey, Thomas,

Do you remember where the offending code is? I'm looking at completely
refactoring FDT locking so I'd like to take a crack and solving the
cpu bringup problem.

g.