From: Scott Wood <scottwood@freescale.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] Add of_platform_device_scan().
Date: Wed, 04 Oct 2006 14:33:38 -0500 [thread overview]
Message-ID: <45240C92.6010006@freescale.com> (raw)
In-Reply-To: <200610041837.47317.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 04 October 2006 18:32, Scott Wood wrote:
>
>>What I'd really like (long-term, of course) is if platform_device and
>>of_device were merged, with device tree support (or at least a means of
>>passing on properties that *could* come from a device tree without
>>special glue code that knows about each property) in arch-neutral code;
>>the mechanism for discovering devices ideally shouldn't depend on the
>>CPU's instruction set.
>
>
> My guess is that this won't happen, because other architectures
> normally don't describe their platform devices in a way that is
> anywhere near what we have on powerpc.
They wouldn't need to, unless they want to support a driver that
requires it. It would simply be an architecture-neutral mechanism for
attaching a dynamic list of properties and OF-compatible matching
criteria (or more generally the ability to match on any set of dynamic
properties) to platform devices; the source of the platform data could
choose to use it to represent an OF device tree, to supply a few
properties needed by a specific driver, or not at all.
Ideally, users of static structure-based platform data would gradually
migrate to dynamic properties, but there's a benefit to the integration
even if they don't. The main issue that I forsee being a problem is
clashing with another standard for the naming and content of properties.
There could be tagging to indicate which standard is being followed by
a given property, but that could lead to some ugliness in drivers that
need to support more than one if the differences can't be easily
abstracted by get-me-this-piece-of-information accessor functions (or by
code that generically converts properties from one standard to
another, which is similar to what we've already got in fsl_soc.c, but
hopefully less device-specific).
-Scott
prev parent reply other threads:[~2006-10-04 19:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-03 22:56 [PATCH] Add of_platform_device_scan() Scott Wood
2006-10-03 23:18 ` Arnd Bergmann
2006-10-04 16:32 ` Scott Wood
2006-10-04 16:37 ` Arnd Bergmann
2006-10-04 19:33 ` Scott Wood [this message]
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=45240C92.6010006@freescale.com \
--to=scottwood@freescale.com \
--cc=arnd@arndb.de \
--cc=linuxppc-dev@ozlabs.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.