From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: "grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org"
<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
"swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org"
<swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
"lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org"
<lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>,
"nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Pawel.Moll-5wv7dgnIgG8@public.gmane.org"
<Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC] early init and DT platform devices allocation/registration
Date: Fri, 28 Jun 2013 12:38:27 +0200 [thread overview]
Message-ID: <20130628103826.GA17680@mithrandir> (raw)
In-Reply-To: <20130628.114915.1341075505557760886.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]
On Fri, Jun 28, 2013 at 10:49:15AM +0200, Hiroshi Doyu wrote:
> Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote @ Wed, 26 Jun 2013 12:03:20 +0200:
>
> > On Wed, Jun 26, 2013 at 7:00 AM, Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > > Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote @ Tue, 25 Jun 2013 19:52:33 +0200:
> > >
> > >> > Here's my workaround. I need to call of_detach_node() with OF_DYNAMIC
> > >> > to avoid duplicated device registration.
> > >>
> > >> Gah! my eyes!
> > >>
> > >> Don't do that. It is incredibly problematic. Look at inhibiting
> > >> duplicate device creation instead.
> > >
> > > I may not follow this thread correctly, but could anyone point out the
> > > above "inhibiting duplicate device creation" if there's already such
> > > solution?
> >
> > No, the solution doesn't exist yet, but it wouldn't be hard to
> > implement. What you need to do is to add a struct device pointer to
> > struct device_node, and set the pointer to the struct device when
> > of_platform_device_create creates a device. (it would also need to be
> > set for early_platform_device creation, but that's not something that
> > should affect you). You would also add a check to
> > of_platform_device_create to check if the device pointer is already
> > set. If it is, then skip creation of the device.
>
> Implemented as Grant suggested. At least this works for our case,
> where IOMMU needs to be instanciated earlier than other device[1].
> early_platform_device case still need to be covered.
I think we arrived at a different conclusion in another branch of this
thread. With the patch below every driver needs to explicitly allocate
the platform device and set the struct device_node's .dev field, which
has other side-effects such as the device hierarchy getting messed up.
A better alternative would be to have of_platform_populate() run early
such that the .dev field in the struct device_node can be set by core
code, which would not require every driver to be changed.
I'm not sure exactly what needs to be done to make this work, however.
Grant, can you provide some guidance here as to how this may be fixed?
Where would we have to call of_platform_populate() from and what makes
this break with the current implementation?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-06-28 10:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-24 16:33 [RFC] early init and DT platform devices allocation/registration Lorenzo Pieralisi
[not found] ` <20130624163340.GB26084-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-06-25 11:45 ` Grant Likely
[not found] ` <CACxGe6sPaV-sBz=SF46KdUexjAhWKGrMpG_ty+K26f6ZU5iKdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-25 14:56 ` Stephen Warren
[not found] ` <51C9AF96.3040107-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-06-25 16:36 ` Hiroshi Doyu
[not found] ` <20130625.193628.2143557800560690024.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-06-25 17:52 ` Grant Likely
[not found] ` <CACxGe6t9ifg9VRfXKypuhie3pXVPneZqcBy+J1bFpUaUx32P7g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-26 6:00 ` Hiroshi Doyu
[not found] ` <20130626.090030.1519009485651154440.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-06-26 10:03 ` Grant Likely
[not found] ` <CACxGe6te2RzFb6nkSZQFrzVX4fkQo4pyzLJ1D7Lf=440mE+jyg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-26 10:31 ` Thierry Reding
2013-06-26 11:04 ` Grant Likely
2013-06-26 12:44 ` Sebastian Hesselbarth
[not found] ` <51CAE235.1000807-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-06-26 13:12 ` Grant Likely
[not found] ` <CACxGe6u=BfnbwmS=7X5eYqKuSkmGdu9v-StAx+m7fLd+8C69pA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-27 9:26 ` Thierry Reding
2013-06-28 8:49 ` Hiroshi Doyu
[not found] ` <20130628.114915.1341075505557760886.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-06-28 10:38 ` Thierry Reding [this message]
2013-06-28 12:27 ` Grant Likely
[not found] ` <CACxGe6vkM+awN94kU2GYfbXPdR=MgYwr=PbqmtD+=i5vmuVSnA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-15 14:23 ` Thierry Reding
2013-06-25 17:07 ` Lorenzo Pieralisi
[not found] ` <20130625170700.GB28654-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-06-26 6:20 ` Magnus Damm
[not found] ` <CANqRtoTVoLHLvhknpKW4th6wDM1EgY4GTx96OrM-yA42+Sm1aw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-26 9:32 ` Lorenzo Pieralisi
2013-06-25 16:53 ` Lorenzo Pieralisi
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=20130628103826.GA17680@mithrandir \
--to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=Pawel.Moll-5wv7dgnIgG8@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org \
--cc=magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.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).