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 10:20:28 +0000 [thread overview]
Message-ID: <20171113102028.c53rlcnwrjaey2tv@dell> (raw)
In-Reply-To: <20171113093544.GR11226@localhost>
On Mon, 13 Nov 2017, Johan Hovold wrote:
> On Mon, Nov 13, 2017 at 09:11:44AM +0000, Lee Jones wrote:
> > 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.
>
> Ok, a follow up: When there are different variants of an MFD and that
> affects the child drivers, then that should be expressed in in the child
> node compatibles rather than having the child match on the parent node?
>
> I'm asking because this came up recently during review and their seems
> to be no precedent for matching on the parent compatible in child
> drivers:
>
> https://lkml.kernel.org/r/20171105154725.GA11226@localhost
Accessing the parent's of_device_id .data directly doesn't sit well
with me. The parent driver should pass this type of configuration
though pdata IMHO.
> > > 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.
>
> Even if that means leaking details of one child driver into a sibling?
Not sure what you mean here. Could you please elaborate or provide an
example?
> Isn't it then cleaner to use the parent MFD to coordinate between the
> cells, just as we do for IO?
>
> In this case a child driver looked up a sibling node based on name, but
This should not be allowed. If >1 sibling requires access to a
particular property, this is normally evidence enough that this
property should be shared and handled by the parent.
> that doesn't mean the node is active, that there's a driver bound, or
> that the sibling node has some other random property for example. The
> parent could be used for such coordination, if only to pass information
> from one sibling to another.
Right.
--
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 10:20 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
2017-11-13 9:35 ` Johan Hovold
2017-11-13 10:20 ` Lee Jones [this message]
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=20171113102028.c53rlcnwrjaey2tv@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).