From: ezequiel.garcia@free-electrons.com (Ezequiel Garcia)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus driver
Date: Tue, 9 Apr 2013 07:34:46 -0300 [thread overview]
Message-ID: <20130409103445.GA2268@localhost> (raw)
In-Reply-To: <201304091140.51839.arnd@arndb.de>
Hi Arnd,
On Tue, Apr 09, 2013 at 11:40:51AM +0200, Arnd Bergmann wrote:
> On Tuesday 09 April 2013, Ezequiel Garcia wrote:
> > > This can probably just be of_platform_populate or similar to do all
> > > children? For instance, I often use many DT nodes to represent a FPGA,
> > > since the my FPGA's tend to have many functionally orthogonal units
> > > inside.
> > >
> >
> > In the past I've found it's not possible to use of_platform_populate,
> > altough I can be wrong.
> >
> > The problem seems to be that through of_platform_populate() it's
> > possible that the child device (cfi-flash, for instance) gets probed
> > before the devbus controller. In other words, the actual parent-child
> > relationship gets lost and it's necesarry to use some child probe deferal
> > mechanism.
> >
> > This has been recently discussed [1] when implementing GPMC where for simplicity
> > the of_platform_device_create() solution was chosen.
> > Anyway, I'll try of_platform_populate early tomorrow.
>
> I think the problem mentioned in that thread was that the device would
> automatically get probed by the top-level of_platform_populate() when
> you mark the devbus as compatible="simple-bus", which is not what Jason
> was referring to. Instead you should call of_platform_populate in the
> probe() function of the devbus device to probe its children after
> the bus is set up.
>
Ah! yes, you're right...
Well, in that case the only issue I can foresee is that if we decide
to use of_platform_populate we won't be able to unregister child
devices from the remove() callback.
Indeed, the benefits of using of_platform_populate are interesting,
but I don't know how much of an issue this represents.
If we can't unregister child devices, we can't remove address windows.
Now, this is not a big deal, since we plan to define them statically in
the DT anyway.
In that case, it seems we shouldn't allow this driver to be a module, uh?
(actually we currently can't have mvebu-devbus as a module, because
mbus API is not exported, but we can fix that if we want).
What do you think?
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
next prev parent reply other threads:[~2013-04-09 10:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-08 11:06 [PATCH v4 0/5] Device Bus support for Marvell EBU SoC Ezequiel Garcia
2013-04-08 11:06 ` [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus driver Ezequiel Garcia
2013-04-08 17:19 ` Jason Gunthorpe
2013-04-08 19:15 ` Arnd Bergmann
2013-04-09 0:42 ` Ezequiel Garcia
2013-04-09 9:40 ` Arnd Bergmann
2013-04-09 10:34 ` Ezequiel Garcia [this message]
2013-04-09 10:44 ` Arnd Bergmann
2013-04-09 11:00 ` Ezequiel Garcia
2013-04-09 16:00 ` Jason Gunthorpe
2013-04-09 16:03 ` Jason Gunthorpe
2013-04-09 20:28 ` Ezequiel Garcia
2013-04-08 11:06 ` [PATCH v4 2/5] ARM: mvebu: Add Device Bus support for Armada 370/XP SoC Ezequiel Garcia
2013-04-08 11:06 ` [PATCH v4 3/5] ARM: mvebu: Add support for NOR flash device on Armada XP-GP board Ezequiel Garcia
2013-04-08 11:06 ` [PATCH v4 4/5] ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board Ezequiel Garcia
2013-04-08 11:06 ` [PATCH v4 5/5] ARM: mvebu: Add Device Bus and CFI flash memory support to defconfig Ezequiel Garcia
2013-04-08 14:17 ` [PATCH v4 0/5] Device Bus support for Marvell EBU SoC Arnd Bergmann
2013-04-08 15:29 ` Ezequiel Garcia
2013-04-08 18:30 ` Jason Cooper
2013-04-08 19:10 ` Jason Cooper
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=20130409103445.GA2268@localhost \
--to=ezequiel.garcia@free-electrons.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 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.