From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] mfd: Fix runtime warning caused by duplicate device registration
Date: Tue, 3 Jul 2012 15:43:25 +0100 [thread overview]
Message-ID: <20120703144325.GR29030@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <201207031401.36262.arnd@arndb.de>
On Tue, Jul 03, 2012 at 02:01:35PM +0000, Arnd Bergmann wrote:
> On Tuesday 03 July 2012, Mark Brown wrote:
> > I'm really unconvinced that instnatiating the MFD cells from device tree
> > is in general a good idea.
> In general it's not, e.g. it makes no sense when the MFD is just
> a bunch of registers that are mapped to various distinct Linux
> devices. The two mfd devices on ux500 (prcmu and ab8500) are really
> buses by themselves that happen to be implemented using the MFD
> framework on Linux.
This is true for pretty much all MFDs except the pure MMIO ones.
> I don't see how we would get around representing the buses in
> the device tree because we have to refer to nodes under them
> from off-chip devices. Simplified we have something like
We can always refer to the parent device itself; there's two separate
things going on here which we can resolve separately. One is
instantiating the children and the other is referencing the various
configuration that's needed which we don't need to do by mapping MFD
cells directly onto device tree nodes. The MFD children can always look
at the DT bindings of their parents.
> Most of the stuff on the board is connected to the ab8500 regulators and
> gpio pins, which are also used as interrupts. In order to hook up
> the external devices in the device tree, we need to have something that
> we can point to as their interrupt-parent or the phandle in the gpio
> description.
Right, but there's no reason we have to instantiate a dedicated node for
each of these things and we should think carefully about what we're
doing. One of the problems I've seen with people doing this stuff is
that the split we do for some of the cells in Linux is often not really
a good generic representation of the hardware (and some of them are actually
churning right now) so encoding it in the device tree isn't so helpful.
You also seem to get stuff where the MFD cells are all full of hard
coding for their parent so there's no way you could reuse them and again
we don't gain anything.
There will be some places where representing things directly in the DT
makes sense but we should think carefully before we go and do it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120703/058ad2f7/attachment.sig>
next prev parent reply other threads:[~2012-07-03 14:43 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-03 11:59 [PATCH 1/1] mfd: Fix runtime warning caused by duplicate device registration Lee Jones
2012-07-03 12:35 ` Mark Brown
2012-07-03 13:07 ` Lee Jones
2012-07-03 13:24 ` Mark Brown
2012-07-03 13:48 ` Lee Jones
2012-07-03 14:21 ` Mark Brown
2012-07-05 7:36 ` Lee Jones
2012-07-05 9:45 ` Mark Brown
2012-07-05 11:46 ` Lee Jones
2012-07-05 12:06 ` Mark Brown
2012-07-05 12:15 ` Lee Jones
2012-07-05 12:29 ` Mark Brown
2012-07-05 12:41 ` Lee Jones
2012-07-05 12:45 ` Mark Brown
2012-07-05 12:55 ` Lee Jones
2012-07-05 13:03 ` Mark Brown
2012-07-05 13:12 ` Lee Jones
2012-07-05 13:20 ` Mark Brown
2012-07-05 13:54 ` Lee Jones
2012-07-05 13:57 ` Mark Brown
2012-07-05 14:06 ` Samuel Ortiz
2012-07-05 13:57 ` Arnd Bergmann
2012-07-05 14:04 ` Mark Brown
2012-07-05 14:06 ` Lee Jones
2012-07-05 14:13 ` Mark Brown
2012-07-05 14:35 ` Lee Jones
2012-07-05 15:41 ` Arnd Bergmann
2012-07-05 15:51 ` Lee Jones
2012-07-03 14:01 ` Arnd Bergmann
2012-07-03 14:43 ` Mark Brown [this message]
2012-07-05 7:33 ` Lee Jones
2012-07-05 13:08 ` Fabio Estevam
2012-07-05 13:13 ` Lee Jones
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=20120703144325.GR29030@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-kernel@lists.infradead.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).