Date: Mon, 02 Oct 2006 15:08:12 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: john@baldwin.cx Cc: freebsd-new-bus@freebsd.org Subject: Re: Properly managing sub-allocations Message-ID: <20061002.150812.151470856.imp@bsdimp.com> In-Reply-To: <200610021620.44185.john@baldwin.cx> References: <200610021403.50339.john@baldwin.cx> <20061002.134204.-749250271.imp@bsdimp.com> <200610021620.44185.john@baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200610021620.44185.john@baldwin.cx>
John Baldwin <john@baldwin.cx> writes:
: On Monday 02 October 2006 15:42, M. Warner Losh wrote:
: > In message: <200610021403.50339.john@baldwin.cx>
: > John Baldwin <john@baldwin.cx> writes:
: > : > However, this may break some existing drivers that allocate a BAR,
: > : > peek at its type and then either activate it or allocate another
: > : > BAR... The TAG is valid, but the handle isn't.
: > :
: > : They generally peak at the BAR register itself though, not the value of
: > : rman_get_bustag() though, right?
: >
: > Some do, some get the resource and look at it. There's a lot of
: > variance here. Do you put knowledge of how to decode PCI bars into
: > every driver, or do you let the pci bus take care of it? Since the
: > knowledge is nearly trivial, different people decide differenly. It
: > is still a technique that has been used, and you'll need to be careful
: > to make sure you don't break anything. After all, 0 is a valid I/O
: > tag and it is also the default value...
:
: Err, how can code examine the actual bus tag value of a non-active resource?
: By definition it's set an opaque MD value. You can't compare it against
: SYS_RES_MEMORY for example. On i386 systems it happens to be an int, on some
: other systems (alpha maybe?) I think it can be a pointer to a structure of
: function pointers for the different bus space operations. I don't think any
: MI code should ever be examining the bus tag or handle except to pass them as
: opaque parameters to bus_space_*().
Actually, you are right. I'm confusing success/failure of allocating
a I/O and/or Memory bar with this...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061002.150812.151470856.imp>