Date: Fri, 28 Dec 2007 13:09:11 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: marcelm@juniper.net Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <20071228.130911.84364727.imp@bsdimp.com> In-Reply-To: <20071228.130329.43010549.imp@bsdimp.com> References: <20071228.121213.-494094613.imp@bsdimp.com> <C95AFF48-2C06-40FA-BDB4-C46011EECCF3@juniper.net> <20071228.130329.43010549.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20071228.130329.43010549.imp@bsdimp.com>
"M. Warner Losh" <imp@bsdimp.com> writes:
: In message: <C95AFF48-2C06-40FA-BDB4-C46011EECCF3@juniper.net>
: Marcel Moolenaar <marcelm@juniper.net> writes:
: : On Dec 28, 2007, at 11:12 AM, M. Warner Losh wrote:
: :
: : > If the ocpbus has a table of bus types, what's wrong with having it
: : > directly assign the driver when it ads its children?
: :
: : It violates newbus in that drivers compete for a device.
: : If the bus assigns the driver, then there's no competition
: : possible. The fact that the bus is abstract should not
: : mean that we should change its paradigm.
:
: No it doesn't. There's two kinds of busses in newbus. Those that
: self enumerate based on the hardware present (ie pccard, pci, usb,
: firewire) and then those that are told what's there (oldcard-style
: pccard, pure ISA, I2C, etc). The busses on the SoC more strongly
: resemble the latter than the former. The former busses already are
: enumerated with hints, but the actual mechanism is just a few calls
: that could be replaced with something better.
Just a correction... 'The latter busses already are already..."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071228.130911.84364727.imp>