From owner-freebsd-current Tue Nov 21 22:23:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id E0DD037B4CF; Tue, 21 Nov 2000 22:23:11 -0800 (PST) Received: from aslan (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id eAM6N9473750; Tue, 21 Nov 2000 23:23:09 -0700 (MST) (envelope-from gibbs@aslan.scsiguy.com) Message-Id: <200011220623.eAM6N9473750@aslan.scsiguy.com> To: Warner Losh Cc: Mike Smith , wpaul@FreeBSD.ORG (Bill Paul), freebsd-current@FreeBSD.ORG Subject: Re: Getting at cardbus CIS data from inside drivers In-Reply-To: Your message of "Tue, 21 Nov 2000 21:42:02 MST." <200011220442.VAA39910@harmony.village.org> Date: Tue, 21 Nov 2000 23:23:09 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >In message <200011220427.eAM4RYF00772@mass.osd.bsdi.com> Mike Smith writes: >: No; the CIS parser should know which function it's being called on behalf >: of, and simply elide the tuples that don't relate to that function. > >This isn't always the right thing to do. At least in the 16-bit >world, there are drivers that want to look at the CIS entries for the >other function of the card for various reasons (some of them need to >know what kind of modem is present, iirc, to initalize some things in >a non-standard way, the example was the NetBSD driver mhz, iirc). I >don't wish to preclude that. The ROM BAR is only implemented for function 0 and the ROM contains information for all functions of the chip. So, functions greater than 0 must have the flexibility to activate at least the ROM BAR on function 0 as well as access that region. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message