linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Matt Sealey <matt@genesi-usa.com>
Cc: Linuxppc-dev@ozlabs.org
Subject: Re: RFC:  replace device_type with new "class" property?
Date: Mon, 29 Oct 2007 14:30:17 -0500	[thread overview]
Message-ID: <472634C9.108@freescale.com> (raw)
In-Reply-To: <47262E36.4030503@genesi-usa.com>

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 report devices? It
> does not really define any interface whatsoever. Having it "conform
> to a standards-compliant binding" by reporting standard,display goes
> in the direction of ignoring the simple fact that most displays act
> and are programmed very differently

In that case, it probably make sense to simply not have a binding for 
displays.

> I would say the same for USB, where standard,usb would be really
> glossing over the simple fact that *all usb controllers should by
> default be created equal*. OHCI does not act any different, and
> UHCI doesn't act any different, in the specification. If the chip
> does weird things, you do not go around revoking it's status as an
> OHCI controller, do you?

If its weird things are sufficiently non-OHCI, yes. :-)
Good luck fitting a CPM USB controller into some *HCI designation.

> As an addendum to Scott's other mail I came up with a good reason to
> give users readable names but standard device_types. Consider 802.11g,
> which may have a name of "wifi"

This is reasonable.

> but since it is a network adapter, have device_type "ethernet".

This is acceptable as existing practice, but "standard,ethernet" would 
be just fine.  And there may be additional properties defined for 
wireless devices, and an additional "standard,wifi" binding could be 
added.  You can't have multiple device_types.

> It is ethernet after all, but users would like to know which it is
> compared with the onboard ethernet, given a list of devices on the OF
> console, without knowing the base addresses of registers.

My preferred solution to this particular problem is a label property, 
that can go beyond ethernet/wifi and say things like "front panel 
ethernet", "back panel ethernet A", "back panel ethernet B", "wireless", 
etc., without taking away name's existing use, and without limiting the 
label to the characters allowed in a node name.

-Scott

  reply	other threads:[~2007-10-29 19:30 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 14:37 RFC: replace device_type with new "class" property? Yoder Stuart-B08248
2007-10-29 15:20 ` Matt Sealey
2007-10-29 16:11   ` Scott Wood
2007-10-29 17:27     ` Dale Farnsworth
2007-10-29 19:02       ` Matt Sealey
2007-10-29 19:30         ` Scott Wood [this message]
2007-10-29 19:34         ` Yoder Stuart-B08248
2007-10-29 19:44           ` Scott Wood
2007-10-29 20:20             ` Yoder Stuart-B08248
2007-10-29 23:03           ` Dale Farnsworth
2007-10-30  0:29           ` David Gibson
2007-10-30  0:26       ` David Gibson
2007-10-29 18:55     ` Matt Sealey
2007-10-29 19:21       ` Scott Wood
2007-10-30  0:23     ` David Gibson
2007-10-29 21:22 ` Olof Johansson
2007-10-30  0:51   ` David Gibson
2007-10-30 14:56     ` Yoder Stuart-B08248
2007-10-30 23:27       ` David Gibson
2007-10-31 15:25         ` Yoder Stuart-B08248
2007-10-31 15:31         ` Yoder Stuart-B08248
2007-10-31 17:06           ` Scott Wood
2007-10-31 18:05             ` Yoder Stuart-B08248
2007-10-31 22:55           ` David Gibson
2007-10-30 16:23     ` Yoder Stuart-B08248
2007-10-30 16:33       ` Scott Wood
2007-10-30 19:06         ` Yoder Stuart-B08248
2007-10-30 19:38           ` Grant Likely
2007-10-30 23:02           ` David Gibson
2007-10-30 22:58       ` David Gibson

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=472634C9.108@freescale.com \
    --to=scottwood@freescale.com \
    --cc=Linuxppc-dev@ozlabs.org \
    --cc=matt@genesi-usa.com \
    /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).