Date: Mon, 27 Nov 2000 17:13:20 -0500 From: Jonathan Chen <jon@spock.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: Warner Losh <imp@village.org>, Bill Paul <wpaul@FreeBSD.ORG>, freebsd-current@FreeBSD.ORG Subject: Re: Getting at cardbus CIS data from inside drivers Message-ID: <20001127171320.D2669@spock.org> In-Reply-To: <200011212028.eALKSk465978@aslan.scsiguy.com>; from gibbs@scsiguy.com on Tue, Nov 21, 2000 at 01:28:46PM -0700 References: <200011211932.MAA36176@harmony.village.org> <200011212028.eALKSk465978@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001127171320.D2669>