All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Sealey <matt@genesi-usa.com>
To: Dale Farnsworth <dale@farnsworth.org>
Cc: Linuxppc-dev@ozlabs.org
Subject: Re: RFC:  replace device_type with new "class" property?
Date: Mon, 29 Oct 2007 19:02:14 +0000	[thread overview]
Message-ID: <47262E36.4030503@genesi-usa.com> (raw)
In-Reply-To: <20071029172724.11354.qmail@farnsworth.org>

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 that the existing compatible property is sufficient to do
> what Stuart wants.  All that is required is to define some standard
> bindings and give them well-known names for the compatible property.
> If needed, we could define a prefix that indicates that a compatible
> entry refers to a standards-compliant binding.  For example,
> "standard,network", or "standard,display".  I don't see the benefit
> of creating a new property similar to device_type.

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 (with the glorious exception of
potentially giving it a "compatible" of "vga" - on PCI this is
handled very easily by the PCI class code! Which was exactly my
point..).

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?

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" but since it is a network adapter,
have device_type "ethernet". 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.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

  reply	other threads:[~2007-10-29 19:02 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 [this message]
2007-10-29 19:30         ` Scott Wood
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=47262E36.4030503@genesi-usa.com \
    --to=matt@genesi-usa.com \
    --cc=Linuxppc-dev@ozlabs.org \
    --cc=dale@farnsworth.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.