Date: Mon, 02 Oct 2006 13:42:04 -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.134204.-749250271.imp@bsdimp.com> In-Reply-To: <200610021403.50339.john@baldwin.cx> References: <200610021323.50997.john@baldwin.cx> <20061002.113954.756907493.imp@bsdimp.com> <200610021403.50339.john@baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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...
: > This specific problem will never happen in pc98, since there are no
: > ACPI pc98 machines and can never be.
:
: Yeah, but I can cleanup the stuff in ACPI a good bit if I can get it
: to stop peeking at the "real" resource to get the bus tag. Also, I
: think fixing this would be important for a driver that wanted to
: sub-alloc its resources out to children (like vgapci, which
: currently cheats on that).
Good point. I don't dispute this is a good thing, just that it will
solve a problem we're currently having. Given the push for embedded,
this is a problem worth solving.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061002.134204.-749250271.imp>