From owner-freebsd-current Mon Nov 27 14:14:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from spock.org (cm-24-169-11-24.nycap.rr.com [24.169.11.24]) by hub.freebsd.org (Postfix) with ESMTP id 9FA0637B4CF; Mon, 27 Nov 2000 14:13:44 -0800 (PST) Received: (from jon@localhost) by spock.org serial EF600Q3T-B7F; Mon, 27 Nov 2000 17:13:20 -0500 (EST) (envelope-from jon) Date: Mon, 27 Nov 2000 17:13:20 -0500 From: Jonathan Chen To: "Justin T. Gibbs" Cc: Warner Losh , Bill Paul , freebsd-current@FreeBSD.ORG Subject: Re: Getting at cardbus CIS data from inside drivers Message-ID: <20001127171320.D2669@spock.org> References: <200011211932.MAA36176@harmony.village.org> <200011212028.eALKSk465978@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: telnet/1.1x In-Reply-To: <200011212028.eALKSk465978@aslan.scsiguy.com>; from gibbs@scsiguy.com on Tue, Nov 21, 2000 at 01:28:46PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 21, 2000 at 01:28:46PM -0700, Justin T. Gibbs wrote: > >That's what I mean. You call this, and it will remap the CIS (if it > >has been unmapped), walk it for you and pass you a pointer to each CIS > >entry one at a time to the function you specify. > > > >Warner > > I'd rather have a seek/read interface than have a callback. As I see it, there are several ways this can be implemented, with several issues to consider. 1) How is the information passed? a) callback b) driver code calling cardbus_get_cistuple(dev, tuplenum) 2) When is the information passed? a) before probe (for callback) b) between probe and attach (for callback) c) automatically after attach (for callback) d) when child requests (for either) 3) When is the information read? a) Once when CIS is read and parsed initially by the bridge, and once when it's time to pass the info to child. b) Only once when CIS is read and parsed initially by the bridge. CIS info is stored in malloc'ed kernel memory c) This point may be moot if the cardbus bus does not read CIS, or if the bridge reading/parsing CIS step is delayed. Personally, I am somewhat torn between using callback or not, but I'm leaning more towards using an interface like cardbus_get_cistuple(). The reasoning behind this is that we may not know when, if ever, a driver would need CIS data. It might need this information in the probe code (unlikely for correctly implemented cardbus hardware and driver set, but IMHO we should keep the interface for cardbus and pccard the same, and pccard drivers might need this functionality) Having callbacks before attach that are actually useful might introduce a whole lot of messiness we don't need. As for point 3, I think that we should read the CIS prior to probe or attach of the child driver, and save the information in memory. My reasoning is that we can't be sure whether we can map and read the CIS after the driver is in control. For all we know the hardware might have been put into some mode where CIS reading would be turned off. True a driver programmer can get around that, but why not just stick it in the ivars to begin with? -- (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o) \\\_\ Jonathan Chen jon@spock.org /_/// <____) No electrons were harmed during production of this message (____> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message