From: Lee Jones <lee.jones@linaro.org>
To: Johan Hovold <johan@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
stable <stable@vger.kernel.org>,
Peter Ujfalusi <peter.ujfalusi@ti.com>,
Marek Belisko <marek@goldelico.com>,
Rob Herring <robh@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH 1/3] Input: twl4030-vibra: fix sibling-node lookup
Date: Mon, 13 Nov 2017 09:11:44 +0000 [thread overview]
Message-ID: <20171113091144.5oz77shbu4oupoy7@dell> (raw)
In-Reply-To: <20171112121235.GO11226@localhost>
On Sun, 12 Nov 2017, Johan Hovold wrote:
> [ +CC: Lee, Rob and device-tree list ]
>
> On Sat, Nov 11, 2017 at 09:50:59AM -0800, Dmitry Torokhov wrote:
> > On Sat, Nov 11, 2017 at 04:43:37PM +0100, Johan Hovold wrote:
> > > A helper purported to look up a child node based on its name was using
> > > the wrong of-helper and ended up prematurely freeing the parent of-node
> > > while searching the whole device tree depth-first starting at the parent
> > > node.
> >
> > Ugh, this all is pretty ugly business. Can we teach MFD to allow
> > specifying firmware node to be attached to the platform devices it
> > creates in mfd_add_device() so that the leaf drivers simply call
> > device_property_read_XXX() on their own device and not be bothered with
> > weird OF refcount issues or what node they need to locate and parse?
If a child compatible is provided, we already set the child's
of_node. It's then up to the driver (set) author(s) to use it in the
correct manner.
> Yeah, that may have helped. You can actually specify a compatible string
> in struct mfd_cell today which does make mfd_add_device() associate a
> matching child node.
>
> Some best practice regarding how to deal with MFD and device tree would
> be good to determine and document too. For example, when should
> of_platform_populate() be used in favour of mfd_add_device()?
When the device supports DT and its entire hierarchical layout, along
with all of its attributes can be expressed in DT.
> And how best to deal with sibling nodes, which is part of the problem
> here (I think the mfd should have provided a flag rather than having
> subdrivers deal with sibling nodes, for example).
I disagree. The only properties the MFD (parent) driver is interested
in is ones which are shared across multiple child devices.
*Everything* which pertains to only a single child device should be
handled by its accompanying driver.
> That said, driver authors using the wrong of-helper could possibly have
> been avoided by amending the kernel docs (I'll do that as a follow up),
> but once these incorrect usages get in, only review can prevent them
> from being reproduced through copy-paste coding.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2017-11-13 9:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-11 15:43 [PATCH 1/3] Input: twl4030-vibra: fix sibling-node lookup Johan Hovold
2017-11-11 15:43 ` [PATCH 2/3] Input: twl6040-vibra: fix child-node lookup Johan Hovold
2017-11-13 7:17 ` Peter Ujfalusi
[not found] ` <91A591C4-D6BD-462D-B81E-224DB268EDDB@goldelico.com>
2017-11-13 9:16 ` Johan Hovold
2017-11-13 14:10 ` Peter Ujfalusi
2017-11-13 14:19 ` Johan Hovold
2017-11-13 14:39 ` H. Nikolaus Schaller
2017-11-13 14:46 ` Johan Hovold
2018-01-09 1:35 ` Dmitry Torokhov
2017-11-11 15:43 ` [PATCH 3/3] Input: 88pm860x-ts: " Johan Hovold
2018-01-09 1:35 ` Dmitry Torokhov
2017-11-11 17:50 ` [PATCH 1/3] Input: twl4030-vibra: fix sibling-node lookup Dmitry Torokhov
2017-11-12 12:12 ` Johan Hovold
2017-11-13 9:11 ` Lee Jones [this message]
2017-11-13 9:35 ` Johan Hovold
2017-11-13 10:20 ` Lee Jones
2017-11-13 11:51 ` Johan Hovold
2017-11-13 21:54 ` Dmitry Torokhov
2017-11-14 10:39 ` Lee Jones
2017-11-13 7:17 ` Peter Ujfalusi
2017-12-11 10:21 ` Johan Hovold
2018-01-08 13:55 ` Johan Hovold
2018-01-09 1:36 ` Dmitry Torokhov
2018-01-09 9:21 ` Johan Hovold
2018-01-09 1:17 ` Dmitry Torokhov
2018-01-09 1:35 ` Dmitry Torokhov
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=20171113091144.5oz77shbu4oupoy7@dell \
--to=lee.jones@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=johan@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marek@goldelico.com \
--cc=peter.ujfalusi@ti.com \
--cc=robh@kernel.org \
--cc=stable@vger.kernel.org \
/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).