On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote:
This works...but certainly is weaker with respect to
standardization. My previous argument had the assumption
that something like mac-address in a network node was
_required_, and thus needed a class id of some sort to tie
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, October 31, 2007 12:06 PM
To: Yoder Stuart-B08248
Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
Subject: Re: RFC: replace device_type with new class property?
On Wed, Oct 31, 2007 at 08:31:02AM -0700
Explicitly specifying what device class bindings / conventions the
node complies with is cute, but not actually all that useful in
practice. If it looks like a duck class device node, and it
quacks^Whas the properties of a duck class device node, it's duck
class compliant.
Don't know how
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
mpic: [EMAIL PROTECTED] {
clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 4 4;
compatible = fsl,xyz;
big-endian;
}
Note-- I
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, October 30, 2007 11:34 AM
To: Yoder Stuart-B08248
Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
Subject: Re: RFC: replace device_type with new class property?
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder
On 10/30/07, Yoder Stuart-B08248 [EMAIL PROTECTED] wrote:
Another good reason for device_type-- it helps
distinguish between two similar classes of devices.
Both open-pic and isa-pic look very similar but
have different encodings of their interrupt cells.
Without a device_type it may be
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
Explicitly specifying what device class bindings / conventions the
node complies with is cute, but not actually all that useful in
practice. If it looks like a duck class device node, and it
quacks^Whas the properties
On Tue, Oct 30, 2007 at 12:06:33PM -0700, Yoder Stuart-B08248 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, October 30, 2007 11:34 AM
To: Yoder Stuart-B08248
Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
Subject: Re: RFC: replace device_type
On Tue, Oct 30, 2007 at 07:56:33AM -0700, Yoder Stuart-B08248 wrote:
[snip]
Yeah.. what he said.
The *only* substantive change with the class proposal is the fact
that multiple classes can be specified. That's nice, but I don't
think it's worth the trouble of attempting to define a
Yoder Stuart-B08248 wrote:
We've had some discussions internally here at Freescale among
various PPC Linux developers about the device_type property
and how 'classes' of devices should be represented in the
device tree.
The initial list of official classes would be small--
cpu,memory,
Scott wrote:
Personally, I'm fine with just using name and compatible, but others such as
Stuart have expressed a desire for something to formally indicate compliance
with a standard binding. I don't think we should expand the use of
device_type in any case.
I agree that the existing
Scott Wood wrote:
On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote:
I think device_type, compatible and model properties fulfil
this already, they simply aren't being used correctly.
device_type has a few drawbacks, though:
1. You can only specify one type, whereas with a new
Matt Sealey wrote:
Scott Wood wrote:
On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote:
I think device_type, compatible and model properties fulfil this
already, they simply aren't being used correctly.
device_type has a few drawbacks, though:
1. You can only specify one type,
Dale Farnsworth wrote:
Scott wrote:
Personally, I'm fine with just using name and compatible, but others such as
Stuart have expressed a desire for something to formally indicate compliance
with a standard binding. I don't think we should expand the use of
device_type in any case.
I agree
Matt Sealey wrote:
I don't see how this makes anything any better.
Under Open Firmware, if device_type is display, then it had better
act as a display through the client interface, interpose it's framebuffer
methods properly and suchlike.
In FDT, what is the purpose of the binding but to
Here's an example of what I'm trying to get at-- take
a node from a FSL device tree. The ideas I've heard
for expressing the class are like this--
#1 don't express any class at all:
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth;
model = UCC;
device-id = 3;
Yoder Stuart-B08248 wrote:
Here's an example of what I'm trying to get at-- take
a node from a FSL device tree. The ideas I've heard
for expressing the class are like this--
#1 don't express any class at all:
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth;
model =
On Mon, Oct 29, 2007 at 07:37:04AM -0700, Yoder Stuart-B08248 wrote:
We've had some discussions internally here at Freescale among
various PPC Linux developers about the device_type property
and how 'classes' of devices should be represented in the
device tree.
Taking a long term view,
-Original Message-
From: Wood Scott-B07421
Sent: Monday, October 29, 2007 2:44 PM
To: Yoder Stuart-B08248
Cc: Matt Sealey; Dale Farnsworth; Linuxppc-dev@ozlabs.org
Subject: Re: RFC: replace device_type with new class property?
Yoder Stuart-B08248 wrote:
Here's an example
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote:
#4 use compatible
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth,[official spec],network;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent =
On Mon, Oct 29, 2007 at 11:11:40AM -0500, Scott Wood wrote:
On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote:
I think device_type, compatible and model properties fulfil
this already, they simply aren't being used correctly.
device_type has a few drawbacks, though:
1. You can
On Mon, Oct 29, 2007 at 10:27:24AM -0700, Dale Farnsworth wrote:
Scott wrote:
Personally, I'm fine with just using name and compatible, but others such as
Stuart have expressed a desire for something to formally indicate compliance
with a standard binding. I don't think we should expand
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote:
Here's an example of what I'm trying to get at-- take
a node from a FSL device tree. The ideas I've heard
for expressing the class are like this--
#1 don't express any class at all:
[EMAIL PROTECTED] {
On Mon, Oct 29, 2007 at 04:22:13PM -0500, Olof Johansson wrote:
[snip]
I don't see how switching the property name from device_type to
class is going to stop people from misunderstanding it's intended
use. There's nothing inherently more understandable in calling it
class -- it also invites
24 matches
Mail list logo
