From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "Dr. H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Rob Herring <robherring2@gmail.com>,
Belisko Marek <marek.belisko@gmail.com>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Grant Likely <grant.likely@linaro.org>
Subject: Re: [PATCH] input: twl4030-vibra: Fix ERROR: Bad of_node_put() warning
Date: Wed, 29 Jul 2015 10:56:56 -0700 [thread overview]
Message-ID: <20150729175656.GE23178@dtor-ws> (raw)
In-Reply-To: <C6FA80D1-B1EC-4C8B-9E58-448156DDE766@goldelico.com>
On Wed, Jul 29, 2015 at 07:50:24PM +0200, Dr. H. Nikolaus Schaller wrote:
>
> Am 29.07.2015 um 19:26 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>
> > On Tue, Jul 28, 2015 at 10:13:54PM -0500, Rob Herring wrote:
> >> On Tue, Jul 28, 2015 at 3:23 PM, Belisko Marek <marek.belisko@gmail.com> wrote:
> >>> Hi Dmitry,
> >>>
> >>> On Thu, Jul 23, 2015 at 10:53 PM, Dmitry Torokhov
> >>> <dmitry.torokhov@gmail.com> wrote:
> >>>> On Thu, Jul 23, 2015 at 10:38:34PM +0200, Marek Belisko wrote:
> >>>>> Fix following:
> >>>>> [ 8.862274] ERROR: Bad of_node_put() on /ocp/i2c@48070000/twl@48/audio
> >>>>> [ 8.869293] CPU: 0 PID: 1003 Comm: modprobe Not tainted 4.2.0-rc2-letux+ #1175
> >>>>> [ 8.876922] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> >>>>> [ 8.883514] [<c00159e0>] (unwind_backtrace) from [<c0012488>] (show_stack+0x10/0x14)
> >>>>> [ 8.891693] [<c0012488>] (show_stack) from [<c05cb810>] (dump_stack+0x78/0x94)
> >>>>> [ 8.899322] [<c05cb810>] (dump_stack) from [<c02cfd5c>] (kobject_release+0x68/0x7c)
> >>>>> [ 8.907409] [<c02cfd5c>] (kobject_release) from [<bf0040c4>] (twl4030_vibra_probe+0x74/0x188 [twl4030_vibra])
> >>>>> [ 8.917877] [<bf0040c4>] (twl4030_vibra_probe [twl4030_vibra]) from [<c03816ac>] (platform_drv_probe+0x48/0x90)
> >>>>> [ 8.928497] [<c03816ac>] (platform_drv_probe) from [<c037feb4>] (really_probe+0xd4/0x238)
> >>>>> [ 8.937103] [<c037feb4>] (really_probe) from [<c0380160>] (driver_probe_device+0x30/0x48)
> >>>>> [ 8.945678] [<c0380160>] (driver_probe_device) from [<c03801e0>] (__driver_attach+0x68/0x8c)
> >>>>> [ 8.954589] [<c03801e0>] (__driver_attach) from [<c037ea60>] (bus_for_each_dev+0x50/0x84)
> >>>>> [ 8.963226] [<c037ea60>] (bus_for_each_dev) from [<c037f828>] (bus_add_driver+0xcc/0x1e4)
> >>>>> [ 8.971832] [<c037f828>] (bus_add_driver) from [<c0380b60>] (driver_register+0x9c/0xe0)
> >>>>> [ 8.980255] [<c0380b60>] (driver_register) from [<c00097e0>] (do_one_initcall+0x100/0x1b8)
> >>>>> [ 8.988983] [<c00097e0>] (do_one_initcall) from [<c00b8008>] (do_init_module+0x58/0x1c0)
> >>>>> [ 8.997497] [<c00b8008>] (do_init_module) from [<c00b8cac>] (SyS_init_module+0x54/0x64)
> >>>>> [ 9.005950] [<c00b8cac>] (SyS_init_module) from [<c000ed20>] (ret_fast_syscall+0x0/0x54)
> >>>>> [ 9.015838] input: twl4030:vibrator as /devices/platform/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl@48:audio/input/input2
> >>>>>
> >>>>> node passed to of_find_node_by_name is put inside that function and new node
> >>>>> is returned if found. Free returned node not already freed node.
> >>>>
> >>>> Hmm, if of_find_node_by_name() "puts" passed in node should we not "get"
> >>>> it before calling of_find_node_by_name()? The node pointer in question
> >>>> is simply copied from parent device.
> >>> I'm not sure. what I can say is that I cannot see such error in 4.1
> >>> but only in 4.2-rcx.
> >>> Adding Grant and Rob to CC, maybe they know what should be done and
> >>> why I see such error in 4.2-rcx.
> >>
> >> The problem was that node passed into of_find_node_by_name is the the
> >> starting point to search, but you should be doing the put on the
> >> returned node. So the patch below is correct.
> >>
> >> As far as why in 4.2, it seems you have OF_DYNAMIC enabled in your
> >> config either because you have DT unit test or overlays enabled.
> >> Overlays are now user enable-able in 4.2.
> >
> > Right, but the question was whether we should also "get" the node that
> > we are passing into of_find_node_by_name(), or, maybe better, stop
> > of_find_node_by_name() from "putting" the node that is passed in? It is
> > really surprising behavior.
>
> I agree that it is quite unexpected and would be much easier to understand
> if it would not put the node.
>
> But I guess it is intended to be a convenience to make it easier to walk down
> the tree, i.e. that you can simply write
>
> np = of_find_node_by_name(NULL, “level11”);
> np = of_find_node_by_name(np, “level2”);
> np = of_find_node_by_name(np, “level3”);
Right, also for_each_node_by_name() relies on this behavior (but we can
fix it to use something like __of_find_node_by_name_and_put_from()).
>
> Otherwise it would need some temporary variable and explicit calls to put the
> parent level after finding a child node.
>
> On the other hand greping for of_find_node_by_name returns many more
> calls with parent = NULL than others. So the put is ignored anyways.
>
> But it is a major change in semantics of a very low level function so it is
> easy to introduce regressions (especially in out-of-the tree drivers).
I am not sure how much we should care about out of tree drivers; but I
worry that there are several callers that simply do:
np = of_find_node_by_bame(dev->of_node, "blah");
in our tree...
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2015-07-29 17:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-23 20:38 [PATCH] input: twl4030-vibra: Fix ERROR: Bad of_node_put() warning Marek Belisko
2015-07-23 20:53 ` Dmitry Torokhov
2015-07-28 20:23 ` Belisko Marek
2015-07-29 3:13 ` Rob Herring
2015-07-29 5:47 ` Dr. H. Nikolaus Schaller
2015-07-29 9:44 ` Dr. H. Nikolaus Schaller
2015-08-06 10:34 ` Tomi Valkeinen
2015-07-29 17:26 ` Dmitry Torokhov
2015-07-29 17:50 ` Dr. H. Nikolaus Schaller
2015-07-29 17:56 ` Dmitry Torokhov [this message]
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=20150729175656.GE23178@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=grant.likely@linaro.org \
--cc=hns@goldelico.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marek.belisko@gmail.com \
--cc=robh+dt@kernel.org \
--cc=robherring2@gmail.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;
as well as URLs for NNTP newsgroup(s).