All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.