devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Sebastian Hesselbarth
	<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
	<nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org"
	<lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>,
	"Pawel.Moll-5wv7dgnIgG8@public.gmane.org"
	<Pawel.Moll-5wv7dgnIgG8@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>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC] early init and DT platform devices allocation/registration
Date: Thu, 27 Jun 2013 11:26:13 +0200	[thread overview]
Message-ID: <20130627092612.GB13562@mithrandir> (raw)
In-Reply-To: <CACxGe6u=BfnbwmS=7X5eYqKuSkmGdu9v-StAx+m7fLd+8C69pA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]

On Wed, Jun 26, 2013 at 02:12:06PM +0100, Grant Likely wrote:
> On Wed, Jun 26, 2013 at 1:44 PM, Sebastian Hesselbarth
> <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On 06/26/13 12:03, Grant Likely wrote:
> >>
> >> 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.
> >
> >
> > Grant,
> >
> > What about the other way round, i.e. check if there is a device with
> > .of_node pointed to the struct device_node currently at
> > of_platform_device_create?
> >
> > That will avoid adding struct device to struct device_node which you
> > fought against for good reasons.
> 
> The main thing is that it means searching through the entire list of
> platform devices every time a new platform device is created. That
> seems unnecessarily expensive to me.

There's not really much reason to not add a pointer to the struct device
of a device_node because you can already obtain the platform_device by
calling of_find_device_by_node(). That doesn't work early, but if that
gets fixed, then of_find_device_by_node() could also be used. And since
adding a struct device * to device_node is pretty much required to fix
of_platform_device_create() for early, of_find_device_by_node() can be
implemented much more efficiently.

> > Also, I guess of_platform_device_create could be exported and used
> > by anyone who wants to create platform_devices early.
> 
> Yes, but in that case it is probably better for them to call
> of_platform_populate early if of_platform_device_create is fixed to
> support early calling. Then you'd just set up all the devices earlier
> in init, allow drivers that support early probing to do so, and then
> everything else uses the normal initcall path.

I've been bugged by the recent additions in drivers/irqchip lately
because they all rely on only the device_node and therefore none of the
functions that require a struct device can be used. If things can indeed
be fixed to call of_platform_populate() early that would restore a whole
lot of consistency.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2013-06-27  9:26 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 [this message]
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
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=20130627092612.GB13562@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=sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@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).