From: Benjamin Herrenschmidt <benh@kernel•crashing.org>
To: Matt Sealey <matt@genesi-usa•com>
Cc: Sylvain Munaut <tnt@246tNt•com>,
bbrv@genesi-usa•com, Linux PPC DEV <linuxppc-dev@ozlabs•org>,
Paul Mackerras <paulus@samba•org>,
David Woodhouse <dwmw2@infradead•org>
Subject: Re: [PATCH] Probe Efika platform before CHRP.
Date: Mon, 08 Jan 2007 11:37:58 +1100 [thread overview]
Message-ID: <1168216678.22458.95.camel@localhost.localdomain> (raw)
In-Reply-To: <45A17D1A.4050201@genesi-usa.com>
> device_type = "ethernet", well, then it's ethernet. Which kind? Well, it's the
> kind that can only be available on that particular combination of hardware. If
> it is an MPC5200B chip or an MPC5200 chip, you can determine exactly which one
> it is. If it is an MPC8349E or an MPC82xx or something, it may be different,
> but in general you can determine the exact device you have much easier (one
> register comparison..) than running through a null-terminated string list,
> doing comparisons against another list, and you get a wealth of information
> out of that single 32-bit register value of the SVR that you would not from
> a simple name. This is where it differs from PCI devices which you can have
> 10 of them in the same box and need to work out which one came from where, and
> what esoteric combination the user will use. The device tree is simply there
> to inform you what is present and what is configured (especially in the case
> when a unit can be configured as multiple devices and may be dangerous to
> reconfigure) and on an SoC or even a northbridge or southbridge which
> implements "non PCI" devices, you have plenty of options for determining
> exactly what is in them (/builtin/ethernet@1 on Pegasos is the Marvell
> controller, even though we use a chip with 2 ethernet controllers in it,
> only one works - there is no PHY card for the other. However rather
> scarily the option of 1 or 2 ethernet ports in Linux is defined by a
> kernel config flag... so much for the device tree..)
I don't know where to begin to explain how wrong I think you are ...
To simplify, let's say that a device should be represented by a device
node that is pretty much self contained. There should be no need to go
look at anything else (processor node, SVR register, whatever). You
should be able to uniquely identify every device in the system based on
a few properties, and OpenFirmware provides precisely a mecanism to do
so.
This mecanism, is the "compatible" property.
If you look closely at the OF PCI binding (since PCI is one of your
examples), you'll notice that while pciDDDD,VVVV (device,vendor) is at
the beginning of the compatible list, pciCCCC (class) follows.
Again, same logic as explained earlier: you define your device from the
more specific to the more generic.
In many cases, a device programming interface is generic (for example,
the UHCI, OHCI and EHCI USB host controller drivers, on PCI, match based
on the class, not the vendor/device IDs. They only use the later for
identifying a handful a chips that need erratas/quirks, they do NOT have
and do not need a complete list of all the vendor/device ID combinations
for those types of controllers).
That sort of class level matching is also widely used for USB devices.
Thus, the driver -choses- at what level it wants to detect supported
devices, based on that, -and- can still explicitely look at the more
"precise" indentification when it needs to single out a given
revision/version of a piece of hardware.
So this mecanism is great and isn't actually that clumsy at all. What
might eventually be clumsy is purely the naming choice when the vendor
doesn't provide something nice/unique enough for a given part. For
example, in order to properly identify the 52xx "fec" ethernet part,
since we don't have a nice/unique codename for it, we use mpc52xx-fec.
it's good enough and it's our convention.
For PCI devices, the compatible property is defined to be a fairly long
list, which can contain vid/did pairs (and multiple ones as one device
cna be made HW compatible with another one) but goes down to class based
matching which is more useful for well defined programming interfaces.
Strings are perfect, much better than numbers, as long as we properly
define the content of the string.
Ben.
next prev parent reply other threads:[~2007-01-08 0:39 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-19 6:23 Bug fixes for 2.6.20 Paul Mackerras
2006-12-19 9:54 ` [PATCH] Probe Efika platform before CHRP David Woodhouse
2006-12-19 11:39 ` Benjamin Herrenschmidt
2006-12-19 11:55 ` Sylvain Munaut
2006-12-19 14:29 ` David Woodhouse
2006-12-19 15:46 ` Grant Likely
2006-12-19 19:58 ` Benjamin Herrenschmidt
2006-12-19 22:33 ` Sylvain Munaut
2007-01-02 21:29 ` David Woodhouse
2007-01-02 21:37 ` Benjamin Herrenschmidt
2007-01-02 22:04 ` David Woodhouse
2007-01-02 23:04 ` Grant Likely
[not found] ` <45A01416.6080401@genesi-usa.com>
2007-01-06 22:23 ` Grant Likely
2007-01-06 23:13 ` David Woodhouse
2007-01-06 23:37 ` Grant Likely
2007-01-07 2:55 ` Sylvain Munaut
2007-01-07 9:11 ` Raquel Velasco and Bill Buck
2007-03-31 13:15 ` David Woodhouse
2007-03-31 13:18 ` Raquel Velasco and Bill Buck
2007-03-31 13:21 ` David Woodhouse
2007-05-09 11:42 ` Olaf Hering
2007-05-09 11:45 ` Raquel Velasco and Bill Buck
2007-01-07 20:09 ` Matt Sealey
2007-01-07 20:24 ` Segher Boessenkool
2007-01-07 22:10 ` Matt Sealey
2007-01-07 22:35 ` Benjamin Herrenschmidt
2007-01-07 22:35 ` Sylvain Munaut
2007-01-07 23:04 ` Segher Boessenkool
2007-01-07 23:07 ` Matt Sealey
2007-01-07 23:38 ` Sylvain Munaut
2007-01-08 0:37 ` Benjamin Herrenschmidt [this message]
2007-01-07 22:32 ` Matt Sealey
2007-01-07 22:39 ` Matt Sealey
2007-01-07 23:27 ` Segher Boessenkool
2007-01-07 21:16 ` Benjamin Herrenschmidt
2007-01-08 2:17 ` David Woodhouse
2007-01-08 9:18 ` Matt Sealey
2007-01-08 12:52 ` Sylvain Munaut
2007-01-08 13:16 ` Sylvain Munaut
2007-01-08 17:25 ` Matt Sealey
2007-01-08 15:44 ` Sylvain Munaut
2007-01-08 17:25 ` Matt Sealey
2007-01-08 17:24 ` Matt Sealey
2007-01-08 17:59 ` Sylvain Munaut
2006-12-19 19:02 ` [PATCH] powerpc export rtas_set_slot_reset() Linas Vepstas
2006-12-19 22:08 ` Brian King
2006-12-19 19:06 ` [PATCH] powerpc fixup error message Linas Vepstas
2006-12-19 20:00 ` [PATCH] powerpc initialize pci device channel state Linas Vepstas
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=1168216678.22458.95.camel@localhost.localdomain \
--to=benh@kernel$(echo .)crashing.org \
--cc=bbrv@genesi-usa$(echo .)com \
--cc=dwmw2@infradead$(echo .)org \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=matt@genesi-usa$(echo .)com \
--cc=paulus@samba$(echo .)org \
--cc=tnt@246tNt$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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