From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Jimmy RUBIN <jimmy.rubin-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>,
Dan JOHANSSON
<dan.johansson-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>,
Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>,
Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Marcus LORENTZON
<marcus.xm.lorentzon-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 09/10] MCDE: Add build files and bus
Date: Wed, 1 Dec 2010 16:39:03 +0100 [thread overview]
Message-ID: <201012011639.03904.arnd@arndb.de> (raw)
In-Reply-To: <20101130234215.GE8521-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
On Wednesday 01 December 2010, Russell King - ARM Linux wrote:
> Right, so saying to ARM developers that they can't submit code which
> adds new static device structures is rather problematical then, and
> effectively brings a section of kernel development to a complete
> standstill - it means no support for additional ARM platforms until
> this issue is resolved. (This "condition" was mentioned by Arnd
> earlier in this thread, and was put in such a way that it was now
> a hard and fast rule.)
At the embedded developer BoF in Cambridge,MA we discussed this
problem quite a bit, and my impression there was that it is a hard
rule indeed, so I said this to the best of my knowledge.
> I feel it would be better to allow the current situation to continue.
> If we start telling people that they can't use statically declared
> devices without first having an alternative, we'll end up with people
> inventing their own individual - and different - solutions to this
> problem, which could actually make the problem harder to resolve in
> the longer term.
Yes, that makes sense. We should probably start thinking about the
migration plan though. There does not seem to be a shortage of
alternatives for registering new platform devices already and once
we can get to agree on how we want it done, we can start mandating
that new drivers do it that way, while we phase out some of the
other ones.
Among the architectures that use platform devices extensively, the
various ways to register them I could find are:
* static platform_register_device:
arm, avr32, frv, mips, m32r, sparc, sh and xtensa
* static platform_add_devices:
arm, blackfin, m68knommu, mips, sh
* dynamic platform_device_register_simple:
m68k, mips, powerpc, sh and x86
* dynamic platform_device_alloc/platform_device_add:
arm, avr32, mips, powerpc, lots of drivers
* dynamic of_platform_bus_probe:
powerpc, microblaze
* dynamic platform_device_register_resndata:
not currently used
I was under the impression that platform_device_register_resndata is
the function that was actually meant to solve this, but there are
exactly zero users of this, except for the
platform_device_register_simple wrapper. The fact that it's currently
not used probably means either that nobody heard about it or that
the interface is lacking in some way and is actually useless for
replacing the static definitions.
Arnd
parent reply other threads:[~2010-12-01 15:39 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20101130234215.GE8521-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
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=201012011639.03904.arnd@arndb.de \
--to=arnd-r2ngtmty4d4@public.gmane.org \
--cc=dan.johansson-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org \
--cc=jimmy.rubin-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marcus.xm.lorentzon-0IS4wlFg1OjSUeElwK9/Pw@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).