[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00fc90ee-de26-f819-9c81-27d06918564d@gmail.com>
Date: Wed, 24 Jan 2018 22:55:13 -0800
From: Frank Rowand <frowand.list@...il.com>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>,
devicetree@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>
Cc: Tyrel Datwyler <tyreld@...ux.vnet.ibm.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
linux-renesas-soc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
Rob Herring <robh+dt@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle
issues
Hi Steve,
On 01/21/18 06:31, Wolfram Sang wrote:
> I got a bug report for a DT node refcounting problem in the I2C subsystem. This
> patch was a huge help in validating the bug report and the proposed solution.
> So, I thought I bring it to attention again. Thanks Tyrel, for the initial
> work!
>
> Note that I did not test the dynamic updates, only of_node_{get|put} so far. I
> read that Tyrel checked dynamic updates extensively with this patch. And since
> DT overlays are also used within our Renesas dev team, this will help there, as
> well.
>
> Tested on a Renesas Salvator-XS board (R-Car H3).
>
> Changes since RFC v1:
> * rebased to v4.15-rc8
> * fixed commit abbrev and one of the sysfs paths in commit desc
> * removed trailing space and fixed pointer declaration in code
>
> I consider all the remaining checkpatch issues irrelevant for this patch.
>
> So what about applying it?
>
> Kind regards,
>
> Wolfram
>
>
> Tyrel Datwyler (1):
> of: introduce event tracepoints for dynamic device_node lifecyle
>
> drivers/of/dynamic.c | 32 ++++++----------
> include/trace/events/of.h | 93 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 105 insertions(+), 20 deletions(-)
> create mode 100644 include/trace/events/of.h
>
Off the top of your head, can you tell me know early in the boot
process a trace_event can be called and successfully provide the
data to someone trying to debug early boot issues?
Also, way back when version 1 of this patch was being discussed,
a question about stacktrace triggers:
>>> # echo stacktrace > /sys/kernel/debug/tracing/trace_options
>>> # cat trace | grep -A6 "/pci@...000020000018"
>>
>> Just to let you know that there is now stacktrace event triggers, where
>> you don't need to stacktrace all events, you can pick and choose. And
>> even filter the stack trace on specific fields of the event.
>
> This is great, and I did figure that out this afternoon. One thing I was
> still trying to determine though was whether its possible to set these
> triggers at boot? As far as I could tell I'm still limited to
> "trace_options=stacktrace" as a kernel boot parameter to get the stack
> for event tracepoints.
No not yet. But I'll add that to the todo list.
Thanks,
-- Steve
Is this still on your todo list, or is it now available?
Thanks,
Frank
Powered by blists - more mailing lists