All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Johan Hovold <johan@kernel.org>,
	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>,
	Lee Jones <lee.jones@linaro.org>, Rob Herring <robh@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 1/3] Input: twl4030-vibra: fix sibling-node lookup
Date: Sun, 12 Nov 2017 13:12:35 +0100	[thread overview]
Message-ID: <20171112121235.GO11226@localhost> (raw)
In-Reply-To: <20171111175059.lwfhw2wdhlj5yxhc@dtor-ws>

[ +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?

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()?
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).

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.

Johan

WARNING: multiple messages have this Message-ID (diff)
From: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Dmitry Torokhov
	<dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>,
	Marek Belisko <marek-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>,
	Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/3] Input: twl4030-vibra: fix sibling-node lookup
Date: Sun, 12 Nov 2017 13:12:35 +0100	[thread overview]
Message-ID: <20171112121235.GO11226@localhost> (raw)
In-Reply-To: <20171111175059.lwfhw2wdhlj5yxhc@dtor-ws>

[ +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?

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()?
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).

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.

Johan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-11-12 12:12 UTC|newest]

Thread overview: 33+ 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
2017-11-13  7:17     ` Peter Ujfalusi
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:10     ` Peter Ujfalusi
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 [this message]
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
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-11-13  7:17   ` Peter Ujfalusi
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=20171112121235.GO11226@localhost \
    --to=johan@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=lee.jones@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.